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

[Jerry Chu <[e-mail]>]

On Wed, Jul 25, 2012 at 11:12 AM, Mirja Kuehlewind
<[e-mail]> wrote:
> Hi Jerry,
>
> just one quick comment:
>
>> 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.
> And that's not really true (anymore). There are several SHOULD and MUST in the
> other sections as well. Thus you have to read all the doc to correctly
> implement the changes. I know that the intent was to have everything in
> section 1 and 2 that is of interest for implementers but due to the many
> changes that have been done in previous versions, it's not the case anymore.

Actually the only other specification related languages is section 9,
and it's not
essential as it simply reiterates what is described in rfc6298.

Yes other SHOULD and MUST can be found in the newly added section 12
"Usage and Deployment Recommendations", but that section is mainly about
what one must do in any future large scale experiment, closely monitoring a
number of key metrics... and not really about protocol specification.

So to summarize, this draft is not just about protocol specification,
it also addresses
many other questions like why, and how to go about doing more
experiments safely.

> That why I said, all the content is there, would be nice to
> clean-up/restructure a little and then it's done.
>
> It's good to have a similar structure than RFC3390 (didn't realize that you
> tried to have exactly the same sections here) but if the content would fit

It was spelled out up front in 1.  Introduction

   "This document proposes to raise the upper bound on TCP's initial
   window (IW) to 10 segments or roughly 15KB. It is patterned after and
   borrows heavily from RFC 3390 [RFC3390] and earlier work in this
   area."

> better with a different structure, I'd prefer to have a good readable doc
> over having a doc that looks similar to RFC3390.

Let's stick to the current format but I will respond to your one other
criticism on
section 12 first. The section is quite specific about the metrics to monitor: "A
key metric to monitor is the rate of packet losses, ECN marking, or
segment retransmissions during the initial burst." But as others have
pointed out it can be
quite difficult to try to get more specific than that, i.e., how much
performance
deteriorates before one must back off. As such all we can do for now is to have
enough warning signs for now but leave some details for future investigation.

Jerry

>
> Mirja
>
>
>>
>> >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)?
>
>
>
> --
> -------------------------------------------------------------------
> Dipl.-Ing. Mirja Kühlewind
> Institute of Communication Networks and Computer Engineering (IKR)
> University of Stuttgart, Germany
> Pfaffenwaldring 47, D-70569 Stuttgart
>
> tel: [phone]
> email: [e-mail]
> web: www.ikr.uni-stuttgart.de
> -------------------------------------------------------------------