[Iccrg] H-TCP I-D feedback from an implementor's perspective

[Lawrence Stewart]

Hi All,

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 [1] for various patches, tools and papers. Thanks also to 
Lachlan Andrew for providing feedback on my feedback!

Questions, comments and discussion welcomed.

Cheers,
Lawrence

http://caia.swin.edu.au

[1] http://caia.swin.edu.au/urp/newtcp/tools.html





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.

##########

General

- 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 
like it).

- 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 
factor", etc.

- I would like to see explicit mention of what to do with ssthresh.

##########

Page 2

- P.1, Duplicate "to".

##########

Page 4

- 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 
other definitions.

- P.5, "...networks of TCP flows..." I think "networks" in this context 
is unfamiliar.

- P.5, Missing a reference for CUBIC (draft-rhee-tcpm-cubic-02.txt 
perhaps?).

- P.5, Should potentially revise wording re CUBIC due to latest CUBIC 
draft's attempt at addressing convergence issues.

##########

Page 6

- 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.

##########

Page 8

- 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.

##########

Page 10

- 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".

##########