[Iccrg] review of Compound TCP draft

[Murari Sridharan]

Thanks for taking time to review. I'll revise draft based on input from you and Lachlan. I see your point on the usefulness of the implementation section I will try and strengthen it better with details on how we decide how many samples to take etc.

"One thought, that might be fruitless:  Given the delay-based component,
is CTCP increasingly vulnerable to ACK-spoofing attacks in comparison
to normal TCP?"

Can you clarify the exact attack here. Are you suggesting that if somebody (in the middle) can inject ACKs in the window it might make things worse since our RTT samples are skewed to be much smaller and as a result we might increase aggressively thinking there is no congestion? If so why is this a problem only to delay based algorithms I think any high-speed algorithm that is ack clocked is equally vulnerable.

Thanks
Murari

-----Original Message-----
From: iccrg-bounces at cs.ucl.ac.uk [mailto:iccrg-bounces at cs.ucl.ac.uk] On Behalf Of weddy at grc.nasa.gov
Sent: Thursday, November 01, 2007 8:22 AM
To: iccrg at cs.ucl.ac.uk
Subject: [Iccrg] review of Compound TCP draft

Here is a review I did of the Compound TCP draft, submitted just as a
normal participant in the group (not as co-chair), of the recently
submitted draft version (draft-sridharan-tcpm-ctcp-01).

Short Review:

The document's intended status is Experimental, for use on the open
Internet.  Based on looking at both the draft and several other
references, I think this is appropriate.  However, the draft on its own
may not have enough information on the exact parameter values (or
ranges) that should be used as guidance to implementers.  I specifically
refer to the dwnd formula on page 7; gamma is discussed at some length,
but alpha, beta, eta, and k are less well explained.  Since I believe
the authors can easily fix this in an updated draft by discussing the
particular values used in their implementations (which have shown
themselves to be very safe, in my opinion), I think this is a rather
minor issue.


Longer Review:


1) minor/editorial comment, in the abstract:

I know what is meant, but the phrase "gracefully reduces" is not quite
right, I think.  It might be better as "proactively reduces".

2) minor/editorial comment:

There's a missing linebreak between the last paragraph of the Introduction
and the heading for "2. Design Goals" at the top of page 5.

3) minor/editorial in section 2:

"the network resource and" -> "the network's resources and" ?

4) in section 2:

The logic is incomplete behind saying HSTCP "is now an experimental IETF
RFC" and using that alone to justify basing CTCP's agressiveness on
HSTCP.  I believe, what you want to say is that HSTCP hasn't been known
to exhibit severe issues in deployment or testing experiences, and
*that's* what makes it a reasonable baseline, NOT that it's an RFC.

5) minor/editorial in section 3:

"the delay component is effective" ->
"the delay component is only activated" ?

6) clarity in section 3 on basertt:

"It is continually measured and updated to track changing network
conditions."

I think you should say something more like it tracks the minimum RTT
sample observed over the course of the connection, or something more
specific than the current sentence alone?

7) "actual" throughput in section 3:

Since this is computed based on SRTT (an estimate itself from the
EWMA), is this really "actual", or "estimated actual" ... not overly
important, just a matter of confusion on my part.

8) clarity in section 3 on dwnd parameters:

Need more data on values/ranges for alpha, beta, eta, and k, I think.
It seems possible that poor selections could influence CTCP's
friendliness, though I have not analyzed this.

9) section 5 - windows measured in bytes, not packets

There is much discussion of window components in terms of packets in
this section: "estimating the backlogged packets", "30 packets", etc. in
this section.  There needs to be some mention of conversion between
number of packets and number of bytes, since the window is in bytes (say
based on MSS).  A couple of sentences could clarify this.

10) praise:

Section 6 on "implementation issues" is excellent, and a good addition,
even though it might not be strictly needed to understand the protocol.
It may be somewhat proprietary, but I think it would be helpful if you
could give just slightly more information on the number of RTT samples
that's kept.  I'm curious whether poor tuning of this could
significantly influence performance or fairness, and since I believe
your implementation to be quite well-behaved, it's a good basis for
others to parameterize from.

11) section 7: bytes/packets

"Only when the congestion window is greater than 38 packets" should
be 38 MSS ?

12) Security Considerations

One thought, that might be fruitless:  Given the delay-based component,
is CTCP increasingly vulnerable to ACK-spoofing attacks in comparison
to normal TCP?

13) references

Should the INFOCOM paper be normative?

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