[Iccrg] proposed Compound TCP review

[Murari Sridharan]

Just to clarify the value 38 for triggering dwnd comes from the low_window idea proposed in HighSpeed TCP which corresponds to a packet drop rate of 10^-3.

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

For the delay window (scalability component) to kick in following conditions have to be met. CWnd >= roughly 38 packets or 57000 bytes && CWnd >= SsThresh

-----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

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