[tsvwg] Fwd: RE: [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest

[Bob Briscoe <[e-mail]>]

Hannes,

Brainfart - sorry. for 'CoDel's 100ms target', read 5ms.

Still crazy for hi-speed.


Bob

>Date: Thu, 11 Oct 2012 17:06:57 +0100
>To: "Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>
>From: Bob Briscoe <[e-mail]>
>Subject: RE: [tsvwg] [REVISED I-D]: Document writeup for 
>draft-ietf-tsvwg-byte-pkt-congest
>Cc: ext Manner Jukka <[e-mail]>, 
><[e-mail]>, <[e-mail]>, 
><[e-mail]>, tsvwg IETF list <[e-mail]>
>
>Hannes,
>
>This doc is very general. The advice on AQM not biasing for small 
>packets applies equally to CoDel as to RED (it has already been 
>applied to PCN, which is another AQM). The doc gives specific advice 
>for RED as an exemplar, but it's not just about RED (it's worrying 
>that you think it is - which text gave this impression?). Everywhere 
>that RED is mentioned, the wording should carefully say it's an example.
>
>Similarly, it gives guidelines on end-to-end transports, and uses 
>TCP as an concrete example.
>
>[Changing the subject to "Who said CoDel is a panacea anyway?" CoDel 
>isn't really applicable on hi-speed links, certainly not if one 
>wants the main benefit of being insensitive to the chosen hard-coded 
>parameters. Even in the CoDel paper's simulations, CoDel gave higher 
>queuing delay than RED in all the cases shown except the lowest link 
>speed experiments. CoDel's 100ms target would be a crazy delay 
>target in a high speed network. To deploy CoDel in hi-speed 
>networks, you have to tune the parameters away from the hard-coded 
>ones, which loses the only benefit it has.
>]
>
>
>Bob
>
>At 13:57 11/10/2012, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>>Hi Jukka,
>>
>>With QoS there is no such thing as "short term" (as we already had to
>>learn painfully).
>>
>>That makes me wonder what is more useful: publish a document that
>>describe how to configure RED correctly or to go for an AQM technique
>>that (according to the authors) works almost zero configuration.
>>
>>My take-away from the Vancouver congestion control workshop was that it
>>is better to ignore RED. (Maybe my impression was wrong -- someone else
>>should confirm.)
>>
>>Ciao
>>Hannes
>>
>>
>> > -----Original Message-----
>> > From: ext Manner Jukka [mailto:[e-mail]]
>> > Sent: Thursday, October 11, 2012 3:50 PM
>> > To: Tschofenig, Hannes (NSN - FI/Espoo)
>> > Cc: Bob Briscoe; <[e-mail]>; <[e-mail]>;
>> > <[e-mail]>; tsvwg IETF list
>> > Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-
>> > tsvwg-byte-pkt-congest
>> >
>> > Hi, this document talks about the current and short term goals and
>> > operations, while AFAIK CoDel is a more futuristic concept,
>>interesting
>> > concept, sure, but not deployed at large.
>> >
>> > cheers,
>> > Jukka
>> >
>> > On Oct 11, 2012, at 3:44 PM, Tschofenig, Hannes (NSN - FI/Espoo)
>>wrote:
>> >
>> > > Hi Jukka, Hi Bob,
>> > >
>> > > having listened to the presentations about CoDel I am wondering
>> > whether
>> > > this document may have taken over by events and is obsolete by now.
>> > > What's your view on that?
>> > >
>> > > Ciao
>> > > Hannes
>> > >
>> > >
>> > >> -----Original Message-----
>> > >> From: [e-mail] [mailto:[e-mail]] On
>> > Behalf
>> > >> Of ext Manner Jukka
>> > >> Sent: Thursday, October 11, 2012 3:34 PM
>> > >> To: Bob Briscoe
>> > >> Cc: <[e-mail]>; <[e-mail]>; <tsvwg-
>> > >> [e-mail]>; tsvwg IETF list
>> > >> Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for
>>draft-ietf-
>> > >> tsvwg-byte-pkt-congest
>> > >>
>> > >> Hi,
>> > >>
>> > >> Yeah, please at the point about cheap devices, still, I wonder what
>> > > the
>> > >> cost of AQM is on those devices. Maybe 1 cnt in mass production?
>> > Thus,
>> > >> I still wonder if it is worth arguing something about the future
>> > that
>> > >> strongly.
>> > >>
>> > >> Sorry, but the same goes for AQM in general, and where it is, or
>> > will
>> > >> not be deployed. I understand technical reasons why not something
>>is
>> > >> feasible, but business or monetary reasons can change very quickly.
>> > ;)
>> > >>
>> > >> Jukka
>> > >>
>> > >> On Oct 11, 2012, at 3:08 PM, Bob Briscoe wrote:
>> > >>
>> > >>> Jukka,
>> > >>>
>> > >>> What I had in mind is all low level buffers in cheap pure L2
>> > > devices,
>> > >> in cheap NATs etc. I was going to list some of these, but instead
>> > > chose
>> > >> to say "no-one expects AQM to be universally deployed". This
>>clearly
>> > >> missed the mark.
>> > >>>
>> > >>> Should we include some of these concrete examples of where AQM
>> > won't
>> > >> be deployed instead?
>> > >>>
>> > >>> [I've cc'd the list, given we're starting to wordsmith
>> > significantly
>> > >> new text added since WG last call.]
>> > >>>
>> > >>>
>> > >>> Bob
>> > >>>
>> > >>> At 20:04 10/10/2012, Manner Jukka wrote:
>> > >>>> Hi, looked good to me. Just one comment, I wouldn't put that much
>> > >> emphasis on what is a probably state of things, e.g.
>> > >>>>
>> > >>>> "no-one expects AQM to ever be .."  > in the future it might, we
>> > >> don't know, and since the paragraph says that it doesn't matter
>> > > anyway,
>> > >> I would formulate this paragraph a bit towards that we have partial
>> > >> deployment now and  even with a full deployment, ...
>> > >>>>
>> > >>>> and similarly with the unrealistic deployment of AQM in the
>> > >> subsequent paragraph.
>> > >>>>
>> > >>>> cheers,
>> > >>>> Jukka
>> > >>>>
>> > >>>> On Oct 10, 2012, at 6:25 PM, Bob Briscoe wrote:
>> > >>>>
>> > >>>>> Phil,
>> > >>>>>
>> > >>>>> Sorry for delay, my round-robin scheduler is taking so long to
>> > > get
>> > >> round all the tasks that I keep finding dead robins (that reminds
>>me
>> > > of
>> > >> a bike ride my grandmother took. On her return, she said there were
>> > a
>> > >> worryingly large number of robins run over on the roads. It turned
>> > out
>> > >> that she had been going round the same small triangle of roads
>> > > multiple
>> > >> times).
>> > >>>>>
>> > >>>>> I've done a complete re-write of 3.4. I hope you will agree that
>> > >> it really is a motivating argument now and it can stay where it is
>>-
>> > > it
>> > >> is not just a preamble.
>> > >>>>>
>> > >>>>> I've gone back to the very first version of 3.4 I wrote and I
>>now
>> > >> realise that I had written the core of the argument so badly that
>> > even
>> > >> I forgot what it was meant to say when we started editing it. In
>>the
>> > >> draft-08 version, the original meaning is lost and in your re-
>> > wording
>> > >> it is entirely lost. The link with the draft-08 version is nearly
>> > >> unrecognisable, but it's the argument I intended here.
>> > >>>>>
>> > >>>>>
>> > >>
>> > >
>> >
>>=======================================================================
>> > >> ===============
>> > >>>>> 3.4.  Permanent Partial Deployment of AQM
>> > >>>>>
>> > >>>>> In overview, the argument in this section runs as follows:
>> > >>>>> * Because the network will not and cannot always drop packets in
>> > >> proportion to their size, it shouldn't be given the task of making
>> > > drop
>> > >> signals depend on packet size at all.
>> > >>>>> * Transports on the other hand don't always want to make their
>> > >> rate response proportional to the size of dropped packets, but if
>> > they
>> > >> want to, they always can.
>> > >>>>>
>> > >>>>> The argument is similar to the end-to-end argument that says
>> > >> "Don't do X in the network if end-systems can do X by themselves,
>> > and
>> > >> they want to be able to choose whether to do X anyway." Actually
>>the
>> > >> following argument is stronger; in addition it says "Don't give the
>> > >> network task X that could be done by the end-systems, if X won't
>> > ever
>> > >> be deployed on all network nodes, and end-systems won't be able to
>> > > tell
>> > >> whether their network is doing X, or whether they need to do X
>> > >> themselves." In this case, the X in question is "making the
>>response
>> > > to
>> > >> congestion depend on packet size".
>> > >>>>>
>> > >>>>> We will now re-run this argument taking each step in more depth.
>> > >> The argument applies solely to drop, not ECN marking.
>> > >>>>>
>> > >>>>> A queue drops packets for either of two reasons: a) to signal to
>> > >> host congestion controls that they should reduce the load and b)
>> > >> because there is no buffer left to store the packets. Active queue
>> > >> management tries to use drops as a signal for hosts to slow down
>> > (case
>> > >> a) so that drop due to buffer exhaustion (case b) should not be
>> > >> necessary.
>> > >>>>>
>> > >>>>> No-one expects AQM to ever be universally deployed in every
>>queue
>> > >> in the Internet; and, even if AQM were universal, it has to be able
>> > to
>> > >> cope with buffer exhaustion (by switching to a behaviour like tail-
>> > >> drop), in order to cope with unresponsive or excessive transports.
>> > >> Therefore networks will often be dropping packets as a last resort
>> > >> (case b) rather than under AQM control (case a).
>> > >>>>>
>> > >>>>> When buffers are exhausted (case b), they don't naturally drop
>> > >> packets in proportion to their size. The network can only reduce
>>the
>> > >> probability of dropping smaller packets if it has enough space to
>> > > store
>> > >> them somewhere while it waits for a larger packet that it can drop.
>> > If
>> > >> the buffer is exhausted, it does not have this choice. Admittedly
>> > > tail-
>> > >> drop does naturally drop somewhat fewer small packets, but exactly
>> > how
>> > >> few depends more on the mix of sizes than the size of the packet in
>> > >> question. Nonetheless, in general, if we wanted networks to do
>>size-
>> > >> dependent drop, we would need universal deployment of (packet-size
>> > >> dependent) AQM code, which is unrealistic.
>> > >>>>>
>> > >>>>> A host transport cannot know whether any particular drop was a
>> > >> deliberate signal from an AQM or a sign of a queue shedding packets
>> > > due
>> > >> to buffer exhaustion. Therefore, because the network cannot
>> > > universally
>> > >> do size-dependent drop, it should not do it all.
>> > >>>>>
>> > >>>>> Whereas universality is desirable in the network, diversity is
>> > >> desirable between different transport layer protocols - some, like
>> > >> NewReno TCP [RFC5681], may not choose to make their rate response
>> > >> proportionate to the size of each dropped packet, while others will
>> > >> (e.g. TFRC-SP [RFC4828]).
>> > >>>>>
>> > >>
>> > >
>> >
>>=======================================================================
>> > >> ===============
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>> Bob
>> > >>>>>
>> > >>>>> At 13:13 04/10/2012, [e-mail] wrote:
>> > >>>>>> That would be brilliant!
>> > >>>>>>
>> > >>>>>> Gorry
>> > >>>>>>
>> > >>>>>>> Will try to look at this later today.
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>> Bob
>> > >>>>>>>
>> > >>>>>>> At 10:42 02/10/2012, [e-mail] wrote:
>> > >>>>>>>> Think the token is with bob
>> > >>>>>>>>
>> > >>>>>>>> Re your comment - yes, I think you could move 3.4 to the end
>> > > of
>> > >> S3 -
>> > >>>>>>>> or to the start - and do some re-phrasing, maybe something
>> > > like
>> > >> I tried.
>> > >>>>>>>>
>> > >>>>>>>> -----Original Message-----
>> > >>>>>>>> From: Manner Jukka [mailto:[e-mail]]
>> > >>>>>>>> Sent: 01 October 2012 20:18
>> > >>>>>>>> To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,Bob,DUB8 R
>> > >>>>>>>> Cc: [e-mail]; Gorry Fairhurst
>> > >>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for
>> > >>>>>>>> draft-ietf-tsvwg-byte-pkt-congest
>> > >>>>>>>>
>> > >>>>>>>> Phil, Bob, can we close this finally? It's three weeks now
>> > >> since
>> > >>>>>>>> this previous message.
>> > >>>>>>>>
>> > >>>>>>>> Jukka
>> > >>>>>>>>
>> > >>>>>>>> On Sep 10, 2012, at 4:42 PM, Jukka Manner wrote:
>> > >>>>>>>>
>> > >>>>>>>>> Ack, I'm getting there...;)
>> > >>>>>>>>>
>> > >>>>>>>>> So, we could move 3.4 at the end of Section 3 and rephrase
>> > >> it to
>> > >>>>>>>> not talk about scaling per se, but rather about how Req 2.2
>> > >>>>>>>> eventually leads to Req 2.3?
>> > >>>>>>>>>
>> > >>>>>>>>> Jukka
>> > >>>>>>>>>
>> > >>>>>>>>> On Sep 7, 2012, at 4:07 PM, <[e-mail]>
>> > >>>>>>>>> <[e-mail]> wrote:
>> > >>>>>>>>>
>> > >>>>>>>>>> 3.4 is, in my mind, completely different from 3.1, 3.2,
>> > > 3.3
>> > >> and 3.5.
>> > >>>>>>>>>>
>> > >>>>>>>>>> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for
>> > >> Recommendation
>> > >>>>>>>>>> 2.2 & a lesser extent 2.3
>> > >>>>>>>>>> 3.4 makes doesn't make a motivating argument - it explains
>> > >> that  Rec
>> > >>>>>>>>>> 2.2 & 2.3 come as a pair (if you recommend one, then
>> > >> inevitably you
>> > >>>>>>>>>> recommend the other) (delta some politeness about TCP)
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>> -----Original Message-----
>> > >>>>>>>>>> From: Manner Jukka [mailto:[e-mail]]
>> > >>>>>>>>>> Sent: 07 September 2012 13:24
>> > >>>>>>>>>> To: Eardley,PL,Philip,DUB8 R
>> > >>>>>>>>>> Cc: Briscoe,RJ,Bob,DUB8 R; <[e-mail]>;
>> > >>>>>>>>>> <[e-mail]>
>> > >>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for
>> > >>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest
>> > >>>>>>>>>>
>> > >>>>>>>>>> Hi, I'm trying to follow your reasoning, with little luck.
>> > >> ;)
>> > >>>>>>>>>>
>> > >>>>>>>>>> After having read Section 3 again, I could think of a few
>> > >>>>>>>> updates, but I'm not fully following what you want to see:
>> > >>>>>>>>>>
>> > >>>>>>>>>> - S3.5 is kind of small and lonely by itself. It could be
>> > >> either
>> > >>>>>>>> longer or merged somewhere. Not a major issue though and
>> > > could
>> > >> remain as
>> > >>>>>>>> is.
>> > >>>>>>>>>>
>> > >>>>>>>>>> - S3.3: Yes, probably could be turned upside down, good
>> > >> first,
>> > >>>>>>>> bad later. Don't have a strong opinion.
>> > >>>>>>>>>>
>> > >>>>>>>>>> - S3.4: Here the scaling is used many times and in the
>> > >> title,
>> > >>>>>>>> although we talk about the end host side. This could be
>> > >> rephrased
>> > >>>>>>>> and slightly reworded to talk about hosts and their operation
>> > >>>>>>>> altogether. Also the word scaling can turn the readers
>> > >> expectation
>> > >>>>>>>> into the wrong direction.
>> > >>>>>>>>>>
>> > >>>>>>>>>> - S3 altogether: It would help to have introductory text
>> > >> about
>> > >>>>>>>> networks vs. end host side, but I fail to see why  (& how) to
>> > >>>>>>>> restructure everything.
>> > >>>>>>>>>>
>> > >>>>>>>>>> cheers,
>> > >>>>>>>>>> Jukka
>> > >>>>>>>>>>
>> > >>>>>>>>>> On Sep 6, 2012, at 6:18 PM,
>> > >>>>>>>> <[e-mail]>  <[e-mail]> wrote:
>> > >>>>>>>>>>
>> > >>>>>>>>>>> Ps otherwise Bob's comments are fine, though I suggest
>> > > for
>> > >> S3.5 you
>> > >>>>>>>>>>> give more context (ie are you knocking down what you
>> > >> recommend
>> > >>>>>>>>>>> against, or building up what you recommend?)  and in S3.3
>> > >> think
>> > >>>>>>>>>>> would be better if you re-structured slightly [first talk
>> > >> about what
>> > >>>>>>>>>>> you like - penult para + 1st sentence of last para - then
>> > >> talk about
>> > >>>>>>>>>>> what you don't like - rest of text]
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> From: Eardley,PL,Philip,DUB8 R
>> > >>>>>>>>>>> Sent: 06 September 2012 16:12
>> > >>>>>>>>>>> To: Briscoe,RJ,Bob,DUB8 R; Manner Jukka
>> > >>>>>>>>>>> Cc: [e-mail]; Gorry Fairhurst
>> > >>>>>>>>>>> Subject: RE: [REVISED I-D]: Document writeup for
>> > >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> Thanks bob. Have now re-booted some state.
>> > >>>>>>>>>>> I don't like S3.4. My basic problem with it is that it
>> > >> isn't a
>> > >>>>>>>> "motivating argument" (S3 title). It's an explanation about
>> > >> the
>> > >>>>>>>> consequences of assuming either [option 1] do pkt-size
>> > > biasing
>> > >> in
>> > >>>>>>>> the transport; [option 2]; do pkt-size biasing in the nw.
>> > >>>>>>>>>>> Perhaps your effort to buy peace with those who won't
>> > >> change
>> > >>>>>>>> TCP has obfuscated the basic point?
>> > >>>>>>>>>>> The title of S3.4 (Scaling...) and the early text
>> > > "scaling
>> > >>>>>>>> argument" suggests that you're going to argue there is some
>> > >> reason
>> > >>>>>>>> why X scales as order N rather than N^2 or something like
>> > > that
>> > >> -
>> > >>>>>>>> which isn't what S3.4 is about.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> I actually think it would be better to put S3.4 at the
>> > >> start of
>> > >>>>>>>> S3 - it's background where you say there are 2 options. After
>> > >> that,
>> > >>>>>>>> you can explain the reasons why option 1 [pkt biasing in the
>> > >>>>>>>> transport] is better - the reasons being:-  S3.1 (security
>> > > etc
>> > >>>>>>>> attacks if small pkts get preferential treatment), S3.2
>> > >> (really a
>> > >>>>>>>> side note to S3.1; ie doesn't really present a "motivating
>> > >>>>>>>> argument"), S3.3 (nw guessing MTU vs transport knowing pkt
>> > >> size),
>> > >>>>>>>> S3.5 (easier implementation).
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> Something like...
>> > >>>>>>>>>>> The behaviour of the network and transport together needs
>> > >> to
>> > >>>>>>>>>>> alleviate congestion. We assume the network is bit-
>> > >> congestible
>> > >>>>>>>> (currently packet-congestible resources are rate). Therefore
>> > >>>>>>>> overall the response of the {network + transport} should be
>> > >> the
>> > >>>>>>>> same for the same congestion - whether the congestion is
>> > >> caused by
>> > >>>>>>>> a lot of small packets or a smaller number of larger packets.
>> > >> The
>> > >>>>>>>> implication is that the transport's behaviour should depend
>> > > on
>> > >>>>>>>> whether the network takes account (or not) of packet size
>> > > when
>> > >> it
>> > >>>>>>>> generates congestion indications:- Case 1: If the network
>> > >>>>>>>> implements packet-mode drop, ie its algorithm treats all
>> > >> packets
>> > >>>>>>>> equally regardless of their size, then the transport should
>> > >> take
>> > >>>>>>>> account of the size of the packet - in other words, the
>> > >> transport's
>> > >>>>>>>> congestion response should depend on the number of dropped
>> > >> bytes.
>> > >>>>>>>>>>> Case 2: If the network implements byte-mode drop, ie its
>> > >>>>>>>> algorithm treats packets differently depending on their size,
>> > >> then
>> > >>>>>>>> the transport should not take account of the size of the
>> > >> packet -
>> > >>>>>>>> in other words, the transport's congestion response should
>> > >> depend
>> > >>>>>>>> on the number of dropped packets.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> These cases are explained in more detail in sub-section
>> > >> below.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> In both cases the same discussion applies if packets are
>> > >>>>>>>> ECN-marked rather than dropped.
>> > >>>>>>>>>>> In the following sections we explain why Case 1 is
>> > >> preferable,
>> > >>>>>>>> and hence why we make the Recommendations of S2.2 and S3.3
>> > >>>>>>>> (respectively, drop/mark pkts equally regardless of their
>> > >> size, and
>> > >>>>>>>> the strength of the transport's response should be
>> > >> proportionate to
>> > >>>>>>>> the size of the dropped/marked pkt).
>> > >>>>>>>>>>> Note that TCP responds to dropped or marked packets,
>> > > which
>> > >> differs
>> > >>>>>>>>>>> from our recommendation for transports. However, we are
>> > >> not
>> > >>>>>>>>>>> recommending that TCP  should be changed; to date it
>> > >> hasn't been a
>> > >>>>>>>>>>> significant problem because most TCP implementations
>> > > have
>> > >> been
>> > >>>>>>>> used with similar packet sizes. But we do recommend that
>> > >> future
>> > >>>>>>>> transport protocols should  respond to dropped or marked
>> > > bytes
>> > >> (as
>> > >>>>>>>> for example TFRC-SP [RFC4828]effectively does).
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> Sub-section
>> > >>>>>>>>>>> You could use much of S3.3, I suggest supplement with
>> > >> numerical
>> > >>>>>>>>>>> examples continuing S1.2
>> > >>>>>>>>>>> --
>> > >>>>>>>>>>> << This gives a get-out clause to any transport that
>> > > isn't
>> > >>>>>>>>>>> packet-size dependent (e.g. current TCP). Lacking packet-
>> > >> size
>> > >>>>>>>>>>> dependence just means they don't scale correctly with
>> > >> packet size -
>> > >>>>>>>>>>> but they are at liberty not to scale with packet size
>> > >> (particularly
>> > >>>>>>>>>>> given MTU growth isn't often being used to increase link
>> > >> rates at
>> > >>>>>>>>>>> this stage in history).>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> This is introducing a different point. it's saying that
>> > >> your
>> > >>>>>>>> recommendation 2 [drop/mark pkts equally regardless of their
>> > >> size]
>> > >>>>>>>> is a really strong reco whilst recommendation 3 [strength of
>> > >>>>>>>> transport's response proportionate to the size of the
>> > >>>>>>>> dropped/marked pkt] is a much less important reco.  I can see
>> > >> this
>> > >>>>>>>> might be true, but I don't think the i-d talks about this.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> --
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> From: Briscoe,RJ,Bob,DUB8 R
>> > >>>>>>>>>>> Sent: 05 September 2012 16:41
>> > >>>>>>>>>>> To: Manner Jukka
>> > >>>>>>>>>>> Cc: [e-mail]; Gorry Fairhurst;
>> > >> Eardley,PL,Philip,DUB8 R
>> > >>>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for
>> > >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> Jukka,
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> I've repeated Phil's suggestions as quoted email then
>> > > made
>> > >> some
>> > >>>>>>>> alterations.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> Phil asked me to send this, then he will think about it.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> I'll respond about John Leslie's argument next...
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> 2.2. Recommendation on Encoding Congestion Notification
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> [...]
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> 1.  AQM algorithms such as RED SHOULD use packet-mode
>> > >> drop, ie they
>> > >>>>>>>>>>>     SHOULD NOT use byte-mode drop. The latter is more
>> > >> complex,
>> > >>>>>>>>>>>     it creates the perverse incentive to fragment
>> > >> segments into
>> > >>>>>>>> tiny
>> > >>>>>>>>>>>     pieces and it is vulnerable to floods of small
>> > >> packets.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> 2.  If a vendor has implemented byte-mode drop, and an
>> > >> operator has
>> > >>>>>>>>>>>     turned it on, it is RECOMMENDED to turn it off,
>> > > after
>> > >>>>>>>> establishing
>> > >>>>>>>>>>>     if there are any implications on the relative
>> > >> performance of
>> > >>>>>>>>>>>     applications using different packet sizes.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>     RED as a whole SHOULD NOT be turned off. Without
>> > > RED,
>> > >> a drop
>> > >>>>>>>> tail
>> > >>>>>>>>>>>     queue biases against large packets
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> [BB adds]:                                 and it is
>> > >> vulnerable to
>> > >>>>>>>> floods
>> > >>>>>>>>>>>      of small-packets.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> (I suggest the last para just qualifies item 2. It
>> > > doesn't
>> > >> warrant
>> > >>>>>>>>>>> another item number.)
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> <Agree with Phil; Don't indent "Note well...">
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> [PE:] S3.3
>> > >>>>>>>>>>> The section could be slightly clearer. Starting with the
>> > >> second
>> > >>>>>>>> para, where you start talking about something you don't
>> > >> recommend
>> > >>>>>>>> (ie you have to remember that you're talking about the
>> > >> consequences
>> > >>>>>>>> of not following your recommendation).
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> 3.3 Transport-Independent Network
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> TCP congestion control ensures that flows competing for
>> > >> the same
>> > >>>>>>>>>>> resource each maintain the same number of segments in
>> > >> flight,
>> > >>>>>>>>>>> irrespective of segment size.  So under similar
>> > >> conditions, flows
>> > >>>>>>>>>>> with different segment sizes will get different
>> > > bit-rates.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> [OLD:]
>> > >>>>>>>>>>> One motivation for the network biasing congestion
>> > >> notification by
>> > >>>>>>>>>>> packet size is to counter this effect and try to equalise
>> > >> the bit-
>> > >>>>>>>>>>> rates of flows with different packet sizes.
>> > >>>>>>>>>>> [SUGGESTED:]
>> > >>>>>>>>>>> To counter this effect it seems tempting not to follow
>> > >> our
>> > >>>>>>>>>>> recommendation,  and instead for the network to bias
>> > >> congestion
>> > >>>>>>>>>>> notification by  packet size in order to equalise the
>> > > bit-
>> > >> rates of
>> > >>>>>>>>>>> flows with different  packet sizes.
>> > >>>>>>>>>>> [CONTINUE AS BEFORE:]
>> > >>>>>>>>>>>               However, in order to do  this, the queuing
>> > >> algorithm
>> > >>>>>>>>>>> has to make assumptions about the  transport, which
>> > > become
>> > >> embedded
>> > >>>>>>>>>>> in the network.  Specifically:
>> > >>>>>>>>>>> [...]
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> S3.3
>> > >>>>>>>>>>> o  The queuing algorithm has to assume how aggressively
>> > >> the
>> > >>>>>>>> transport
>> > >>>>>>>>>>>    will respond to congestion (see Section 4.2.4).  If
>> > >> the network
>> > >>>>>>>>>>>    assumes the transport responds as aggressively as TCP
>> > >> NewReno,
>> > >>>>>>>> it
>> > >>>>>>>>>>>    will be wrong for Compound TCP and differently wrong
>> > >> for Cubic
>> > >>>>>>>>>>>    TCP, etc.  To achieve equal bit-rates, each transport
>> > >> then has
>> > >>>>>>>> to
>> > >>>>>>>>>>>    guess what assumption the network made, and work out
>> > >> how to
>> > >>>>>>>>>>>    replace this assumed aggressiveness with its own
>> > >> aggressiveness.
>> > >>>>>>>>>>> o  Also, if the network biases congestion notification
>> > > by
>> > >> packet
>> > >>>>>>>> size
>> > >>>>>>>>>>>    it has to assume a baseline packet size--all proposed
>> > >> algorithms
>> > >>>>>>>>>>>    use the local MTU.  Then transports have to guess
>> > >> which link was
>> > >>>>>>>>>>>    congested and what its local MTU was, in order to
>> > > know
>> > >> how to
>> > >>>>>>>>>>>    tailor their congestion response to that link.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> So you're saying that for byte-mode drop, the network
>> > >> element
>> > >>>>>>>> has to compare the size of the current pkt with the MTU, and
>> > >> if
>> > >>>>>>>> it's 25* smaller then reduce the pkt loss probably by 25*?
>> > > And
>> > >> if
>> > >>>>>>>> the MTU was bigger, then the current pkt would be dropped
>> > > with
>> > >>>>>>>> greater probability? And both of these things are hard to do.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> [BB]: SUGGESTED REPLACEMENT to 2nd bullet:
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> o  Also, if the network biases congestion notification
>> > > by
>> > >> packet
>> > >>>>>>>> size
>> > >>>>>>>>>>>    it has to assume a baseline packet size--all proposed
>> > >> algorithms
>> > >>>>>>>>>>>    use the local MTU (for example see the byte-mode loss
>> > >>>>>>>> probability
>> > >>>>>>>>>>>    formula in Table 1).  Then if the non-Reno transports
>> > >> mentioned
>> > >>>>>>>> above
>> > >>>>>>>>>>>    are trying to reverse engineer what the network
>> > >> assumed, they
>> > >>>>>>>> also
>> > >>>>>>>>>>>    have to guess the MTU of the congested link.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> [Aside for Phil: The byte-mode algo uses MTU as its
>> > >> baseline because
>> > >>>>>>>>>>> a link cannot send a packet bigger than its MTU so the
>> > >> algo won't
>> > >>>>>>>>>>> ever give a drop probability >1).]
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> S3.4 (& knock-on effect on 3.3)
>> > >>>>>>>>>>> I think this could be better.
>> > >>>>>>>>>>> I agree with your arguments in S3.1 & 3.2 that dropping
>> > > or
>> > >>>>>>>> marking should be independent of pkt size.
>> > >>>>>>>>>>> You now go into a couple of pages, which I think could be
>> > >> boiled
>> > >>>>>>>>>>> down to a paragraph, saying something like:-
>> > >>>>>>>>>>> * the overall system (network + transport) has to be
>> > >> packet-size
>> > >>>>>>>>>>> dependent in order to drive out the right amount of
>> > >> traffic so the
>> > >>>>>>>>>>> resource becomes uncongested (since we assume all
>> > >> resources are in
>> > >>>>>>>>>>> practice byte rather than packet limited)
>> > >>>>>>>>>>> * from S3.1 and S3.2 the IETF is convinced that the
>> > >> network
>> > >>>>>>>> should notify independent of packet-size.
>> > >>>>>>>>>>> * therefore the transport must act dependent on packet-
>> > >> size.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> It seems to me this is a necessary consequence of your
>> > >> earlier
>> > >>>>>>>> assumptions /arguments.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> [BB:] This isn't at all obvious. Until I worked it
>> > >> through, it
>> > >>>>>>>> wasn't obvious to me. I think it needs to be spelled out.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> [On the other hand, if someone disagrees with the
>> > >> arguments and
>> > >>>>>>>>>>> thinks that the network should notify dependent on
>> > > packet-
>> > >> size, then
>> > >>>>>>>>>>> it follows that the transport can act independent of
>> > >> packet-size.]
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> I think in S3.3 you're trying to make another argument
>> > >> (?):-
>> > >>>>>>>>>>> * we can either do packet-size biasing in the network
>> > >> element or on
>> > >>>>>>>>>>> the end host transport (see argument above)
>> > >>>>>>>>>>> * packet-size biasing in the network is quite tricky,
>> > >> because
>> > >>>>>>>> then both the network element & the transport have to make
>> > >> some
>> > >>>>>>>> guesses about MTU - whereas with packet-size biasing in the
>> > >>>>>>>> transport, neither network element nor transport needs to
>> > > know
>> > >> what the
>> > >>>>>>>> MTU is.
>> > >>>>>>>>>>> * it is also easier to implement packet-size biasing in
>> > >> the
>> > >>>>>>>> transport than in the network.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> [BB] ...and all the other arguments about vulnerability
>> > > to
>> > >>>>>>>> flooding etc, transport-independence etc.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> Our argument is sort of like how Phil summarises it, but
>> > >> with
>> > >>>>>>>> an added nuance. It's also saying no-one has to do
>> > > packet-size
>> > >>>>>>>> biasing anyway. It's not saying "The transport should given
>> > >> the
>> > >>>>>>>> network shouldn't". It's saying "*If the transport wants to
>> > >> claim
>> > >>>>>>>> to be scalable wrt packet size* it should if the network
>> > >> shouldn't".
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> This gives a get-out clause to any transport that isn't
>> > >>>>>>>> packet-size dependent (e.g. current TCP). Lacking packet-size
>> > >>>>>>>> dependence just means they don't scale correctly with packet
>> > >> size -
>> > >>>>>>>> but they are at liberty not to scale with packet size
>> > >> (particularly
>> > >>>>>>>> given MTU growth isn't often being used to increase link
>> > > rates
>> > >> at
>> > >>>>>>>> this stage in history).
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> None of what Phil says convinces me we could say 3.4 (or
>> > >> 3.3)
>> > >>>>>>>> any more briefly or differently. It's easier to summarise
>> > > what
>> > >> you
>> > >>>>>>>> understand having read something. But that's not the same as
>> > >>>>>>>> writing the thing that helped you understand. There doesn't
>> > >> seem to
>> > >>>>>>>> be any argument for why anything needs to be changed, so I'm
>> > >> going
>> > >>>>>>>> to leave it as is, unless pushed.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> On the last bullet, I didn't really follow your argument
>> > >> in
>> > >>>>>>>> S3.5. Might be easier to follow if S3.5 also talked about how
>> > >> a
>> > >>>>>>>> network element would take account of pkt size?
>> > >>>>>>>>>>> Also, does the following argument also apply?:
>> > >>>>>>>>>>> * if pkt-size biasing is done in the transport, then the
>> > >> work (to do
>> > >>>>>>>>>>> the biasing) is spread over many end hosts,
>> > >>>>>>>>>>> * whereas if pkt-size biasing is done in the network,
>> > > then
>> > >> the
>> > >>>>>>>> work is concentrated in just the congested network element,
>> > >> which
>> > >>>>>>>> has to operate on all the traffic at line speed.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> [BB]: 3.5. Implementation Efficiency
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> [ADD:]
>> > >>>>>>>>>>> Biasing against large packets typically requires an
>> > > extra
>> > >> multiply
>> > >>>>>>>>>>> and  divide in the network (see the example byte-mode
>> > > drop
>> > >>>>>>>> formula in table 1).
>> > >>>>>>>>>>> [CONTINUE AS BEFORE:]
>> > >>>>>>>>>>> Allowing for packet size at the transport rather than in
>> > >> the
>> > >>>>>>>>>>> network  ensures that neither the network nor the
>> > >> transport needs to
>> > >>>>>>>>>>> do a  multiply operation--multiplication by packet size
>> > > is
>> > >>>>>>>>>>> effectively  achieved as a repeated add when the
>> > > transport
>> > >> adds to
>> > >>>>>>>>>>> its count of  marked bytes as each congestion event is
>> > > fed
>> > >> to it.
>> > >>>>>>>>>>> [ADD:]
>> > >>>>>>>>>>> Also the work to do the biasing is spread over many
>> > >> hosts, rather
>> > >>>>>>>>>>> than  concentrated in just the congested network element.
>> > >>>>>>>>>>> [CONTINUE AS BEFORE:]
>> > >>>>>>>>>>>
>> > > These
>> > >> aren't
>> > >>>>>>>>>>> principled reasons in themselves, but they are a happy
>> > >> consequence
>> > >>>>>>>>>>> of the  other principled reasons.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> Bob
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> At 13:36 05/09/2012, Manner Jukka wrote:
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> Hi Bob,
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> Since Phil is your colleague at BT, even at Ipswich (?),
>> > >> can
>> > >>>>>>>> you check those and agree with Phil how to go forward? Some
>> > > of
>> > >>>>>>>> those are clear, others need discussion with Phil.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> Gorry, on point 2) below, I don't follow Leslie's
>> > >> arguments. I
>> > >>>>>>>> asked from him detailed comments and resolutions months ago,
>> > >> and nothing
>> > >>>>>>>> came.
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> cheers,
>> > >>>>>>>>>>> Jukka
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> On Sep 5, 2012, at 3:26 PM, Gorry Fairhurst wrote:
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>> Bob and Jukka,
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> I think I need your help to resolve this... Some of the
>> > >>>>>>>> comments raised by John Leslie appear to have substance, and
>> > >> I'm
>> > >>>>>>>> not sure what you plan to do to address these.
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> It would be good to do something quick so that I can
>> > >> complete
>> > >>>>>>>> the submission to the IESG.
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> The issues I particularly note are:
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> 1) This contribution from Phil appears to be within
>> > > scope
>> > >> and
>> > >>>>>>>> it seems may have been overlooked (sorry):
>> > >>>>>>>>>>>> http://www.ietf.org/mail-
>> > >> archive/web/tsvwg/current/msg11234.html
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> 2) Can you be clear here about what is actually been
>> > > said
>> > >> -
>> > >>>>>>>> because the point below seems to be a misunderstanding of
>> > >> language
>> > >>>>>>>> to me, and I hoped we did not claim this:
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find
>> > > that
>> > >> Bob is
>> > >>>>>>>>>>>>>> actually ] saying that transport-layer should _only_
>> > >> consider
>> > >>>>>>>>>>>>>> "congested bytes", not ] "congested packets".
>> > >>>>>>>>>>>>>> ]
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> 3) You'll need to post the updated draft and send a note
>> > >> to
>> > >>>>>>>> the group to confirm that the new version indeed concludes
>> > > the
>> > >>>>>>>> WGLC. I'll add a note to the writeup to indicate the draft
>> > >> content
>> > >>>>>>>> has been stable since Oct 2011.
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> Gorry (with my TSVWG Documnent Shepherd hat)
>> > >>>>>>>>>>>> cc: Co-Chairs for info.
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> -----Original Message-----
>> > >>>>>>>>>>>>>> From: Gorry Fairhurst [ mailto:[e-mail]]
>> > >>>>>>>>>>>>>> Sent: Mittwoch, 15. August 2012 21:41
>> > >>>>>>>>>>>>>> To: tsvwg chair
>> > >>>>>>>>>>>>>> Subject: Fwd: Re: [tsvwg] FYI: Document writeup for
>> > >>>>>>>>>>>>>> draft-ietf-tsvwg- byte-pkt-congest
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> Hi guys,
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> Apart form the usual rhetoric, there are some points
>> > >> here that we
>> > >>>>>>>>>>>>>> should note as chairs. What are you own thoughts? And
>> > >> was
>> > >>>>>>>>>>>>>> anything noted at the IETF in Vancouver concerning
>> > > this
>> > >> draft?
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> Gorry
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> -------- Original Message --------
>> > >>>>>>>>>>>>>> Subject: Re: [tsvwg] FYI: Document writeup for
>> > >>>>>>>>>>>>>> draft-ietf-tsvwg-byte- pkt-congest
>> > >>>>>>>>>>>>>> Date: Wed, 15 Aug 2012 15:07:28 -0400
>> > >>>>>>>>>>>>>> From: John Leslie <[e-mail]>
>> > >>>>>>>>>>>>>> To: Gorry Fairhurst <[e-mail]>
>> > >>>>>>>>>>>>>> CC: [e-mail]
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> Gorry Fairhurst <[e-mail]> wrote:
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> The following document has been revised after
>> > >> receiving
>> > >>>>>>>> WGLC comments.
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>  The changes are mostly refreshing a document
>> > >> scheduled to
>> > >>>>>>>>>>>>>> expire this month.
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> No issues were found:
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>  Is that with WGC-hat-on?
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>  Neither my issues nor Philip Eardley's comments were
>> > >> addressed.
>> > >>>>>>>>>>>>>> In fact, not even the changes Bob Briscoe mentioned
>> > > on-
>> > >> list have
>> > >>>>>>>>>>>>>> been included.
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> As required by RFC 4858, this is the current template
>> > >> for the
>> > >>>>>>>>>>>>>> Document
>> > >>>>>>>>>>>>>>> Shepherd Write-Up.
>> > >>>>>>>>>>>>>>> ...
>> > >>>>>>>>>>>>>>> (1) What type of RFC is being requested (BCP,
>> > > Proposed
>> > >> Standard,
>> > >>>>>>>>>>>>>>> Internet Standard, Informational, Experimental, or
>> > >> Historic)?
>> > >>>>>>>>>>>>>>> Why is this the proper type of RFC? Is this type of
>> > >> RFC
>> > >>>>>>>>>>>>>>> indicated in the title page header?
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> This document is intended as BCP. (This was discussed
>> > >> at IETF-81
>> > >>>>>>>>>>>>>>> and that the status changed from Informational to BCP
>> > >> since it
>> > >>>>>>>>>>>>>>> provides guidance to implementors and people
>> > >> configuring
>> > >>>>>>>> routers and hosts).
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>  Thank you for finally answering my question about
>> > > BCP
>> > >> status.
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> ...
>> > >>>>>>>>>>>>>>> Working Group Summary
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> There was consensus to publish this as a WG document
>> > >> and
>> > >>>>>>>>>>>>>>> agreement at
>> > >>>>>>>>>>>>>>> IETF-82 that the document was now complete.
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>  Was that reviewed on-list?
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> ...
>> > >>>>>>>>>>>>>>> (3) Briefly describe the review of this document that
>> > >> was
>> > >>>>>>>>>>>>>>> performed
>> > >>>>>>>>>>>>>> by
>> > >>>>>>>>>>>>>>> the Document Shepherd. If this version of the
>> > > document
>> > >> is not
>> > >>>>>>>>>>>>>>> ready for publication, please explain why the
>> > > document
>> > >> is being
>> > >>>>>>>>>>>>>>> forwarded to the IESG.
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> The document was presented at IEWTF-82 (Taipei), with
>> > >> a request
>> > >>>>>>>>>>>>>>> for
>> > >>>>>>>>>>>>>> WGLC.
>> > >>>>>>>>>>>>>>> WGLC concluded with some discussion but no
>> > > substantive
>> > >> changes
>> > >>>>>>>>>>>>>>> on Friday 30th March 2012.
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>  Yes, I guess that is true; but ignoring substantive
>> > >> comments
>> > >>>>>>>>>>>>>> isn't a good practice IMHO.
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> (4) Does the document Shepherd have any concerns
>> > > about
>> > >> the depth
>> > >>>>>>>>>>>>>>> or breadth of the reviews that have been performed?
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> No - the original draft had a lot of background
>> > >> material, much
>> > >>>>>>>>>>>>>>> of
>> > >>>>>>>>>>>>>> this
>> > >>>>>>>>>>>>>>> has been condensed or removed, resulting in a smaller
>> > >> document.
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>  That is indeed what I basically asked for, but I
>> > >> don't see any
>> > >>>>>>>>>>>>>> evidence of it:
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> - diff(07,08)  48 lines changed or deleted;  53 lines
>> > >> changed or
>> > >>>>>>>> added
>> > >>>>>>>>>>>>>> - diff(06,07)   8 lines changed or deleted;  13 lines
>> > >> changed or
>> > >>>>>>>> added
>> > >>>>>>>>>>>>>> - diff(05,06)  64 lines changed or deleted;  69 lines
>> > >> changed or
>> > >>>>>>>>>>>>>> added
>> > >>>>>>>>>>>>>> - diff(04,05) 823 lines changed or deleted; 864 lines
>> > >> changed or
>> > >>>>>>>>>>>>>> added
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> (Need I go farther? That gets us back to March
>> > > 2011...)
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> (9) How solid is the WG consensus behind this
>> > >> document? Does it
>> > >>>>>>>>>>>>>>> represent the strong concurrence of a few
>> > > individuals,
>> > >> with
>> > >>>>>>>>>>>>>>> others being silent, or does the WG as a whole
>> > >> understand
>> > >>>>>>>> and agree with it?
>> > >>>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> The document has WG support and there is consensus to
>> > >> publish.
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>  This, IMHO, doesn't answer the question. :^(
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>  Does it represent the concurrence of a few
>> > >> individuals, or does
>> > >>>>>>>>>>>>>> the WG as a whole understand and agree with it?
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> For reference, my comments included:
>> > >>>>>>>>>>>>>> ]
>> > >>>>>>>>>>>>>> ] When I previously skimmed this document, I believed
>> > >> it
>> > >>>>>>>>>>>>>> contained only ] common ground: that AQM should
>> > >> drop/mark packets
>> > >>>>>>>>>>>>>> without favoring small ] packets, and that to whatever
>> > >> extent
>> > >>>>>>>>>>>>>> packet size _is_ considered, that ] should be a
>> > >>>>>>>> transport-layer responsibility.
>> > >>>>>>>>>>>>>> ]
>> > >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find
>> > > that
>> > >> Bob is
>> > >>>>>>>>>>>>>> actually ] saying that transport-layer should _only_
>> > >> consider
>> > >>>>>>>>>>>>>> "congested bytes", not ] "congested packets".
>> > >>>>>>>>>>>>>> ]
>> > >>>>>>>>>>>>>> ] In fact, Bob openly endorses replacing TCP
>> > >> congestion-control
>> > >>>>>>>>>>>>>> with an ] algorithm which calculates "fair-share
>> > > bytes"
>> > >> and
>> > >>>>>>>>>>>>>> doesn't back off at all ] (even in the presence of 20%
>> > >> packet
>> > >>>>>>>>>>>>>> loss) unless you're already sending ] more than this
>> > >>>>>>>> "fair-share".
>> > >>>>>>>>>>>>>> ]
>> > >>>>>>>>>>>>>> ]    I do not believe that is the consensus of this
>> > > WG;
>> > >> and I
>> > >>>>>>>> believe
>> > >>>>>>>>>>>>>> if
>> > >>>>>>>>>>>>>> ] that were the consensus it would exceed our charter.
>> > >>>>>>>>>>>>>> ]
>> > >>>>>>>>>>>>>> ] The draft contains a number of things I _do_
>> > > support;
>> > >> and I'd
>> > >>>>>>>>>>>>>> be happy ] to support a considerably shorter draft
>> > >> which
>> > >>>>>>>>>>>>>> concentrates on the AQM ] recommendation, omitting any
>> > >>>>>>>>>>>>>> suggestions of modifying TCP congestion ] control.
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> and Philip's comments included:
>> > >>>>>>>>>>>>>> ]
>> > >>>>>>>>>>>>>> ] S2.2 I thought the numbered bullets could be better
>> > >> phrased,
>> > >>>>>>>>>>>>>> something like ] +this:- ]
>> > >>>>>>>>>>>>>> ]   1.  AQM algorithms such as RED SHOULD use packet-
>> > >> mode
>> > >>>>>>>> drop, ie they
>> > >>>>>>>>>>>>>> SHOULD NOT
>> > >>>>>>>>>>>>>> ] +use byte-mode drop. The latter ] is more complex,
>> > >>>>>>>>>>>>>> ]        it creates the perverse incentive to fragment
>> > >> segments
>> > >>>>>>>> into
>> > >>>>>>>>>>>>>> tiny
>> > >>>>>>>>>>>>>> ]        pieces and it is vulnerable to floods of
>> > >> small-
>> > >>>>>>>>>>>>>> ]        packets.
>> > >>>>>>>>>>>>>> ]
>> > >>>>>>>>>>>>>> ]    2.  If a vendor has implemented byte-mode drop,
>> > >> and an
>> > >>>>>>>> operator
>> > >>>>>>>>>>>>>> has
>> > >>>>>>>>>>>>>> ]        turned it on, it is RECOMMENDED to turn it
>> > >> off, after
>> > >>>>>>>>>>>>>> establishing if
>> > >>>>>>>>>>>>>> ] +there are any implications on
>> > >>>>>>>>>>>>>> ] the relative performance of
>> > >>>>>>>>>>>>>> ]        applications using different packet sizes.
>> > >>>>>>>>>>>>>> ]
>> > >>>>>>>>>>>>>> ]   3.  RED SHOULD NOT be turned off. Without RED, a
>> > >> drop tail
>> > >>>>>>>>>>>>>> ]        queue biases against large packets.
>> > >>>>>>>>>>>>>> ]
>> > >>>>>>>>>>>>>> ] Nit - the following paragraph shouldn't be indented
>> > >> (Note well
>> > >>>>>>>>>>>>>> that
>> > >>>>>>>>>>>>>> RED's...)
>> > >>>>>>>>>>>>>> ]
>> > >>>>>>>>>>>>>> ] S3.3
>> > >>>>>>>>>>>>>> ] The section could be slightly clearer. Starting with
>> > >> the second
>> > >>>>>>>>>>>>>> para, where you ] +start talking about something you
>> > >> don't
>> > >>>>>>>>>>>>>> recommend (ie you have to remember that ] +you're
>> > >> talking about
>> > >>>>>>>>>>>>>> the consequences of not following your
>> > > recommendation).
>> > >>>>>>>>>>>>>> ]
>> > >>>>>>>>>>>>>> ] S3.3
>> > >>>>>>>>>>>>>> ]    o  Also, if the network biases congestion
>> > >> notification by
>> > >>>>>>>> packet
>> > >>>>>>>>>>>>>> size
>> > >>>>>>>>>>>>>> ]       it has to assume a baseline packet size--all
>> > >> proposed
>> > >>>>>>>>>>>>>> algorithms
>> > >>>>>>>>>>>>>> ]       use the local MTU.  Then transports have to
>> > >> guess which
>> > >>>>>>>> link
>> > >>>>>>>>>>>>>> was
>> > >>>>>>>>>>>>>> ]       congested and what its local MTU was, in order
>> > >> to know
>> > >>>>>>>> how to
>> > >>>>>>>>>>>>>> ]       tailor their congestion response to that link.
>> > >>>>>>>>>>>>>> ] So you're saying that for byte-mode drop, the
>> > > network
>> > >> element
>> > >>>>>>>>>>>>>> has to compare the ] +size of the current pkt with the
>> > >> MTU, and
>> > >>>>>>>>>>>>>> if it's 25* smaller then reduce the ] +pkt loss
>> > >> probably by 25*?
>> > >>>>>>>>>>>>>> And if the MTU was bigger, then the current pkt would
>> > > ]
>> > >> +be
>> > >>>>>>>>>>>>>> dropped with greater probability? And both of these
>> > >> things
>> > >>>>>>>> are hard to do.
>> > >>>>>>>>>>>>>> ]
>> > >>>>>>>>>>>>>> ] S3.4 (& knock-on effect on 3.3) ] I think this could
>> > >> be better.
>> > >>>>>>>>>>>>>> ] I agree with your arguments in S3.1 & 3.2 that
>> > >> dropping or
>> > >>>>>>>>>>>>>> marking should be ] +independent of pkt size.
>> > >>>>>>>>>>>>>> ] You now go into a couple of pages, which I think
>> > >> could be
>> > >>>>>>>>>>>>>> boiled down to a ] +paragraph, saying something like:-
>> > >> ] * the
>> > >>>>>>>>>>>>>> overall system (network + transport) has to be packet-
>> > >> size
>> > >>>>>>>>>>>>>> dependent in ]
>> > >>>>>>>>>>>>>> +order to drive out the right amount of traffic so the
>> > >> resource
>> > >>>>>>>>>>>>>> becomes ]
>> > >>>>>>>>>>>>>> +uncongested (since we assume all resources are in
>> > >> practice byte
>> > >>>>>>>>>>>>>> +rather
>> > >>>>>>>>>>>>>> than ] +packet limited) ] * from S3.1 and S3.2 the
>> > > IETF
>> > >> is
>> > >>>>>>>>>>>>>> convinced that the network should notify ]
>> > > +independent
>> > >> of
>> > >>>>>>>> packet-size.
>> > >>>>>>>>>>>>>> ] * therefore the transport must act dependent on
>> > >> packet-size.
>> > >>>>>>>>>>>>>> ]
>> > >>>>>>>>>>>>>> ] It seems to me this is a necessary consequence of
>> > >> your earlier
>> > >>>>>>>>>>>>>> assumptions ] +/arguments.
>> > >>>>>>>>>>>>>> ]
>> > >>>>>>>>>>>>>> ] [On the other hand, if someone disagrees with the
>> > >> arguments and
>> > >>>>>>>>>>>>>> thinks that the ] +network should notify dependent on
>> > >>>>>>>>>>>>>> packet-size, then it follows that the ] +transport can
>> > >> act
>> > >>>>>>>>>>>>>> independent of
>> > >>>>>>>>>>>>>> packet- size.] ] ] I think in S3.3 you're trying to
>> > >> make another
>> > >>>>>>>>>>>>>> argument (?):-  ] * we can either do packet-size
>> > >> biasing in the
>> > >>>>>>>>>>>>>> network element or on the end host ] +transport (see
>> > >> argument
>> > >>>>>>>>>>>>>> above) ] * packet-size biasing in the network is quite
>> > >> tricky,
>> > >>>>>>>>>>>>>> because then both the ] +network element & the
>> > >> transport have to
>> > >>>>>>>>>>>>>> make some guesses about MTU - whereas ]
>> > >>>>>>>>>>>>>> +with packet-size biasing in the transport, neither
>> > >> network
>> > >>>>>>>>>>>>>> +element
>> > >>>>>>>>>>>>>> nor ] +transport needs to know what the MTU is.
>> > >>>>>>>>>>>>>> ] * it is also easier to implement packet-size biasing
>> > >> in the
>> > >>>>>>>>>>>>>> transport than in ] +the network.
>> > >>>>>>>>>>>>>> ]
>> > >>>>>>>>>>>>>> ] On the last bullet, I didn't really follow your
>> > >> argument in
>> > >>>>>>>> S3.5.
>> > >>>>>>>>>>>>>> Might be ] +easier to follow if S3.5 also talked about
>> > >> how a
>> > >>>>>>>>>>>>>> network element would take ] +account of pkt size?
>> > >> Also, does the
>> > >>>>>>>>>>>>>> following argument also apply?:
>> > >>>>>>>>>>>>>> ] * if pkt-size biasing is done in the transport, then
>> > >> the work
>> > >>>>>>>>>>>>>> (to do the ] +biasing) is spread over many end hosts,
>> > > ]
>> > >> * whereas
>> > >>>>>>>>>>>>>> if pkt-size biasing is done in the network, then the
>> > >> work is ]
>> > >>>>>>>>>>>>>> +concentrated in just the congested network element,
>> > >> which has to
>> > >>>>>>>>>>>>>> operate on all ] +the traffic at line speed.
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>  (Has there perhaps been some confusion about what
>> > >> went into the
>> > >>>>>>>>>>>>>> -08
>> > >>>>>>>>>>>>>> version?)
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> --
>> > >>>>>>>>>>>>>> John Leslie <[e-mail]>
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >> ________________________________________________________________
>> > >>>>>>>>>>> Bob Briscoe,                                BT Innovate &
>> > >> Design
>> > >>>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>
>> > >>>>>>>
>> > >> ________________________________________________________________
>> > >>>>>>> Bob Briscoe,                                BT Innovate &
>> > >> Design
>> > >>>>>>>
>> > >>>>>
>> > >>>>> ________________________________________________________________
>> > >>>>> Bob Briscoe,                                BT Innovate & Design
>> > >>>
>> > >>> ________________________________________________________________
>> > >>> Bob Briscoe,                                BT Innovate & Design
>> > >
>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design