[Iccrg] proposed Compound TCP review

[Douglas Leith]

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