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

<philip.eardley@bt.com> Mon, 02 April 2012 16:49 UTC

Return-Path: <philip.eardley@bt.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CF821F8710 for <tsvwg@ietfa.amsl.com>; Mon, 2 Apr 2012 09:49:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57Rq0txyS1ru for <tsvwg@ietfa.amsl.com>; Mon, 2 Apr 2012 09:49:38 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8695021F8711 for <tsvwg@ietf.org>; Mon, 2 Apr 2012 09:49:37 -0700 (PDT)
Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 2 Apr 2012 17:49:35 +0100
Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.191]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Mon, 2 Apr 2012 17:49:35 +0100
From: philip.eardley@bt.com
To: gorry@erg.abdn.ac.uk, tsvwg@ietf.org
Date: Mon, 02 Apr 2012 17:49:46 +0100
Subject: RE: Note: WGLC Announcement for draft-ietf-tsvwg-byte-pkt-congest-07
Thread-Topic: Note: WGLC Announcement for draft-ietf-tsvwg-byte-pkt-congest-07
Thread-Index: Ac0M4vKqnp7S76aSSPemhojy7VLG0AEAz1CA
Message-ID: <9510D26531EF184D9017DF24659BB87F332793C419@EMV65-UKRD.domain1.systemhost.net>
References: <4F605902.40009@erg.abdn.ac.uk> <4F730BAC.4040602@erg.abdn.ac.uk>
In-Reply-To: <4F730BAC.4040602@erg.abdn.ac.uk>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 16:49:38 -0000

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: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of Gorry Fairhurst
Sent: 28 March 2012 14:02
To: tsvwg@ietf.org
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)
tsvwg-chairs@ietf.org