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

From: Bob Briscoe <[email-masked]>
Date: Thu, 11 Oct 2012 13:08:09 +0100

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, [email-masked] wrote:
> >> That would be brilliant!
> >>
> >> Gorry
> >>
> >> > Will try to look at this later today.
> >> >
> >> >
> >> > Bob
> >> >
> >> > At 10:42 02/10/2012, [email-masked] 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:[email-masked]]
> >> >>Sent: 01 October 2012 20:18
> >> >>To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,Bob,DUB8 R
> >> >>Cc: [email-masked]; 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, <[email-masked]>
> >> >> > <[email-masked]> 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:[email-masked]]
> >> >> >> Sent: 07 September 2012 13:24
> >> >> >> To: Eardley,PL,Philip,DUB8 R
> >> >> >> Cc: Briscoe,RJ,Bob,DUB8 R; <[email-masked]>;
> >> >> >> <[email-masked]>
> >> >> >> 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,
> >> >> <[email-masked]>  <[email-masked]> 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: [email-masked]; 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: [email-masked]; 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:[email-masked]]
> >> >> >>>>>> 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 <[email-masked]>
> >> >> >>>>>> To: Gorry Fairhurst <[email-masked]>
> >> >> >>>>>> CC: [email-masked]
> >> >> >>>>>>
> >> >> >>>>>> Gorry Fairhurst <[email-masked]> 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 <[email-masked]>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>
> >> >> >>>>
> >> >> >>> ________________________________________________________________
> >> >> >>> Bob Briscoe,                                BT Innovate & Design
> >> >> >>>
> >> >> >>
> >> >> >
> >> >
> >> > ________________________________________________________________
> >> > Bob Briscoe,                                BT Innovate & Design
> >> >
> >
> > ________________________________________________________________
> > Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Manner Jukka <[email-masked]>
Date: Thu, 11 Oct 2012 12:34:24 +0000

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
> 
>> 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
>> 
>> > 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.
>> >
>> > * 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]).
>> >> >> >> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for Recommendation
>> >> >> longer or merged somewhere. Not a major issue though and could remain as
>> >> >> is.
>> >> >> >>
>> >> >> >>> would be better if you re-structured slightly [first talk about what
>> >> >> >>> you like - penult para + 1st sentence of last para - then talk about
>> >> >> >>> Cc: [email-masked]; Gorry Fairhurst; Eardley,PL,Philip,DUB8 R
>> >> >> >>>  1.  AQM algorithms such as RED SHOULD use packet-mode drop, ie they
>> >> >> >>>  2.  If a vendor has implemented byte-mode drop, and an operator has
>> >> >> >>>     replace this assumed aggressiveness with its own aggressiveness.
>> >> >> >>>     it has to assume a baseline packet size--all proposed algorithms
>> >> >> >>>     use the local MTU.  Then transports have to guess which link was
>> >> >> >>>     it has to assume a baseline packet size--all proposed algorithms
>> >> >> >>> [Aside for Phil: The byte-mode algo uses MTU as its baseline because
>> >> >> >>> thinks that the network should notify dependent on packet-size, then
>> >> >> >>> * if pkt-size biasing is done in the transport, then the work (to do
>> >> >> >>> network  ensures that neither the network nor the transport needs to
>> >> >> asked from him detailed comments and resolutions months ago, and nothing
>> >> >> came.
>> >> >> >>>
>> >> >> >>> cheers,
>> >> >> >>> Jukka
>> >> >> >>>
>> >> >> >>>>>> Apart form the usual rhetoric, there are some points here that we
>> >> >> >>>>>>   Neither my issues nor Philip Eardley's comments were addressed.
>> >> >> >>>>>>> (1) What type of RFC is being requested (BCP, Proposed Standard,
>> >> >> >>>>>>> This document is intended as BCP. (This was discussed at IETF-81
>> >> >> >>>>>>> (4) Does the document Shepherd have any concerns about the depth
>> >> >> >>>>>>   Does it represent the concurrence of a few individuals, or does
>> >> >> >>>>>> contained only ] common ground: that AQM should drop/mark packets
>> >> >> >>>>>> ] The section could be slightly clearer. Starting with the second
>> >> >> >>>>>> ] S3.4 (& knock-on effect on 3.3) ] I think this could be better.
>> >> >> >>>>>> ] [On the other hand, if someone disagrees with the arguments and
>> >> >> >>>>>> network element would take ] +account of pkt size? Also, does the
>> >> >> >>>>>> (to do the ] +biasing) is spread over many end hosts, ] * whereas
>> >> >> >>>>>> +concentrated in just the congested network element, which has to
>> >> >> >>>>>>   (Has there perhaps been some confusion about what went into the
>> >> >> >>>>>> -08
>> >> >> >>>>>> version?)
>> >> >> >>>>>>
>> >> >> >>>>>> --

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 11 Oct 2012 15:44:31 +0300

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

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Manner Jukka
> Sent: Thursday, October 11, 2012 3:34 PM
> To: Bob Briscoe
> Cc: <[email-masked]>; <[email-masked]>; <tsvwg-
> [email-masked]>; 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
> 
chose
> to say "no-one expects AQM to be universally deployed". This clearly
> missed the mark.
> >
anyway,
> I would formulate this paragraph a bit towards that we have partial
> deployment now and  even with a full deployment, ...
> >>
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).
> it really is a motivating argument now and it can stay where it is -
it
> is not just a preamble.
> 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.
> >> >
> >> >
>
=======================================================================
> ===============
drop
> signals depend on packet size at all.
> rate response proportional to the size of dropped packets, but if they
> want to, they always can.
> >> >
> "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".
> >> >
> 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.
> >> >
> 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).
> >> >
> 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.
> >> >
due
> to buffer exhaustion. Therefore, because the network cannot
universally
> do size-dependent drop, it should not do it all.
> >> >
=======================================================================
> ===============
> >> >> >>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.
> >> >> >> >> 3.4 is, in my mind, completely different from 3.1, 3.2,
3.3
> and 3.5.
could
> remain as
> >> >> >> >>> Ps otherwise Bob's comments are fine, though I suggest
for
> S3.5 you
> >> >> >> consequences of assuming either [option 1] do pkt-size
biasing
> in
> >> >> >> why X scales as order N rather than N^2 or something like
that
> -
> >> >> >> whether the network takes account (or not) of packet size
when
> >> >> >> >>> Note that TCP responds to dropped or marked packets,
which
> differs
> >> >> >> >>> significant problem because most TCP implementations
have
> been
> >> >> >> transport protocols should  respond to dropped or marked
bytes
> (as
> >> >> >> >>> I've repeated Phil's suggestions as quoted email then
made
> some
> >> >> >> >>>      RED as a whole SHOULD NOT be turned off. Without
RED,
> a drop
> >> >> >> >>> (I suggest the last para just qualifies item 2. It
doesn't
> warrant
> >> >> >> >>> notification by  packet size in order to equalise the
bit-
> >> >> >> >>> has to make assumptions about the  transport, which
become
> embedded
> >> >> >> >>>  o  Also, if the network biases congestion notification
by
> >> >> >> >>>     congested and what its local MTU was, in order to
know
> >> >> >> it's 25* smaller then reduce the pkt loss probably by 25*?
And
> >> >> >> >>>  o  Also, if the network biases congestion notification
by
> >> >> >> >>> thinks that the network should notify dependent on
packet-
> size, then
> >> >> >> transport, neither network element nor transport needs to
know
> what the
> >> >> >> given MTU growth isn't often being used to increase link
rates
> at
> >> >> >> any more briefly or differently. It's easier to summarise
what
> you
> >> >> >> >>> * whereas if pkt-size biasing is done in the network,
then
> the
> >> >> >> >>>  Biasing against large packets typically requires an
extra
> multiply
> >> >> >> >>> effectively  achieved as a repeated add when the
transport
> adds to
> >> >> >> >>> its count of  marked bytes as each congestion event is
fed
> to it.
These
> aren't
> >> >> >> >>>> 1) This contribution from Phil appears to be within
scope
> and
> >> >> >> >>>> 2) Can you be clear here about what is actually been
said
> -
> >> >> >> >>>>>> ] Alas, when I read it carefully this week, I find
that
> Bob is
> >> >> >> >>>>>> anything noted at the IETF in Vancouver concerning
this
> draft?
> >> >> >> >>>>>> In fact, not even the changes Bob Briscoe mentioned
on-
> list have
Proposed
> Standard,
> >> >> >> >>>>>>   Thank you for finally answering my question about
BCP
> status.
> >> >> >> >>>>>>> the Document Shepherd. If this version of the
document
> is not
> >> >> >> >>>>>>> ready for publication, please explain why the
document
> is being
> >> >> >> >>>>>>> WGLC concluded with some discussion but no
substantive
> changes
about
> the depth
> >> >> >> >>>>>>> represent the strong concurrence of a few
individuals,
> with
> >> >> >> >>>>>> ] Alas, when I read it carefully this week, I find
that
> Bob is
> >> >> >> >>>>>> with an ] algorithm which calculates "fair-share
bytes"
> and
> >> >> >> >>>>>> ]    I do not believe that is the consensus of this
WG;
> and I
> >> >> >> >>>>>> ] The draft contains a number of things I _do_
support;
> and I'd
> >> >> >> >>>>>> ] So you're saying that for byte-mode drop, the
network
> element
> >> >> >> >>>>>> And if the MTU was bigger, then the current pkt would
]
> +be
> >> >> >> >>>>>> than ] +packet limited) ] * from S3.1 and S3.2 the
IETF
> is
> >> >> >> >>>>>> convinced that the network should notify ]
+independent
]
> * whereas

---

From: Manner Jukka <[email-masked]>
Date: Thu, 11 Oct 2012 12:49:41 +0000

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:

>> rates at

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 11 Oct 2012 15:57:43 +0300

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

> From: ext Manner Jukka [mailto:[email-masked]]
> Sent: Thursday, October 11, 2012 3:50 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo)
> Cc: Bob Briscoe; <[email-masked]>; <[email-masked]>;
> <[email-masked]>; tsvwg IETF list
> 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
> 
-
> even
> (case
the

---

From: <[email-masked]>
Date: Thu, 11 Oct 2012 16:48:25 +0200

Hi Hannes,

haven't been at the workshop or last IETF, read into the draft
and into Codel:
- it is unclear to me, whether codel is dealing with CPE issues
  or RED in general.
- I've understood Bobs/Jukkas draft to deal with RED in general.

If Codel is about RED in general, backbone router vendor support
is required. Has there been feedback from this community?

It may be a good idea to try to finalise the work of Bob and Jukka.

Regards,

Rüdiger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Thursday, October 11, 2012 2:58 PM
To: ext Manner Jukka
Cc: [email-masked]; [email-masked]; tsvwg IETF list; [email-masked]
Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest

Hi Jukka,

Ciao
Hannes

interesting
-
the

---

From: <[email-masked]>
Date: Thu, 11 Oct 2012 17:16:40 +0100

I also think it's a good idea to finalise draft-ietf-tsvwg-byte-pkt-congest.

Anyway, I think draft-nichols-tsvwg-codel is in reasonable alignment (my understanding of codel is limited) - see the 3 recommendations in the abstract of draft-ietf-tsvwg-byte-pkt-congest: " (1) packet size should be taken
   into account when transports read and respond to congestion
   indications, (2) packet size should not be taken into account when
   network equipment creates congestion signals (marking, dropping), and
   therefore (3) the byte-mode packet drop variant of the RED AQM
   algorithm that drops fewer small packets should not be used."

phil
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 11 October 2012 15:48
To: [email-masked]
Cc: [email-masked]; Eardley,PL,Philip,DUB8 R; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest

Hi Hannes,

haven't been at the workshop or last IETF, read into the draft and into Codel:
- it is unclear to me, whether codel is dealing with CPE issues
  or RED in general.
- I've understood Bobs/Jukkas draft to deal with RED in general.

If Codel is about RED in general, backbone router vendor support is required. Has there been feedback from this community?

Regards,

Rüdiger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Thursday, October 11, 2012 2:58 PM
To: ext Manner Jukka
Cc: [email-masked]; [email-masked]; tsvwg IETF list; [email-masked]
Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest

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

interesting
-
the
> >>>>>>>>>>> S3.4 (& knock-on effect on 3.3) I think this could be
> >>>>>>>>>>> better.
> >>>>>>>>>>>>>> ] +there are any implications on ] the relative
> >>>>>>>>>>>>>> performance of

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 11 Oct 2012 17:06:57 +0100

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

---

From: Andrew McGregor <[email-masked]>
Date: Fri, 12 Oct 2012 11:24:33 +1300

On 12/10/2012, at 5:06 AM, Bob Briscoe <[email-masked]> wrote:

> 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

In discussing CoDel, it is important to realise that the 100ms interval is not a delay target, nor is the 5ms.  They're both measurement intervals, and pretty much form bounds on how long the algorithm will allow the queueing delay to spike above whatever value CoDel is going to converge to on that link.  Interval at 100ms was chosen such that CoDel would still be able to converge even on the longest delay links likely in the internet (it degrades somewhat gracefully with RTT between 5x interval and 8x interval, but performs horribly if RTT is greater than that).  Convergence queueing delay depends on the link characteristics somewhat, especially if it is an aggregating link or one that is transmission opportunity limited rather than bit rate limited, but is generally around the transmission time of a few packets, between two and perhaps 30.  Which is on most realistic links, much less than 100ms of delay, and on most fast links much less than 5ms.  We've seen the actual delay be under 250 microseconds on 10GbE.

However, my view is that CoDel itself is just an ingredient in a solution.  CoDel will pick victim packets from flows that are not congesting the queue, and does nothing for RTT fairness.  The two fq_codel variants that are around are much closer to a solution, but even they are strong hints not a completely general answer.  The 'fq' in the name is somewhat of a misnomer too, since neither is strictly classical fair queueing.

In an actual deployed situation, fq_codel (Eric Dumazet version in the Linux kernel) is magic.  The interactive feel of a network where the bottleneck link is managed by fq_codel in both directions is vastly superior, RTT fairness is vastly superior, VoIP and video conferencing just work in conjunction with throughput-maximising traffic, and in actual practice the problems of poor queue management are in fact fixed.

I've deployed fq_codel into four different networks now, three homes (one DSL, two cable) and one 120-odd person office (gigabit fiber ethernet), and in every case there was an immediate and noticeable improvement in web latency, VoIP and video call quality, and in the residential environments game transports benefited spectacularly as well.  The office required a transparent filtering web proxy, and the web browsing behaviour there is now totally dominated by the proxy's decision latency.  Even then, the latency is so much better than without fq_codel, it was a very noticeable benefit.

I'll not that the residential deployments I'm referring to do use the trick of rate-limiting both directions to a fraction less than the available bandwidth so as to gain control of the bottleneck queue.  This loses about 10% of the bandwidth, but you gain so much from fq_codel that it is a very worthwhile tradeoff.  Actual observed downloads usually complete faster due to fewer stalls anyway.

In every case, the improvement was dramatic enough to be observed by non-technical users. In the office case the mostly very technical user base were not told of the deployment in advance, but most users noticed that something had changed immediately, just from the improvement in browsing and VoIP experience.

So, proof by example: It is possible to do much, much better with AQM.  A good AQM can spectacularly improve coexistence of very different transports sharing a bottleneck link, and in particular can allow throughput maximising and real-time traffic to share a link with very little impact on each other (yes, the real-time jitter does degrade slightly in the presence of other traffic, but this is well within the bounds of acceptable even on a fairly slow DSL link).

Andrew

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 15 Oct 2012 10:17:59 +0100

Jukka,

OK, 2nd attempt below, annotated with HTML formatting. Rather than 
predicting the future, I have confined the text to the lack of 
universal deployment in the present. If you're happy with this, pls 
go ahead and re-issue the draft.

In overview, the argument in this section runs as follows:
* Because the network does 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 is not 
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 to 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 is not to ever be universally deployed in every 
queue in the Internet; many cheap ethernet bridges, software 
firewalls, NATs on consumer devices, etc implement simple tail-drop 
buffers. and, eEven 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 
For both these reasons 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 currently unrealistic.

Bob

At 13:34 11/10/2012, Manner Jukka wrote:
>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
>
> > 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.
> >
> > [I've cc'd the list, given we're starting to wordsmith 
> significantly new text added since WG last call.]
> >
> >
> > Bob
> >
> >> 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.
> >>
> >> > 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.
> >> >
> >> > 
> >> > * 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.
> >> > 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) 
> >> > 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 
> like I tried.
> 3.3 and 3.5.
> for S3.5 you
> which differs
> RED, a drop
> doesn't warrant
> bit-rates of
> become embedded
> know how to
> know what the
> extra multiply
> transport adds to
> fed to it.
> that Bob is
> this draft?
> on-list have
> BCP status.
> document is not
> document is being
> substantive changes
> that Bob is
> support; and I'd
> network element

---

From: <[email-masked]>
Date: Mon, 15 Oct 2012 11:41:37 +0100

Bob,
Your argument seems ok to me.
<< 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>>
"always can"? do they always know?
<< rate response proportionate to the size of each dropped packet, while others will (e.g. TFRC-SP [RFC4828]).>>
Does 4828 make a packet-by-packet decision or does it know that the small pkt source has a particular pkt size for a long run? "each dropped pkt" sounds like the former, thought 4828 was the latter?
<< The argument applies solely to drop, not to ECN marking.>>
Should you make more comment here? Given that much of the draft is about ecn marking.
<< For both these reasons networks will often be dropping packets as a last resort (case b) rather than under AQM control (case a).>>
"often" seems wrong. "sometimes"?
Also, pendantically "both reasons" seems wrong, since the two reasons are mutually exclusive they cannot both be true.
Thanks
phil

From: Briscoe,RJ,Bob,DUB8 R
Sent: 15 October 2012 10:18
To: Manner Jukka
Cc: Eardley,PL,Philip,DUB8 R; <[email-masked]>; <[email-masked]>; tsvwg IETF list
Subject: Re: [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest

Jukka,

OK, 2nd attempt below, annotated with HTML formatting. Rather than predicting the future, I have confined the text to the lack of universal deployment in the present. If you're happy with this, pls go ahead and re-issue the draft.

In overview, the argument in this section runs as follows:
* Because the network does 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 is not 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 to ECN marking.

No-one expects AQM is not to ever be universally deployed in every queue in the Internet; many cheap ethernet bridges, software firewalls, NATs on consumer devices, etc implement simple tail-drop buffers. and, eEven 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 For both these reasons 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 currently unrealistic.

Bob

Hi,

Jukka

On Oct 11, 2012, at 3:08 PM, Bob Briscoe wrote:

>> > At 13:13 04/10/2012, [email-masked]<mailto:[email-masked]> wrote:
>> >> That would be brilliant!
>> >>
>> >> Gorry
>> >>
>> >> > At 10:42 02/10/2012, [email-masked]<mailto:[email-masked]> wrote:
>> >> >>From: Manner Jukka [ mailto:[email-masked]]
>> >> >>Cc: [email-masked]<mailto:[email-masked]>; Gorry Fairhurst
>> >> >> > On Sep 7, 2012, at 4:07 PM, <[email-masked]<mailto:[email-masked]>>
>> >> >> > <[email-masked]<mailto:[email-masked]>> wrote:
>> >> >> >
>> >> >> >> From: Manner Jukka [ mailto:[email-masked]]
>> >> >> >> Cc: Briscoe,RJ,Bob,DUB8 R; <[email-masked]<mailto:[email-masked]>>;
>> >> >> >> <[email-masked]<mailto:[email-masked]>>
>> >> >> <[email-masked]<mailto:[email-masked]>>  <[email-masked]<mailto:[email-masked]>> wrote:
>> >> >> >>
>> >> >> >>> Cc: [email-masked]<mailto:[email-masked]>; Gorry Fairhurst
>> >> >> >>> Cc: [email-masked]<mailto:[email-masked]>; Gorry Fairhurst; Eardley,PL,Philip,DUB8 R
>> >> >> >>>>>> From: John Leslie <[email-masked]<mailto:[email-masked]>>
>> >> >> >>>>>> To: Gorry Fairhurst <[email-masked]<mailto:[email-masked]>>
>> >> >> >>>>>> CC: [email-masked]<mailto:[email-masked]>
>> >> >> >>>>>>
>> >> >> >>>>>> Gorry Fairhurst <[email-masked]<mailto:[email-masked]>> wrote:
>> >> >> >>>>>>>
>> >> >> >>>>>> John Leslie <[email-masked]<mailto:[email-masked]>>
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>
>> >> >> >>>>

---

From: Manner Jukka <[email-masked]>
Date: Mon, 15 Oct 2012 14:31:06 +0000

Hi, works with me. :)

If we are done, then I can submit a revision asap.

Jukka