[Iccrg] review of Compound TCP draft
weddy@grc.nasa.gov (weddy@grc.nasa.gov) Thu, 01 November 2007 15:24 UTC
From: weddy@grc.nasa.gov
Date: Thu, 01 Nov 2007 15:24:06 +0000
Subject: [Iccrg] review of Compound TCP draft
Message-ID: <20071101152220.GB16742@grc.nasa.gov>
X-Date: Thu Nov 1 15:24:06 2007
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] review of Compound TCP draft Lachlan Andrew
- [Iccrg] review of Compound TCP draft weddy@grc.nasa.gov
- [Iccrg] review of Compound TCP draft Douglas Leith
- [Iccrg] review of Compound TCP draft Lachlan Andrew
- [Iccrg] review of Compound TCP draft Murari Sridharan
- [Iccrg] review of Compound TCP draft weddy@grc.nasa.gov
- [Iccrg] review of Compound TCP draft Lachlan Andrew