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

[Bob Briscoe <[e-mail]>]

John,

inline...

At 16:50 30/03/2012, John Leslie wrote:
>Gorry Fairhurst <[e-mail]> wrote:
> >
> > Please respond to the WGLC that ends on Friday 30th March 2012.
> >
> > Notes to the list would be helpful to complete the WGCC.
>
>    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 <[e-mail]>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design