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

[Jerry Chu <[e-mail]>]

On Mon, Aug 13, 2012 at 1:39 PM, Mirja Kuehlewind
<[e-mail]> wrote:
> Hi Jerry,
>
> I still believe restructuring the document would help to make it better
> readable but I'm okay to keep the same structure than RFC 3390. Please check
> if all paragraph are actually in the right section or more subsection are
> needed to improve readability. Someone who wants to implement the change
> might not read the whole document and might very easy overread any
> SHOULDs/MUSTs in any later section than section 3. Maybe it is an option to
> add a reference to the later SHOULDs/MUSTs  in section 2?

Like I said the only other sections containing specification related
language are
section 9 and section 12. Since section 12 has been mentioned prominently
in the Introduction, I'm adding a reference to section 9 at the end of section 2
per your suggestion.

>
> Regarding the comments below. You several times named a reference to
> slides/papers/mails instead of actually addressing my comment in the draft. I

I don't understand. When did I name any reference not already in the
draft in order
to address your comments on the draft, and why would I do that if the discussion
here is about the text of the draft itself, not about further debating on IW10?

The only case I can possibly think of wrt this was your question about TCP
SACK. Frankly I don't remember the content of the email discussion but it was
studied as part of [CW10] as mentioned in the draft.

> know where to find the information as I've been following the discussion. But
> someone who later reads the document, might not have followed mail discussion
> or ieft slides. Thus you really should add the references in the document or

Again the draft is self-contained. All the references are included. I
think you've
asked repeatedly to expand the links, i.e., to provide a summary of each
study/paper/report... But I felt we've done enough. Interesting
readers can always
follow the references provided by the draft to find all the info.

I will submit an updated draft soon.

Jerry

> even better, explain the outcome better in the document such that the
> references are not need anymore.
>
> Mirja
>
>
> On Wednesday 01 August 2012 07:32:31 Jerry Chu wrote:
>> On Wed, Jul 25, 2012 at 2:58 PM, Jerry Chu <[e-mail]> wrote:
>> > 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.
>>
>> This is exactly the point - it's not the general case but may be the
>> vast majority.
>> I.e., 95% of severely b/w limited hosts may be just 1 hop away or even
>> directly attached to a slow link (e.g., dailup modem) hence can be
>> mitigated much easily. No one suggested a solution here to solve the
>> general problem of
>> detecting bottleneck
>> b/w. That's the job TCP's CC algorithm.
>>
>> >>> > - 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
>>
>> Plagiarized from RFC3390 :)
>>
>> >>> > - equation 1: say somewhere that numbers are in KByte
>>
>> Not really.
>>
>> >>> > - 4. paragraph ("Note that...") does not belong in this section
>>
>> Why not? (It's more or less a disclaim because no one has done any study
>> on non-Ethernet MTU.
>>
>> >>> > - maybe new subsection for paragraph 5 "Resetting the IW after SYN
>> >>> > loss"; what are "multiple SYN or SYN/ACK retransmissions" -> maybe
>> >>> > say a number
>>
>> Ok. Changed to "more than one".
>>
>> >>> > - 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
>>
>> Non-essential. Remember even IW10 is just an upperbound.
>>
>> >>> > - 4. paragraph: Please give some explanation (or remove)
>>
>> This was brought up and discussed on the list long ago.
>>
>> >>> > 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
>>
>> See my other response. I prefer not to change the structure at this time.
>>
>> >>> > - 7. paragraph: "pacing will not be necessary"
>> >>> >   -> I can't remember having seen any results on this. Please explain
>> >>> > further or remove!
>>
>> The statement was really "We suspect" pacing will not be necessary because
>> our test results do not show any severe congestion from IW10...
>>
>> >>> > 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.
>>
>> Isn't it obvious already?
>>
>> >>> > - 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.
>>
>> It's not just google data (see all the refs.)
>>
>> >>> > 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
>>
>> Non-essential because it simply restates what is said in rfc6298. It was
>> added to address some concern (or confusion) that was brought up in the
>> past that the initial burst of 10 pkts won't bid well for RTO hence causing
>> spurious rexmits.
>>
>> >>> > - 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...?
>>
>> We just stated what we have.
>>
>> >>> > 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.
>>
>> If you are interested please go read them yourself.
>>
>> >>> > 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....
>>
>> See 1st paragraph of section 7.
>>
>> >>> > Section 15 Conclusion
>> >>> > --------
>> >>> > - Is not needed here at all, as no new information
>>
>> Most rfcs have a conclusion section for those who have time only for
>> the 1st and last sections.
>>
>> >>> > 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?
>>
>> Why should it recommend NOT? How would the TCP stack know apriori bulk
>> or not? So it will require input from the apps... Is it really worth
>> the complexity?
>>
>> >>> > - "[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!
>>
>> Read the slides please.
>>
>> >>> > - 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)?
>>
>> Studies are still on-going. I don't remember there has been a conclusive
>> result.
>>
>> Jerry
>>
>> >> --
>> >> -------------------------------------------------------------------
>> >> 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
>> >> -------------------------------------------------------------------
>
>
>
> --
> -------------------------------------------------------------------
> 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
> -------------------------------------------------------------------