[Iccrg] H-TCP I-D feedback from an implementor's perspective
lastewart at swin.edu.au
Tue Oct 13 01:57:03 BST 2009
Finally got around to writing up an initial review of the H-TCP draft.
Apologies to those who have been waiting a long time for this. As part
of the NewTCP research project I'm involved with, we independently
implemented H-TCP for FreeBSD, and a lot of the feedback stems from that
experience. Anyone interested in experimental TCP work should have a
look at  for various patches, tools and papers. Thanks also to
Lachlan Andrew for providing feedback on my feedback!
Questions, comments and discussion welcomed.
All comments below relate to draft-leith-tcp-htcp-06.txt. Some of the
general comments in particular are also relevant to a number of other
congestion control algorithm drafts.
P.X refers to paragraph X on that page.
- What is a packet? An SMSS sized segment? An average sized segment?
Need to somehow acknowledge stacks that are not packet based.
- Perhaps have a note explaining that parts of the algorithm defined in
external papers are explicitly not included in the draft (reason why not
overly important, but feel free to provide an explanation if you feel
- Could break out a number of discussion points into an implementer's
section? I'd also like to see a public domain code snippet in the draft
that demonstrates fixed point math calculation of f_alpha.
- Does appropriate byte counting and/or delayed ack change the dynamics
of the algorithm?
- How often should alpha be evaluated? Does the answer change with
respect to above point about ABC and/or delayed ack?
- "Cubic" => "CUBIC" throughout.
- Streamline uses of "Beta" vs "Backoff factor" vs "mult. decrease
factor". Ditto for alpha/additive increase/increase factor.
- Need somewhere to define terms e.g. AIMD, cwnd, "mult. decrease
- I would like to see explicit mention of what to do with ssthresh.
- P.1, Duplicate "to".
- P.1, Duplicate "to".
- P.4, "...this proposal also increases the multiplicative decrease
factor..." reads like you're referring to the H-TCP proposal.
- P.4, "increasing the multiplicative decrease factor to increase
aggressiveness" is confusing if interpreted as "increasing the factor by
which we multiplicatively decrease". Consider revising.
- P.4, Move note defining multiplicative decrease elsewhere with some
- P.5, "...networks of TCP flows..." I think "networks" in this context
- P.5, Missing a reference for CUBIC (draft-rhee-tcpm-cubic-02.txt
- P.5, Should potentially revise wording re CUBIC due to latest CUBIC
draft's attempt at addressing convergence issues.
- P.1, "...an increasing function of flow cwnd..." is somewhat ambiguous
(instantaneous value of cwnd? No, but could read like that) and possibly
misleading. CUBIC for example uses time since congestion as well as a
memory of the previous value of cwnd at congestion. Consider revising.
- P.1, Should probably note that CUBIC uses time since congestion as well.
- P.1, "...increase the aggressivness of the AIMD increase..." poorly
worded sentence with lots of "increase". Consider revising.
- P.2, RFC2591 is the wrong reference. RFC2581 is probably what you meant.
- P.3, I suspect providing a reference to a document that explores
reasoning for the Delta_L value would be a good idea. A value of 1
second will seem long to people who want to push the envelope with a
high speed algorithm like H-TCP i.e. you should show some good
reasoning/theory/results so that people won't second guess you.
- P.2, I believe there is a standard definition of friendliness (needs a
citation), but more fundamentally, do we really care about friendliness
in such a spec? Ditto for responsiveness and efficiency.
- P.2 "This an indication..."
- P.4, Meaning and relevance of the last sentence re "similar efficiency
gains to standard TCP" is unclear to me. More discussion needed here.
- RTT should perhaps be referred to as RTT_min and some discussion added
to highlight the subtle details/issues (e.g. smoothed/instantaneous RTT,
how long before we can trust RTT estimate, RTT with delayed ACK,
hysteresis for min RTT).
- Formula + P.3, Suggest changing K to rho as in other H-TCP documents.
- P.3, More discussion required re "low speed conditions".
More information about the Iccrg