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
- WGLC Announcement for draft-ietf-tsvwg-iana-ports… Gorry Fairhurst
- Re: WGLC Announcement for draft-ietf-tsvwg-iana-p… t.petch
- Re: WGLC Announcement for draft-ietf-tsvwg-iana-p… Magnus Westerlund
- Re: WGLC Announcement for draft-ietf-tsvwg-iana-p… t.petch
- Re: WGLC Announcement for draft-ietf-tsvwg-iana-p… Magnus Westerlund
- Re: WGLC Announcement for draft-ietf-tsvwg-iana-p… t.petch
- WGLC Announcement for draft-ietf-tsvwg-source-que… Gorry Fairhurst
- WGLC Announcement for draft-ietf-tsvwg-byte-pkt-c… Gorry Fairhurst
- Note: WGLC Announcement for draft-ietf-tsvwg-byte… Gorry Fairhurst
- Re: Note: WGLC Announcement for draft-ietf-tsvwg-… John Leslie
- RE: Note: WGLC Announcement for draft-ietf-tsvwg-… philip.eardley
- Re: Note: WGLC Announcement for draft-ietf-tsvwg-… Bob Briscoe
- Re: Note: WGLC Announcement for draft-ietf-tsvwg-… John Leslie
- Re: [tsvwg] Note: WGLC Announcement for draft-iet… Manner Jukka
- [tsvwg] WGLC Announcement for draft-ietf-tsvwg-sc… Gorry Fairhurst
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Black, David
- [tsvwg] WGLC Announcement for draft-ietf-tsvwg-sc… Gorry Fairhurst
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Michael Tuexen
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Black, David
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Michael Tuexen
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Yoshifumi Nishida
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Michael Tuexen
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Michael Welzl
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Michael Tuexen
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Yoshifumi Nishida
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Thomas Dreibholz
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Thomas Dreibholz
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Michael Welzl
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Becke, Martin
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Becke, Martin
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Michael Welzl
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Thomas Dreibholz
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Thomas Dreibholz
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Michael Tuexen
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Michael Tuexen
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Michael Welzl
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Michael Tuexen
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Michael Welzl
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Anna Brunstrom
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Irene Rüngeler
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Michael Tuexen
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Anna Brunstrom
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Michael Tuexen
- [tsvwg] WGLC for draft-ietf-tsvwg-sctp-sack-immed… gorry
- Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-sack-i… Michael Tuexen
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Randy Stewart
- Re: [tsvwg] WGLC Announcement for draft-ietf-tsvw… Yoshifumi Nishida