Subject: RE: Note: WGLC Announcement for draft-ietf-tsvwg-byte-pkt-congest-07

From: <[email-masked]>
Date: Mon, 2 Apr 2012 17:49:46 +0100

Hi,
Sorry these comments are late.

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.
	
Nits
Page 5, line 3 - less control packets /fewer control packets
Page 7, RED terminology - In RED /In RED [ref]

Best wishes,
phil
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
Sent: 28 March 2012 14:02
To: [email-masked]
Subject: Note: WGLC Announcement for draft-ietf-tsvwg-byte-pkt-congest-07

Please respond to the WGLC that ends on Friday 30th March 2012.

Notes to the list would be helpful to complete the WGCC.

Gorry & James

-------- Original Message --------
Subject: WGLC Announcement for draft-ietf-tsvwg-byte-pkt-congest-07

This email announces the start of a working group last call for
draft-ietf-tsvwg-byte-pkt-congest-07, "Byte and Packet Congestion
Notification". This document is now thought to be ready
to proceed to be published as a BCP. Please send any comments to the
TSVWG list.

The draft is available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-byte-pkt-congest-07

The last call will run for TWO weeks, ending Friday 30th March 2012.

Emails saying "I support" or "I don't support" publication are also most 
helpful in judging the WG consensus. Please let us know if this draft is 
useful and seems to provide the correct advice.

James and Gorry
(TSVWG Chairs)
[email-masked]

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 18 Apr 2012 19:13:44 +0100

John,

inline...

At 16:50 30/03/2012, John Leslie wrote:
>Gorry Fairhurst <[email-masked]> wrote:
> >
>    I cannot support this draft as written.
>
>    Perhaps some background would help...
>
>    It will be no secret to anyone following the ConEx WG that Bob and I
>fundamentally disagree about whether to model congestion as per-packet
>or per-byte. I strongly believe that it's packets that are congested, and
>that we'll do better to accurately count congested packets than estimate
>congested bytes; Bob seems to strongly believe that we'll do better to
>estimate congested bytes than accurately count congested packets.

This doesn't need to be personal. There are two co-authors, and this 
is also the output of everyone else who has contributed (see acks). 
This is not just me, this is a WG document.

If you believe differently, we need to hear a technical argument. 
There are 5 technical motivating arguments in this doc (S.3) that 
back up the recommendations. One specifically relates to the 
recommendations you don't like about the transport layer (S3.4). Then 
there is a more equivocal discussion in S.5 about whether 
bit-congestible is more prevalent than pkt-congestible, and whether 
this might change in future.

I have been encouraging you to have this argument out, rather than 
just saying we shouldn't decide because 'some people' disagree. Let's hear it.

I believe the disagreement is rooted in the idea that vendors hit the 
design limits of equipment performance when they cannot process 
packets any faster, whereas raw line transmission rates could be a 
lot faster. The point referred to by this draft [RFC6077] is that 
vendors then limit the bit-rate of the ports to the packet-processing 
rates they can achieve with a workload that includes reasonable runs 
of small packets (what point would there be in faster line rates?). 
Therefore, at *run-time*, congestion signals from the queues in such 
equipment generally represent bit-congestion, not packet-congestion, 
even though the kit was mostly constrained by packet processing 
during the *design* phase.

>    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.

Good - this is the main thing we wanted to ensure was said.

>    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".

Assuming we are talking about the general recommendation in 2.3 here, 
it endorses protocols like TFRC-SP [RFC4828] that weights losses 
proportionate to packet size within a flow with variable size 
packets. The recommendation in 2.3 is largely unchanged since Sally 
Floyd (one of the authors of RFC4828) reviewed byte-pkt.

In fact, TFRC-SP wrestled with the possibility that the network, not 
the transport, could weight its congestion signals relative to packet 
size. But it didn't even entertain the possibility that congestion 
might be packet-based not bit-based, so packet size wouldn't be an 
issue at all.

byte-pkt-congest does at least entertain the possibility that 
prevalent bit-congestion may be a wrong assumption and describes a 
future where it might be wrong, but it also justifies fairly 
carefully why it is a safe working assumption and it will continue to 
be safe, based on advice from equipment designers. (Actually, in 
reading the latest draft, I notice some of this argument has 
disappeared in the editing and it now mainly justifies this position 
by reference to RFC6077. I would be happy to bring some of that 
removed text back in.)

But, I gather that wouldn't satisfy you, because you believe 
packet-congestion is prevalent, so let's please have that technical discussion.

>    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 assume you're referring to bullet 1. under "What this advice means 
for the case of TCP:" in S2.3.

If so, that's not how it should read at all.

It says
"  1.  If two TCP flows with different packet sizes are required to run
        at equal bit rates under the same path conditions, this should be
        done by altering TCP (Section 4.2.2), not network equipment [...]
"

This doesn't say TCP should do this, it just says TCP is the place to 
fiddle, *if* you want to equalise bit-rates.

If that's not clear, I would be happy (and I hope Jukka would too) to 
make it clearer that this recommendation is irrelevant if TCP flows 
are *not* required to run at equal bit-rates (Personally I would like 
to say that there should be no need for any equal-bit-rate 
requirement - however, that *would* be going beyond our charter).

How about this text after S2.3. bullet 1?

"  For the avoidance of doubt, this is not a recommendation that TCP
    should be changed so that all TCP flows run at equal bit-rates.  It is a
    recommendation that the transport protocol not the network is where any
    attempt should be made to equalise bit-rates of competing flows, *if*
    that is ever considered an important requirement.
"

>    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.

We could omit "What this means for TCP" altogether. However, given 
people of the standing of Sally Floyd originally tried to equalise 
bit-rates in the network, then moved to doing it in the transport, I 
don't think it is wise to leave a vacuum. It is our duty to record 
the advice from this collective experience. But if the wording isn't 
nuanced correctly, let's change it.

Bob

>--
>John Leslie <[email-masked]>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: John Leslie <[email-masked]>
Date: Thu, 19 Apr 2012 09:38:02 -0400

Bob Briscoe <[email-masked]> wrote:
> lot faster.

   Actually, that's not it at all.

>> saying that transport-layer should _only_ consider "congested bytes",
>> not "congested packets".
> 

   Hopefully, we all can agree the network should not weigh congestion
signals by packet size. But that doesn't mean some other layer needs
to do so in any "ordinary" case.

> by reference to RFC6077. I would be happy to bring some of that 

   I very much doubt that what we need here is to add such text.

> packet-congestion is prevalent, so let's please have that technical 

   Once again, that's not it at all.

   My technical argument is it's really-hard to accurately estimate
per-packet overhead when counting bits for bit-congestible node pairs;
and that counting packets (which we can do accurately) works well in
all cases where packet size within a flow is fairly constant.

   This is basically what we do today; and I'm very resistant to any
call to replace it with algorithms which tend to underestimate the
overhead when counting payload bytes.

>> more than this "fair-share".

   BTW, I was very surprised to find "fair-share" as a recommendation
in a Bob Briscoe document, given his previous "dismantling a religion"
documents.

> for the case of TCP:" in S2.3.

   Actually, that's not what I was referring to.

>        done by altering TCP (Section 4.2.2), not network equipment [...]

   More likely, it was Section 4.2.2... I don't think this document
needs a 4.2.2 at all. This statement would be stronger if we didn't try
to describe possible modifications to TCP.

> fiddle, *if* you want to equalise bit-rates.

   And I didn't find it objectionble until I read the rest of the
document carefully.

> requirement - however, that *would* be going beyond our charter).

   Maybe we should explore exactly what about our charter excludes such
a statement?

>    that is ever considered an important requirement.

   I preferred your short-form:
" 
" If you want to equalize bit-rates between TCP flows, this should be
" done within TCP, not by network equipment.

> We could omit "What this means for TCP" altogether.

   IMHO, the document would be stronger without it.

> However, given people of the standing of Sally Floyd originally tried
> to equalise bit-rates in the network, then moved to doing it in the
> transport, I don't think it is wise to leave a vacuum.

   I don't perceive any such vacuum. At most, we might need an informative
reference to a Sally Floyd document.

---

From: Manner Jukka <[email-masked]>
Date: Thu, 26 Apr 2012 08:50:37 +0000

Hi John,

Could you give a concrete clear list of things, you would like to be changed?

Jukka