Re: [tcpm] Review of draft-ietf-tcpm-initcwnd-04

[Jerry Chu <[e-mail]>]

On Wed, Jul 25, 2012 at 9:11 AM, Mirja Kühlewind
<[e-mail]> wrote:
> Hi Jerry,
>
> I'd say the draft now covers all the points discussed in tcpm and as such has
> all the content needed. As you actually only propose a small change to TCP,
> I'd prefer to have a quite short document describing mainly only the changes
> itself and move most of the reasoning to the appendix.

A document describing only the change can be done, or at least summed up in
one line. But this is not how it is or should be done. We are proposing a small
change to a critical TCP parameter because the impact can be profound. (That's
why we've been wrestling with it for more than 2 years now!) So the
focus is really
on the ramification and justification of the change rather than the
change itself
(which can be summed up in one line). For this reason we've been following the
structure of RFC3390.

Moreover, the TOC provides a very clear index of the contents so a
savvy reader can
quickly pick the sections of interesting. E.g., if you only want to
focus on the change
you'll know to read section 1 and 2 only. That's it.

>Hence I'd like to
> propose quite a little restructuring before moving the document forward as it
> is hard to easily catch the main points at the moment. More concrete, I'd move
> at least section 4, 10 and 11, maybe also 5, 6 and 7 (or at least partly) to
> the appendix. The first two paragraph of section 7 might actually belong in

Yes it's doable but I think the current flow is fine if you realize
the main purpose of
the document is to justify the change, not the change itself. Also TOC
will make it
much easier to navigate through.

> the security consideration section. And section 15 (conclusion) is not needed
> at all. More detailed comments below.
>
> Mirja
>
> =============
> Section 1 Introduction:
> ----------------------------
> - s/roughly 15KB/maxium 14600B/

Ok.

>
> - 2. paragraph: Don't like this two sentences at all. I hope the reason to
> increase IW is not just the fact there the queues are large enough to store 10
> packets. You basically saying "Let's send more packets at once to blow the
> queues!". I'd say the reason is that flow sizes have increased and therefore
> IW10 would improve latency a lot. Only because queues are likely to be large
> than 10 packets today, it is possible at all to send more than 10 packet at
> once. Btw. even if the queue would be small, pacing could help to still allow
> an IW of 10. Moreover, the fact that there might be several concurrent flows,
> does not mean that the buffer has to be larger (only if those flow start at
> the same time with IW10). And even if there is a large buffer, if there is a
> long-lived TCP connection, this flow will fill up the queue and there might
> be by chance still no space in the queue for 10 additional packets.

Guess you read the paragraph differently from what the authors had in mind.
What we have in mind was  "Ten segments are likely to fit into queue space"
because access link drains much faster these days (due to b/w growth)...

Will try to make it more clear.

Will continue later,

Jerry

>
> - 3. paragraph: Don't agree. You might not know that there is a low speed link
> somewhere on the path. There are cases where the endpoint can protect its path
> by setting the receiver window but that's not the general case.
>
> - 5. paragraph: "We recommend that all TCP implementations have a settable TCP
> IW parameter..."
>   -> I'd like to see this not only in the introduction but also in the main
> section (2.) that is describing the changes and maybe even as a SHOULD
>
>
> Section 2 TCP Modifications
> -------------
> - Maybe have a more specific title like "Setting the IW" and some subsections
>
> - equation 1: say somewhere that numbers are in KByte
>
> - 4. paragraph ("Note that...") does not belong in this section
>
> - maybe new subsection for paragraph 5 "Resetting the IW after SYN loss";
>   what are "multiple SYN or SYN/ACK retransmissions" -> maybe say a number
>
> - last paragraph: maybe s/implementations SHOULD fall back/implementations
> MUST fall back/ ?
>
>
> Section 3 Implementation Issues
> -------------
> - Maybe move the 3 paragraph into section 2 such that the setting of the
> receive window is a MUST or SHOULD of the changes to TCP
>
> - 4. paragraph: Please give some explanation (or remove)
>
>
> Section 4 Background
> ------------
> - Move most parts in the appendix
>
> - Move 2. paragraph into Introduction
>
> - Maybe improve structure with subsections e.g. paragraph 5 and 6
> as "Recommendation for HTTP Traffic" or something
>
> - 7. paragraph: "pacing will not be necessary"
>   -> I can't remember having seen any results on this. Please explain further
> or remove!
>
> Section 5 Advantages of a Larger Initial Window
> -----------
> - section 5.1 Reducing Latency
>    You should also mention that for larger transmission with several 100s of
> RTT a save of 4 RTT does not really help. Thus transmissions which will
> finish within a small number of RTT will benefit the most.
>
> - section 5.2
>   You make some quite general statements here and then u only refer to google
> data. Maybe you can find some other references as well.
>
> Section 6
> ----------
> - paragraph 3 and 4 belong in an evaluation section/appendix (maybe own
> subsection on "Influence of simultaneous opened connections")
>
> Section 7
> --------
> - Move 1. paragraph to security consideration
>
> - Move rest in appendix or even parts in  the introduction
>
> Section 9
> ----------
> - move to main section which  is introducing the TCP changes as own subsection
> as a MUST is in here
>
> - can you explain better why this is need or what would happen otherwise?
>
> Section 10
> ----------
> - Move to appendix, have more subsections and better titles for the
> subsections e.g. "Improvements in Latency", "Impact on the Retransmission
> Rate" and "Multiple TCP Connections"
>
> - The numbers for the latency improvement are only on (google) web search. Of
> course there are quite large improvements possible but the Internet contains
> also other traffic. Not sure if your number are really that significant...?
>
> Section 11
> ---------
> - move to appendix
>
> - It's nice that you list all the studies. Could you please quickly summarize
> their results/findings, too? Because I guess that the intersting part to
> know.
>
> Section 12
> --------
> - Its good to have this section but it's quite unspecific. E.g. you say "An
> increased initial window MUST NOT be turned on by default on systems without
> such monitoring capabilities." But what exactly should be monitored and how
> frequently and so on. Also "any significant deterioration" doesn't say
> anything to me. Is it possible to have a concrete approach/algorithm here
> what to monitor when and what to do in which cases? And than have this even
> as part of the main section with TCP changes as this section has also some
> SHOULD and MUST and might be overread otherwise.
>
> Section 14
> ---------
> - "highly unlikely to lead to a persistent state of network congestion" ->
> Even a "highly unlikely" is concerning me in this case! Also there is no
> reasoning for this. But I guess you can even say, that this change cannot
> cause persistent network congestion as congestion control is still used....
>
> Section 15 Conclusion
> --------
> - Is not needed here at all, as no new information
>
> Appendix
> ---------
> - "One notable exception is YouTube because we don't think
>      the large initial window will have much material impact, either
>      positive or negative, on bulk data services."
>   -> Why is this document than not recommending to NOT use IW10 for bulk data
> services?
>
> - "[CW10] contains some result from a testbed study on how short flows
>      with a larger initial window might affect the throughput
>      performance of other co-existing, long lived, bulk data transfers."
>    -> Please also describe what the results are!
>
> - paragraph on "Why 10 segment?"
>   -> This is something I would prefer to have in the body of the document not
> in the appendix
>
> - "Some simulation studies [JNDK10, JNDK10-1] have been conducted to
>      study the effect of a larger initial window on wireless links from
>      2G to 4G networks (EGDE/HSPA/LTE). The overall result seems mixed
>      in both raw performance and the fairness index."
>   -> Should it be recommend to not use IW10 in wireless scenarios (if known)?