Subject: Re: [tsvwg] FYI: Document writeup for draft-ietf-tsvwg-byte-pkt-congest

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 05 Sep 2012 15:06:05 +0100

We plan to review your message with the authors and will report back to 
the mailing list - I expect most issues can be resolved.

Gorry

On 15/08/2012 20:07, John Leslie wrote:
> 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]>
>