From wwwrun@rfc-editor.org Tue Jun 4 08:24:25 2013 Return-Path: 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 BEC4A21F85F7 for ; Tue, 4 Jun 2013 08:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.953 X-Spam-Level: X-Spam-Status: No, score=-101.953 tagged_above=-999 required=5 tests=[AWL=0.647, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 fXXKVcanC+WH for ; Tue, 4 Jun 2013 08:24:06 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 52C8B21F9C88 for ; Tue, 4 Jun 2013 06:31:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5CF5EB1E003; Tue, 4 Jun 2013 06:30:09 -0700 (PDT) To: kk@teraoptic.com, floyd@aciri.org, black_david@emc.com, spencerdawkins.ietf@gmail.com, martin.stiemerling@neclab.eu, gorry@erg.abdn.ac.uk, david.black@emc.com, jmpolk@cisco.com From: RFC Errata System Message-Id: <20130604133009.5CF5EB1E003@rfc-editor.org> Date: Tue, 4 Jun 2013 06:30:09 -0700 (PDT) Cc: tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [tsvwg] [Editorial Errata Reported] RFC3168 (3636) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 15:24:25 -0000 The following errata report has been submitted for RFC3168, "The Addition of Explicit Congestion Notification (ECN) to IP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3168&eid=3636 -------------------------------------- Type: Editorial Reported by: Mirja Kühlewind Section: 6.1.1. Original Text ------------- If the TCP connection does not wish to use ECN notification for a particular packet, the sending TCP sets the ECN codepoint to not-ECT, and the TCP receiver ignores the CE codepoint in the received packet. Corrected Text -------------- If the TCP connection does not wish to use ECN notification for a particular packet, the sending TCP sets the ECN codepoint to not-ECT. Notes ----- CE should not be set on not-ECT capable packets. If this happens anyway, the CE codepoint would overwrite the ECT codepoint. Thus there is no way for the receiver to know it should ignore the CE codepoint; the sentence is therefore nonsensical. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3168 (draft-ietf-tsvwg-ecn-04) -------------------------------------- Title : The Addition of Explicit Congestion Notification (ECN) to IP Publication Date : September 2001 Author(s) : K. Ramakrishnan, S. Floyd, D. Black Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From david.black@emc.com Tue Jun 4 08:50:16 2013 Return-Path: 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 F112521F9EA0 for ; Tue, 4 Jun 2013 08:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Jem0wOsRTCPa for ; Tue, 4 Jun 2013 08:50:02 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id BF67921F9E3C for ; Tue, 4 Jun 2013 06:50:14 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r54Do4oe009592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Jun 2013 09:50:06 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 4 Jun 2013 09:49:50 -0400 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r54DnmaU022411; Tue, 4 Jun 2013 09:49:49 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Tue, 4 Jun 2013 09:49:48 -0400 From: "Black, David" To: RFC Errata System , "kk@teraoptic.com" , "floyd@aciri.org" , "spencerdawkins.ietf@gmail.com" , "martin.stiemerling@neclab.eu" , "gorry@erg.abdn.ac.uk" , "jmpolk@cisco.com" Date: Tue, 4 Jun 2013 09:49:48 -0400 Thread-Topic: [Editorial Errata Reported] RFC3168 (3636) Thread-Index: Ac5hJ+grbpLLLSvDQmONo7Yw7q245AAAXGUg Message-ID: <8D3D17ACE214DC429325B2B98F3AE712980C9B6E@MX15A.corp.emc.com> References: <20130604133009.5CF5EB1E003@rfc-editor.org> In-Reply-To: <20130604133009.5CF5EB1E003@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (3636) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 15:50:16 -0000 While the basic facts are correct, specifically that the receiver cannot determine whether CE has been erroneously set on a not-ECT-marked packet, I don't think this errata should be applied. The original sentence was intended to refer to independent actions by the sender and receiver, and was not supposed to imply that the receiver would ignore a received CE marking as a consequence of a not-ECT being applied by the sender. The following editorial clarification would improve the text (add "endpoint", and insert the word "independently"): Original Text ------------- If the TCP connection does not wish to use ECN notification for a particular packet, the sending TCP sets the ECN codepoint to not-ECT, and the TCP receiver ignores the CE codepoint in the received packet. Corrected Text -------------- If either endpoint of the TCP connection does not wish to use ECN notification for a particular packet, the sending TCP sets the ECN codepoint to not-ECT, and the TCP receiver independently ignores a CE codepoint in the received packet. Thanks, --David > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: Tuesday, June 04, 2013 9:30 AM > To: kk@teraoptic.com; floyd@aciri.org; Black, David; > spencerdawkins.ietf@gmail.com; martin.stiemerling@neclab.eu; > gorry@erg.abdn.ac.uk; Black, David; jmpolk@cisco.com > Cc: mirja.kuehlewind@ikr.uni-stuttgart.de; tsvwg@ietf.org; rfc-editor@rfc= - > editor.org > Subject: [Editorial Errata Reported] RFC3168 (3636) >=20 > The following errata report has been submitted for RFC3168, > "The Addition of Explicit Congestion Notification (ECN) to IP". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D3168&eid=3D3636 >=20 > -------------------------------------- > Type: Editorial > Reported by: Mirja K=FChlewind >=20 > Section: 6.1.1. >=20 > Original Text > ------------- > If the TCP connection does not > wish to use ECN notification for a particular packet, the sending TCP > sets the ECN codepoint to not-ECT, and the TCP receiver ignores the > CE codepoint in the received packet. >=20 > Corrected Text > -------------- > If the TCP connection does not > wish to use ECN notification for a particular packet, the sending TCP > sets the ECN codepoint to not-ECT. >=20 > Notes > ----- > CE should not be set on not-ECT capable packets. If this happens anyway, = the > CE codepoint would overwrite the ECT codepoint. Thus there is no way for = the > receiver to know it should ignore the CE codepoint; the sentence is there= fore > nonsensical. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC3168 (draft-ietf-tsvwg-ecn-04) > -------------------------------------- > Title : The Addition of Explicit Congestion Notification (E= CN) > to IP > Publication Date : September 2001 > Author(s) : K. Ramakrishnan, S. Floyd, D. Black > Category : PROPOSED STANDARD > Source : Transport Area Working Group > Area : Transport > Stream : IETF > Verifying Party : IESG From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Jun 4 09:37:49 2013 Return-Path: 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 BFB3B21F9C27 for ; Tue, 4 Jun 2013 09:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[AWL=0.973, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 BASh-aTFDK3U for ; Tue, 4 Jun 2013 09:37:34 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id DA4DA21F9AB0 for ; Tue, 4 Jun 2013 07:22:00 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 68371601FC; Tue, 4 Jun 2013 16:21:58 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 6477C601FA; Tue, 4 Jun 2013 16:21:58 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: "Black, David" Date: Tue, 4 Jun 2013 16:21:58 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <20130604133009.5CF5EB1E003@rfc-editor.org> <8D3D17ACE214DC429325B2B98F3AE712980C9B6E@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712980C9B6E@MX15A.corp.emc.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201306041621.58362.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , "floyd@aciri.org" , "kk@teraoptic.com" , "jmpolk@cisco.com" , RFC Errata System Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (3636) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:37:50 -0000 That means the sentence should say that an ECN receiver can choose for ever= y=20 received CE to ignore it? What's the sense behind this? (Maybe this is a=20 technical erratum then, as e.g. ECN Nonce was designed to prevent exactly=20 this behavior.) If not, the sentence is still not very clear. Maybe splitting it up into tw= o=20 sentences would help: Original Text =2D------------ If the TCP connection does not wish to use ECN notification for a particular packet, the sending TCP sets the ECN codepoint to not-ECT, and the TCP receiver ignores the CE codepoint in the received packet. Corrected Text =2D------------- If the sending TCP does not wish to use ECN notification for a particular packet, it sets the ECN codepoint to not-ECT. If the TCP receiver independently doe= s =09 not wish to use ECN notification for a particular packet, it ignores a CE codepoint in the received packet. Mirja=20 On Tuesday 04 June 2013 15:49:48 Black, David wrote: > While the basic facts are correct, specifically that the receiver cannot > determine whether CE has been erroneously set on a not-ECT-marked packet, > I don't think this errata should be applied. > > The original sentence was intended to refer to independent actions by > the sender and receiver, and was not supposed to imply that the receiver > would ignore a received CE marking as a consequence of a not-ECT being > applied by the sender. > > The following editorial clarification would improve the text (add > "endpoint", and insert the word "independently"): > > Original Text > ------------- > If the TCP connection does not > wish to use ECN notification for a particular packet, the sending TCP > sets the ECN codepoint to not-ECT, and the TCP receiver ignores the > CE codepoint in the received packet. > > Corrected Text > -------------- > If either endpoint of the TCP connection does not > wish to use ECN notification for a particular packet, the sending TCP > sets the ECN codepoint to not-ECT, and the TCP receiver independently > ignores a CE codepoint in the received packet. > > Thanks, > --David > > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > Sent: Tuesday, June 04, 2013 9:30 AM > > To: kk@teraoptic.com; floyd@aciri.org; Black, David; > > spencerdawkins.ietf@gmail.com; martin.stiemerling@neclab.eu; > > gorry@erg.abdn.ac.uk; Black, David; jmpolk@cisco.com > > Cc: mirja.kuehlewind@ikr.uni-stuttgart.de; tsvwg@ietf.org; > > rfc-editor@rfc- editor.org > > Subject: [Editorial Errata Reported] RFC3168 (3636) > > > > The following errata report has been submitted for RFC3168, > > "The Addition of Explicit Congestion Notification (ECN) to IP". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D3168&eid=3D3636 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Mirja K=FChlewind > > > > Section: 6.1.1. > > > > Original Text > > ------------- > > If the TCP connection does not > > wish to use ECN notification for a particular packet, the sending TCP > > sets the ECN codepoint to not-ECT, and the TCP receiver ignores the > > CE codepoint in the received packet. > > > > Corrected Text > > -------------- > > If the TCP connection does not > > wish to use ECN notification for a particular packet, the sending TCP > > sets the ECN codepoint to not-ECT. > > > > Notes > > ----- > > CE should not be set on not-ECT capable packets. If this happens anyway, > > the CE codepoint would overwrite the ECT codepoint. Thus there is no way > > for the receiver to know it should ignore the CE codepoint; the sentence > > is therefore nonsensical. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC3168 (draft-ietf-tsvwg-ecn-04) > > -------------------------------------- > > Title : The Addition of Explicit Congestion Notification > > (ECN) to IP > > Publication Date : September 2001 > > Author(s) : K. Ramakrishnan, S. Floyd, D. Black > > Category : PROPOSED STANDARD > > Source : Transport Area Working Group > > Area : Transport > > Stream : IETF > > Verifying Party : IESG =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From david.black@emc.com Tue Jun 4 12:57:20 2013 Return-Path: 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 D654921F93D2 for ; Tue, 4 Jun 2013 12:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 VmgOQhgtjMWV for ; Tue, 4 Jun 2013 12:57:16 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id D242521F9B30 for ; Tue, 4 Jun 2013 12:00:37 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r54J0SSL018429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Jun 2013 15:00:30 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 4 Jun 2013 15:00:18 -0400 Received: from mxhub27.corp.emc.com (mxhub27.corp.emc.com [10.254.110.183]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r54J0FmR015596; Tue, 4 Jun 2013 15:00:16 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub27.corp.emc.com ([10.254.110.183]) with mapi; Tue, 4 Jun 2013 15:00:15 -0400 From: "Black, David" To: Mirja Kuehlewind Date: Tue, 4 Jun 2013 15:00:14 -0400 Thread-Topic: [Editorial Errata Reported] RFC3168 (3636) Thread-Index: Ac5hLuRHcU/HereuTIK+Pd2IjIQXJQAJEWMQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712980C9C7F@MX15A.corp.emc.com> References: <20130604133009.5CF5EB1E003@rfc-editor.org> <8D3D17ACE214DC429325B2B98F3AE712980C9B6E@MX15A.corp.emc.com> <201306041621.58362.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201306041621.58362.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , "floyd@aciri.org" , "kk@teraoptic.com" , "jmpolk@cisco.com" , RFC Errata System Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (3636) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 19:57:21 -0000 For more context, here's the entire paragraph that contains the sentence in question: 6.1.1 TCP Initialization In the TCP connection setup phase, the source and destination TCPs exchange information about their willingness to use ECN. Subsequent to the completion of this negotiation, the TCP sender sets an ECT codepoint in the IP header of data packets to indicate to the network that the transport is capable and willing to participate in ECN for this packet. This indicates to the routers that they may mark this packet with the CE codepoint, if they would like to use that as a method of congestion notification. If the TCP connection does not wish to use ECN notification for a particular packet, the sending TCP sets the ECN codepoint to not-ECT, and the TCP receiver ignores the CE codepoint in the received packet. That's not stating that "an ECN receiver can choose for every received CE to ignore it" - rather (at least as I read the text), it's stating that for a small specific fraction of the packets ("particular") the sender and receiver somehow know or have agreed in advance that ECN is not to be used, and such packets are sent as not-ECT with CE ignored on receipt. This is all rather hypothetical, as I agree with Mirja's underlying sense that once ECN is enabled on a TCP connection, it SHOULD be used with every packet. All in all, it may be better to pursue some sort of technical that as opposed to trying to clean up this text editorially. It is dangerous for receivers to ignore CE markings if there is any possibility that the CE marking was applied as a congestion indication, and the original sentence can be read as allowing that dangerous behavior. The simplest way out of this may be to re-classify the errata (which removes the text that refers to that receiver behavior) as technical, and proceed from there. Thanks, --David > -----Original Message----- > From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] > Sent: Tuesday, June 04, 2013 10:22 AM > To: Black, David > Cc: RFC Errata System; kk@teraoptic.com; floyd@aciri.org; > spencerdawkins.ietf@gmail.com; martin.stiemerling@neclab.eu; > gorry@erg.abdn.ac.uk; jmpolk@cisco.com; tsvwg@ietf.org > Subject: Re: [Editorial Errata Reported] RFC3168 (3636) >=20 > That means the sentence should say that an ECN receiver can choose for ev= ery > received CE to ignore it? What's the sense behind this? (Maybe this is a > technical erratum then, as e.g. ECN Nonce was designed to prevent exactly > this behavior.) >=20 > If not, the sentence is still not very clear. Maybe splitting it up into = two > sentences would help: >=20 > Original Text > ------------- > If the TCP connection does not > wish to use ECN notification for a particular packet, the sending TCP > sets the ECN codepoint to not-ECT, and the TCP receiver ignores the > CE codepoint in the received packet. >=20 > Corrected Text > -------------- > If the sending TCP does not > wish to use ECN notification for a particular packet, it > sets the ECN codepoint to not-ECT. If the TCP receiver independently d= oes > not wish to use ECN notification for a particular packet, it ignores a= CE > codepoint in the received packet. >=20 >=20 > Mirja >=20 >=20 > On Tuesday 04 June 2013 15:49:48 Black, David wrote: > > While the basic facts are correct, specifically that the receiver canno= t > > determine whether CE has been erroneously set on a not-ECT-marked packe= t, > > I don't think this errata should be applied. > > > > The original sentence was intended to refer to independent actions by > > the sender and receiver, and was not supposed to imply that the receive= r > > would ignore a received CE marking as a consequence of a not-ECT being > > applied by the sender. > > > > The following editorial clarification would improve the text (add > > "endpoint", and insert the word "independently"): > > > > Original Text > > ------------- > > If the TCP connection does not > > wish to use ECN notification for a particular packet, the sending TC= P > > sets the ECN codepoint to not-ECT, and the TCP receiver ignores the > > CE codepoint in the received packet. > > > > Corrected Text > > -------------- > > If either endpoint of the TCP connection does not > > wish to use ECN notification for a particular packet, the sending TC= P > > sets the ECN codepoint to not-ECT, and the TCP receiver independentl= y > > ignores a CE codepoint in the received packet. > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > > Sent: Tuesday, June 04, 2013 9:30 AM > > > To: kk@teraoptic.com; floyd@aciri.org; Black, David; > > > spencerdawkins.ietf@gmail.com; martin.stiemerling@neclab.eu; > > > gorry@erg.abdn.ac.uk; Black, David; jmpolk@cisco.com > > > Cc: mirja.kuehlewind@ikr.uni-stuttgart.de; tsvwg@ietf.org; > > > rfc-editor@rfc- editor.org > > > Subject: [Editorial Errata Reported] RFC3168 (3636) > > > > > > The following errata report has been submitted for RFC3168, > > > "The Addition of Explicit Congestion Notification (ECN) to IP". > > > > > > -------------------------------------- > > > You may review the report below and at: > > > http://www.rfc-editor.org/errata_search.php?rfc=3D3168&eid=3D3636 > > > > > > -------------------------------------- > > > Type: Editorial > > > Reported by: Mirja K=FChlewind > > > > > > Section: 6.1.1. > > > > > > Original Text > > > ------------- > > > If the TCP connection does not > > > wish to use ECN notification for a particular packet, the sending = TCP > > > sets the ECN codepoint to not-ECT, and the TCP receiver ignores th= e > > > CE codepoint in the received packet. > > > > > > Corrected Text > > > -------------- > > > If the TCP connection does not > > > wish to use ECN notification for a particular packet, the sending = TCP > > > sets the ECN codepoint to not-ECT. > > > > > > Notes > > > ----- > > > CE should not be set on not-ECT capable packets. If this happens anyw= ay, > > > the CE codepoint would overwrite the ECT codepoint. Thus there is no = way > > > for the receiver to know it should ignore the CE codepoint; the sente= nce > > > is therefore nonsensical. > > > > > > Instructions: > > > ------------- > > > This errata is currently posted as "Reported". If necessary, please > > > use "Reply All" to discuss whether it should be verified or > > > rejected. When a decision is reached, the verifying party (IESG) > > > can log in to change the status and edit the report, if necessary. > > > > > > -------------------------------------- > > > RFC3168 (draft-ietf-tsvwg-ecn-04) > > > -------------------------------------- > > > Title : The Addition of Explicit Congestion Notificatio= n > > > (ECN) to IP > > > Publication Date : September 2001 > > > Author(s) : K. Ramakrishnan, S. Floyd, D. Black > > > Category : PROPOSED STANDARD > > > Source : Transport Area Working Group > > > Area : Transport > > > Stream : IETF > > > Verifying Party : IESG >=20 >=20 >=20 > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart >=20 > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- From rs@netapp.com Wed Jun 5 03:32:06 2013 Return-Path: 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 92E2821F99C0 for ; Wed, 5 Jun 2013 03:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.524 X-Spam-Level: X-Spam-Status: No, score=-9.524 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 cMXjnexvyUtR for ; Wed, 5 Jun 2013 03:32:02 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id A0C7F21F99AA for ; Wed, 5 Jun 2013 03:31:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,804,1363158000"; d="scan'208";a="61709778" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 05 Jun 2013 03:31:58 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r55AVuSL012751; Wed, 5 Jun 2013 03:31:56 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Wed, 5 Jun 2013 03:31:56 -0700 From: "Scheffenegger, Richard" To: "Black, David" , Mirja Kuehlewind Thread-Topic: [Editorial Errata Reported] RFC3168 (3636) Thread-Index: AQHOYV3PuKETtyTnA0CjQMcAYGwwRZkm642w Date: Wed, 5 Jun 2013 10:31:55 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24BCBCA8@SACEXCMBX02-PRD.hq.netapp.com> References: <20130604133009.5CF5EB1E003@rfc-editor.org> <8D3D17ACE214DC429325B2B98F3AE712980C9B6E@MX15A.corp.emc.com> <201306041621.58362.mirja.kuehlewind@ikr.uni-stuttgart.de> <8D3D17ACE214DC429325B2B98F3AE712980C9C7F@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712980C9C7F@MX15A.corp.emc.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , "floyd@aciri.org" , "kk@teraoptic.com" , "jmpolk@cisco.com" , RFC Errata System Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (3636) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 10:32:06 -0000 Hi David, While we are at it - 3168 is also missing another aspect: The receipt of a CE-marked CWR TCP segment... In 3168 the exact TCP interaction behavior is not described sufficiently; w= hen I investigated this aspect, I found that all derivatives of BSD used to= =20 First, set ECE because of CE Second, reset ECE because of CWR While the NS2 "sample" code, Sally's TBIT tool, Windows, Solaris and Linux = would First, reset ECE because of CWR Second, set ECE because of CE. It appeared to be, that the latter approach is the sensible one, and it was= quickly fixed. http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039450.html I guess I'm asking if that clarification should be filed against 3168 to be= eventually included in an update? Best regards, Richard Scheffenegger > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Black, David > Sent: Dienstag, 04. Juni 2013 21:00 > To: Mirja Kuehlewind > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org; floyd@aciri.org; > kk@teraoptic.com; jmpolk@cisco.com; RFC Errata System > Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (3636) >=20 > For more context, here's the entire paragraph that contains the sentence > in question: >=20 > 6.1.1 TCP Initialization >=20 > In the TCP connection setup phase, the source and destination TCPs > exchange information about their willingness to use ECN. Subsequent > to the completion of this negotiation, the TCP sender sets an ECT > codepoint in the IP header of data packets to indicate to the network > that the transport is capable and willing to participate in ECN for > this packet. This indicates to the routers that they may mark this > packet with the CE codepoint, if they would like to use that as a > method of congestion notification. If the TCP connection does not > wish to use ECN notification for a particular packet, the sending TCP > sets the ECN codepoint to not-ECT, and the TCP receiver ignores the > CE codepoint in the received packet. >=20 > That's not stating that "an ECN receiver can choose for every received CE > to ignore it" - rather (at least as I read the text), it's stating that > for a small specific fraction of the packets ("particular") the sender an= d > receiver somehow know or have agreed in advance that ECN is not to be > used, and such packets are sent as not-ECT with CE ignored on receipt. >=20 > This is all rather hypothetical, as I agree with Mirja's underlying sense > that once ECN is enabled on a TCP connection, it SHOULD be used with ever= y > packet. All in all, it may be better to pursue some sort of technical > that as opposed to trying to clean up this text editorially. >=20 > It is dangerous for receivers to ignore CE markings if there is any > possibility that the CE marking was applied as a congestion indication, > and the original sentence can be read as allowing that dangerous behavior= . > The simplest way out of this may be to re-classify the errata (which > removes the text that refers to that receiver behavior) as technical, and > proceed from there. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] > > Sent: Tuesday, June 04, 2013 10:22 AM > > To: Black, David > > Cc: RFC Errata System; kk@teraoptic.com; floyd@aciri.org; > > spencerdawkins.ietf@gmail.com; martin.stiemerling@neclab.eu; > > gorry@erg.abdn.ac.uk; jmpolk@cisco.com; tsvwg@ietf.org > > Subject: Re: [Editorial Errata Reported] RFC3168 (3636) > > > > That means the sentence should say that an ECN receiver can choose for > > every received CE to ignore it? What's the sense behind this? (Maybe > > this is a technical erratum then, as e.g. ECN Nonce was designed to > > prevent exactly this behavior.) > > > > If not, the sentence is still not very clear. Maybe splitting it up > > into two sentences would help: > > > > Original Text > > ------------- > > If the TCP connection does not > > wish to use ECN notification for a particular packet, the sending TC= P > > sets the ECN codepoint to not-ECT, and the TCP receiver ignores the > > CE codepoint in the received packet. > > > > Corrected Text > > -------------- > > If the sending TCP does not > > wish to use ECN notification for a particular packet, it > > sets the ECN codepoint to not-ECT. If the TCP receiver independently > does > > not wish to use ECN notification for a particular packet, it ignores > a CE > > codepoint in the received packet. > > > > > > Mirja > > > > > > On Tuesday 04 June 2013 15:49:48 Black, David wrote: > > > While the basic facts are correct, specifically that the receiver > > > cannot determine whether CE has been erroneously set on a > > > not-ECT-marked packet, I don't think this errata should be applied. > > > > > > The original sentence was intended to refer to independent actions > > > by the sender and receiver, and was not supposed to imply that the > > > receiver would ignore a received CE marking as a consequence of a > > > not-ECT being applied by the sender. > > > > > > The following editorial clarification would improve the text (add > > > "endpoint", and insert the word "independently"): > > > > > > Original Text > > > ------------- > > > If the TCP connection does not > > > wish to use ECN notification for a particular packet, the sending > TCP > > > sets the ECN codepoint to not-ECT, and the TCP receiver ignores th= e > > > CE codepoint in the received packet. > > > > > > Corrected Text > > > -------------- > > > If either endpoint of the TCP connection does not > > > wish to use ECN notification for a particular packet, the sending > TCP > > > sets the ECN codepoint to not-ECT, and the TCP receiver > independently > > > ignores a CE codepoint in the received packet. > > > > > > Thanks, > > > --David > > > > > > > -----Original Message----- > > > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > > > Sent: Tuesday, June 04, 2013 9:30 AM > > > > To: kk@teraoptic.com; floyd@aciri.org; Black, David; > > > > spencerdawkins.ietf@gmail.com; martin.stiemerling@neclab.eu; > > > > gorry@erg.abdn.ac.uk; Black, David; jmpolk@cisco.com > > > > Cc: mirja.kuehlewind@ikr.uni-stuttgart.de; tsvwg@ietf.org; > > > > rfc-editor@rfc- editor.org > > > > Subject: [Editorial Errata Reported] RFC3168 (3636) > > > > > > > > The following errata report has been submitted for RFC3168, "The > > > > Addition of Explicit Congestion Notification (ECN) to IP". > > > > > > > > -------------------------------------- > > > > You may review the report below and at: > > > > http://www.rfc-editor.org/errata_search.php?rfc=3D3168&eid=3D3636 > > > > > > > > -------------------------------------- > > > > Type: Editorial > > > > Reported by: Mirja K=FChlewind > > > > > > > > > > > > Section: 6.1.1. > > > > > > > > Original Text > > > > ------------- > > > > If the TCP connection does not > > > > wish to use ECN notification for a particular packet, the sendin= g > TCP > > > > sets the ECN codepoint to not-ECT, and the TCP receiver ignores > the > > > > CE codepoint in the received packet. > > > > > > > > Corrected Text > > > > -------------- > > > > If the TCP connection does not > > > > wish to use ECN notification for a particular packet, the sendin= g > TCP > > > > sets the ECN codepoint to not-ECT. > > > > > > > > Notes > > > > ----- > > > > CE should not be set on not-ECT capable packets. If this happens > > > > anyway, the CE codepoint would overwrite the ECT codepoint. Thus > > > > there is no way for the receiver to know it should ignore the CE > > > > codepoint; the sentence is therefore nonsensical. > > > > > > > > Instructions: > > > > ------------- > > > > This errata is currently posted as "Reported". If necessary, > > > > please use "Reply All" to discuss whether it should be verified or > > > > rejected. When a decision is reached, the verifying party (IESG) > > > > can log in to change the status and edit the report, if necessary. > > > > > > > > -------------------------------------- > > > > RFC3168 (draft-ietf-tsvwg-ecn-04) > > > > -------------------------------------- > > > > Title : The Addition of Explicit Congestion > Notification > > > > (ECN) to IP > > > > Publication Date : September 2001 > > > > Author(s) : K. Ramakrishnan, S. Floyd, D. Black > > > > Category : PROPOSED STANDARD > > > > Source : Transport Area Working Group > > > > Area : Transport > > > > Stream : IETF > > > > Verifying Party : IESG > > > > > > > > -- > > ------------------------------------------------------------------- > > Dipl.-Ing. Mirja K=FChlewind > > Institute of Communication Networks and Computer Engineering (IKR) > > University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart > > > > tel: +49(0)711/685-67973 > > email: mirja.kuehlewind@ikr.uni-stuttgart.de > > web: www.ikr.uni-stuttgart.de > > ------------------------------------------------------------------- From david.black@emc.com Wed Jun 5 06:40:25 2013 Return-Path: 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 B8EF721F9AAC for ; Wed, 5 Jun 2013 06:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 qRVC0Z9Oh48B for ; Wed, 5 Jun 2013 06:40:21 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id C0E8221F91AB for ; Wed, 5 Jun 2013 06:40:21 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r55DeAGk016397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Jun 2013 09:40:13 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 5 Jun 2013 09:39:50 -0400 Received: from mxhub34.corp.emc.com (mxhub34.corp.emc.com [10.254.93.82]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r55Ddm5A011527; Wed, 5 Jun 2013 09:39:48 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub34.corp.emc.com ([::1]) with mapi; Wed, 5 Jun 2013 09:39:48 -0400 From: "Black, David" To: "Scheffenegger, Richard" , Mirja Kuehlewind Date: Wed, 5 Jun 2013 09:39:47 -0400 Thread-Topic: [Editorial Errata Reported] RFC3168 (3636) Thread-Index: AQHOYV3PuKETtyTnA0CjQMcAYGwwRZkm642wgAA12zA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712980C9DB6@MX15A.corp.emc.com> References: <20130604133009.5CF5EB1E003@rfc-editor.org> <8D3D17ACE214DC429325B2B98F3AE712980C9B6E@MX15A.corp.emc.com> <201306041621.58362.mirja.kuehlewind@ikr.uni-stuttgart.de> <8D3D17ACE214DC429325B2B98F3AE712980C9C7F@MX15A.corp.emc.com> <012C3117EDDB3C4781FD802A8C27DD4F24BCBCA8@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24BCBCA8@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , "floyd@aciri.org" , "kk@teraoptic.com" , "jmpolk@cisco.com" , RFC Errata System Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (3636) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 13:40:25 -0000 Yes, filing this as an errata would be a good thing to do. Thanks, --David > -----Original Message----- > From: Scheffenegger, Richard [mailto:rs@netapp.com] > Sent: Wednesday, June 05, 2013 6:32 AM > To: Black, David; Mirja Kuehlewind > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org; floyd@aciri.org; kk@teraoptic.c= om; > jmpolk@cisco.com; RFC Errata System > Subject: RE: [Editorial Errata Reported] RFC3168 (3636) >=20 > Hi David, >=20 >=20 > While we are at it - 3168 is also missing another aspect: >=20 > The receipt of a CE-marked CWR TCP segment... >=20 > In 3168 the exact TCP interaction behavior is not described sufficiently;= when > I investigated this aspect, I found that all derivatives of BSD used to >=20 > First, set ECE because of CE > Second, reset ECE because of CWR >=20 > While the NS2 "sample" code, Sally's TBIT tool, Windows, Solaris and Linu= x > would >=20 > First, reset ECE because of CWR > Second, set ECE because of CE. >=20 > It appeared to be, that the latter approach is the sensible one, and it w= as > quickly fixed. >=20 > http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039450.html >=20 >=20 > I guess I'm asking if that clarification should be filed against 3168 to = be > eventually included in an update? >=20 > Best regards, >=20 > Richard Scheffenegger >=20 >=20 >=20 > > -----Original Message----- > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf = Of > > Black, David > > Sent: Dienstag, 04. Juni 2013 21:00 > > To: Mirja Kuehlewind > > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org; floyd@aciri.org; > > kk@teraoptic.com; jmpolk@cisco.com; RFC Errata System > > Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (3636) > > > > For more context, here's the entire paragraph that contains the sentenc= e > > in question: > > > > 6.1.1 TCP Initialization > > > > In the TCP connection setup phase, the source and destination TCPs > > exchange information about their willingness to use ECN. Subsequent > > to the completion of this negotiation, the TCP sender sets an ECT > > codepoint in the IP header of data packets to indicate to the networ= k > > that the transport is capable and willing to participate in ECN for > > this packet. This indicates to the routers that they may mark this > > packet with the CE codepoint, if they would like to use that as a > > method of congestion notification. If the TCP connection does not > > wish to use ECN notification for a particular packet, the sending TC= P > > sets the ECN codepoint to not-ECT, and the TCP receiver ignores the > > CE codepoint in the received packet. > > > > That's not stating that "an ECN receiver can choose for every received = CE > > to ignore it" - rather (at least as I read the text), it's stating that > > for a small specific fraction of the packets ("particular") the sender = and > > receiver somehow know or have agreed in advance that ECN is not to be > > used, and such packets are sent as not-ECT with CE ignored on receipt. > > > > This is all rather hypothetical, as I agree with Mirja's underlying sen= se > > that once ECN is enabled on a TCP connection, it SHOULD be used with ev= ery > > packet. All in all, it may be better to pursue some sort of technical > > that as opposed to trying to clean up this text editorially. > > > > It is dangerous for receivers to ignore CE markings if there is any > > possibility that the CE marking was applied as a congestion indication, > > and the original sentence can be read as allowing that dangerous behavi= or. > > The simplest way out of this may be to re-classify the errata (which > > removes the text that refers to that receiver behavior) as technical, a= nd > > proceed from there. > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] > > > Sent: Tuesday, June 04, 2013 10:22 AM > > > To: Black, David > > > Cc: RFC Errata System; kk@teraoptic.com; floyd@aciri.org; > > > spencerdawkins.ietf@gmail.com; martin.stiemerling@neclab.eu; > > > gorry@erg.abdn.ac.uk; jmpolk@cisco.com; tsvwg@ietf.org > > > Subject: Re: [Editorial Errata Reported] RFC3168 (3636) > > > > > > That means the sentence should say that an ECN receiver can choose fo= r > > > every received CE to ignore it? What's the sense behind this? (Maybe > > > this is a technical erratum then, as e.g. ECN Nonce was designed to > > > prevent exactly this behavior.) > > > > > > If not, the sentence is still not very clear. Maybe splitting it up > > > into two sentences would help: > > > > > > Original Text > > > ------------- > > > If the TCP connection does not > > > wish to use ECN notification for a particular packet, the sending = TCP > > > sets the ECN codepoint to not-ECT, and the TCP receiver ignores th= e > > > CE codepoint in the received packet. > > > > > > Corrected Text > > > -------------- > > > If the sending TCP does not > > > wish to use ECN notification for a particular packet, it > > > sets the ECN codepoint to not-ECT. If the TCP receiver independent= ly > > does > > > not wish to use ECN notification for a particular packet, it ignor= es > > a CE > > > codepoint in the received packet. > > > > > > > > > Mirja > > > > > > > > > On Tuesday 04 June 2013 15:49:48 Black, David wrote: > > > > While the basic facts are correct, specifically that the receiver > > > > cannot determine whether CE has been erroneously set on a > > > > not-ECT-marked packet, I don't think this errata should be applied. > > > > > > > > The original sentence was intended to refer to independent actions > > > > by the sender and receiver, and was not supposed to imply that the > > > > receiver would ignore a received CE marking as a consequence of a > > > > not-ECT being applied by the sender. > > > > > > > > The following editorial clarification would improve the text (add > > > > "endpoint", and insert the word "independently"): > > > > > > > > Original Text > > > > ------------- > > > > If the TCP connection does not > > > > wish to use ECN notification for a particular packet, the sendin= g > > TCP > > > > sets the ECN codepoint to not-ECT, and the TCP receiver ignores = the > > > > CE codepoint in the received packet. > > > > > > > > Corrected Text > > > > -------------- > > > > If either endpoint of the TCP connection does not > > > > wish to use ECN notification for a particular packet, the sendin= g > > TCP > > > > sets the ECN codepoint to not-ECT, and the TCP receiver > > independently > > > > ignores a CE codepoint in the received packet. > > > > > > > > Thanks, > > > > --David > > > > > > > > > -----Original Message----- > > > > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > > > > Sent: Tuesday, June 04, 2013 9:30 AM > > > > > To: kk@teraoptic.com; floyd@aciri.org; Black, David; > > > > > spencerdawkins.ietf@gmail.com; martin.stiemerling@neclab.eu; > > > > > gorry@erg.abdn.ac.uk; Black, David; jmpolk@cisco.com > > > > > Cc: mirja.kuehlewind@ikr.uni-stuttgart.de; tsvwg@ietf.org; > > > > > rfc-editor@rfc- editor.org > > > > > Subject: [Editorial Errata Reported] RFC3168 (3636) > > > > > > > > > > The following errata report has been submitted for RFC3168, "The > > > > > Addition of Explicit Congestion Notification (ECN) to IP". > > > > > > > > > > -------------------------------------- > > > > > You may review the report below and at: > > > > > http://www.rfc-editor.org/errata_search.php?rfc=3D3168&eid=3D3636 > > > > > > > > > > -------------------------------------- > > > > > Type: Editorial > > > > > Reported by: Mirja K=FChlewind > > > > > > > > > > > > > > > Section: 6.1.1. > > > > > > > > > > Original Text > > > > > ------------- > > > > > If the TCP connection does not > > > > > wish to use ECN notification for a particular packet, the send= ing > > TCP > > > > > sets the ECN codepoint to not-ECT, and the TCP receiver ignore= s > > the > > > > > CE codepoint in the received packet. > > > > > > > > > > Corrected Text > > > > > -------------- > > > > > If the TCP connection does not > > > > > wish to use ECN notification for a particular packet, the send= ing > > TCP > > > > > sets the ECN codepoint to not-ECT. > > > > > > > > > > Notes > > > > > ----- > > > > > CE should not be set on not-ECT capable packets. If this happens > > > > > anyway, the CE codepoint would overwrite the ECT codepoint. Thus > > > > > there is no way for the receiver to know it should ignore the CE > > > > > codepoint; the sentence is therefore nonsensical. > > > > > > > > > > Instructions: > > > > > ------------- > > > > > This errata is currently posted as "Reported". If necessary, > > > > > please use "Reply All" to discuss whether it should be verified o= r > > > > > rejected. When a decision is reached, the verifying party (IESG) > > > > > can log in to change the status and edit the report, if necessary= . > > > > > > > > > > -------------------------------------- > > > > > RFC3168 (draft-ietf-tsvwg-ecn-04) > > > > > -------------------------------------- > > > > > Title : The Addition of Explicit Congestion > > Notification > > > > > (ECN) to IP > > > > > Publication Date : September 2001 > > > > > Author(s) : K. Ramakrishnan, S. Floyd, D. Black > > > > > Category : PROPOSED STANDARD > > > > > Source : Transport Area Working Group > > > > > Area : Transport > > > > > Stream : IETF > > > > > Verifying Party : IESG > > > > > > > > > > > > -- > > > ------------------------------------------------------------------- > > > Dipl.-Ing. Mirja K=FChlewind > > > Institute of Communication Networks and Computer Engineering (IKR) > > > University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgar= t > > > > > > tel: +49(0)711/685-67973 > > > email: mirja.kuehlewind@ikr.uni-stuttgart.de > > > web: www.ikr.uni-stuttgart.de > > > ------------------------------------------------------------------- >=20 From lucy.yong@huawei.com Wed Jun 5 07:11:18 2013 Return-Path: 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 E914D21F957B for ; Wed, 5 Jun 2013 07:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 odvIcSc9V8Aj for ; Wed, 5 Jun 2013 07:11:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2061421F9133 for ; Wed, 5 Jun 2013 07:11:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASD27654; Wed, 05 Jun 2013 14:11:11 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 5 Jun 2013 15:10:21 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 5 Jun 2013 15:11:08 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Wed, 5 Jun 2013 07:10:58 -0700 From: Lucy yong To: "tsvwg@ietf.org" Thread-Topic: New Version Notification for draft-yong-tsvwg-gre-in-udp-encap-00.txt Thread-Index: AQHOYVOXrM7TkrO1ZkSye6NMVAdrVZknJbbA Date: Wed, 5 Jun 2013 14:10:58 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4526F6AA@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.69] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Xuxiaohu , Edward Crabbe Subject: [tsvwg] FW: New Version Notification for draft-yong-tsvwg-gre-in-udp-encap-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:11:19 -0000 DQpIZWxsbywNCg0KRllJLiBXZSB1cGxvYWQgdGhpcyBuZXcgZHJhZnQgdGhhdCBhZGRyZXNzZXMg dGhlIGlucHV0cyBhbmQgc3VnZ2VzdGlvbnMgZm9yIGRyYWZ0LXlvbmctdHN2d2ctdXBkLWVuY3At NC1pcC10dW5uZWxpbmcgcHJpb3IgdG8gYW5kIGluIElFVEY4Ni4gTG9vayBmb3J3YXJkIHRvIHNl ZWluZyB0aGUgZmVlZGJhY2sgb24gdGhpcyBkcmFmdC4NCg0KVGhhbmtzLA0KTHVjeQ0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogVHVlc2RheSwgSnVu ZSAwNCwgMjAxMyAxOjQyIFBNDQo+IFRvOiBFZHdhcmQgQ3JhYmJlOyBMdWN5IHlvbmc7IFh1eGlh b2h1OyBYdXhpYW9odQ0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LXlvbmctdHN2d2ctZ3JlLWluLXVkcC0NCj4gZW5jYXAtMDAudHh0DQo+IA0KPiANCj4gQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXlvbmctdHN2d2ctZ3JlLWluLXVkcC1lbmNhcC0wMC50 eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBFZHdhcmQgQ3JhYmJlIGFu ZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJh ZnQteW9uZy10c3Z3Zy1ncmUtaW4tdWRwLWVuY2FwDQo+IFJldmlzaW9uOgkgMDANCj4gVGl0bGU6 CQkgR2VuZXJpYyBVRFAgRW5jYXBzdWxhdGlvbiBmb3IgSVAgVHVubmVsaW5nDQo+IENyZWF0aW9u IGRhdGU6CSAyMDEzLTA2LTA0DQo+IEdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBO dW1iZXIgb2YgcGFnZXM6IDEwDQo+IFVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteW9uZy10c3Z3Zy0NCj4gZ3JlLWluLXVkcC1lbmNhcC0w MC50eHQNCj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXlvbmctdHN2d2ctZ3JlLQ0KPiBpbi11ZHAtZW5jYXANCj4gSHRtbGl6ZWQ6ICAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15b25nLXRzdndnLWdyZS1pbi0NCj4g dWRwLWVuY2FwLTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzIGEgbWV0aG9kIG9mIGVuY2Fwc3VsYXRpbmcgYXJiaXRyYXJ5DQo+IHByb3RvY29scw0K PiAgICB3aXRoaW4gVURQIGFuZCBHUkUgaGVhZGVycy4gIEluIHRoaXMgZW5jYXBzdWxhdGlvbiwg dGhlIHNvdXJjZSBVRFANCj4gICAgcG9ydCBtYXkgYmUgdXNlZCBhcyBhbiBlbnRyb3B5IGZpZWxk IGZvciBwdXJwb3NlcyBvZiBsb2FkIGJhbGFuY2luZw0KPiAgICB3aGlsZSB0aGUgcGF5bG9hZCBw cm90b2NvbCBtYXkgYmUgaWRlbnRpZmllZCBieSB0aGUgR1JFIFByb3RvY29sDQo+ICAgIFR5cGUu DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From gorry@erg.abdn.ac.uk Wed Jun 5 07:25:23 2013 Return-Path: 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 08B0621F93D2 for ; Wed, 5 Jun 2013 07:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.203 X-Spam-Level: X-Spam-Status: No, score=-105.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 cC4CrAXDCWue for ; Wed, 5 Jun 2013 07:25:18 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 75FBB21F915B for ; Wed, 5 Jun 2013 07:25:02 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 38BBC2B44D5; Wed, 5 Jun 2013 15:25:01 +0100 (BST) Received: from [137.50.87.75] (oa-edu-87-75.wireless.abdn.ac.uk [137.50.87.75]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPA id 577422B41C8; Wed, 5 Jun 2013 15:24:51 +0100 (BST) References: <20130604133009.5CF5EB1E003@rfc-editor.org> <8D3D17ACE214DC429325B2B98F3AE712980C9B6E@MX15A.corp.emc.com> <201306041621.58362.mirja.kuehlewind@ikr.uni-stuttgart.de> <8D3D17ACE214DC429325B2B98F3AE712980C9C7F@MX15A.corp.emc.com> <012C3117EDDB3C4781FD802A8C27DD4F24BCBCA8@SACEXCMBX02-PRD.hq.netapp.com> <8D3D17ACE214DC429325B2B98F3AE712980C9DB6@MX15A.corp.emc.com> Mime-Version: 1.0 (1.0) In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712980C9DB6@MX15A.corp.emc.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B146) From: Gorry Date: Wed, 5 Jun 2013 15:24:49 +0100 To: "Black, David" Cc: "tsvwg@ietf.org" , "floyd@aciri.org" , "kk@teraoptic.com" , "jmpolk@cisco.com" , RFC Errata System Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (3636) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:25:23 -0000 I agree it would be good to propose an Erata, this seems like a small, but s= ignificant clarification. Gorry Sent from my iPad On 5 Jun 2013, at 14:39, "Black, David" wrote: > Yes, filing this as an errata would be a good thing to do. >=20 > Thanks, > --David >=20 >=20 >> -----Original Message----- >> From: Scheffenegger, Richard [mailto:rs@netapp.com] >> Sent: Wednesday, June 05, 2013 6:32 AM >> To: Black, David; Mirja Kuehlewind >> Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org; floyd@aciri.org; kk@teraoptic.c= om; >> jmpolk@cisco.com; RFC Errata System >> Subject: RE: [Editorial Errata Reported] RFC3168 (3636) >>=20 >> Hi David, >>=20 >>=20 >> While we are at it - 3168 is also missing another aspect: >>=20 >> The receipt of a CE-marked CWR TCP segment... >>=20 >> In 3168 the exact TCP interaction behavior is not described sufficiently;= when >> I investigated this aspect, I found that all derivatives of BSD used to >>=20 >> First, set ECE because of CE >> Second, reset ECE because of CWR >>=20 >> While the NS2 "sample" code, Sally's TBIT tool, Windows, Solaris and Linu= x >> would >>=20 >> First, reset ECE because of CWR >> Second, set ECE because of CE. >>=20 >> It appeared to be, that the latter approach is the sensible one, and it w= as >> quickly fixed. >>=20 >> http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039450.html >>=20 >>=20 >> I guess I'm asking if that clarification should be filed against 3168 to b= e >> eventually included in an update? >>=20 >> Best regards, >>=20 >> Richard Scheffenegger >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf O= f >>> Black, David >>> Sent: Dienstag, 04. Juni 2013 21:00 >>> To: Mirja Kuehlewind >>> Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org; floyd@aciri.org; >>> kk@teraoptic.com; jmpolk@cisco.com; RFC Errata System >>> Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (3636) >>>=20 >>> For more context, here's the entire paragraph that contains the sentence= >>> in question: >>>=20 >>> 6.1.1 TCP Initialization >>>=20 >>> In the TCP connection setup phase, the source and destination TCPs >>> exchange information about their willingness to use ECN. Subsequent >>> to the completion of this negotiation, the TCP sender sets an ECT >>> codepoint in the IP header of data packets to indicate to the network >>> that the transport is capable and willing to participate in ECN for >>> this packet. This indicates to the routers that they may mark this >>> packet with the CE codepoint, if they would like to use that as a >>> method of congestion notification. If the TCP connection does not >>> wish to use ECN notification for a particular packet, the sending TCP >>> sets the ECN codepoint to not-ECT, and the TCP receiver ignores the >>> CE codepoint in the received packet. >>>=20 >>> That's not stating that "an ECN receiver can choose for every received C= E >>> to ignore it" - rather (at least as I read the text), it's stating that >>> for a small specific fraction of the packets ("particular") the sender a= nd >>> receiver somehow know or have agreed in advance that ECN is not to be >>> used, and such packets are sent as not-ECT with CE ignored on receipt. >>>=20 >>> This is all rather hypothetical, as I agree with Mirja's underlying sens= e >>> that once ECN is enabled on a TCP connection, it SHOULD be used with eve= ry >>> packet. All in all, it may be better to pursue some sort of technical >>> that as opposed to trying to clean up this text editorially. >>>=20 >>> It is dangerous for receivers to ignore CE markings if there is any >>> possibility that the CE marking was applied as a congestion indication, >>> and the original sentence can be read as allowing that dangerous behavio= r. >>> The simplest way out of this may be to re-classify the errata (which >>> removes the text that refers to that receiver behavior) as technical, an= d >>> proceed from there. >>>=20 >>> Thanks, >>> --David >>>=20 >>>> -----Original Message----- >>>> From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] >>>> Sent: Tuesday, June 04, 2013 10:22 AM >>>> To: Black, David >>>> Cc: RFC Errata System; kk@teraoptic.com; floyd@aciri.org; >>>> spencerdawkins.ietf@gmail.com; martin.stiemerling@neclab.eu; >>>> gorry@erg.abdn.ac.uk; jmpolk@cisco.com; tsvwg@ietf.org >>>> Subject: Re: [Editorial Errata Reported] RFC3168 (3636) >>>>=20 >>>> That means the sentence should say that an ECN receiver can choose for >>>> every received CE to ignore it? What's the sense behind this? (Maybe >>>> this is a technical erratum then, as e.g. ECN Nonce was designed to >>>> prevent exactly this behavior.) >>>>=20 >>>> If not, the sentence is still not very clear. Maybe splitting it up >>>> into two sentences would help: >>>>=20 >>>> Original Text >>>> ------------- >>>> If the TCP connection does not >>>> wish to use ECN notification for a particular packet, the sending TCP= >>>> sets the ECN codepoint to not-ECT, and the TCP receiver ignores the >>>> CE codepoint in the received packet. >>>>=20 >>>> Corrected Text >>>> -------------- >>>> If the sending TCP does not >>>> wish to use ECN notification for a particular packet, it >>>> sets the ECN codepoint to not-ECT. If the TCP receiver independently >>> does >>>> not wish to use ECN notification for a particular packet, it ignores >>> a CE >>>> codepoint in the received packet. >>>>=20 >>>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>> On Tuesday 04 June 2013 15:49:48 Black, David wrote: >>>>> While the basic facts are correct, specifically that the receiver >>>>> cannot determine whether CE has been erroneously set on a >>>>> not-ECT-marked packet, I don't think this errata should be applied. >>>>>=20 >>>>> The original sentence was intended to refer to independent actions >>>>> by the sender and receiver, and was not supposed to imply that the >>>>> receiver would ignore a received CE marking as a consequence of a >>>>> not-ECT being applied by the sender. >>>>>=20 >>>>> The following editorial clarification would improve the text (add >>>>> "endpoint", and insert the word "independently"): >>>>>=20 >>>>> Original Text >>>>> ------------- >>>>> If the TCP connection does not >>>>> wish to use ECN notification for a particular packet, the sending >>> TCP >>>>> sets the ECN codepoint to not-ECT, and the TCP receiver ignores the >>>>> CE codepoint in the received packet. >>>>>=20 >>>>> Corrected Text >>>>> -------------- >>>>> If either endpoint of the TCP connection does not >>>>> wish to use ECN notification for a particular packet, the sending >>> TCP >>>>> sets the ECN codepoint to not-ECT, and the TCP receiver >>> independently >>>>> ignores a CE codepoint in the received packet. >>>>>=20 >>>>> Thanks, >>>>> --David >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>>>> Sent: Tuesday, June 04, 2013 9:30 AM >>>>>> To: kk@teraoptic.com; floyd@aciri.org; Black, David; >>>>>> spencerdawkins.ietf@gmail.com; martin.stiemerling@neclab.eu; >>>>>> gorry@erg.abdn.ac.uk; Black, David; jmpolk@cisco.com >>>>>> Cc: mirja.kuehlewind@ikr.uni-stuttgart.de; tsvwg@ietf.org; >>>>>> rfc-editor@rfc- editor.org >>>>>> Subject: [Editorial Errata Reported] RFC3168 (3636) >>>>>>=20 >>>>>> The following errata report has been submitted for RFC3168, "The >>>>>> Addition of Explicit Congestion Notification (ECN) to IP". >>>>>>=20 >>>>>> -------------------------------------- >>>>>> You may review the report below and at: >>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D3168&eid=3D3636 >>>>>>=20 >>>>>> -------------------------------------- >>>>>> Type: Editorial >>>>>> Reported by: Mirja K=C3=BChlewind >>>>>> >>>>>>=20 >>>>>> Section: 6.1.1. >>>>>>=20 >>>>>> Original Text >>>>>> ------------- >>>>>> If the TCP connection does not >>>>>> wish to use ECN notification for a particular packet, the sending >>> TCP >>>>>> sets the ECN codepoint to not-ECT, and the TCP receiver ignores >>> the >>>>>> CE codepoint in the received packet. >>>>>>=20 >>>>>> Corrected Text >>>>>> -------------- >>>>>> If the TCP connection does not >>>>>> wish to use ECN notification for a particular packet, the sending >>> TCP >>>>>> sets the ECN codepoint to not-ECT. >>>>>>=20 >>>>>> Notes >>>>>> ----- >>>>>> CE should not be set on not-ECT capable packets. If this happens >>>>>> anyway, the CE codepoint would overwrite the ECT codepoint. Thus >>>>>> there is no way for the receiver to know it should ignore the CE >>>>>> codepoint; the sentence is therefore nonsensical. >>>>>>=20 >>>>>> Instructions: >>>>>> ------------- >>>>>> This errata is currently posted as "Reported". If necessary, >>>>>> please use "Reply All" to discuss whether it should be verified or >>>>>> rejected. When a decision is reached, the verifying party (IESG) >>>>>> can log in to change the status and edit the report, if necessary. >>>>>>=20 >>>>>> -------------------------------------- >>>>>> RFC3168 (draft-ietf-tsvwg-ecn-04) >>>>>> -------------------------------------- >>>>>> Title : The Addition of Explicit Congestion >>> Notification >>>>>> (ECN) to IP >>>>>> Publication Date : September 2001 >>>>>> Author(s) : K. Ramakrishnan, S. Floyd, D. Black >>>>>> Category : PROPOSED STANDARD >>>>>> Source : Transport Area Working Group >>>>>> Area : Transport >>>>>> Stream : IETF >>>>>> Verifying Party : IESG >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> ------------------------------------------------------------------- >>>> Dipl.-Ing. Mirja K=C3=BChlewind >>>> Institute of Communication Networks and Computer Engineering (IKR) >>>> University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart >>>>=20 >>>> tel: +49(0)711/685-67973 >>>> email: mirja.kuehlewind@ikr.uni-stuttgart.de >>>> web: www.ikr.uni-stuttgart.de >>>> ------------------------------------------------------------------- >>=20 From wwwrun@rfc-editor.org Wed Jun 5 13:13:25 2013 Return-Path: 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 BA73221F9B12 for ; Wed, 5 Jun 2013 13:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.209 X-Spam-Level: X-Spam-Status: No, score=-102.209 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 au4dmPcqpEFe for ; Wed, 5 Jun 2013 13:13:23 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id B5D0021F9AFF for ; Wed, 5 Jun 2013 13:12:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2441E62113; Wed, 5 Jun 2013 13:11:02 -0700 (PDT) To: kk@teraoptic.com, floyd@aciri.org, black_david@emc.com, spencerdawkins.ietf@gmail.com, martin.stiemerling@neclab.eu, gorry@erg.abdn.ac.uk, david.black@emc.com, jmpolk@cisco.com From: RFC Errata System Message-Id: <20130605201102.2441E62113@rfc-editor.org> Date: Wed, 5 Jun 2013 13:11:02 -0700 (PDT) Cc: tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [tsvwg] [Technical Errata Reported] RFC3168 (3639) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 20:13:25 -0000 The following errata report has been submitted for RFC3168, "The Addition of Explicit Congestion Notification (ECN) to IP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3168&eid=3639 -------------------------------------- Type: Technical Reported by: Richard Scheffenegger Section: 6.1 / 6.1.3 Original Text ------------- Section 6.1 says: * The receiver receives the packet with the CE codepoint set, and sets the ECN-Echo flag in its next TCP ACK sent to the sender. [...] * The sender sets the CWR flag in the TCP header of the next packet sent to the receiver to acknowledge its receipt of and reaction to the ECN-Echo flag. Section 6.1.3 says: When TCP receives a CE data packet at the destination end-system, the TCP data receiver sets the ECN-Echo flag in the TCP header of the subsequent ACK packet. [...] The TCP receiver uses the CWR flag received from the TCP sender to determine when to stop setting the ECN-Echo flag. Corrected Text -------------- Section 6.1.3 should say: The TCP receiver uses the CWR flag received from the TCP sender to determine when to stop setting the ECN-Echo flag. This check has to be performed before checking if the received segment is CE marked. Notes ----- The ordering of the text in the bullet points in section 6.1, and the text in section 6.1.3 can led to inappropriate implementations. At least Section 6.1.3 should be strict about the handling of CE-marked CWR-segments. If CE is checked first, and ECE set, and thereafter CWR used to disable ECE, a CE-marked CWR segment will not result in the sending of an additional window of ECEs. All derivatives of BSD used to First, set ECE because of CE Second, reset ECE because of CWR However, the "authorative" NS2 sample code, the TBIT tool, Windows, Solaris and Linux would First, reset ECE because of CWR Second, set ECE because of CE The latter approach seems to be the sensible one, and it was quickly fixed: http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039450.html Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3168 (draft-ietf-tsvwg-ecn-04) -------------------------------------- Title : The Addition of Explicit Congestion Notification (ECN) to IP Publication Date : September 2001 Author(s) : K. Ramakrishnan, S. Floyd, D. Black Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From rs@netapp.com Wed Jun 5 13:13:30 2013 Return-Path: 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 AE31921F9B06 for ; Wed, 5 Jun 2013 13:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.739 X-Spam-Level: X-Spam-Status: No, score=-9.739 tagged_above=-999 required=5 tests=[AWL=0.860, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 CvS8-+110Kev for ; Wed, 5 Jun 2013 13:13:26 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id A426021F9AFE for ; Wed, 5 Jun 2013 13:13:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,809,1363158000"; d="scan'208";a="61899060" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 05 Jun 2013 13:13:08 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r55KD6IW022380; Wed, 5 Jun 2013 13:13:07 -0700 (PDT) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht01-prd.hq.netapp.com (10.106.76.239) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 5 Jun 2013 13:13:07 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Wed, 5 Jun 2013 13:13:06 -0700 From: "Scheffenegger, Richard" To: "Black, David" , Mirja Kuehlewind Thread-Topic: [Editorial Errata Reported] RFC3168 (3636) Thread-Index: AQHOYV3PuKETtyTnA0CjQMcAYGwwRZkm642wgAA12zCAAG6K0A== Date: Wed, 5 Jun 2013 20:13:06 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24BCD9EC@SACEXCMBX02-PRD.hq.netapp.com> References: <20130604133009.5CF5EB1E003@rfc-editor.org> <8D3D17ACE214DC429325B2B98F3AE712980C9B6E@MX15A.corp.emc.com> <201306041621.58362.mirja.kuehlewind@ikr.uni-stuttgart.de> <8D3D17ACE214DC429325B2B98F3AE712980C9C7F@MX15A.corp.emc.com> <012C3117EDDB3C4781FD802A8C27DD4F24BCBCA8@SACEXCMBX02-PRD.hq.netapp.com> <8D3D17ACE214DC429325B2B98F3AE712980C9DB6@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712980C9DB6@MX15A.corp.emc.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , "floyd@aciri.org" , "kk@teraoptic.com" , "jmpolk@cisco.com" , RFC Errata System Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (3636) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 20:13:30 -0000 Done, Richard Scheffenegger > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Mittwoch, 05. Juni 2013 15:40 > To: Scheffenegger, Richard; Mirja Kuehlewind > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org; floyd@aciri.org; > kk@teraoptic.com; jmpolk@cisco.com; RFC Errata System; Black, David > Subject: RE: [Editorial Errata Reported] RFC3168 (3636) >=20 > Yes, filing this as an errata would be a good thing to do. >=20 > Thanks, > --David >=20 >=20 > > -----Original Message----- > > From: Scheffenegger, Richard [mailto:rs@netapp.com] > > Sent: Wednesday, June 05, 2013 6:32 AM > > To: Black, David; Mirja Kuehlewind > > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org; floyd@aciri.org; > > kk@teraoptic.com; jmpolk@cisco.com; RFC Errata System > > Subject: RE: [Editorial Errata Reported] RFC3168 (3636) > > > > Hi David, > > > > > > While we are at it - 3168 is also missing another aspect: > > > > The receipt of a CE-marked CWR TCP segment... > > > > In 3168 the exact TCP interaction behavior is not described > > sufficiently; when I investigated this aspect, I found that all > > derivatives of BSD used to > > > > First, set ECE because of CE > > Second, reset ECE because of CWR > > > > While the NS2 "sample" code, Sally's TBIT tool, Windows, Solaris and > > Linux would > > > > First, reset ECE because of CWR > > Second, set ECE because of CE. > > > > It appeared to be, that the latter approach is the sensible one, and > > it was quickly fixed. > > > > http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039450.html > > > > > > I guess I'm asking if that clarification should be filed against 3168 > > to be eventually included in an update? > > > > Best regards, > > > > Richard Scheffenegger > > > > > > > > > -----Original Message----- > > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On > > > Behalf Of Black, David > > > Sent: Dienstag, 04. Juni 2013 21:00 > > > To: Mirja Kuehlewind > > > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org; floyd@aciri.org; > > > kk@teraoptic.com; jmpolk@cisco.com; RFC Errata System > > > Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (3636) > > > > > > For more context, here's the entire paragraph that contains the > > > sentence in question: > > > > > > 6.1.1 TCP Initialization > > > > > > In the TCP connection setup phase, the source and destination TCPs > > > exchange information about their willingness to use ECN. > Subsequent > > > to the completion of this negotiation, the TCP sender sets an ECT > > > codepoint in the IP header of data packets to indicate to the > network > > > that the transport is capable and willing to participate in ECN fo= r > > > this packet. This indicates to the routers that they may mark this > > > packet with the CE codepoint, if they would like to use that as a > > > method of congestion notification. If the TCP connection does not > > > wish to use ECN notification for a particular packet, the sending > TCP > > > sets the ECN codepoint to not-ECT, and the TCP receiver ignores th= e > > > CE codepoint in the received packet. > > > > > > That's not stating that "an ECN receiver can choose for every > > > received CE to ignore it" - rather (at least as I read the text), > > > it's stating that for a small specific fraction of the packets > > > ("particular") the sender and receiver somehow know or have agreed > > > in advance that ECN is not to be used, and such packets are sent as > not-ECT with CE ignored on receipt. > > > > > > This is all rather hypothetical, as I agree with Mirja's underlying > > > sense that once ECN is enabled on a TCP connection, it SHOULD be > > > used with every packet. All in all, it may be better to pursue some > > > sort of technical that as opposed to trying to clean up this text > editorially. > > > > > > It is dangerous for receivers to ignore CE markings if there is any > > > possibility that the CE marking was applied as a congestion > > > indication, and the original sentence can be read as allowing that > dangerous behavior. > > > The simplest way out of this may be to re-classify the errata (which > > > removes the text that refers to that receiver behavior) as > > > technical, and proceed from there. > > > > > > Thanks, > > > --David > > > > > > > -----Original Message----- > > > > From: Mirja Kuehlewind > > > > [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] > > > > Sent: Tuesday, June 04, 2013 10:22 AM > > > > To: Black, David > > > > Cc: RFC Errata System; kk@teraoptic.com; floyd@aciri.org; > > > > spencerdawkins.ietf@gmail.com; martin.stiemerling@neclab.eu; > > > > gorry@erg.abdn.ac.uk; jmpolk@cisco.com; tsvwg@ietf.org > > > > Subject: Re: [Editorial Errata Reported] RFC3168 (3636) > > > > > > > > That means the sentence should say that an ECN receiver can choose > > > > for every received CE to ignore it? What's the sense behind this? > > > > (Maybe this is a technical erratum then, as e.g. ECN Nonce was > > > > designed to prevent exactly this behavior.) > > > > > > > > If not, the sentence is still not very clear. Maybe splitting it > > > > up into two sentences would help: > > > > > > > > Original Text > > > > ------------- > > > > If the TCP connection does not > > > > wish to use ECN notification for a particular packet, the sendin= g > TCP > > > > sets the ECN codepoint to not-ECT, and the TCP receiver ignores > the > > > > CE codepoint in the received packet. > > > > > > > > Corrected Text > > > > -------------- > > > > If the sending TCP does not > > > > wish to use ECN notification for a particular packet, it > > > > sets the ECN codepoint to not-ECT. If the TCP receiver > > > > independently > > > does > > > > not wish to use ECN notification for a particular packet, it > > > > ignores > > > a CE > > > > codepoint in the received packet. > > > > > > > > > > > > Mirja > > > > > > > > > > > > On Tuesday 04 June 2013 15:49:48 Black, David wrote: > > > > > While the basic facts are correct, specifically that the > > > > > receiver cannot determine whether CE has been erroneously set on > > > > > a not-ECT-marked packet, I don't think this errata should be > applied. > > > > > > > > > > The original sentence was intended to refer to independent > > > > > actions by the sender and receiver, and was not supposed to > > > > > imply that the receiver would ignore a received CE marking as a > > > > > consequence of a not-ECT being applied by the sender. > > > > > > > > > > The following editorial clarification would improve the text > > > > > (add "endpoint", and insert the word "independently"): > > > > > > > > > > Original Text > > > > > ------------- > > > > > If the TCP connection does not > > > > > wish to use ECN notification for a particular packet, the > > > > > sending > > > TCP > > > > > sets the ECN codepoint to not-ECT, and the TCP receiver ignore= s > the > > > > > CE codepoint in the received packet. > > > > > > > > > > Corrected Text > > > > > -------------- > > > > > If either endpoint of the TCP connection does not > > > > > wish to use ECN notification for a particular packet, the > > > > > sending > > > TCP > > > > > sets the ECN codepoint to not-ECT, and the TCP receiver > > > independently > > > > > ignores a CE codepoint in the received packet. > > > > > > > > > > Thanks, > > > > > --David > > > > > > > > > > > -----Original Message----- > > > > > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > > > > > Sent: Tuesday, June 04, 2013 9:30 AM > > > > > > To: kk@teraoptic.com; floyd@aciri.org; Black, David; > > > > > > spencerdawkins.ietf@gmail.com; martin.stiemerling@neclab.eu; > > > > > > gorry@erg.abdn.ac.uk; Black, David; jmpolk@cisco.com > > > > > > Cc: mirja.kuehlewind@ikr.uni-stuttgart.de; tsvwg@ietf.org; > > > > > > rfc-editor@rfc- editor.org > > > > > > Subject: [Editorial Errata Reported] RFC3168 (3636) > > > > > > > > > > > > The following errata report has been submitted for RFC3168, > > > > > > "The Addition of Explicit Congestion Notification (ECN) to IP". > > > > > > > > > > > > -------------------------------------- > > > > > > You may review the report below and at: > > > > > > http://www.rfc-editor.org/errata_search.php?rfc=3D3168&eid=3D36= 36 > > > > > > > > > > > > -------------------------------------- > > > > > > Type: Editorial > > > > > > Reported by: Mirja K=FChlewind > > > > > > > > > > > > > > > > > > Section: 6.1.1. > > > > > > > > > > > > Original Text > > > > > > ------------- > > > > > > If the TCP connection does not > > > > > > wish to use ECN notification for a particular packet, the > > > > > > sending > > > TCP > > > > > > sets the ECN codepoint to not-ECT, and the TCP receiver > > > > > > ignores > > > the > > > > > > CE codepoint in the received packet. > > > > > > > > > > > > Corrected Text > > > > > > -------------- > > > > > > If the TCP connection does not > > > > > > wish to use ECN notification for a particular packet, the > > > > > > sending > > > TCP > > > > > > sets the ECN codepoint to not-ECT. > > > > > > > > > > > > Notes > > > > > > ----- > > > > > > CE should not be set on not-ECT capable packets. If this > > > > > > happens anyway, the CE codepoint would overwrite the ECT > > > > > > codepoint. Thus there is no way for the receiver to know it > > > > > > should ignore the CE codepoint; the sentence is therefore > nonsensical. > > > > > > > > > > > > Instructions: > > > > > > ------------- > > > > > > This errata is currently posted as "Reported". If necessary, > > > > > > please use "Reply All" to discuss whether it should be > > > > > > verified or rejected. When a decision is reached, the > > > > > > verifying party (IESG) can log in to change the status and edit > the report, if necessary. > > > > > > > > > > > > -------------------------------------- > > > > > > RFC3168 (draft-ietf-tsvwg-ecn-04) > > > > > > -------------------------------------- > > > > > > Title : The Addition of Explicit Congestion > > > Notification > > > > > > (ECN) to IP > > > > > > Publication Date : September 2001 > > > > > > Author(s) : K. Ramakrishnan, S. Floyd, D. Black > > > > > > Category : PROPOSED STANDARD > > > > > > Source : Transport Area Working Group > > > > > > Area : Transport > > > > > > Stream : IETF > > > > > > Verifying Party : IESG > > > > > > > > > > > > > > > > -- > > > > ------------------------------------------------------------------ > > > > - > > > > Dipl.-Ing. Mirja K=FChlewind > > > > Institute of Communication Networks and Computer Engineering (IKR) > > > > University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 > > > > Stuttgart > > > > > > > > tel: +49(0)711/685-67973 > > > > email: mirja.kuehlewind@ikr.uni-stuttgart.de > > > > web: www.ikr.uni-stuttgart.de > > > > ------------------------------------------------------------------ > > > > - > > From gjshep@gmail.com Thu Jun 13 08:29:36 2013 Return-Path: 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 45ED721F855F for ; Thu, 13 Jun 2013 08:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 hA8xp84IC6d8 for ; Thu, 13 Jun 2013 08:29:31 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 077CD21F99EE for ; Thu, 13 Jun 2013 08:29:27 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id n11so1724339wgh.21 for ; Thu, 13 Jun 2013 08:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=gj9azWuIgQc51M3AZII0JjM77r7ZxebTZ2WwVPhxpcQ=; b=0Rp3lf+F3ZUt/MkA5lxrcSJsY1R0boalFlHsWdb+msPdN2OIJ2IrZDSmZOyKPL86li QzwNajaZS65cJtzc4EgmQruzGib4DInVoBN7+6gmeTqaWQQhizgs2gpJ/WJJIig123bn frhmCg0tPCr948D5Yk72cEReIVX44ykKeTY7FRB4Bd/yb/E6VoI2C6NOVqDzFoZ0HKO4 w6JsdmPYzeX3HXgMQzZfNKWjxQzHBQQBB4NCmZSXc92WN+DK24LfeWvam0sSJs6E2gPD FtX9mecFaxZkztftHiF4cDNfRlfd0E53tdfLJeIRA+WX2WsOeYgVDGoxZc8tItvWNN4d X2jw== MIME-Version: 1.0 X-Received: by 10.194.6.37 with SMTP id x5mr925179wjx.35.1371137366835; Thu, 13 Jun 2013 08:29:26 -0700 (PDT) Received: by 10.180.189.12 with HTTP; Thu, 13 Jun 2013 08:29:26 -0700 (PDT) Date: Thu, 13 Jun 2013 08:29:26 -0700 Message-ID: From: Greg Shepherd To: Gorry Fairhurst , David Black , James Polk , Spencer Dawkins , tsvwg@ietf.org Content-Type: multipart/alternative; boundary=047d7b5d9acdb0476004df0acb24 Subject: [tsvwg] Fwd: Confirmation for Auto-Post of I-D draft-shepherd-multicast-udp-guidelines X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:29:36 -0000 --047d7b5d9acdb0476004df0acb24 Content-Type: text/plain; charset=ISO-8859-1 I'd like an agenda slot in Berlin to discuss this work. Thanks, Greg ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Wed, Jun 12, 2013 at 10:30 AM Subject: Confirmation for Auto-Post of I-D draft-shepherd-multicast-udp-guidelines To: Greg Shepherd Hi, The IETF datatracker draft submission service has received your draft draft-shepherd-multicast-udp-guidelines-01, and requires a confirmation step in order to be able to complete the posting of the draft. Please follow this link to the page where you can confirm the posting: Confirmation URL: http://datatracker.ietf.org/submit/status/51145/confirm/1b4e70f5499fef25c2d9d6c7990b8e06df9c81b8/ Best regards, The IETF Secretariat through the draft submission service --047d7b5d9acdb0476004df0acb24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I'd like an agenda slot in Berlin to discuss this = work.

Thanks,
Greg

---------- Forwarded message ----------
From: IETF I-D Submission Tool <idsubmission@ietf.org>
Date: Wed, Jun 12, 2013 at 10:30 AM
Subject: Confirmation for Auto-Post = of I-D draft-shepherd-multicast-udp-guidelines
To: Greg Shepherd <gjshep@gmail.com>



Hi,

The IETF datatracker draft submission service has received your draft
draft-shepherd-multicast-udp-guidelines-01, and requires a
confirmation step in order to be able to complete the posting of
the draft.

Please follow this link to the page where you can confirm the posting:
Confirmation URL: http= ://datatracker.ietf.org/submit/status/51145/confirm/1b4e70f5499fef25c2d9d6c= 7990b8e06df9c81b8/


Best regards,

=A0 =A0 =A0 =A0 The IETF Secretariat
=A0 =A0 =A0 =A0 through the draft submission service



--047d7b5d9acdb0476004df0acb24-- From lars@netapp.com Thu Jun 13 08:49:22 2013 Return-Path: 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 1F97921F98AD for ; Thu, 13 Jun 2013 08:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.921 X-Spam-Level: X-Spam-Status: No, score=-8.921 tagged_above=-999 required=5 tests=[AWL=1.678, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ZY+oo2HnYX5Q for ; Thu, 13 Jun 2013 08:49:17 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1717621F96D9 for ; Thu, 13 Jun 2013 08:49:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,859,1363158000"; d="scan'208";a="263580010" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx1-out.netapp.com with ESMTP; 13 Jun 2013 08:49:15 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.48]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Thu, 13 Jun 2013 08:49:14 -0700 From: "Eggert, Lars" To: "" Thread-Topic: [tsvwg] Confirmation for Auto-Post of I-D draft-shepherd-multicast-udp-guidelines Thread-Index: AQHOaE2Mnj8IyqRYJEC0VtnUPmSarg== Date: Thu, 13 Jun 2013 15:49:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.118] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gorry Fairhurst , James Polk , "" Subject: Re: [tsvwg] Confirmation for Auto-Post of I-D draft-shepherd-multicast-udp-guidelines X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:49:22 -0000 Hi Greg, On Jun 13, 2013, at 17:29, Greg Shepherd wrote: > I'd like an agenda slot in Berlin to discuss this work. I'm generally in favor of this ID, because it fills an obvious void left by= RFC5405. I'd be curious to know why Section 2.1.4 doesn't follow the guidelines for = picking an MTU given in Section 3.2 of RFC5405 and instead always recommend= s 1280 bytes? Lars= From gjshep@gmail.com Thu Jun 13 09:17:22 2013 Return-Path: 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 A709821F9A4E for ; Thu, 13 Jun 2013 09:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 KNpS-HnKfciI for ; Thu, 13 Jun 2013 09:17:22 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id B794F21F960D for ; Thu, 13 Jun 2013 09:17:21 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so4016545wgh.18 for ; Thu, 13 Jun 2013 09:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=r/d5ym+1z2KXZ7IfHJl0c/FsNMpc/xcxnN1PhU6dezA=; b=S1msHbr7rO1o3Dvyj3xF8ICDU6zyVjL1sABmPqnW5LY35MZuC2arLFTgKlCOts6DDK 4Ka/7A6iDLfIgiZmQIGhmdM8IM52+U3ssqKe8h0prgPKUYbbmG4ymp2BBTpbPfH5hXqN BZWZ808GHPjOZKuL1m6LkAeksxwuPRG4VWVSOwtFDSHwHeWN/pqd1/TVzuZYTr2NvO3i /FfHDwyKaubEXFOSFPgVHYqSX1HZkPOgddVsBqrmYWelOiF6Uy/KSr6N8psGxPFE7SWL FaFUK+F3GSZmhwHDAMRQmekf92XU//KXHHtVJ21FRx1rYlPRiwYPNkg0H/qgyD0nsbzS a0pA== MIME-Version: 1.0 X-Received: by 10.180.95.201 with SMTP id dm9mr8094270wib.21.1371140240788; Thu, 13 Jun 2013 09:17:20 -0700 (PDT) Received: by 10.180.189.12 with HTTP; Thu, 13 Jun 2013 09:17:20 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Jun 2013 09:17:20 -0700 Message-ID: From: Greg Shepherd To: "Eggert, Lars" Content-Type: multipart/alternative; boundary=f46d044402b6fd543704df0b7659 Cc: Gorry Fairhurst , "" , joel jaeggli , Ali Begen , James Polk Subject: Re: [tsvwg] Confirmation for Auto-Post of I-D draft-shepherd-multicast-udp-guidelines X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 16:17:22 -0000 --f46d044402b6fd543704df0b7659 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 13, 2013 at 8:49 AM, Eggert, Lars wrote: > Hi Greg, > > On Jun 13, 2013, at 17:29, Greg Shepherd wrote: > > I'd like an agenda slot in Berlin to discuss this work. > > I'm generally in favor of this ID, because it fills an obvious void left > by RFC5405. > > I'd be curious to know why Section 2.1.4 doesn't follow the guidelines for > picking an MTU given in Section 3.2 of RFC5405 and instead always > recommends 1280 bytes? Okay, solid point. I could just mirror the text there for IPv4 and IPv6. I chose the latter as an overall guideline, but since this is the fall-back condition when all above recommendations are unavailable, the RFC5405 approach is better. Thanks, Greg > > Lars --f46d044402b6fd543704df0b7659 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 13, 2013 at 8:49 AM, Eggert, Lars <= ;lars@netapp.com&g= t; wrote:
Hi Greg,

On Jun 13, 2013, at 17:29, Greg Shepherd <gjshep@gmail.com> wrote:
> I'd like an agenda slot in Berlin to discuss this work.

I'm generally in favor of this ID, because it fills an obvious vo= id left by RFC5405.

I'd be curious to know why Section 2.1.4 doesn't follow the guideli= nes for picking an MTU given in Section 3.2 of RFC5405 and instead always r= ecommends 1280 bytes?

Okay, solid poi= nt. I could just mirror the text there for IPv4 and IPv6. I chose the latte= r as an overall guideline, but since this is the fall-back condition when a= ll above recommendations are unavailable, the RFC5405 approach is better.= =A0

Thanks,
Greg
=A0<= /div>

Lars

--f46d044402b6fd543704df0b7659-- From Mirko.Suznjevic@fer.hr Fri Jun 14 04:54:13 2013 Return-Path: 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 C7DA521F9C56; Fri, 14 Jun 2013 04:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 03-oMvmB6cMs; Fri, 14 Jun 2013 04:54:09 -0700 (PDT) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) by ietfa.amsl.com (Postfix) with ESMTP id A761D21F9BFE; Fri, 14 Jun 2013 04:54:08 -0700 (PDT) Received: from MAIL4.fer.hr ([2002:a135:48ea::a135:48ea]) by MAIL.fer.hr ([2002:a135:48e9::a135:48e9]) with mapi id 14.02.0342.003; Fri, 14 Jun 2013 13:54:06 +0200 From: =?iso-8859-2?Q?Mirko_Su=BEnjevi=E6?= To: "tcmtf@ietf.org" , "tsvwg@ietf.org" Thread-Topic: New version of draft-suznjevic-tsvwg-mtd-tcmtf Thread-Index: Ac5o9d5YwCnm2ioUSW+hBpRYjidpfg== Date: Fri, 14 Jun 2013 11:54:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.53.19.114] Content-Type: multipart/alternative; boundary="_000_E004A7C54DE04F4BB87DB9F32308DA5C0C0E13MAIL4ferhr_" MIME-Version: 1.0 Subject: [tsvwg] New version of draft-suznjevic-tsvwg-mtd-tcmtf X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 11:54:13 -0000 --_000_E004A7C54DE04F4BB87DB9F32308DA5C0C0E13MAIL4ferhr_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hello, We have just submitted the new version of draft draft-suznjevic-tsvwg-mtd-= tcmtf-01 renamed Delay Limits and Multiplexing Policies to be employed with= Tunneling Compressed Multiplexed Traffic Flows http://tools.ietf.org/html/= draft-suznjevic-tsvwg-mtd-tcmtf-01. It is an extension of tcmtf http://datatracker.ietf.org/doc/draft-saldana-t= svwg-tcmtf/. Since a specific list for tcmtf exists (tcmtf@ietf.org), the idea is to discuss it there. The draft contains recommendations for TCMTF multiplexing period for differ= ent network services as well as description of several policies required in= the process of packet multiplexing. We are discussing to revise the draft once more before the IETF meeting in = Berlin so your feedback will be very welcome. Thank you. Sincerely, Mirko Suznjevic --_000_E004A7C54DE04F4BB87DB9F32308DA5C0C0E13MAIL4ferhr_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hello,

We have just submitted the new = version of draft  draft-suznjevic-tsvwg-mtd-tcmtf-01 renamed Delay Lim= its and Multiplexing Policies to be employed with Tunneling Compressed Mult= iplexed Traffic Flows http://tools.ietf.org/html/draft-suznjevic-tsvwg-mtd-tcmtf-01.

It is an extension of tcmtf http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/. Since a spe= cific list for tcmtf exists (tcmtf@ietf.o= rg), the idea is to discuss it there.

The draft contains recommendati= ons for TCMTF multiplexing period for different network services as well as= description of several policies required in the process of packet multiple= xing.

We are discussing to revise the= draft once more before the IETF meeting in Berlin so your feedback will be= very welcome. Thank you.

Sincerely,

Mirko Suznjevic

 

--_000_E004A7C54DE04F4BB87DB9F32308DA5C0C0E13MAIL4ferhr_-- From dave.taht@gmail.com Mon Jun 17 12:41:23 2013 Return-Path: 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 8954521F85D1 for ; Mon, 17 Jun 2013 12:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] 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 auo4hON8414c for ; Mon, 17 Jun 2013 12:41:23 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 562CE21F99DD for ; Mon, 17 Jun 2013 12:40:58 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so7291372ief.26 for ; Mon, 17 Jun 2013 12:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WVLDH7rXKpeuLtcNVt0YtdjXYIJqWAjkFJGskAFLszs=; b=WXCq3vF7KlH1uibNxjdjQf7/s01Vz9hAOwJcJKT+65uu+9PESRAh0CYGEy/DgqekRq hg9Q7Y5Jlwd4fl3RmcJFds9P9yUqHsyiG23WfXdYHn+koNVbeTC4IxRBhkwoMyKkOAsb aBZbNftY52IxxwQ/1M0nEMuXJh345Bt9SqWXyd6mRidE4XberVaYCRTN0xjTVAuiG/Py j7xVqC/g2pURjFAQUQ9xB7BDgauc6WTGKpXmhKe/OVr1NJx0xqspWTChAYljq9Kf9WfW bh5vdGdsqnFz45k1LdwU+Xu761fsRJv4Gv1FsQFz4hy0EbSZ7W6ciUxxcSbPAUn59vvC DK2w== MIME-Version: 1.0 X-Received: by 10.50.56.50 with SMTP id x18mr5930280igp.87.1371498052899; Mon, 17 Jun 2013 12:40:52 -0700 (PDT) Received: by 10.64.45.137 with HTTP; Mon, 17 Jun 2013 12:40:52 -0700 (PDT) Date: Mon, 17 Jun 2013 12:40:52 -0700 Message-ID: From: Dave Taht To: tsvwg@ietf.org, bloat , iccrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [tsvwg] some comments on draft-ietf-tsvwg-byte-pkt-congest-10.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 19:41:23 -0000 This draft "updates" RFC2309 which has already been obsoleted by one of it's original authors and a replacement draft ( http://tools.ietf.org/html/draft-baker-aqm-recommendation-00 ) is in progress. Be that as it may... This draft starts off on the wrong foot, and proceeds downhill rapidly. I am glad that someone is trying to update BCP for their current RED usage, but in general I think it is incorrect to extrapolate from RED's behavior to other behaviors in many cases, so... " This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, such as random early detection (RED), BLUE, pre-congestion notification (PCN), etc. " By excluding DRR, SFQ, SQF, Codel, FQ_Codel, PIE and others, and attempting to generalize from experiences with RED to all AQM technologies, it does its potential readers a disservice. I'd change the first sentence to: " This document provides recommendations of best current practice for dropping or marking packets using the RED active queue management (AQM) algorithm, using packet drop and congestion notification" >From that, it is possible to generalize the following, although the backing argument is suspect, which I'll get into later... " We give three strong recommendations: (1) packet size should be taken into account when transports read and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) in the specific case of RED, the byte-mode packet drop variant that drops fewer small packets should not be used. " "This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms." as RFC2309 itself is being obsoleted, we're going around in circles here. Before tackling byte-pkt-congest-10 directly - a couple asides.. ...snip snip... RFC2309 refers to this 1994 paper: "On the Self-Similar Nature of Ethernet Traffic (Extended Version)" I would certainly like the model and analysis of this paper repeated against modern traffic patterns. Has anyone done this? I loved this paper when it came out.... last paragraph in section 2 of RFC2039 I heartily agree with " In short, scheduling algorithms and queue management should be seen as complementary, not as replacements for each other." And if we can agree that AQM = Active queue *length* management and can come up with a name for FQ+AQM hybrids that works for people (SQM - smart queue management?) so we know what we're talking about when talking about things, certain bits in section 3 get easier to deal with. Because of the overload on AQM I'm going to use SQM throughout what I write below. As one last general example of problems with rfc2039, some of the references are to protocols so ancient and non-deployed as to render the relevant arguments moot: " voice and video, and also multicast bulk data transport [SRM96]. If no action is taken, such unresponsive flows could lead to a new congestive collapse. In general, all UDP-based streaming applications should incorporate effective congestion avoidance mechanisms. For example, recent research has shown the possibility of incorporating congestion avoidance mechanisms such as Receiver- driven Layered Multicast (RLM) within UDP-based streaming applications such as packet video [McCanne96] [Bolot94]. Further research and development on ways to accomplish congestion avoidance for streaming applications will be very important." It would be nice to have relevance to new stuff like webrtc in a new draft of some sort rather than to non-deployed 20 year old protocols. ...ok back to the pkt-congest draft... " Consensus has emerged over the years concerning the first stage: if queues cannot be measured in time, whether they should be measured in bytes or packets. Section 2.1 of this memo records this consensus in the RFC Series. In summary the choice solely depends on whether the resource is congested by bytes or packets." Measuring queues in time is totally feasible as shown by pie and codel, and implementations on weak hardware such as on mips. Last week I got fq_codel running on a raspberri pi and a beaglebone to no observable hit on cpu usage vs pfifo_fast... I'll do an arduino if that's necessary to make the point, harder. Anybody got a 68020 or slower to play with? So an alternative formulation that makes sense is: " When queues cannot be measured in time, should they be measured in bytes or packets? And dropping the rest of this: " Section 2.1 of this memo records this consensus in the RFC Series. In summary the choice solely depends on whether the resource is congested by bytes or packets." Moving on: " This memo updates [RFC2309] to deprecate deliberate preferential treatment of small packets in AQM algorithms. It recommends that (1) packet size should be taken into account when transports read congestion indications, (2) not when network equipment writes them. This memo also adds to the congestion control principles enumerated in BCP 41 [RFC2914]." s/AQM/the RED/g across the draft Still... to get to the meat of my own complaint with the draft and philosophy expoused within, I'll pull out two example paragraphs and try to make my argument.... "However, at the transport layer, TCP congestion control is a widely deployed protocol that doesn't scale with packet size. To date this hasn't been a significant problem because most TCP implementations have been used with similar packet sizes. But, as we design new congestion control mechanisms, this memo recommends that we should build in scaling with packet size rather than assuming we should follow TCP's example." "Although many control packets happen to be small, the alternative of network equipment favouring all small packets would be dangerous. That would create perverse incentives to split data transfers into smaller packets." packets were (at least originally) "a small group or package of anything", I view the incentives to create larger packets as *far, far, far, far more perverse* than the incentives to create smaller ones. There will always be header overhead, there will always be small signalling packets, and there will always be bulk data that can *always* be broken up into packets of smaller size, that gets in the way of more interactive data if the larger packets aren't broken up into packets of smaller size. In my talks of late, I toss a 64GB memory stick across the room at someone - wow! check out that bandwidth! 64GB/sec!! and then challenge someone to try and read the last byte from the file on it going sequentually) (hint, most USB sticks barely do 8MB/sec and you'll be waiting a looong time) If it were up to me I'd have held the internet's MTU to 574 bytes until everybody was running at greater than 1Mbit, and the ratio between the largest packet and smallest held to less than 10x1 for eternity. Big packets affect latency, badly. They are also subject to much higher potential rates of error. At 1500 bytes, header overhead, even with ipv6, is pretty minimal and few gains can be had by increasing it. Jumbo frames are barely accepted in very few circumstances, etc. So the argument and conclusions about larger packet sizes that permeates this document is the opposite of the argument I'd make, throughout. So, as one example: "6. Security Considerations This memo recommends that queues do not bias drop probability towards small packets as this creates a perverse incentive for transports to break down their flows into tiny segments. One of the benefits of implementing AQM was meant to be to remove this perverse incentive that drop-tail queues gave to small packets." I think the author has got the intended statement wrong ("away from" rather than "towards"?)... and my take on it is that the drop tail behavior towards small packets was indeed very desirable, and should be retained in an SQM, to keep latencies low on overload and create incentives for right-sizing packets in general as per their actual transport needs. "In summary, it says that making drop probability depend on the size of the packets that bits happen to be divided into simply encourages the bits to be divided into smaller packets. " YEA! " Byte-mode drop would therefore irreversibly complicate any attempt to fix the Internet's incentive structures." s/complicate/enhance/ The document refers to things like rfc5690 and I long ago lost hope for ECN. The document then makes some blanket statements that aren't backed by data (that I'm aware of) Section 6 " In practice, transports cannot all be trusted to respond to congestion. So another reason for recommending that queues do not bias drop probability towards small packets is to avoid the vulnerability to small packet DDoS attacks that would otherwise result. One of the benefits of implementing AQM was meant to be to remove drop-tail's DoS vulnerability to small packets, so we shouldn't add it back again." I am only aware of a few small packet attacks. (most UDP DNS attacks try to do amplification actuallly) A strict DDOS based on small packets can be made effective against drop tail and somewhat effective against RED. Most attacks I've looked at are actually MUCH less effective against a SQM like fq_codel, given the random hash and equal service guarantees. I would certainly like to take a hard look at the tools used to attack and create Robust RED, so everything in section 6 seems highly theoretical and needs proof. Lastly: section 5.2 needs to be thought about in the age of wireless, which is often TXOP-congested rather than either of the two problems identified, and is kind of pressing. "5.2. Bit- & Packet-congestible Network The position is much less clear-cut if the Internet becomes populated by a more even mix of both packet-congestible and bit-congestible resources (see Appendix B.2). This problem is not pressing, because most Internet resources are designed to be bit-congestible before packet processing starts to congest (see Section 1.1)." From internet-drafts@ietf.org Tue Jun 18 21:56:52 2013 Return-Path: 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 439DD21F9D10; Tue, 18 Jun 2013 21:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 JGDK1Id8F3Qv; Tue, 18 Jun 2013 21:56:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B664F21F9CF8; Tue, 18 Jun 2013 21:56:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130619045651.31928.53400.idtracker@ietfa.amsl.com> Date: Tue, 18 Jun 2013 21:56:51 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-failover-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 04:56:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : Quick Failover Algorithm in SCTP Author(s) : Yoshifumi Nishida Preethi Natarajan Armando Caro Paul D. Amer Filename : draft-ietf-tsvwg-sctp-failover-01.txt Pages : 17 Date : 2013-06-18 Abstract: One of the major advantages in SCTP is supporting multi-homing communication. If a multi-homed end-point has redundant network connections, SCTP sessions can have a good chance to survive from network failures by migrating inactive network to active one. However, if we follow the SCTP standard, there can be significant delay for the network migration. During this migration period, SCTP cannot transmit much data to the destination. This issue drastically impairs the usability of SCTP in some situations. This memo describes the issue of SCTP failover mechanism and discuss its solutions which require minimal modification to the current standard. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-failover-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-failover-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nishida@sfc.wide.ad.jp Wed Jun 19 00:23:58 2013 Return-Path: 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 40EE621F9D6C for ; Wed, 19 Jun 2013 00:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 i6JrgdYNdCh6 for ; Wed, 19 Jun 2013 00:23:56 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id AF9B921F9F65 for ; Wed, 19 Jun 2013 00:23:48 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 54B182780B7 for ; Wed, 19 Jun 2013 16:23:47 +0900 (JST) Received: by mail-lb0-f170.google.com with SMTP id t13so4497455lbd.15 for ; Wed, 19 Jun 2013 00:23:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9VolIe9jpjAfOWcLr9RVUy5UufdxzMSnOE/yvJ32Ksg=; b=nGkgs4/AnqHZk5n7YwR8nC18SkutxvQsCe85mLKsfClsFBdr5mUZ8UXBpWb13qUr1X hYrLCLCQqf3zMXZ4+FKTv1v3vx56plf19WbxMGX5bWtVHf0fBzHETX0cAPbFE1ke6NsA ZIJU4Q961uh34DBjzAm3Sn+KXdpjOz+xPczgBBvWoF9JiuQ5Y0sSpo1+4cIhOIQGHA1h 0LyKqu5xN9UHsUWdws+5WxR0Chzi6Ks87AoaaM+4Ca43fe8vi5ibbmiCuO7YXoptPcdD 86Cgt7TrMSLH8IEBD46d6gPc+Sw82+A/c9Kf9TGkZduuq5mlE4nUHWoijhXUKDpH2OC0 YStg== MIME-Version: 1.0 X-Received: by 10.152.1.102 with SMTP id 6mr711071lal.49.1371626624203; Wed, 19 Jun 2013 00:23:44 -0700 (PDT) Received: by 10.114.1.12 with HTTP; Wed, 19 Jun 2013 00:23:44 -0700 (PDT) In-Reply-To: <51A360E7.7020209@ericsson.com> References: <51A360E7.7020209@ericsson.com> Date: Wed, 19 Jun 2013 00:23:44 -0700 Message-ID: From: Yoshifumi Nishida To: Salvatore Loreto Content-Type: multipart/alternative; boundary=089e013c64d6b3434e04df7cb511 Cc: "Karen E. E. Nielsen" , tsvwg , draft-ietf-tsvwg-sctp-failover@tools.ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-sctp-failover: comments and suggestions X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 07:23:58 -0000 --089e013c64d6b3434e04df7cb511 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello Salvatore, I'm sorry for my very slow reply. We've just submitted a new version in order to avoid expiration status. We've also added some texts for further discussions. And thank you so much for the comments. I believe these are very good suggestions. Please see in line. On Mon, May 27, 2013 at 6:34 AM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > Hi there, > > Karen (in cc) and I have reviewed together the draft and written down the > following comments and suggestions > > > - Section 5.1: CWND Handling for Potentially Failed Destinations > > The draft speaks about setting the CWND to 1 MTU (or 2MTU ?) when a > Potentially Failed Path (destination) is reinstated > in ACTIVE state as a result of the receipt of an HB ACK. > > We are not sure what is the motivation for any special measures to be > taken in this situation. > > Generally the CWND settings are governed by RFC4960 prescriptions as to > set the CWND to 1 MTU after T3-rtx (but not afterHB timeout) > as well as RFC4960 guidelines to converge the CWND to the initial CWND > towards idle destination addresses. > > We believe, in this respect, it is appropriate to keep the standard > behaviour of RFC4960. > I agree with you to stick to the behavior of RFC4960 as default behavior. We've been exploring several possibilities for performance improvement and discussing using 2 MTU might be an idea, although we think we'll need further discussions. Preethi might have some more comments on this point. > - Section 5.3: Permanent Failover > > We have good experiences from live networks with running SCTP in a =93no > switchback=94 mode of operation with no automatic migration > back to a preferred primary path. Once the primary path is left due to it > being potentially failed, then a selected alternative path automatically > becomes the new primary path. > > This mode of operation corresponds to a simplified variant of the > permanent failover operation proposed in [CAR002] > with alpha =3D beta =3D SCTP_PEER_ADDR:THLDS. The mode of operation is ru= n > with notifications of change of primary path being provided > to upper layers via RFC6458 SCTP_PEER_ADDR_CHANGE semantics > (SCTP_ADDR_MADE_PRIM). > > The mode of operation does not suit all purposes, but in networks > environments where a number of equally preferred paths are available, > then by this mode of operation one minimizes the effects of unnecessary > path bouncing and the thereby associated effects of throughput > degradation due to path changes and slow start operation. > > Based on our experiences we would recommend and support that the Permanen= t > Failover mode of operation, at least in the simple variant > described above, is promoted as a valid alternative approach. For the > purpose of activation of this mode of operation a switchback (or failover= ) > mode operation parameter could be introduced as configurable by the > introduction of an appropriate new read/write socket option in the Socket > API. > Yes. I agree that there will be a situation where Permanent Failover work effectively. OTOH, supporting this prevents us from keeping RFC4960 behavior as RFC4960 doesn't have this mode. But, I believe this is a very interesting point and we would like to get more feedback in order to think about this more. > - Section 5.4: The impact of HB timeouts in association error counter > > The draft recommends for excluding HB timeouts from contributing to the > (association) error counter. We fully support this approach for > all timeouts of HBs that are send to probe the state of destinations > addresses that are in PF state and we would even propose for the draft > to demand that generally timeouts stemming from HBs, which are not sent o= n > the Primary Path, will be excluded from the association error counter. > > Thereby the association error counter and thus the association fate > reflects the forward progress of the data transmission to peer endpoint > while > at the same time it will be appropriately isolated from timeouts of HBs > sent on non-data carrying paths. > > Allowing timeout of HBs sent on the Primary Path to impact the associatio= n > error counter will serve to validate the aliveness of the peer endpoint > when there is no data in transit. > > This suggestion follows the thought expressed in http://www.ietf.org/mail= - > **archive/web/tsvwg/current/**msg11294.htmland it is thus believed > to fulfil the original intend of RFC4960. > This is a bit difficult point for me. I don't know much about the original intention of RFC4960, but if we follow what is written there, i think we need to increment association error count. (Please correct me if I misunderstand this point) So, my personal preference is to set bigger AMR to avoid early termination so that we can keep the RFC4960 behavior. However, we don't mind discussing to update the logic described in 4960 for more sophisticated solution. > > - Section 5.1 Thoughts on the destination address state machine > > In RFC4960 address state machine, notification of cease of use of the > current primary path as transmission path for new data is provided to upp= er > layer > via (coupled with) the announcement of the destination as being > UNREACHABLE. With the introduction of the potentially failed state as a > semi-hidden > state (not resulting in notified state transition to UL) the information > on the fail-over to use a new data carrying path is lost. > While there may be merits in suppressing notifications on potentially > failed addresses, then we believe that it is unfortunate that the > notification > of failover from usage of the primary path for new data is lost. > This is especially problematic in path bouncing scenarios where the > primary path is unstable but still works some. E.g., HBs may go through, > but the path breaks (data transmission fails) as soon as it is more > loaded. In such a situation no notifications may be generated to UL, > even if new data transmission consistently cycles to and from the primary > path. The solution to such path bouncing scenarios will have to come > from more advanced path failover mechanism, like [CAR002] (and would not > be solved just by notification), but it would be a great help if appropri= ate > notifications were provided. > I think it will be OK to send notification as long as it's a new notification type. But we should not send notifications defined in RFC6458. I guess having a new notification type won't cause problems, but I would like to get more feedback on this. Thanks! -- Yoshifumi --089e013c64d6b3434e04df7cb511 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hello Salvatore,

I'm sorry for my v= ery slow reply. We've just submitted a new version in order to avoid ex= piration status. We've also added some texts for further discussions.
And thank you so much for the comments. I believe these are very good = suggestions. Please see in line.

On Mon, May 27, 2013 at 6:34 AM, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:
Hi there,

Karen (in cc) and I have reviewed together the draft and written down the f= ollowing comments and suggestions


- Section 5.1: CWND Handling for Potentially Failed Destinations

The draft speaks about setting the CWND to 1 MTU (or 2MTU ?) when a Potenti= ally Failed Path (destination) is reinstated
in ACTIVE state as a result of the receipt of an HB ACK.

We are not sure what is the motivation for any special measures to be taken= in this situation.

Generally the CWND settings are governed by RFC4960 prescriptions as to set= the CWND to 1 MTU after T3-rtx (but not afterHB timeout)
as well as RFC4960 guidelines to converge the CWND to the initial CWND towa= rds idle destination addresses.

We believe, in this respect, it is appropriate to keep the standard behavio= ur of RFC4960.

I agree with you t= o stick to the behavior of RFC4960 as default behavior.=A0
We've been exploring several possibilities for performance improvement = and discussing using 2 MTU might be an idea, although we think we'll ne= ed further discussions. Preethi might have some more comments on this point= .
=A0
- Section 5.3: Permanent Failover

We have good experiences from live networks with running SCTP in a =93no sw= itchback=94 mode of operation with no automatic migration
back to a preferred primary path. Once the primary path is left due to it b= eing potentially failed, then a selected alternative path automatically
becomes the new primary path.

This mode of operation corresponds to a simplified variant of the permanent= failover operation proposed in [CAR002]
with alpha =3D beta =3D SCTP_PEER_ADDR:THLDS. The mode of operation is run = with notifications of change of primary path being provided
to upper layers via RFC6458 SCTP_PEER_ADDR_CHANGE semantics (SCTP_ADDR_MADE= _PRIM).

The mode of operation does not suit all purposes, but in networks environme= nts where a number of equally preferred paths are available,
then by this mode of operation one minimizes the effects of unnecessary pat= h bouncing and the thereby associated effects of throughput
degradation due to path changes and slow start operation.

Based on our experiences we would recommend and support that the Permanent = Failover mode of operation, at least in the simple variant
described above, is promoted as a valid alternative approach. For the purpo= se of activation of this mode of operation a switchback (or failover)
mode operation parameter could be introduced as configurable by the introdu= ction of an appropriate new read/write socket option in the Socket API.
=


Yes. I agree that the= re will be a situation where Permanent Failover work effectively. OTOH, sup= porting this=A0= prevents us from keeping RFC4960 behavior as RFC4960 doesn't have this = mode.
But, I believe this is a very interesting point and we would lik= e to get more feedback in order to think about this more.=A0


- Section 5.4: The impact of HB timeouts in association error counter

The draft recommends for excluding HB timeouts from contributing to the (as= sociation) error counter. We fully support this approach for
all timeouts of HBs that are send to probe the state of destinations addres= ses that are in PF state and we would even propose for the draft
to demand that generally timeouts stemming from HBs, which are not sent on = the Primary Path, will be excluded from the association error counter.

Thereby the association error counter and thus the association fate reflect= s the forward progress of the data transmission to peer endpoint while
at the same time it will be appropriately isolated from timeouts of HBs sen= t on non-data carrying paths.

Allowing timeout of HBs sent on the Primary Path to impact the association = error counter will serve to validate the aliveness of the peer endpoint
when there is no data in transit.

This suggestion follows the thought expressed in http:/= /www.ietf.org/mail-archive/web/tsvwg/current/msg11294.html and it is thus believed
to fulfil the original intend of RFC4960.

This is a bit difficult point for me. I don't know much about = the original intention of RFC4960, but if we follow what is written there, = i think we need to increment association error count. (Please correct me if= I misunderstand this point)
So, my personal preference is to set bigger AMR to avoid early t= ermination so that we can keep the RFC4960 behavior.
Howeve= r, we don't mind discussing to update the logic described in 4960 for m= ore sophisticated solution.=A0
=A0

- Section 5.1 Thoughts on the destination address state machine

In RFC4960 address state machine, notification of cease of use of the curre= nt primary path as transmission path for new data is provided to upper laye= r
via (coupled with) the announcement of the destination as being UNREACHABLE= . With the introduction of the potentially failed state as a semi-hidden state (not resulting in notified state transition to UL) the information on= the fail-over to use a new data carrying path is lost.
While there may be merits in suppressing notifications on potentially faile= d addresses, then we believe that it is unfortunate that the notification of failover from usage of the primary path for new data is lost.
This is especially problematic in path bouncing scenarios where the primary= path is unstable but still works some. E.g., HBs may go through,
but the path breaks (data transmission fails) as soon as it is more loaded.= In such a situation no notifications may be generated to UL,
even if new data transmission consistently cycles to and from the primary p= ath. The solution to such path bouncing scenarios will have to come
from more advanced path failover mechanism, like [CAR002] (and would not be= solved just by notification), but it would be a great help if appropriate<= br> notifications were provided.

I think= it will be OK to send notification as long as it's a new notification = type. But we should not send notifications defined in RFC6458.
=
Thanks!
--
Yoshifumi

--089e013c64d6b3434e04df7cb511-- From gorry@erg.abdn.ac.uk Wed Jun 19 08:25:34 2013 Return-Path: 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 A747A21F9BAD for ; Wed, 19 Jun 2013 08:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 aA+TtmUvi-rj for ; Wed, 19 Jun 2013 08:25:30 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id ACBC821F9CD8 for ; Wed, 19 Jun 2013 08:25:25 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 883EF2FE0A2; Wed, 19 Jun 2013 16:25:24 +0100 (BST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id BEDB62B4039; Wed, 19 Jun 2013 16:25:23 +0100 (BST) Message-ID: <51C1CD63.7070106@erg.abdn.ac.uk> Date: Wed, 19 Jun 2013 16:25:23 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: tsvwg WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tsvwg chair Subject: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 15:25:34 -0000 This email announces the beginning of a short working group last call for draft-ietf-tsvwg-byte-pkt-congest-10, "Byte and Packet Congestion Notification". This document is now thought by the authors to be ready to proceed to be published as a Proposed Standard, it completed a former WGLC and has since received review by the IESG and was subsequently revised. Please send any comments on version -10 to the TSVWG list. The draft is available at: http://tools.ietf.org/html/draft-ietf-tsvwg-byte-pkt-congest The last call will run for one week, ending Friday, 28th June 2013. Emails saying "I support" or "I don't support" are also most helpful in judging the consensus. James, David and Gorry (TSVWG Chairs) From john@jlc.net Wed Jun 19 09:08:39 2013 Return-Path: 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 745EA21F9B7C for ; Wed, 19 Jun 2013 09:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.265 X-Spam-Level: X-Spam-Status: No, score=-106.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 rwKQFZNyl6Jd for ; Wed, 19 Jun 2013 09:08:24 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4D26121F9DD6 for ; Wed, 19 Jun 2013 09:08:24 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0B3A133C28; Wed, 19 Jun 2013 12:08:24 -0400 (EDT) Date: Wed, 19 Jun 2013 12:08:24 -0400 From: John Leslie To: Gorry Fairhurst Message-ID: <20130619160823.GD44982@verdi> References: <51C1CD63.7070106@erg.abdn.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C1CD63.7070106@erg.abdn.ac.uk> User-Agent: Mutt/1.4.1i Cc: tsvwg WG Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 16:08:39 -0000 Gorry Fairhurst wrote: > > This email announces the beginning of a short working group last call > for draft-ietf-tsvwg-byte-pkt-congest-10, "Byte and Packet Congestion > Notification". First of all, I wish to applaud the authors for expanding the question of scaling congestion control signals and responses to include queue length in time. I agree with the authors that _when_ queue size cannot be measured in time, the remaining question is whether to measure bytes or packets. Alas, I do not agree with the authors that measuring queue size in _payload_ bytes is useful -- the measurement should be bytes-on-the-wire. It is because of the difficulties in measuring byte-on-the-wire that I tend to prefer measuring the queue length in packets. But arguing that becomes pointless when queue size can be measured in time. Considering the current work in progress on CoDel and PIE, etc., I wonder whether it actually makes sense to nail down the question of what to do when we can't measure queue length in time. Thus, I do not favor trying to finish this draft at this time. If we do wish to finish this draft at this time, I have other questions that I hope we will consider. I also note the Fred Baker draft revising RFC2309 being considered in the proposed AQM WG. These two drafts overlap so much that I believe a single co-ordinated draft revising 2309 is wiser. -- John Leslie From fred@cisco.com Wed Jun 19 11:04:24 2013 Return-Path: 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 76BC621F9E05 for ; Wed, 19 Jun 2013 11:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.044 X-Spam-Level: X-Spam-Status: No, score=-110.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 eazsmHslMAcY for ; Wed, 19 Jun 2013 11:04:11 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C289721F9E06 for ; Wed, 19 Jun 2013 11:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2145; q=dns/txt; s=iport; t=1371665049; x=1372874649; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4hgfObNtU7dBC+FBfvC8/fp/wHg9YRNYrUv47/d8D7s=; b=FlsvCP+cJFio1SMp+4Qpd2SV4OeYEI5YYphkyoUAwszyc0vVeyN/+rhs KVnLnSNeNgi9Cq3mmkgdIUU4xYI2xF9/gIn+I+jUay2f0DTmsWiw4PQCB 3t/mP4ds4E8ogUcIln/s1tQDuTuZWwT40oJ7mPKKTZbg3w7JSOSv3czi/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIFALrxwVGtJXHB/2dsb2JhbABagwl6vxuBABZ0giMBAQEDATozDAULAgEIGAoUEDIlAgQOBQiIAAa7YY4AgQ8CMQeDAGEDqQWBWIE3gXE3 X-IronPort-AV: E=Sophos;i="4.87,899,1363132800"; d="scan'208";a="224707435" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 19 Jun 2013 18:04:09 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5JI499Z013318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 18:04:09 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 19 Jun 2013 13:04:08 -0500 From: "Fred Baker (fred)" To: John Leslie Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 Thread-Index: AQHObRdk5hCPvkIeOEul3y1ejE5WdA== Date: Wed, 19 Jun 2013 18:04:07 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B91EB9C@xmb-rcd-x09.cisco.com> References: <51C1CD63.7070106@erg.abdn.ac.uk> <20130619160823.GD44982@verdi> In-Reply-To: <20130619160823.GD44982@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.125] Content-Type: text/plain; charset="us-ascii" Content-ID: <5B8E9025772CD24893F582461B484DC6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gorry Fairhurst , tsvwg WG Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 18:04:24 -0000 I would agree that it makes little sense to almost-simultaneously update an= d obsolete RFC 2309. If we are going to have a working group whose job is t= o rewrite the AQM recommendation, which is what Wes said to TSVAREA that he= wanted to do (and hence my draft) at IETF 86, it would be best to collabor= ate. On Jun 19, 2013, at 9:08 AM, John Leslie wrote: > Gorry Fairhurst wrote: >>=20 >> This email announces the beginning of a short working group last call=20 >> for draft-ietf-tsvwg-byte-pkt-congest-10, "Byte and Packet Congestion=20 >> Notification". >=20 > First of all, I wish to applaud the authors for expanding the question > of scaling congestion control signals and responses to include queue > length in time. >=20 > I agree with the authors that _when_ queue size cannot be measured in > time, the remaining question is whether to measure bytes or packets. >=20 > Alas, I do not agree with the authors that measuring queue size in > _payload_ bytes is useful -- the measurement should be bytes-on-the-wire. > It is because of the difficulties in measuring byte-on-the-wire that I > tend to prefer measuring the queue length in packets. >=20 > But arguing that becomes pointless when queue size can be measured in > time. >=20 > Considering the current work in progress on CoDel and PIE, etc., I > wonder whether it actually makes sense to nail down the question of > what to do when we can't measure queue length in time. >=20 > Thus, I do not favor trying to finish this draft at this time. >=20 > If we do wish to finish this draft at this time, I have other questions > that I hope we will consider. >=20 > I also note the Fred Baker draft revising RFC2309 being considered > in the proposed AQM WG. These two drafts overlap so much that I believe > a single co-ordinated draft revising 2309 is wiser. >=20 > -- > John Leslie ----------------------------------- "We are learning to do a great many clever things...The next great task will be to learn not to do them." - G. K. Chesterton (1874-1936) From gorry@erg.abdn.ac.uk Wed Jun 19 11:40:24 2013 Return-Path: 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 60BDC21F9DE4 for ; Wed, 19 Jun 2013 11:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 AX2e7N9gBPvR for ; Wed, 19 Jun 2013 11:40:18 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6878921F9AE2 for ; Wed, 19 Jun 2013 11:40:18 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id E11942B4039; Wed, 19 Jun 2013 19:40:16 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 19 Jun 2013 19:40:17 +0100 Message-ID: In-Reply-To: <8C48B86A895913448548E6D15DA7553B91EB9C@xmb-rcd-x09.cisco.com> References: <51C1CD63.7070106@erg.abdn.ac.uk> <20130619160823.GD44982@verdi> <8C48B86A895913448548E6D15DA7553B91EB9C@xmb-rcd-x09.cisco.com> Date: Wed, 19 Jun 2013 19:40:17 +0100 From: gorry@erg.abdn.ac.uk To: "Fred Baker (fred)" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Gorry Fairhurst , tsvwg WG Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 18:40:24 -0000 The intended purpose of the WGLC was to confirm the final changes made by the IESG. I'm happy to see discussion on these important topics, however in considering this we also need to note the set of issues that were raised during the original WGLC. If this is in conflict with new individual submission, then maybe we have a potential charter problem that should also perhaps be considered. Gorry > I would agree that it makes little sense to almost-simultaneously update > and obsolete RFC 2309. If we are going to have a working group whose job > is to rewrite the AQM recommendation, which is what Wes said to TSVAREA > that he wanted to do (and hence my draft) at IETF 86, it would be best to > collaborate. > > On Jun 19, 2013, at 9:08 AM, John Leslie wrote: > >> Gorry Fairhurst wrote: >>> >>> This email announces the beginning of a short working group last call >>> for draft-ietf-tsvwg-byte-pkt-congest-10, "Byte and Packet Congestion >>> Notification". >> >> First of all, I wish to applaud the authors for expanding the question >> of scaling congestion control signals and responses to include queue >> length in time. >> >> I agree with the authors that _when_ queue size cannot be measured in >> time, the remaining question is whether to measure bytes or packets. >> >> Alas, I do not agree with the authors that measuring queue size in >> _payload_ bytes is useful -- the measurement should be >> bytes-on-the-wire. >> It is because of the difficulties in measuring byte-on-the-wire that I >> tend to prefer measuring the queue length in packets. >> >> But arguing that becomes pointless when queue size can be measured in >> time. >> >> Considering the current work in progress on CoDel and PIE, etc., I >> wonder whether it actually makes sense to nail down the question of >> what to do when we can't measure queue length in time. >> >> Thus, I do not favor trying to finish this draft at this time. >> >> If we do wish to finish this draft at this time, I have other >> questions >> that I hope we will consider. >> >> I also note the Fred Baker draft revising RFC2309 being considered >> in the proposed AQM WG. These two drafts overlap so much that I believe >> a single co-ordinated draft revising 2309 is wiser. >> >> -- >> John Leslie > > ----------------------------------- > "We are learning to do a great many clever things...The next great task > will be to learn not to do them." > > - G. K. Chesterton (1874-1936) > > > > From wes@mti-systems.com Wed Jun 19 19:31:14 2013 Return-Path: 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 A026421F9C53 for ; Wed, 19 Jun 2013 19:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 X-RFJ3DDGZte for ; Wed, 19 Jun 2013 19:31:08 -0700 (PDT) Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id 74CCA21F9C65 for ; Wed, 19 Jun 2013 19:31:08 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r5K2V61p011762 for ; Wed, 19 Jun 2013 22:31:06 -0400 Received: (qmail 25497 invoked by uid 0); 20 Jun 2013 02:31:06 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.136?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 20 Jun 2013 02:31:06 -0000 Message-ID: <51C26950.20602@mti-systems.com> Date: Wed, 19 Jun 2013 22:30:40 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Leslie References: <51C1CD63.7070106@erg.abdn.ac.uk> <20130619160823.GD44982@verdi> In-Reply-To: <20130619160823.GD44982@verdi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Gorry Fairhurst , tsvwg WG Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 02:31:14 -0000 On 6/19/2013 12:08 PM, John Leslie wrote: > I agree with the authors that _when_ queue size cannot be measured in > time, the remaining question is whether to measure bytes or packets. I also agree with this. > Alas, I do not agree with the authors that measuring queue size in > _payload_ bytes is useful -- the measurement should be bytes-on-the-wire. > It is because of the difficulties in measuring byte-on-the-wire that I > tend to prefer measuring the queue length in packets. The document explains why packets are generally a less useful metric, and why bytes are preferred and won the recommendation. Clearly you're right that bytes on-the-wire might in several cases be difficult to infer in code looking only at layer-3 packets, but this isn't impossible, nor does it seem to lead to an unusably bad approximation in many common cases. So, I think the recommendation as-is is perfectly valid, and would not sacrifice recommending the best thing in order to recommend something that's easy but known to have pathologies. Since this isn't a protocol with compatibility requirements, any piece of equipment or software is free to disregard that advice and the analysis if it seems too difficult, and the Internet will survive. -- Wes Eddy MTI Systems From wes@mti-systems.com Wed Jun 19 19:31:20 2013 Return-Path: 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 741B521F9CD1 for ; Wed, 19 Jun 2013 19:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Jlh2SIpX2O10 for ; Wed, 19 Jun 2013 19:31:14 -0700 (PDT) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2D121F9BC0 for ; Wed, 19 Jun 2013 19:31:14 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r5K2VDL0016418 for ; Wed, 19 Jun 2013 22:31:13 -0400 Received: (qmail 18338 invoked by uid 0); 20 Jun 2013 02:31:13 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.136?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 20 Jun 2013 02:31:13 -0000 Message-ID: <51C26957.6020904@mti-systems.com> Date: Wed, 19 Jun 2013 22:30:47 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <51C1CD63.7070106@erg.abdn.ac.uk> <20130619160823.GD44982@verdi> <8C48B86A895913448548E6D15DA7553B91EB9C@xmb-rcd-x09.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Fred Baker \(fred\)" , tsvwg WG Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 02:31:20 -0000 On 6/19/2013 2:40 PM, gorry@erg.abdn.ac.uk wrote: > The intended purpose of the WGLC was to confirm the final changes made by > the IESG. I'm happy to see discussion on these important topics, however > in considering this we also need to note the set of issues that were > raised during the original WGLC. > > If this is in conflict with new individual submission, then maybe we have > a potential charter problem that should also perhaps be considered. > I'm not sure that there has to be any conflict. This document already mentions sojourn time as a possible dimension to measure, as an alternative to length in bytes of packets. It makes pretty clear statements that time is the desirable metric, if it can be used, and that the majority of this document only pertains to the algorithms that don't use time (see first paragraph of section 2.1). This document is a focused piece of work on that particular issue of bytes versus packets as a measure of length. Fred's AQM document is much higher-level, and tries to fold in the full set of things learned since 2309. This byte/packet topic is only one of several. It seems obvious that the take-away recommendation here about bytes rather than packets can be inserted into Fred's document with reference to this one for the full details. So ... yeah, there is a separate WG trying to be born to deal with AQM, but I don't understand why that would hold this up at all. Sorting out the family tree of documents (and documents coming out of a not yet even formed WG) and who updates or obsoletes who and how they all relate is good to do, but this one is a WG item for TSVWG and can be completed now ... we'll worry about the metadata on the AQM WG docs when there is actually an AQM WG. Just my 2 cents. -- Wes Eddy MTI Systems From Ruediger.Geib@telekom.de Wed Jun 19 23:18:58 2013 Return-Path: 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 A344B11E80D9 for ; Wed, 19 Jun 2013 23:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 lJNijx6nGhZ7 for ; Wed, 19 Jun 2013 23:18:54 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4563821F9C2F for ; Wed, 19 Jun 2013 23:18:53 -0700 (PDT) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 20 Jun 2013 08:18:51 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 20 Jun 2013 08:18:51 +0200 From: To: Date: Thu, 20 Jun 2013 08:18:49 +0200 Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 Thread-Index: Ac5tAUSuZb/7wYL5Sqi3lKwRWoYGIwAe4cbg Message-ID: References: <51C1CD63.7070106@erg.abdn.ac.uk> In-Reply-To: <51C1CD63.7070106@erg.abdn.ac.uk> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 06:18:58 -0000 I support progress of the document. I also agree, that measuring queues by delay as proposed by Codel and PIE i= s desireable. These mechanisms are no commodity yet. Regards, Ruediger -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of G= orry Fairhurst Sent: Wednesday, June 19, 2013 5:25 PM To: tsvwg WG Cc: tsvwg chair Subject: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclud= e 28th June 2013 This email announces the beginning of a short working group last call for draft-ietf-tsvwg-byte-pkt-congest-10, "Byte and Packet Congestion Notification". This document is now thought by the authors to be ready to proceed to be published as a Proposed Standard, it completed a former WGLC and has since received review by the IESG and was subsequently revised. Please send any comments on version -10 to the TSVWG list. The draft is available at: http://tools.ietf.org/html/draft-ietf-tsvwg-byte-pkt-congest The last call will run for one week, ending Friday, 28th June 2013. Emails saying "I support" or "I don't support" are also most helpful in judging the consensus. James, David and Gorry (TSVWG Chairs) From fred@cisco.com Thu Jun 20 00:06:27 2013 Return-Path: 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 6DCC021F9F4A for ; Thu, 20 Jun 2013 00:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.229 X-Spam-Level: X-Spam-Status: No, score=-110.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 GZeTmMMe9xbX for ; Thu, 20 Jun 2013 00:06:21 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A392521F9BA0 for ; Thu, 20 Jun 2013 00:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=588; q=dns/txt; s=iport; t=1371711981; x=1372921581; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZF3fHN3bNbQmu7pIYKB2kcVfQE/dUXHUhUNnUPC/P6w=; b=mCO00ROlvqAoUoZ0o/W76FlYgDk/iOb0dul809Zu9qISpTOv2KY1Eico I6unatfNwnf2QkCXhk+CazLC2Nx71RIOuOjb0vIywBQWWk4Rik6VTcwM9 WU2VjKNi5tc4/CKm0Lw664hK5+e9MBOuuTVZIsswmoeNoXr7X23XxykbW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0OAH2owlGtJXG8/2dsb2JhbABagwl6gju8YAEDAQMBfhZ0giMBAQEDAXkFCwIBCA4UJDIlAgQOBQiIAAa8F48PAjEHgwBhA4hooB2BWIE3gig X-IronPort-AV: E=Sophos;i="4.87,903,1363132800"; d="scan'208";a="225244422" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 20 Jun 2013 07:06:21 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5K76Kfj006803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Jun 2013 07:06:20 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 20 Jun 2013 02:06:20 -0500 From: "Fred Baker (fred)" To: Wesley Eddy Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 Thread-Index: AQHObYSq+AYPy+CNmUKkzllMv9ymZg== Date: Thu, 20 Jun 2013 07:06:20 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B91F81F@xmb-rcd-x09.cisco.com> References: <51C1CD63.7070106@erg.abdn.ac.uk> <20130619160823.GD44982@verdi> <51C26950.20602@mti-systems.com> In-Reply-To: <51C26950.20602@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.125] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6397B8475F864B47BC500CAACFB6C3B0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gorry Fairhurst , tsvwg WG Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 07:06:27 -0000 On Jun 19, 2013, at 7:30 PM, Wesley Eddy wrote: > Clearly you're right that bytes on-the-wire might in several cases be > difficult to infer in code looking only at layer-3 packets, but this > isn't impossible, nor does it seem to lead to an unusably bad > approximation in many common cases. I can only speak for one implementation, but that one implementation looks = at link-layer bytes (including VPN-overhead bytes), not network-layer bytes= . With all due respect, this entire discussion is pretty academic once one = gets away from packets.= From lars@netapp.com Thu Jun 20 01:19:33 2013 Return-Path: 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 521D911E8110 for ; Thu, 20 Jun 2013 01:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.007 X-Spam-Level: X-Spam-Status: No, score=-9.007 tagged_above=-999 required=5 tests=[AWL=1.592, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 s0bi5UzQTnMw for ; Thu, 20 Jun 2013 01:19:28 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC5411E810B for ; Thu, 20 Jun 2013 01:19:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,903,1363158000"; d="scan'208";a="66719630" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx12-out.netapp.com with ESMTP; 20 Jun 2013 01:19:21 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.35]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Thu, 20 Jun 2013 01:19:20 -0700 From: "Eggert, Lars" To: "Fred Baker (fred)" Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 Thread-Index: AQHObRd2EzOX5OhLOkW4d0bm20Ax8Zk+uOgA Date: Thu, 20 Jun 2013 08:19:19 +0000 Message-ID: References: <51C1CD63.7070106@erg.abdn.ac.uk> <20130619160823.GD44982@verdi> <8C48B86A895913448548E6D15DA7553B91EB9C@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B91EB9C@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <2220148519BAFE45BF4CAE5BADB636B9@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gorry Fairhurst , tsvwg WG Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 08:19:33 -0000 Hi, On Jun 19, 2013, at 20:04, Fred Baker (fred) wrote: > I would agree that it makes little sense to almost-simultaneously update = and obsolete RFC 2309. I think you're vastly optimistic in terms of seeing an RFC out of the AQM W= G-to-be :-) > If we are going to have a working group whose job is to rewrite the AQM r= ecommendation, which is what Wes said to TSVAREA that he wanted to do (and = hence my draft) at IETF 86, it would be best to collaborate. I think we should ship draft-ietf-tsvwg-byte-pkt-congest now, and figure ou= t what to do with it and RFC2309 when the AQM is underway. Lars= From dave.taht@gmail.com Thu Jun 20 02:04:56 2013 Return-Path: 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 405E421E80F6 for ; Thu, 20 Jun 2013 02:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 bbh5P786BxzK for ; Thu, 20 Jun 2013 02:04:54 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 96C0B21E80DE for ; Thu, 20 Jun 2013 02:04:54 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id u16so16226306iet.9 for ; Thu, 20 Jun 2013 02:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=n21PgaTrNq8Wgau1eMUjKsWiQAtnmhPhG1GaBh7KPh0=; b=UsrSf4ii53WbmMSHzsQvaN39+33FXjnWA3nAPUVr/Tos9tRRfkOArqPijcgJqNrYyo mDhtxuR5nTzX9ZpGI/sdk0IJ++F22L9ErcpQ4u1T4optMO59KnEUU7hQiTr3JBHvEz2k H0w31fxdHbAiH4oIYrvgxFYNdrxNgQraiM5DjIQWu3VqW4kLlaXeUx2hjEQJmOhq8F+p MurH+ZmabMnGXd6iVLGseSQQ+jp9mYL3XsAmwrKuDsr2yl/dbNm7klCCnxaO1p2nFxkn J5x5jzeIevJH0LAsy9sMpBexDHz3eztHDSza6786rHWHz24Agz2vZopO+KciyzNAarkO w2kA== MIME-Version: 1.0 X-Received: by 10.50.153.10 with SMTP id vc10mr3343536igb.12.1371719093398; Thu, 20 Jun 2013 02:04:53 -0700 (PDT) Received: by 10.64.45.137 with HTTP; Thu, 20 Jun 2013 02:04:53 -0700 (PDT) In-Reply-To: References: <51C1CD63.7070106@erg.abdn.ac.uk> <20130619160823.GD44982@verdi> <8C48B86A895913448548E6D15DA7553B91EB9C@xmb-rcd-x09.cisco.com> Date: Thu, 20 Jun 2013 02:04:53 -0700 Message-ID: From: Dave Taht To: "Eggert, Lars" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Gorry Fairhurst , "Fred Baker \(fred\)" , tsvwg WG Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 09:04:56 -0000 On Thu, Jun 20, 2013 at 1:19 AM, Eggert, Lars wrote: > Hi, > > On Jun 19, 2013, at 20:04, Fred Baker (fred) wrote: >> I would agree that it makes little sense to almost-simultaneously update= and obsolete RFC 2309. > > I think you're vastly optimistic in terms of seeing an RFC out of the AQM= WG-to-be :-) > >> If we are going to have a working group whose job is to rewrite the AQM = recommendation, which is what Wes said to TSVAREA that he wanted to do (and= hence my draft) at IETF 86, it would be best to collaborate. > > I think we should ship draft-ietf-tsvwg-byte-pkt-congest now, and figure = out what to do with it and RFC2309 when the AQM is underway. I do not support this draft for the reasons I outlined in: http://www.ietf.org/mail-archive/web/tsvwg/current/msg12003.html the least of which was the competing updates to rfc2039. As noted therein, byte-congest might be useful if it were specifically narrowed down to focus on best current practices for RED and came with operational advice from an actual deployment and data from actual traffic (rather than the theoretical argument at it core), backing references for section 6, had updates for more modern protocols, and so on. and I'd made a few other comments. > > Lars --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From david.black@emc.com Thu Jun 20 05:58:28 2013 Return-Path: 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 2B78721F99FC for ; Thu, 20 Jun 2013 05:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 kYdPG0nw5Vzz for ; Thu, 20 Jun 2013 05:58:23 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB1A21F9BCF for ; Thu, 20 Jun 2013 05:58:20 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5KCwDs6032741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 08:58:14 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 20 Jun 2013 08:57:55 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5KCvsoC012082; Thu, 20 Jun 2013 08:57:54 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Thu, 20 Jun 2013 08:57:54 -0400 From: "Black, David" To: Dave Taht , "Eggert, Lars" Date: Thu, 20 Jun 2013 08:57:53 -0400 Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 Thread-Index: Ac5tlWauKB9eCwl1Sdm0d2tgFfZkuQAHf7Pg Message-ID: <8D3D17ACE214DC429325B2B98F3AE71298265693@MX15A.corp.emc.com> References: <51C1CD63.7070106@erg.abdn.ac.uk> <20130619160823.GD44982@verdi> <8C48B86A895913448548E6D15DA7553B91EB9C@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: Gorry Fairhurst , "Fred Baker \(fred\)" , tsvwg WG Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 12:58:28 -0000 > the least of which was the competing updates to rfc2039. That would be 2309, and I agree with Lars that holding this draft up becaus= e a new WG-to-be aspires to replace 2309 is not a good idea. > As noted therein, byte-congest might be useful if it were specifically > narrowed down to focus on best current practices for RED and came with > operational advice from an actual deployment and data from actual > traffic (rather than the theoretical argument at its core), backing > references for section 6, had updates for more modern protocols, and Actually, it's somewhat broader than that, as I think Dave T. hit the nail on the head in this line in his other message: > And if we can agree that AQM =3D Active queue *length* management That appears to exactly right - the byte-pkt-congest draft applies to algorithms that manage queues primarily by size (length), not time. A little bit of clarifying text in the draft would go a long way in that regard. In contrast, I would not impose a corresponding restriction on the AQM BOF in Berlin - that effort is starting from a problem and should have flexibility in figuring out what to do to address it. I think this draft has done something useful; the algorithms to which it applies are extensively deployed and far from obsolete, and I'd be disappointed if we lose the results that apply to existing algorithms courtesy of strong interest in working on new ones. Thanks, --David > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of= Dave > Taht > Sent: Thursday, June 20, 2013 5:05 AM > To: Eggert, Lars > Cc: Gorry Fairhurst; Fred Baker (fred); tsvwg WG > Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to > conclude 28th June 2013 >=20 > On Thu, Jun 20, 2013 at 1:19 AM, Eggert, Lars wrote: > > Hi, > > > > On Jun 19, 2013, at 20:04, Fred Baker (fred) wrote: > >> I would agree that it makes little sense to almost-simultaneously upda= te > and obsolete RFC 2309. > > > > I think you're vastly optimistic in terms of seeing an RFC out of the A= QM > WG-to-be :-) > > > >> If we are going to have a working group whose job is to rewrite the AQ= M > recommendation, which is what Wes said to TSVAREA that he wanted to do (a= nd > hence my draft) at IETF 86, it would be best to collaborate. > > > > I think we should ship draft-ietf-tsvwg-byte-pkt-congest now, and figur= e out > what to do with it and RFC2309 when the AQM is underway. >=20 > I do not support this draft for the reasons I outlined in: >=20 > http://www.ietf.org/mail-archive/web/tsvwg/current/msg12003.html >=20 > the least of which was the competing updates to rfc2039. >=20 > As noted therein, byte-congest might be useful if it were specifically > narrowed down to focus on best current practices for RED and came with > operational advice from an actual deployment and data from actual > traffic (rather than the theoretical argument at it core), backing > references for section 6, had updates for more modern protocols, and > so on. >=20 > and I'd made a few other comments. >=20 > > > > Lars >=20 >=20 >=20 > -- > Dave T=E4ht >=20 > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html From fred@cisco.com Thu Jun 20 07:40:18 2013 Return-Path: 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 855BC21F9D00 for ; Thu, 20 Jun 2013 07:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 yzeNU7l-ZzGs for ; Thu, 20 Jun 2013 07:40:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E8F4721F9D09 for ; Thu, 20 Jun 2013 07:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=242; q=dns/txt; s=iport; t=1371739213; x=1372948813; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HWrPdN4IFzh9fuBD1bZYM/7aP4wxqyU+4sKCVHRSllM=; b=DnEsn/JGPcKdKrYyyF4DhLMLeNzLV7RbGoSYb5BJsWsq6PkB7JrBceV5 5bIu2bpgI8iBXB4+94OOQ9y+DzKcRG77Wj8/V4AoDlwNYVZekv0WrLeNj Pv2RFeIKFhyi31l/Aq8/vIL2nwne4HsvFhOlRIlq4rS5cd6GiRXepSfK+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcGAK4Tw1GtJV2Z/2dsb2JhbABbgwl6gju8b3wWdIIjAQEBAwE6PwULAgEIIhQQMiUCBA4FCIgABrtujw8CMQeDAGEDqQWBWIE3gig X-IronPort-AV: E=Sophos;i="4.87,905,1363132800"; d="scan'208";a="225428288" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 20 Jun 2013 14:40:12 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5KEeCR5018565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Jun 2013 14:40:12 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 20 Jun 2013 09:40:11 -0500 From: "Fred Baker (fred)" To: "Eggert, Lars" Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 Thread-Index: AQHObcQRB14sMaczM0ynYaPhEvDNfw== Date: Thu, 20 Jun 2013 14:40:10 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B91FDD8@xmb-rcd-x09.cisco.com> References: <51C1CD63.7070106@erg.abdn.ac.uk> <20130619160823.GD44982@verdi> <8C48B86A895913448548E6D15DA7553B91EB9C@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.125] Content-Type: text/plain; charset="us-ascii" Content-ID: <21B2B26536C515449D60B32D6CE5DC5C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gorry Fairhurst , tsvwg WG Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 14:40:18 -0000 On Jun 20, 2013, at 1:19 AM, "Eggert, Lars" wrote: > I think we should ship draft-ietf-tsvwg-byte-pkt-congest now, and figure = out what to do with it and RFC2309 when the AQM is underway. I'm in favor of that.= From Ruediger.Geib@telekom.de Mon Jun 24 00:59:05 2013 Return-Path: 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 1119D21F9B85 for ; Mon, 24 Jun 2013 00:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 CyQf0OtNE01q for ; Mon, 24 Jun 2013 00:59:00 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id EA22C21E809E for ; Mon, 24 Jun 2013 00:58:59 -0700 (PDT) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 24 Jun 2013 09:58:57 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113656.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 24 Jun 2013 09:58:57 +0200 From: To: , , Date: Mon, 24 Jun 2013 09:58:55 +0200 Thread-Topic: draft-geib-tsvwg-diffserv-intercon-03.txt Thread-Index: Ac5wr3pxMI2u61mZQFiO4cP+go4lTQAAEMnQ Message-ID: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: [tsvwg] draft-geib-tsvwg-diffserv-intercon-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 07:59:05 -0000 Dear TSV WG, the new version of diffserv-intercon should have more comprehensible termin= ology. It further contains a discussion about treatment of PHB network mana= gement / CS6 at interconnection interfaces. Regards, Ruediger -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, June 24, 2013 9:50 AM To: Geib, R=FCdiger; Geib, R=FCdiger Subject: New Version Notification for draft-geib-tsvwg-diffserv-intercon-03= .txt A new version of I-D, draft-geib-tsvwg-diffserv-intercon-03.txt has been successfully submitted by Ruediger Geib and posted to the IETF repository. Filename: draft-geib-tsvwg-diffserv-intercon Revision: 03 Title: DiffServ interconnection classes and practice Creation date: 2013-06-24 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-geib-tsvwg-diffs= erv-intercon-03.txt Status: http://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-= intercon Htmlized: http://tools.ietf.org/html/draft-geib-tsvwg-diffserv-inter= con-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-geib-tsvwg-diffse= rv-intercon-03 Abstract: This document proposes a limited set of interconnection QoS PHBs and PHB groups. It further introduces some DiffServ deployment aspects. The proposals made here should be integrated into a revised version of RFC5127. The IETF Secretariat From svshah@cisco.com Thu Jun 27 07:37:11 2013 Return-Path: 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 7439121F9DC9; Thu, 27 Jun 2013 07:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 2vbcwQcYqH+D; Thu, 27 Jun 2013 07:37:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C04DE21F9D7F; Thu, 27 Jun 2013 07:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2789; q=dns/txt; s=iport; t=1372343823; x=1373553423; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=PwtCkAbTcvQtBdJpevg5SI0NRM6VOz/io8FQnr0c1Io=; b=a+09tbJRkCzmhvHixbQQBtJGB8wZLx6/hVkKpKKcZcYE+xTtLEfxfxJQ 7jpOFqYSbC9YiLw8v9ECvxqDSv7TBEkX60Vt610/t9SGWDNRoMQvfb6f2 CByM6tlL/GjZ6lIrNVWCMcyVJzY/IDfAM5QN6SB778z0tWAKy672Twcj2 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAK9MzFGtJV2Z/2dsb2JhbABbgwkxQwa/CX8WdIIjAQEBAQMBAQE3MwEdAQgiFDcLGwEGAwIEARIIAYgFBwW6cI4dgQczBYMCYwOYbop6hSKDEYFoQA X-IronPort-AV: E=Sophos;i="4.87,952,1363132800"; d="scan'208";a="228166289" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 27 Jun 2013 14:37:02 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5REb28L030496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Jun 2013 14:37:02 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 09:37:01 -0500 From: "Shitanshu Shah (svshah)" To: "idr@ietf.org" , "tsvwg@ietf.org" Thread-Topic: I-D Action: draft-ietf-idr-sla-exchange-01.txt Thread-Index: AQHOc0Ki0np6g8+K9U6RkYxz8y4hCplJf5+A Date: Thu, 27 Jun 2013 14:37:00 +0000 Message-ID: In-Reply-To: <20130627142833.21297.87327.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.21.82.96] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tsvwg] FW: I-D Action: draft-ietf-idr-sla-exchange-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:37:11 -0000 Dear WG, Following is a revised draft incorporating feed-back/comments from the last IETF. Notable changes from the last revision, - use of IPFIX IANA registry for Classifier Elements - use of Tspec for SLA rates - L2_OVERHEAD attribute to allow SLA advertise L3, L2 or customized L2 rates Please provide comments, Regards, Shitanshu On 6/27/13 7:28 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Inter-Domain Routing Working Group of >the IETF. > > Title : Inter-domain SLA Exchange > Author(s) : Shitanshu Shah > Keyur Patel > Sandeep Bajaj > Luis Tomotaki > Mohamed Boucadair > Filename : draft-ietf-idr-sla-exchange-01.txt > Pages : 24 > Date : 2013-06-27 > >Abstract: > Network administrators typically provision QoS (Quality of Service) > policies for their application traffic (such as voice, video) based > on SLAs (Service Level Agreements) negotiated with their providers, > and translate those SLAs to vendor specific configuration language. > Both learning of SLA, either thru SLA documents or via some other > out-of-band method, and translating them to vendor specific > configuration language is a complex, many times manual, process and > prone to errors. This document proposes an in-band method of SLA > signaling which can help to simplify some of the complexities. > > This document defines an operational transitive attribute to signal > SLA details in-band, across administrative boundaries (considered as > Autonomous Systems (AS)), thus simplify and speed-up some of the > complex provisioning tasks. > > Though the use case with the proposed attribute is explicitly defined > in this document, purpose of this attribute is not limited to this > use case only. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-idr-sla-exchange-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-sla-exchange-01 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From john@jlc.net Fri Jun 28 11:09:31 2013 Return-Path: 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 201E421F9B93 for ; Fri, 28 Jun 2013 11:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 MZkAsyopI+eT for ; Fri, 28 Jun 2013 11:09:26 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3468E21F9BBE for ; Fri, 28 Jun 2013 11:09:24 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0A4BA33C21; Fri, 28 Jun 2013 14:09:24 -0400 (EDT) Date: Fri, 28 Jun 2013 14:09:24 -0400 From: John Leslie To: Gorry Fairhurst Message-ID: <20130628180923.GF6068@verdi> References: <51C1CD63.7070106@erg.abdn.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C1CD63.7070106@erg.abdn.ac.uk> User-Agent: Mutt/1.4.1i Cc: tsvwg chair , tsvwg WG Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-byte-pkt-congest-10 - to conclude 28th June 2013 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 18:09:31 -0000 Gorry Fairhurst wrote: > > This email announces the beginning of a short working group last call > for draft-ietf-tsvwg-byte-pkt-congest-10, "Byte and Packet Congestion > Notification". This document is now thought by the authors to be ready > to proceed to be published as a Proposed Standard... Alas, we do need clarity about the intended status. I cannot see how this draft would qualify for Proposed Standard; so I will not discuss that further unless someone confirms that that indeed is the status that will be proposed. The document itself claims Intended status: BCP. IMHO, we have been overtaken by events over the last six years; and to publish a BCP on this topic today would require considerable review and discussion. I am willing to participate in such review; but I am doubtful we will see quick progress with the current authors. :^( I suggest instead publishing pretty much as-is with intended status: Informational. Surely the effort which has gone into it so far justifies a WG Informational RFC. (I'd be happiest with an added note of the expected work in AQM; but I certainly won't insist on that.) I do encourage everyone interested in this to attend the AQM BoF at 1700 on Tuesday, July 30th. (As a brief suggestion of issues deserving our work to publish this as a BCP today, I'll mention: - whether we are attempting to estimate time-on-the-wire when we count bytes and/or packets; - what AQM has come to mean over the last few years; and - how byte and/or packet counting will interact with time-in-queue AQM.) -- John Leslie From jmpolk@cisco.com Fri Jun 28 14:23:12 2013 Return-Path: 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 4E91021F9D78 for ; Fri, 28 Jun 2013 14:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 3NE3PeI4XEHz for ; Fri, 28 Jun 2013 14:23:04 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 419CB21F9D38 for ; Fri, 28 Jun 2013 14:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=889; q=dns/txt; s=iport; t=1372454584; x=1373664184; h=message-id:date:to:from:subject:mime-version; bh=SCdSZSfP9d4KdRbTAY2kOrItS/GYavj0Z5KFXsIOPGo=; b=c25oNbIPuXKqNRTE0ZXwnFrs6mYsZi/eObTVJC0pNlpjdwmtl0vLhwgm OkIuoYxvPwJ+cfCBqjy3FVPEWJXo0H/NERkqvloEHVGivV2ijVqQkOD3t H6UGwqPMwQtr18Ah2QeJt0tFzVwuD/ux53VL0jaTzqyMVJGjqnQ6RdHoP g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAJ/9zVGtJXHB/2dsb2JhbABbgwnBDhZ0gmICViUVHwqIZppMoA6Pc4NRA4kin2iDLx4 X-IronPort-AV: E=Sophos;i="4.87,961,1363132800"; d="scan'208";a="228808411" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 28 Jun 2013 21:22:56 +0000 Received: from jmpolk-WS.cisco.com ([10.89.8.39]) (authenticated bits=0) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5SLMuwW028051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Jun 2013 21:22:56 GMT Message-Id: <201306282122.r5SLMuwW028051@rcdn-core2-6.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 28 Jun 2013 16:22:56 -0500 To: tsvwg@ietf.org From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: [tsvwg] Draft timeslots for TSVWG at IETF87, subject to change X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 21:23:12 -0000 TSVWG Below is the draft agenda times we've been given. There's a typo below in that Session 1 says it's 60 minutes long and Session 2 is 150 minutes, when in fact they are reversed, as indicated by the timeslots of the two sessions. The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tsvwg Session 1 (1:00:00) Monday, Morning Session I 0900-1130 Room Name: Potsdam 2 --------------------------------------------- tsvwg Session 2 (2:30:00) Monday, Afternoon Session II 1510-1610 Room Name: Charlottenburg 2/3 --------------------------------------------- These timeslots for either session is subject to change, so don't make travel plans based on this information. James/Gorry/David TSVWG chairs