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

[<[e-mail]>]

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; <[e-mail]>; <[e-mail]>; 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.


======================================================================================
3.4.  Permanent Partial Deployment of AQM

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.

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:34 11/10/2012, Manner Jukka wrote:

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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
>> >> >> > <[e-mail]<mailto:[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]<mailto:[e-mail]>>;
>> >> >> >> <[e-mail]<mailto:[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]<mailto:[e-mail]>>  <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
>> >> >> >>>>>> To: Gorry Fairhurst <[e-mail]<mailto:[e-mail]>>
>> >> >> >>>>>> CC: [e-mail]<mailto:[e-mail]>
>> >> >> >>>>>>
>> >> >> >>>>>> Gorry Fairhurst <[e-mail]<mailto:[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]<mailto:[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