[Iccrg] proposed Compound TCP review

[Murari Sridharan]

Regarding BaseRTT the effect of that value on the algorithm behavior is fairly deterministic and straightforward.

While dwnd is active (non-zero) and cwnd is still catching up, baseRTT is used to detect congestion. BaseRTT tracks the lowest RTT measured since the last timeout. Again for correctness we don't go by one sample but averaged over a window worth of samples. So reverse path queueing for instance is going to show up as congestion.

Once Cwnd catches up and Dwnd becomes zero then basertt has no real effect since the loss based flow is fully taken over at that point.

I don't understand the security implication, are you talking about optimistic ACKs skewing the baseRTT to be lower than it is? Firstly that attack exists for regular TCP but in our case if we measure the baseRTT to be lower than normal, then any actual sample is only going to make us think that the link is congested. One more thing to note here is that DWND is independent of RTT in the sense that the amount of packets it keeps backlogged in the queue is not a function of RTT so I don't see what the security implications here could be. Also note that RTT samples are taken only at the sender and not based on echoed value from receiver.

Thanks



-----Original Message-----
From: iccrg-bounces at cs.ucl.ac.uk [mailto:iccrg-bounces at cs.ucl.ac.uk] On Behalf Of Douglas Leith
Sent: Tuesday, March 04, 2008 9:02 AM
To: Eddy, Wesley M. (GRC-RCN0)[VZ]
Cc: iccrg
Subject: Re: [Iccrg] proposed Compound TCP review

I'm not so clear about the correctness of the following sentence:

"Compound TCP's design only utilizes the delay-based
component when the loss-rate is low and the congestion window
has been able to grow large already based on the current
Standards Track mechanisms."

As I understand it, the delay based increase action is used whenever
the estimated queueing delay is low.   Since it is a fairly
aggressive increase (similar to HS-TCP) it seems possible that the
delay window can  reach large values even when the loss rate is quite
high (and so the standard Reno cwnd would be relatively low).

If that's correct then the above sentence doesn't seem quite right.
For example under conditions with high loss rates (e.g. due to non-
congestive loss) it might be possible for the delay component to
dominate CTCP behaviour, although I have seen no studies of this.  It
might be worth checking such scenarios in view of the apparent
importance of the above sentence in the stated case for the safety of
CTCP.

I think it might also be useful to include some discussion (at a
minimum it would at leats be worth highlighting that they aren't
covered by this document) of the following issues:

1. The CTCP delay component operates on the basis of *estimated*
queueing delay.  What is the impact, if any, of errors in the
estimated value ?  Reverse path queueing and errors in baseRTT
estimation spring to mind here as possible issues that could create
estimation errors.    Also, Constantine Dovrolis and others have
already highlighted possible sampling issues when trying to use delay
to infer congestion on heavily multiplexed links where delay may be
only weakly correlated with congestion.

2. Operation over wireless.  I've seen no studies of operation over
802.11 wireless, which is ubiquitous as a last hop.  Since its a
random access technology, there is not necessarily a strong
connection between variations in delay and network queue occupancy (I
have some measurements illustrating this).  The baseRTT also varies
with network load (number of contending stations) at a wireless hop
and this might have implications for estimating queueing delay.

3. Security implications of use of delay.   The use of a new
measurement for congestion control immediately raises concerns about
security.  Can the measurement be spoofed, or otherwise manipulated
to create an advantage ?  Does it create new avenues for denial of
service attack etc ?   If delay is measured via packet time-stamps it
seems pretty likely that a receiver could do all sorts of interesting
things by manipulating the timestamp echoed back to the sender.    I
reckon this can be addressed by using delay measurements derived at
the sender side only (this is now done in Linux for example, and may
well be already done in Vista although I haven't seen it stated
anywhere), but it seems worth a comment and perhaps a little more
thought.

Lastly, I don't know how people fell about this but it might well be
worth prefacing the review with some statement of terms of
reference.  At the moment the review seems to focus on safety and
suitability for release as an experimental RFC.    That's fine but an
obvious question is should there be any comment on performance or
likely benefits to be gained from use of the algorithm ?  If not (and
I guess this will be the case) it might be a good idea to state up
front that analysis of performance benefits is out of scope for this
document, to avoid potential misunderstandings in the future.


Doug

Prof. Douglas Leith
Hamilton Institute
www.hamilton.ie




On 4 Mar 2008, at 16:07, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:

> Attached is a proposed RG review of the Compound TCP draft that we
> were
> asked to consider the safety of for experimental deployment on the
> Internet,
> on behalf of TCPM.
>
> We had several mails on-list about this in recent months, and now that
> discussion has slowed down, I believe we may be ready to close on this
> and submit an official RG review to TCPM.  Please review the attached
> text
> for accuracy, and comment on it.  I drafted it with help from the list
> archives, and believe it captures a consensus that the RG has at a
> high-level.
>
> Replies via email that either support this, or suggest clarifications,
> improvements, or fixes are welcomed at this time.  I also set aside
> time during the Philadelphia meeting that we can use to discuss or
> revise this in real-time face-to-face.  Also, let us know if it is
> wildly inaccurate or doesn't capture your individual concerns at a
> high-level.  Thanks for your help.<ctcp-
> review.txt>_______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg


_______________________________________________
Iccrg mailing list
Iccrg at cs.ucl.ac.uk
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg