[Iccrg] proposed Compound TCP review

[[e-mail] (Eddy, Wesley M. (GRC-RCN0)[VZ])]

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.
-------------- next part --------------
In July 2007, the ICCRG began reviewing the Compound TCP
congestion control technique described in
draft-sridharan-tcpm-ctcp-00 in terms of its safety for
widespread experimental deployment on the public Internet.
This review was conducted as an input to the IETF TCPM
working group, where the draft was being considered for
possible Experimental publication.

Based on initial RG comments, an update to the original
internet-draft was published.  Based on further RG comments,
another update is expected that contains several clarifications
(itemized at the end of this document).  This review assumes
that those changes are made.

After reviewing the draft and a number of other documents
with results from testing and simulation, three public
evaluations were submitted to the ICCRG by RG participants.
Several follow-on messages and comments were submitted by
these and other RG participants.  The RG seems to have
consensus that (given the expected draft clarifications)
the Compound TCP mechanism is safe for experimental deployment
on the public Internet.

Its novelty from the current Standards Track congestion control
techniques is that Compound TCP also contains a delay-based
component.  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.  This was noted by some reviewers
as a major inspiration of confidence.  The simulation results
and analysis made available were also helpful, but were not found
to be overwhelmingly convincing.

Expected changes from the 01 draft version:

1. Clarify how RTT samples are captured (1323 or some other filter).

2. Clarify definition of baseRTT. (noted by 2 reviewers)

3. Clarify definition of "round" in dwnd update (is it in terms of
   RTT or cwnd worth of packets).

4. What happens to dwnd during slow-start, and when is slow-start
   exited?

5. Clarify dwnd update parameters and specific values or ranges
   that are safe for use (alpha, beta, eta, k)
   (noted by 3 reviewers)

6. Be precise about clipping dwnd so that it cannot become negative

Public reviews from:
Wesley Eddy (Nov 1, 2007)
Mark Allman (Nov 29, 2007)
Doug Leith (Jan 16, 2008)

additionally, several thread comments from:
Lachlan Andrew
Michael Welzl
Dino-Martin Lopez-Pacheco
>From [e-mail]  Tue Mar  4 17:01:58 2008
From: [e-mail] (Douglas Leith)
Date: Tue Mar  4 17:02:15 2008
Subject: [Iccrg] proposed Compound TCP review
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

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
> [e-mail]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg