From dreibh@iem.uni-due.de Mon Oct 1 22:55:04 2012 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 8E37721F8B5E for ; Mon, 1 Oct 2012 22:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yK31N+2J-QZm for ; Mon, 1 Oct 2012 22:55:03 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3512021F8B5D for ; Mon, 1 Oct 2012 22:55:02 -0700 (PDT) Received: from lupo.localnet ([132.252.151.208]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id q925swKJ032229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 2 Oct 2012 07:54:59 +0200 From: Thomas Dreibholz To: tsvwg@ietf.org Date: Tue, 02 Oct 2012 07:54:53 +0200 Message-ID: <1959305.91fAY4UN8U@lupo> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.9.1 (Linux/3.2.0-31-generic; KDE/4.9.1; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Subject: [tsvwg] [Extended Deadline] Call for Papers of the PAMS 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: Tue, 02 Oct 2012 05:55:04 -0000 We apologize if you receive multiple copies of this CFP. CALL FOR PAPERS The 3rd International Workshop on Protocols and Applications with Multi= -Homing=20 Support (PAMS 2013) In conjunction with the 27th IEEE International Conference on Advanced=20= Information Networking and Applications (AINA 2013) Barcelona, Spain, March 25-28, 2013 http://simula.no/pams2013 The intent of our workshop is to bring together people from research an= d industry, in order to provide a discussion forum for state-of-the-art t= opics related to multi-homing on Network, Transport, Session and Application = Layers. The PAMS workshop will include full-paper sessions as well as a poster = session (with short presentations) to introduce preliminary ideas as well as wo= rk in progress. Workshops proceedings will be published by the IEEE CS Conference Publi= shing Service and will be included in the Digital Library. The main topics to be addressed include (but are not limited to): * Network Resilience by Multi-Homing * Network Architectures for Multi-Homed Systems * Performance Evaluation of Multi-Homed Systems * Deployment of Multi-Homed Protocols in Existing Networks with Middleboxes * Design and Implementation of Multi-Homed Systems * Testbeds for Multi-Homed Systems * Load Sharing and Load Balancing for Multi-Homed Systems * Mobility for Multi-Homed Systems * Protocols with Multi-Homing Support * Congestion and Flow Control of Multi-Homed Systems * Quality of Service for Multi-Homed Systems * Multi-Homing for Interconnection Networks * Security of Multi-Homed Systems * Application Deployment and Support for Legacy Applications * Cross-Layer Optimisation for Multi-Homed Systems * Multi-Homing in the Context of the Future Internet GENERAL CHAIRS: * Thomas Dreibholz, Simula Research Laboratory, Norway * Hakim Adhari, University of Duisburg-Essen, Germany PROGRAM CHAIRS: * Martin Becke, University of Duisburg-Essen, Germany * Thomas Dreibholz, Simula Research Laboratory, Norway PUBLICITY CHAIRS: * Glenford Mapp, Middlesex University, United Kingdom * Xing Zhou, Hainan University, China PROGRAM COMMITTEE * Hakim Adhari, University of Duisburg-Essen, Germany * Nicola Altan, ista International, Germany * Paul Amer, University of Delaware, U.S.A. * Holger Bleul, DB Systel, Germany * Anna Brunstr=F6m, Karlstad University, Sweden * Ahmed Elmokashfi, Simula Research Laboratory, Norway * Kristian Evensen, Simula Research Laboratory, Norway * Ernst Gunnar Gran, Simula Research Laboratory, Norway * Seok Joo Koh, Kyungpook National University, South Korea * Amund Kvalbein, Simula Research Laboratory, Norway * Glenford Mapp, Middlesex University, United Kingdom * Preethi Natarajan, Cisco, U.S.A. * Brad Penoff, Google, U.S.A. * Esbold Unurkhaan, Mongolian University of Science and Technology,= =20 Mongolia * Andreas Timm-Giel, TU Hamburg-Harburg, Germany * Alan Wagner, University of British Columbia, Canada * Michael Welzl, University of Oslo, Norway * Xing Zhou, Hainan University, China IMPORTANT DATES * Paper Submission Deadline: October 15, 2012 -- EXTENDED -- * Author Notification: November 25, 2012 * Camera-Ready Paper Submission: December 28, 2012 * Author Registration: January 11, 2013 CONTACT For further information, please contact: * Thomas Dreibholz (dreibh@simula.no) * Hakim Adhari (hakim.adhari@uni-due.de) WEBSITE http://simula.no/pams2013 From jmpolk@cisco.com Thu Oct 4 15:44:51 2012 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 43A3921F85F7 for ; Thu, 4 Oct 2012 15:44:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rd4y0-CEa4FB for ; Thu, 4 Oct 2012 15:44:50 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 36B9B21F85DA for ; Thu, 4 Oct 2012 15:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1233; q=dns/txt; s=iport; t=1349390681; x=1350600281; h=message-id:date:to:from:subject:mime-version; bh=Qb3hGIPvpjghiaAVN/xwpYYjmAFQIksNYChirvipQGo=; b=dabcBtKnNQcBxeAjQSwBpv9vuNy0UOeIvtcSCawdMvbyZ7EPopXSXNcL VVXbFDLB8zxkzCkx7NvhEFu0Melwc0+ur7oa69KRmgu3x097j17Igcu07 Cfefv1Z8mY+WIig7mRvAkLZA6/9bg2I8n2PCtkqHYmIVxVj5cpfYBm57g 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAHsQblCrRDoJ/2dsb2JhbABFvxeBCII5ASUCVjopeYdilniBKKAMjiaDIQOIWJtUgWmDCw X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="60471552" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 04 Oct 2012 22:44:41 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q94Miei0032713 for ; Thu, 4 Oct 2012 22:44:40 GMT Message-Id: <201210042244.q94Miei0032713@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 04 Oct 2012 17:44:39 -0500 To: tsvwg@ietf.org From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [tsvwg] TSVWG meeting in Atlanta TWICE 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, 04 Oct 2012 22:44:51 -0000 TSVWG Here is the **DRAFT** scheduling for when TSVWG is meeting in Atlanta. This is SUBJECT to change. Please do not base any travel arrangements on this schedule, other than to plan on being in Atlanta for both Thursday and Friday. ++++++++++++++++++++++++++++++ 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) Thursday, Afternoon Session II 1510-1710 Room Name: Grand Ballroom C --------------------------------------------- tsvwg Session 2 (2:00:00) Friday, Morning Session I 0900-1100 Room Name: Salon D --------------------------------------------- ++++++++++++++++++++++++++++++ The plan is to have the Diffserv discussion during the 1 hour slot, which is first, followed by the rest of the WG agenda during the second (2 hour) slot. The best case is for all of the Diffserv discussion to be finished during the first slot. The chairs *think* there might be a little time during the second slot if the Diffserv discussion is not finished. However, that topic cannot run over the other agenda items. James/Gorry/Rolf TSVWG chairs From internet-drafts@ietf.org Tue Oct 9 08:27:34 2012 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 CB07621F873E; Tue, 9 Oct 2012 08:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENxBo3aWoYBd; Tue, 9 Oct 2012 08:27:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A8C21F8734; Tue, 9 Oct 2012 08:27:34 -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.34 Message-ID: <20121009152734.29481.3024.idtracker@ietfa.amsl.com> Date: Tue, 09 Oct 2012 08:27:34 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-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: Tue, 09 Oct 2012 15:27:35 -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 : Stream Control Transmission Protocol (SCTP) Network Addr= ess Translation for Endpoints Author(s) : Randall R. Stewart Michael Tuexen Irene Ruengeler Filename : draft-ietf-tsvwg-natsupp-03.txt Pages : 12 Date : 2012-10-09 Abstract: Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind a NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation (NAPT). To date, specialized code for SCTP has not yet been added to most NATs so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. This document describes the protocol extensions required for the SCTP endpoints to help NAT's provide similar features of NAPT in the single-point and multi-point traversal scenario. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-natsupp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-natsupp-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bob.briscoe@bt.com Thu Oct 11 05:10:43 2012 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 EA0AA21F86CA for ; Thu, 11 Oct 2012 05:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjmG5BAybPeO for ; Thu, 11 Oct 2012 05:10:40 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 0D92C21F866C for ; Thu, 11 Oct 2012 05:10:40 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 11 Oct 2012 13:10:38 +0100 Received: from dyw02134app02.domain1.systemhost.net (193.113.249.14) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 11 Oct 2012 13:10:37 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app02.domain1.systemhost.net (10.35.25.215) with Microsoft SMTP Server id 14.2.309.2; Thu, 11 Oct 2012 13:10:23 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1349957294523; Thu, 11 Oct 2012 13:08:14 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.18.185]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q9BC8BAU012305; Thu, 11 Oct 2012 13:08:11 +0100 Message-ID: <201210111208.q9BC8BAU012305@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 11 Oct 2012 13:08:09 +0100 To: Manner Jukka From: Bob Briscoe In-Reply-To: <3A5279D338C75C40B4B3DA15BA47D6330B6FC2BB@EXMDB04.org.aalto .fi> References: <20120815190728.GQ15012@verdi> <502BFB47.7010803@erg.abdn.ac.uk> <791AD3077F94194BB2BDD13565B6295D45A6212A@PALLENE.office.hd> <15181_1346848013_5047450C_15181_645_1_50474507.3090706@erg.abdn.ac.uk> <3A5279D338C75C40B4B3DA15BA47D6330B616BD2@EXMDB04.org.aalto.fi> <201209051541.q85FfCs0019699@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F33D793B351@EMV65-UKRD.domain1.systemhost.net> <3A5279D338C75C40B4B3DA15BA47D6330B69261A@EXMDB04.org.aalto.fi> <9510D26531EF184D9017DF24659BB87F33D793B845@EMV65-UKRD.domain1.systemhost.net> <04AC95B5-A2B1-4DD2-B765-E20A4C1A69A3@aalto.fi> <3A5279D338C75C40B4B3DA15BA47D6330B6E81E4@EXMDB04.org.aalto.fi> <9510D26531EF184D9017DF24659BB87F33DCE34251@EMV65-UKRD.domain1.systemhost.net> <201210041126.q94BQ0hx002951@bagheera.jungle.bt.co.uk> <1904eec816d080f886f5bf8685358ddc.squirrel@www.erg.abdn.ac.uk> <201210101525.q9AFP4Mi008013@bagheera.jungle.bt.co.uk> <3A5279D338C75C40B4B3DA15BA47D6330B6FC2BB@EXMDB04.org.aalto.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: "" , "" , "" , tsvwg IETF list Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest 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, 11 Oct 2012 12:10:44 -0000 Jukka, What I had in mind is all low level buffers in cheap pure L2 devices, in cheap NATs etc. I was going to list some of these, but instead chose to say "no-one expects AQM to be universally deployed". This clearly missed the mark. Should we include some of these concrete examples of where AQM won't be deployed instead? [I've cc'd the list, given we're starting to wordsmith significantly new text added since WG last call.] Bob At 20:04 10/10/2012, Manner Jukka wrote: >Hi, looked good to me. Just one comment, I wouldn't put that much >emphasis on what is a probably state of things, e.g. > >"no-one expects AQM to ever be .." > in the future it might, we >don't know, and since the paragraph says that it doesn't matter >anyway, I would formulate this paragraph a bit towards that we have >partial deployment now and even with a full deployment, ... > >and similarly with the unrealistic deployment of AQM in the >subsequent paragraph. > >cheers, >Jukka > >On Oct 10, 2012, at 6:25 PM, Bob Briscoe wrote: > > > Phil, > > > > Sorry for delay, my round-robin scheduler is taking so long to > get round all the tasks that I keep finding dead robins (that > reminds me of a bike ride my grandmother took. On her return, she > said there were a worryingly large number of robins run over on the > roads. It turned out that she had been going round the same small > triangle of roads multiple times). > > > > I've done a complete re-write of 3.4. I hope you will agree that > it really is a motivating argument now and it can stay where it is > - it is not just a preamble. > > > > I've gone back to the very first version of 3.4 I wrote and I now > realise that I had written the core of the argument so badly that > even I forgot what it was meant to say when we started editing it. > In the draft-08 version, the original meaning is lost and in your > re-wording it is entirely lost. The link with the draft-08 version > is nearly unrecognisable, but it's the argument I intended here. > > > > > ====================================================================================== > > 3.4. Permanent Partial Deployment of AQM > > > > In overview, the argument in this section runs as follows: > > * Because the network will not and cannot always drop packets in > proportion to their size, it shouldn't be given the task of making > drop signals depend on packet size at all. > > * Transports on the other hand don't always want to make their > rate response proportional to the size of dropped packets, but if > they want to, they always can. > > > > The argument is similar to the end-to-end argument that says > "Don't do X in the network if end-systems can do X by themselves, > and they want to be able to choose whether to do X anyway." > Actually the following argument is stronger; in addition it says > "Don't give the network task X that could be done by the > end-systems, if X won't ever be deployed on all network nodes, and > end-systems won't be able to tell whether their network is doing X, > or whether they need to do X themselves." In this case, the X in > question is "making the response to congestion depend on packet size". > > > > We will now re-run this argument taking each step in more depth. > The argument applies solely to drop, not ECN marking. > > > > A queue drops packets for either of two reasons: a) to signal to > host congestion controls that they should reduce the load and b) > because there is no buffer left to store the packets. Active queue > management tries to use drops as a signal for hosts to slow down > (case a) so that drop due to buffer exhaustion (case b) should not > be necessary. > > > > No-one expects AQM to ever be universally deployed in every queue > in the Internet; and, even if AQM were universal, it has to be able > to cope with buffer exhaustion (by switching to a behaviour like > tail-drop), in order to cope with unresponsive or excessive > transports. Therefore networks will often be dropping packets as a > last resort (case b) rather than under AQM control (case a). > > > > When buffers are exhausted (case b), they don't naturally drop > packets in proportion to their size. The network can only reduce > the probability of dropping smaller packets if it has enough space > to store them somewhere while it waits for a larger packet that it > can drop. If the buffer is exhausted, it does not have this choice. > Admittedly tail-drop does naturally drop somewhat fewer small > packets, but exactly how few depends more on the mix of sizes than > the size of the packet in question. Nonetheless, in general, if we > wanted networks to do size-dependent drop, we would need universal > deployment of (packet-size dependent) AQM code, which is unrealistic. > > > > A host transport cannot know whether any particular drop was a > deliberate signal from an AQM or a sign of a queue shedding packets > due to buffer exhaustion. Therefore, because the network cannot > universally do size-dependent drop, it should not do it all. > > > > Whereas universality is desirable in the network, diversity is > desirable between different transport layer protocols - some, like > NewReno TCP [RFC5681], may not choose to make their rate response > proportionate to the size of each dropped packet, while others will > (e.g. TFRC-SP [RFC4828]). > > > ====================================================================================== > > > > > > > > > > Bob > > > > At 13:13 04/10/2012, gorry@erg.abdn.ac.uk wrote: > >> That would be brilliant! > >> > >> Gorry > >> > >> > Will try to look at this later today. > >> > > >> > > >> > Bob > >> > > >> > At 10:42 02/10/2012, philip.eardley@bt.com wrote: > >> >>Think the token is with bob > >> >> > >> >>Re your comment - yes, I think you could move 3.4 to the end of S3 - > >> >>or to the start - and do some re-phrasing, maybe something like I tried. > >> >> > >> >>-----Original Message----- > >> >>From: Manner Jukka [mailto:jukka.manner@aalto.fi] > >> >>Sent: 01 October 2012 20:18 > >> >>To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,Bob,DUB8 R > >> >>Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst > >> >>Subject: Re: [REVISED I-D]: Document writeup for > >> >>draft-ietf-tsvwg-byte-pkt-congest > >> >> > >> >>Phil, Bob, can we close this finally? It's three weeks now since > >> >>this previous message. > >> >> > >> >>Jukka > >> >> > >> >>On Sep 10, 2012, at 4:42 PM, Jukka Manner wrote: > >> >> > >> >> > Ack, I'm getting there...;) > >> >> > > >> >> > So, we could move 3.4 at the end of Section 3 and rephrase it to > >> >> not talk about scaling per se, but rather about how Req 2.2 > >> >> eventually leads to Req 2.3? > >> >> > > >> >> > Jukka > >> >> > > >> >> > On Sep 7, 2012, at 4:07 PM, > >> >> > wrote: > >> >> > > >> >> >> 3.4 is, in my mind, completely different from 3.1, 3.2, 3.3 and 3.5. > >> >> >> > >> >> >> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for > Recommendation > >> >> >> 2.2 & a lesser extent 2.3 > >> >> >> 3.4 makes doesn't make a motivating argument - it explains that Rec > >> >> >> 2.2 & 2.3 come as a pair (if you recommend one, then inevitably you > >> >> >> recommend the other) (delta some politeness about TCP) > >> >> >> > >> >> >> > >> >> >> > >> >> >> -----Original Message----- > >> >> >> From: Manner Jukka [mailto:jukka.manner@aalto.fi] > >> >> >> Sent: 07 September 2012 13:24 > >> >> >> To: Eardley,PL,Philip,DUB8 R > >> >> >> Cc: Briscoe,RJ,Bob,DUB8 R; ; > >> >> >> > >> >> >> Subject: Re: [REVISED I-D]: Document writeup for > >> >> >> draft-ietf-tsvwg-byte-pkt-congest > >> >> >> > >> >> >> Hi, I'm trying to follow your reasoning, with little luck. ;) > >> >> >> > >> >> >> After having read Section 3 again, I could think of a few > >> >> updates, but I'm not fully following what you want to see: > >> >> >> > >> >> >> - S3.5 is kind of small and lonely by itself. It could be either > >> >> longer or merged somewhere. Not a major issue though and > could remain as > >> >> is. > >> >> >> > >> >> >> - S3.3: Yes, probably could be turned upside down, good first, > >> >> bad later. Don't have a strong opinion. > >> >> >> > >> >> >> - S3.4: Here the scaling is used many times and in the title, > >> >> although we talk about the end host side. This could be rephrased > >> >> and slightly reworded to talk about hosts and their operation > >> >> altogether. Also the word scaling can turn the readers expectation > >> >> into the wrong direction. > >> >> >> > >> >> >> - S3 altogether: It would help to have introductory text about > >> >> networks vs. end host side, but I fail to see why (& how) to > >> >> restructure everything. > >> >> >> > >> >> >> cheers, > >> >> >> Jukka > >> >> >> > >> >> >> On Sep 6, 2012, at 6:18 PM, > >> >> wrote: > >> >> >> > >> >> >>> Ps otherwise Bob's comments are fine, though I suggest for S3.5 you > >> >> >>> give more context (ie are you knocking down what you recommend > >> >> >>> against, or building up what you recommend?) and in S3.3 think > >> >> >>> would be better if you re-structured slightly [first talk > about what > >> >> >>> you like - penult para + 1st sentence of last para - then > talk about > >> >> >>> what you don't like - rest of text] > >> >> >>> > >> >> >>> From: Eardley,PL,Philip,DUB8 R > >> >> >>> Sent: 06 September 2012 16:12 > >> >> >>> To: Briscoe,RJ,Bob,DUB8 R; Manner Jukka > >> >> >>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst > >> >> >>> Subject: RE: [REVISED I-D]: Document writeup for > >> >> >>> draft-ietf-tsvwg-byte-pkt-congest > >> >> >>> > >> >> >>> Thanks bob. Have now re-booted some state. > >> >> >>> I don't like S3.4. My basic problem with it is that it isn't a > >> >> "motivating argument" (S3 title). It's an explanation about the > >> >> consequences of assuming either [option 1] do pkt-size biasing in > >> >> the transport; [option 2]; do pkt-size biasing in the nw. > >> >> >>> Perhaps your effort to buy peace with those who won't change > >> >> TCP has obfuscated the basic point? > >> >> >>> The title of S3.4 (Scaling...) and the early text "scaling > >> >> argument" suggests that you're going to argue there is some reason > >> >> why X scales as order N rather than N^2 or something like that - > >> >> which isn't what S3.4 is about. > >> >> >>> > >> >> >>> I actually think it would be better to put S3.4 at the start of > >> >> S3 - it's background where you say there are 2 options. After that, > >> >> you can explain the reasons why option 1 [pkt biasing in the > >> >> transport] is better - the reasons being:- S3.1 (security etc > >> >> attacks if small pkts get preferential treatment), S3.2 (really a > >> >> side note to S3.1; ie doesn't really present a "motivating > >> >> argument"), S3.3 (nw guessing MTU vs transport knowing pkt size), > >> >> S3.5 (easier implementation). > >> >> >>> > >> >> >>> Something like... > >> >> >>> The behaviour of the network and transport together needs to > >> >> >>> alleviate congestion. We assume the network is bit-congestible > >> >> (currently packet-congestible resources are rate). Therefore > >> >> overall the response of the {network + transport} should be the > >> >> same for the same congestion - whether the congestion is caused by > >> >> a lot of small packets or a smaller number of larger packets. The > >> >> implication is that the transport's behaviour should depend on > >> >> whether the network takes account (or not) of packet size when it > >> >> generates congestion indications:- Case 1: If the network > >> >> implements packet-mode drop, ie its algorithm treats all packets > >> >> equally regardless of their size, then the transport should take > >> >> account of the size of the packet - in other words, the transport's > >> >> congestion response should depend on the number of dropped bytes. > >> >> >>> Case 2: If the network implements byte-mode drop, ie its > >> >> algorithm treats packets differently depending on their size, then > >> >> the transport should not take account of the size of the packet - > >> >> in other words, the transport's congestion response should depend > >> >> on the number of dropped packets. > >> >> >>> > >> >> >>> These cases are explained in more detail in sub-section below. > >> >> >>> > >> >> >>> In both cases the same discussion applies if packets are > >> >> ECN-marked rather than dropped. > >> >> >>> In the following sections we explain why Case 1 is preferable, > >> >> and hence why we make the Recommendations of S2.2 and S3.3 > >> >> (respectively, drop/mark pkts equally regardless of their size, and > >> >> the strength of the transport's response should be proportionate to > >> >> the size of the dropped/marked pkt). > >> >> >>> Note that TCP responds to dropped or marked packets, which differs > >> >> >>> from our recommendation for transports. However, we are not > >> >> >>> recommending that TCP should be changed; to date it hasn't been a > >> >> >>> significant problem because most TCP implementations have been > >> >> used with similar packet sizes. But we do recommend that future > >> >> transport protocols should respond to dropped or marked bytes (as > >> >> for example TFRC-SP [RFC4828]effectively does). > >> >> >>> > >> >> >>> > >> >> >>> Sub-section > >> >> >>> You could use much of S3.3, I suggest supplement with numerical > >> >> >>> examples continuing S1.2 > >> >> >>> -- > >> >> >>> << This gives a get-out clause to any transport that isn't > >> >> >>> packet-size dependent (e.g. current TCP). Lacking packet-size > >> >> >>> dependence just means they don't scale correctly with packet size - > >> >> >>> but they are at liberty not to scale with packet size (particularly > >> >> >>> given MTU growth isn't often being used to increase link rates at > >> >> >>> this stage in history).>> > >> >> >>> > >> >> >>> This is introducing a different point. it's saying that your > >> >> recommendation 2 [drop/mark pkts equally regardless of their size] > >> >> is a really strong reco whilst recommendation 3 [strength of > >> >> transport's response proportionate to the size of the > >> >> dropped/marked pkt] is a much less important reco. I can see this > >> >> might be true, but I don't think the i-d talks about this. > >> >> >>> > >> >> >>> -- > >> >> >>> > >> >> >>> From: Briscoe,RJ,Bob,DUB8 R > >> >> >>> Sent: 05 September 2012 16:41 > >> >> >>> To: Manner Jukka > >> >> >>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst; > Eardley,PL,Philip,DUB8 R > >> >> >>> Subject: Re: [REVISED I-D]: Document writeup for > >> >> >>> draft-ietf-tsvwg-byte-pkt-congest > >> >> >>> > >> >> >>> Jukka, > >> >> >>> > >> >> >>> I've repeated Phil's suggestions as quoted email then made some > >> >> alterations. > >> >> >>> > >> >> >>> Phil asked me to send this, then he will think about it. > >> >> >>> > >> >> >>> I'll respond about John Leslie's argument next... > >> >> >>> > >> >> >>> > >> >> >>> 2.2. Recommendation on Encoding Congestion Notification > >> >> >>> > >> >> >>> [...] > >> >> >>> > >> >> >>> 1. AQM algorithms such as RED SHOULD use packet-mode > drop, ie they > >> >> >>> SHOULD NOT use byte-mode drop. The latter is more complex, > >> >> >>> it creates the perverse incentive to fragment segments into > >> >> tiny > >> >> >>> pieces and it is vulnerable to floods of small packets. > >> >> >>> > >> >> >>> 2. If a vendor has implemented byte-mode drop, and an > operator has > >> >> >>> turned it on, it is RECOMMENDED to turn it off, after > >> >> establishing > >> >> >>> if there are any implications on the relative performance of > >> >> >>> applications using different packet sizes. > >> >> >>> > >> >> >>> RED as a whole SHOULD NOT be turned off. Without RED, a drop > >> >> tail > >> >> >>> queue biases against large packets > >> >> >>> > >> >> >>> [BB adds]: and it is vulnerable to > >> >> floods > >> >> >>> of small-packets. > >> >> >>> > >> >> >>> (I suggest the last para just qualifies item 2. It doesn't warrant > >> >> >>> another item number.) > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> [PE:] S3.3 > >> >> >>> The section could be slightly clearer. Starting with the second > >> >> para, where you start talking about something you don't recommend > >> >> (ie you have to remember that you're talking about the consequences > >> >> of not following your recommendation). > >> >> >>> > >> >> >>> 3.3 Transport-Independent Network > >> >> >>> > >> >> >>> TCP congestion control ensures that flows competing for the same > >> >> >>> resource each maintain the same number of segments in flight, > >> >> >>> irrespective of segment size. So under similar conditions, flows > >> >> >>> with different segment sizes will get different bit-rates. > >> >> >>> > >> >> >>> [OLD:] > >> >> >>> One motivation for the network biasing congestion notification by > >> >> >>> packet size is to counter this effect and try to equalise the bit- > >> >> >>> rates of flows with different packet sizes. > >> >> >>> [SUGGESTED:] > >> >> >>> To counter this effect it seems tempting not to follow our > >> >> >>> recommendation, and instead for the network to bias congestion > >> >> >>> notification by packet size in order to equalise the bit-rates of > >> >> >>> flows with different packet sizes. > >> >> >>> [CONTINUE AS BEFORE:] > >> >> >>> However, in order to do this, the queuing algorithm > >> >> >>> has to make assumptions about the transport, which become embedded > >> >> >>> in the network. Specifically: > >> >> >>> [...] > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> S3.3 > >> >> >>> o The queuing algorithm has to assume how aggressively the > >> >> transport > >> >> >>> will respond to congestion (see Section 4.2.4). If the network > >> >> >>> assumes the transport responds as aggressively as TCP NewReno, > >> >> it > >> >> >>> will be wrong for Compound TCP and differently wrong for Cubic > >> >> >>> TCP, etc. To achieve equal bit-rates, each transport then has > >> >> to > >> >> >>> guess what assumption the network made, and work out how to > >> >> >>> replace this assumed aggressiveness with its own > aggressiveness. > >> >> >>> o Also, if the network biases congestion notification by packet > >> >> size > >> >> >>> it has to assume a baseline packet size--all proposed > algorithms > >> >> >>> use the local MTU. Then transports have to guess > which link was > >> >> >>> congested and what its local MTU was, in order to know how to > >> >> >>> tailor their congestion response to that link. > >> >> >>> > >> >> >>> So you're saying that for byte-mode drop, the network element > >> >> has to compare the size of the current pkt with the MTU, and if > >> >> it's 25* smaller then reduce the pkt loss probably by 25*? And if > >> >> the MTU was bigger, then the current pkt would be dropped with > >> >> greater probability? And both of these things are hard to do. > >> >> >>> > >> >> >>> [BB]: SUGGESTED REPLACEMENT to 2nd bullet: > >> >> >>> > >> >> >>> o Also, if the network biases congestion notification by packet > >> >> size > >> >> >>> it has to assume a baseline packet size--all proposed > algorithms > >> >> >>> use the local MTU (for example see the byte-mode loss > >> >> probability > >> >> >>> formula in Table 1). Then if the non-Reno transports mentioned > >> >> above > >> >> >>> are trying to reverse engineer what the network assumed, they > >> >> also > >> >> >>> have to guess the MTU of the congested link. > >> >> >>> > >> >> >>> [Aside for Phil: The byte-mode algo uses MTU as its > baseline because > >> >> >>> a link cannot send a packet bigger than its MTU so the algo won't > >> >> >>> ever give a drop probability >1).] > >> >> >>> > >> >> >>> > >> >> >>> S3.4 (& knock-on effect on 3.3) > >> >> >>> I think this could be better. > >> >> >>> I agree with your arguments in S3.1 & 3.2 that dropping or > >> >> marking should be independent of pkt size. > >> >> >>> You now go into a couple of pages, which I think could be boiled > >> >> >>> down to a paragraph, saying something like:- > >> >> >>> * the overall system (network + transport) has to be packet-size > >> >> >>> dependent in order to drive out the right amount of traffic so the > >> >> >>> resource becomes uncongested (since we assume all resources are in > >> >> >>> practice byte rather than packet limited) > >> >> >>> * from S3.1 and S3.2 the IETF is convinced that the network > >> >> should notify independent of packet-size. > >> >> >>> * therefore the transport must act dependent on packet-size. > >> >> >>> > >> >> >>> It seems to me this is a necessary consequence of your earlier > >> >> assumptions /arguments. > >> >> >>> > >> >> >>> [BB:] This isn't at all obvious. Until I worked it through, it > >> >> wasn't obvious to me. I think it needs to be spelled out. > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> [On the other hand, if someone disagrees with the arguments and > >> >> >>> thinks that the network should notify dependent on > packet-size, then > >> >> >>> it follows that the transport can act independent of packet-size.] > >> >> >>> > >> >> >>> I think in S3.3 you're trying to make another argument (?):- > >> >> >>> * we can either do packet-size biasing in the network element or on > >> >> >>> the end host transport (see argument above) > >> >> >>> * packet-size biasing in the network is quite tricky, because > >> >> then both the network element & the transport have to make some > >> >> guesses about MTU - whereas with packet-size biasing in the > >> >> transport, neither network element nor transport needs to know what the > >> >> MTU is. > >> >> >>> * it is also easier to implement packet-size biasing in the > >> >> transport than in the network. > >> >> >>> > >> >> >>> [BB] ...and all the other arguments about vulnerability to > >> >> flooding etc, transport-independence etc. > >> >> >>> > >> >> >>> Our argument is sort of like how Phil summarises it, but with > >> >> an added nuance. It's also saying no-one has to do packet-size > >> >> biasing anyway. It's not saying "The transport should given the > >> >> network shouldn't". It's saying "*If the transport wants to claim > >> >> to be scalable wrt packet size* it should if the network shouldn't". > >> >> >>> > >> >> >>> This gives a get-out clause to any transport that isn't > >> >> packet-size dependent (e.g. current TCP). Lacking packet-size > >> >> dependence just means they don't scale correctly with packet size - > >> >> but they are at liberty not to scale with packet size (particularly > >> >> given MTU growth isn't often being used to increase link rates at > >> >> this stage in history). > >> >> >>> > >> >> >>> None of what Phil says convinces me we could say 3.4 (or 3.3) > >> >> any more briefly or differently. It's easier to summarise what you > >> >> understand having read something. But that's not the same as > >> >> writing the thing that helped you understand. There doesn't seem to > >> >> be any argument for why anything needs to be changed, so I'm going > >> >> to leave it as is, unless pushed. > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> On the last bullet, I didn't really follow your argument in > >> >> S3.5. Might be easier to follow if S3.5 also talked about how a > >> >> network element would take account of pkt size? > >> >> >>> Also, does the following argument also apply?: > >> >> >>> * if pkt-size biasing is done in the transport, then the > work (to do > >> >> >>> the biasing) is spread over many end hosts, > >> >> >>> * whereas if pkt-size biasing is done in the network, then the > >> >> work is concentrated in just the congested network element, which > >> >> has to operate on all the traffic at line speed. > >> >> >>> > >> >> >>> [BB]: 3.5. Implementation Efficiency > >> >> >>> > >> >> >>> [ADD:] > >> >> >>> Biasing against large packets typically requires an extra multiply > >> >> >>> and divide in the network (see the example byte-mode drop > >> >> formula in table 1). > >> >> >>> [CONTINUE AS BEFORE:] > >> >> >>> Allowing for packet size at the transport rather than in the > >> >> >>> network ensures that neither the network nor the > transport needs to > >> >> >>> do a multiply operation--multiplication by packet size is > >> >> >>> effectively achieved as a repeated add when the transport adds to > >> >> >>> its count of marked bytes as each congestion event is fed to it. > >> >> >>> [ADD:] > >> >> >>> Also the work to do the biasing is spread over many hosts, rather > >> >> >>> than concentrated in just the congested network element. > >> >> >>> [CONTINUE AS BEFORE:] > >> >> >>> These aren't > >> >> >>> principled reasons in themselves, but they are a happy consequence > >> >> >>> of the other principled reasons. > >> >> >>> > >> >> >>> > >> >> >>> Bob > >> >> >>> > >> >> >>> At 13:36 05/09/2012, Manner Jukka wrote: > >> >> >>> > >> >> >>> Hi Bob, > >> >> >>> > >> >> >>> Since Phil is your colleague at BT, even at Ipswich (?), can > >> >> you check those and agree with Phil how to go forward? Some of > >> >> those are clear, others need discussion with Phil. > >> >> >>> > >> >> >>> Gorry, on point 2) below, I don't follow Leslie's arguments. I > >> >> asked from him detailed comments and resolutions months ago, > and nothing > >> >> came. > >> >> >>> > >> >> >>> cheers, > >> >> >>> Jukka > >> >> >>> > >> >> >>> On Sep 5, 2012, at 3:26 PM, Gorry Fairhurst wrote: > >> >> >>> > >> >> >>>> Bob and Jukka, > >> >> >>>> > >> >> >>>> I think I need your help to resolve this... Some of the > >> >> comments raised by John Leslie appear to have substance, and I'm > >> >> not sure what you plan to do to address these. > >> >> >>>> > >> >> >>>> It would be good to do something quick so that I can complete > >> >> the submission to the IESG. > >> >> >>>> > >> >> >>>> The issues I particularly note are: > >> >> >>>> > >> >> >>>> 1) This contribution from Phil appears to be within scope and > >> >> it seems may have been overlooked (sorry): > >> >> >>>> http://www.ietf.org/mail-archive/web/tsvwg/current/msg11234.html > >> >> >>>> > >> >> >>>> 2) Can you be clear here about what is actually been said - > >> >> because the point below seems to be a misunderstanding of language > >> >> to me, and I hoped we did not claim this: > >> >> >>>> > >> >> >>>>>> ] Alas, when I read it carefully this week, I find that Bob is > >> >> >>>>>> actually ] saying that transport-layer should _only_ consider > >> >> >>>>>> "congested bytes", not ] "congested packets". > >> >> >>>>>> ] > >> >> >>>> > >> >> >>>> 3) You'll need to post the updated draft and send a note to > >> >> the group to confirm that the new version indeed concludes the > >> >> WGLC. I'll add a note to the writeup to indicate the draft content > >> >> has been stable since Oct 2011. > >> >> >>>> > >> >> >>>> Gorry (with my TSVWG Documnent Shepherd hat) > >> >> >>>> cc: Co-Chairs for info. > >> >> >>>> > >> >> >>>>> > >> >> >>>>>> -----Original Message----- > >> >> >>>>>> From: Gorry Fairhurst [ mailto:gorry@erg.abdn.ac.uk] > >> >> >>>>>> Sent: Mittwoch, 15. August 2012 21:41 > >> >> >>>>>> To: tsvwg chair > >> >> >>>>>> Subject: Fwd: Re: [tsvwg] FYI: Document writeup for > >> >> >>>>>> draft-ietf-tsvwg- byte-pkt-congest > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> Hi guys, > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> Apart form the usual rhetoric, there are some points > here that we > >> >> >>>>>> should note as chairs. What are you own thoughts? And was > >> >> >>>>>> anything noted at the IETF in Vancouver concerning this draft? > >> >> >>>>>> > >> >> >>>>>> Gorry > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> -------- Original Message -------- > >> >> >>>>>> Subject: Re: [tsvwg] FYI: Document writeup for > >> >> >>>>>> draft-ietf-tsvwg-byte- pkt-congest > >> >> >>>>>> Date: Wed, 15 Aug 2012 15:07:28 -0400 > >> >> >>>>>> From: John Leslie > >> >> >>>>>> To: Gorry Fairhurst > >> >> >>>>>> CC: tsvwg@ietf.org > >> >> >>>>>> > >> >> >>>>>> Gorry Fairhurst wrote: > >> >> >>>>>>> > >> >> >>>>>>> The following document has been revised after receiving > >> >> WGLC comments. > >> >> >>>>>> > >> >> >>>>>> The changes are mostly refreshing a document scheduled to > >> >> >>>>>> expire this month. > >> >> >>>>>> > >> >> >>>>>>> No issues were found: > >> >> >>>>>> > >> >> >>>>>> Is that with WGC-hat-on? > >> >> >>>>>> > >> >> >>>>>> Neither my issues nor Philip Eardley's comments were > addressed. > >> >> >>>>>> In fact, not even the changes Bob Briscoe mentioned on-list have > >> >> >>>>>> been included. > >> >> >>>>>> > >> >> >>>>>>> As required by RFC 4858, this is the current template for the > >> >> >>>>>> Document > >> >> >>>>>>> Shepherd Write-Up. > >> >> >>>>>>> ... > >> >> >>>>>>> (1) What type of RFC is being requested (BCP, > Proposed Standard, > >> >> >>>>>>> Internet Standard, Informational, Experimental, or Historic)? > >> >> >>>>>>> Why is this the proper type of RFC? Is this type of RFC > >> >> >>>>>>> indicated in the title page header? > >> >> >>>>>>> > >> >> >>>>>>> This document is intended as BCP. (This was discussed > at IETF-81 > >> >> >>>>>>> and that the status changed from Informational to BCP since it > >> >> >>>>>>> provides guidance to implementors and people configuring > >> >> routers and hosts). > >> >> >>>>>> > >> >> >>>>>> Thank you for finally answering my question about BCP status. > >> >> >>>>>> > >> >> >>>>>>> ... > >> >> >>>>>>> Working Group Summary > >> >> >>>>>>> > >> >> >>>>>>> There was consensus to publish this as a WG document and > >> >> >>>>>>> agreement at > >> >> >>>>>>> IETF-82 that the document was now complete. > >> >> >>>>>> > >> >> >>>>>> Was that reviewed on-list? > >> >> >>>>>> > >> >> >>>>>>> ... > >> >> >>>>>>> (3) Briefly describe the review of this document that was > >> >> >>>>>>> performed > >> >> >>>>>> by > >> >> >>>>>>> the Document Shepherd. If this version of the document is not > >> >> >>>>>>> ready for publication, please explain why the document is being > >> >> >>>>>>> forwarded to the IESG. > >> >> >>>>>>> > >> >> >>>>>>> The document was presented at IEWTF-82 (Taipei), with a request > >> >> >>>>>>> for > >> >> >>>>>> WGLC. > >> >> >>>>>>> WGLC concluded with some discussion but no substantive changes > >> >> >>>>>>> on Friday 30th March 2012. > >> >> >>>>>> > >> >> >>>>>> Yes, I guess that is true; but ignoring substantive comments > >> >> >>>>>> isn't a good practice IMHO. > >> >> >>>>>> > >> >> >>>>>>> (4) Does the document Shepherd have any concerns > about the depth > >> >> >>>>>>> or breadth of the reviews that have been performed? > >> >> >>>>>>> > >> >> >>>>>>> No - the original draft had a lot of background material, much > >> >> >>>>>>> of > >> >> >>>>>> this > >> >> >>>>>>> has been condensed or removed, resulting in a smaller document. > >> >> >>>>>> > >> >> >>>>>> That is indeed what I basically asked for, but I don't see any > >> >> >>>>>> evidence of it: > >> >> >>>>>> > >> >> >>>>>> - diff(07,08) 48 lines changed or deleted; 53 lines changed or > >> >> added > >> >> >>>>>> - diff(06,07) 8 lines changed or deleted; 13 lines changed or > >> >> added > >> >> >>>>>> - diff(05,06) 64 lines changed or deleted; 69 lines changed or > >> >> >>>>>> added > >> >> >>>>>> - diff(04,05) 823 lines changed or deleted; 864 lines changed or > >> >> >>>>>> added > >> >> >>>>>> > >> >> >>>>>> (Need I go farther? That gets us back to March 2011...) > >> >> >>>>>> > >> >> >>>>>>> (9) How solid is the WG consensus behind this document? Does it > >> >> >>>>>>> represent the strong concurrence of a few individuals, with > >> >> >>>>>>> others being silent, or does the WG as a whole understand > >> >> and agree with it? > >> >> >>>>>>> > >> >> >>>>>>> The document has WG support and there is consensus to publish. > >> >> >>>>>> > >> >> >>>>>> This, IMHO, doesn't answer the question. :^( > >> >> >>>>>> > >> >> >>>>>> Does it represent the concurrence of a few > individuals, or does > >> >> >>>>>> the WG as a whole understand and agree with it? > >> >> >>>>>> > >> >> >>>>>> For reference, my comments included: > >> >> >>>>>> ] > >> >> >>>>>> ] When I previously skimmed this document, I believed it > >> >> >>>>>> contained only ] common ground: that AQM should > drop/mark packets > >> >> >>>>>> without favoring small ] packets, and that to whatever extent > >> >> >>>>>> packet size _is_ considered, that ] should be a > >> >> transport-layer responsibility. > >> >> >>>>>> ] > >> >> >>>>>> ] Alas, when I read it carefully this week, I find that Bob is > >> >> >>>>>> actually ] saying that transport-layer should _only_ consider > >> >> >>>>>> "congested bytes", not ] "congested packets". > >> >> >>>>>> ] > >> >> >>>>>> ] In fact, Bob openly endorses replacing TCP congestion-control > >> >> >>>>>> with an ] algorithm which calculates "fair-share bytes" and > >> >> >>>>>> doesn't back off at all ] (even in the presence of 20% packet > >> >> >>>>>> loss) unless you're already sending ] more than this > >> >> "fair-share". > >> >> >>>>>> ] > >> >> >>>>>> ] I do not believe that is the consensus of this WG; and I > >> >> believe > >> >> >>>>>> if > >> >> >>>>>> ] that were the consensus it would exceed our charter. > >> >> >>>>>> ] > >> >> >>>>>> ] The draft contains a number of things I _do_ support; and I'd > >> >> >>>>>> be happy ] to support a considerably shorter draft which > >> >> >>>>>> concentrates on the AQM ] recommendation, omitting any > >> >> >>>>>> suggestions of modifying TCP congestion ] control. > >> >> >>>>>> > >> >> >>>>>> and Philip's comments included: > >> >> >>>>>> ] > >> >> >>>>>> ] S2.2 I thought the numbered bullets could be better phrased, > >> >> >>>>>> something like ] +this:- ] > >> >> >>>>>> ] 1. AQM algorithms such as RED SHOULD use packet-mode > >> >> drop, ie they > >> >> >>>>>> SHOULD NOT > >> >> >>>>>> ] +use byte-mode drop. The latter ] is more complex, > >> >> >>>>>> ] it creates the perverse incentive to fragment segments > >> >> into > >> >> >>>>>> tiny > >> >> >>>>>> ] pieces and it is vulnerable to floods of small- > >> >> >>>>>> ] packets. > >> >> >>>>>> ] > >> >> >>>>>> ] 2. If a vendor has implemented byte-mode drop, and an > >> >> operator > >> >> >>>>>> has > >> >> >>>>>> ] turned it on, it is RECOMMENDED to turn it off, after > >> >> >>>>>> establishing if > >> >> >>>>>> ] +there are any implications on > >> >> >>>>>> ] the relative performance of > >> >> >>>>>> ] applications using different packet sizes. > >> >> >>>>>> ] > >> >> >>>>>> ] 3. RED SHOULD NOT be turned off. Without RED, a drop tail > >> >> >>>>>> ] queue biases against large packets. > >> >> >>>>>> ] > >> >> >>>>>> ] Nit - the following paragraph shouldn't be indented (Note well > >> >> >>>>>> that > >> >> >>>>>> RED's...) > >> >> >>>>>> ] > >> >> >>>>>> ] S3.3 > >> >> >>>>>> ] The section could be slightly clearer. Starting with > the second > >> >> >>>>>> para, where you ] +start talking about something you don't > >> >> >>>>>> recommend (ie you have to remember that ] +you're talking about > >> >> >>>>>> the consequences of not following your recommendation). > >> >> >>>>>> ] > >> >> >>>>>> ] S3.3 > >> >> >>>>>> ] o Also, if the network biases congestion notification by > >> >> packet > >> >> >>>>>> size > >> >> >>>>>> ] it has to assume a baseline packet size--all proposed > >> >> >>>>>> algorithms > >> >> >>>>>> ] use the local MTU. Then transports have to guess which > >> >> link > >> >> >>>>>> was > >> >> >>>>>> ] congested and what its local MTU was, in order to know > >> >> how to > >> >> >>>>>> ] tailor their congestion response to that link. > >> >> >>>>>> ] So you're saying that for byte-mode drop, the network element > >> >> >>>>>> has to compare the ] +size of the current pkt with the MTU, and > >> >> >>>>>> if it's 25* smaller then reduce the ] +pkt loss probably by 25*? > >> >> >>>>>> And if the MTU was bigger, then the current pkt would ] +be > >> >> >>>>>> dropped with greater probability? And both of these things > >> >> are hard to do. > >> >> >>>>>> ] > >> >> >>>>>> ] S3.4 (& knock-on effect on 3.3) ] I think this could > be better. > >> >> >>>>>> ] I agree with your arguments in S3.1 & 3.2 that dropping or > >> >> >>>>>> marking should be ] +independent of pkt size. > >> >> >>>>>> ] You now go into a couple of pages, which I think could be > >> >> >>>>>> boiled down to a ] +paragraph, saying something like:- ] * the > >> >> >>>>>> overall system (network + transport) has to be packet-size > >> >> >>>>>> dependent in ] > >> >> >>>>>> +order to drive out the right amount of traffic so the resource > >> >> >>>>>> becomes ] > >> >> >>>>>> +uncongested (since we assume all resources are in practice byte > >> >> >>>>>> +rather > >> >> >>>>>> than ] +packet limited) ] * from S3.1 and S3.2 the IETF is > >> >> >>>>>> convinced that the network should notify ] +independent of > >> >> packet-size. > >> >> >>>>>> ] * therefore the transport must act dependent on packet-size. > >> >> >>>>>> ] > >> >> >>>>>> ] It seems to me this is a necessary consequence of your earlier > >> >> >>>>>> assumptions ] +/arguments. > >> >> >>>>>> ] > >> >> >>>>>> ] [On the other hand, if someone disagrees with the > arguments and > >> >> >>>>>> thinks that the ] +network should notify dependent on > >> >> >>>>>> packet-size, then it follows that the ] +transport can act > >> >> >>>>>> independent of > >> >> >>>>>> packet- size.] ] ] I think in S3.3 you're trying to make another > >> >> >>>>>> argument (?):- ] * we can either do packet-size biasing in the > >> >> >>>>>> network element or on the end host ] +transport (see argument > >> >> >>>>>> above) ] * packet-size biasing in the network is quite tricky, > >> >> >>>>>> because then both the ] +network element & the transport have to > >> >> >>>>>> make some guesses about MTU - whereas ] > >> >> >>>>>> +with packet-size biasing in the transport, neither network > >> >> >>>>>> +element > >> >> >>>>>> nor ] +transport needs to know what the MTU is. > >> >> >>>>>> ] * it is also easier to implement packet-size biasing in the > >> >> >>>>>> transport than in ] +the network. > >> >> >>>>>> ] > >> >> >>>>>> ] On the last bullet, I didn't really follow your argument in > >> >> S3.5. > >> >> >>>>>> Might be ] +easier to follow if S3.5 also talked about how a > >> >> >>>>>> network element would take ] +account of pkt size? > Also, does the > >> >> >>>>>> following argument also apply?: > >> >> >>>>>> ] * if pkt-size biasing is done in the transport, then the work > >> >> >>>>>> (to do the ] +biasing) is spread over many end hosts, > ] * whereas > >> >> >>>>>> if pkt-size biasing is done in the network, then the work is ] > >> >> >>>>>> +concentrated in just the congested network element, > which has to > >> >> >>>>>> operate on all ] +the traffic at line speed. > >> >> >>>>>> > >> >> >>>>>> (Has there perhaps been some confusion about what > went into the > >> >> >>>>>> -08 > >> >> >>>>>> version?) > >> >> >>>>>> > >> >> >>>>>> -- > >> >> >>>>>> John Leslie > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>> > >> >> >>>> > >> >> >>> ________________________________________________________________ > >> >> >>> Bob Briscoe, BT Innovate & Design > >> >> >>> > >> >> >> > >> >> > > >> > > >> > ________________________________________________________________ > >> > Bob Briscoe, BT Innovate & Design > >> > > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design From jukka.manner@aalto.fi Thu Oct 11 05:34:30 2012 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 C915D21F853A; Thu, 11 Oct 2012 05:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAwKzV2WLexz; Thu, 11 Oct 2012 05:34:28 -0700 (PDT) Received: from mx05.aalto.fi (mx05.aalto.fi [130.233.222.104]) by ietfa.amsl.com (Postfix) with ESMTP id E673A21F852C; Thu, 11 Oct 2012 05:34:26 -0700 (PDT) Received: from mx05.aalto.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AA13C805EC; Thu, 11 Oct 2012 15:34:25 +0300 (EEST) Received: from EXHUB04.org.aalto.fi (ex-hub04.org.aalto.fi [130.233.222.117]) by mx05.aalto.fi (Postfix) with ESMTP id 853DE805DA; Thu, 11 Oct 2012 15:34:25 +0300 (EEST) Received: from EXMDB04.org.aalto.fi ([169.254.1.56]) by EXHUB04.org.aalto.fi ([130.233.222.117]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 15:34:25 +0300 From: Manner Jukka To: Bob Briscoe Thread-Topic: [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest Thread-Index: AQHNp6lsRPJg5MIAXUex2DyM9GzvLZez196A Date: Thu, 11 Oct 2012 12:34:24 +0000 Message-ID: <3A5279D338C75C40B4B3DA15BA47D6330B6FD072@EXMDB04.org.aalto.fi> References: <20120815190728.GQ15012@verdi> <502BFB47.7010803@erg.abdn.ac.uk> <791AD3077F94194BB2BDD13565B6295D45A6212A@PALLENE.office.hd> <15181_1346848013_5047450C_15181_645_1_50474507.3090706@erg.abdn.ac.uk> <3A5279D338C75C40B4B3DA15BA47D6330B616BD2@EXMDB04.org.aalto.fi> <201209051541.q85FfCs0019699@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F33D793B351@EMV65-UKRD.domain1.systemhost.net> <3A5279D338C75C40B4B3DA15BA47D6330B69261A@EXMDB04.org.aalto.fi> <9510D26531EF184D9017DF24659BB87F33D793B845@EMV65-UKRD.domain1.systemhost.net> <04AC95B5-A2B1-4DD2-B765-E20A4C1A69A3@aalto.fi> <3A5279D338C75C40B4B3DA15BA47D6330B6E81E4@EXMDB04.org.aalto.fi> <9510D26531EF184D9017DF24659BB87F33DCE34251@EMV65-UKRD.domain1.systemhost.net> <201210041126.q94BQ0hx002951@bagheera.jungle.bt.co.uk> <1904eec816d080f886f5bf8685358ddc.squirrel@www.erg.abdn.ac.uk> <201210101525.q9AFP4Mi008013@bagheera.jungle.bt.co.uk> <3A5279D338C75C40B4B3DA15BA47D6330B6FC2BB@EXMDB04.org.aalto.fi> <201210111208.q9BC8BAU012305@bagheera.jungle.bt.co.uk> In-Reply-To: <201210111208.q9BC8BAU012305@bagheera.jungle.bt.co.uk> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.152.186.160] Content-Type: text/plain; charset="us-ascii" Content-ID: <8F3970199241254EA15348CB79A33AEF@aalto.fi> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , tsvwg IETF list Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest 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, 11 Oct 2012 12:34:31 -0000 Hi, Yeah, please at the point about cheap devices, still, I wonder what the cos= t of AQM is on those devices. Maybe 1 cnt in mass production? Thus, I still= wonder if it is worth arguing something about the future that strongly. Sorry, but the same goes for AQM in general, and where it is, or will not b= e deployed. I understand technical reasons why not something is feasible, b= ut business or monetary reasons can change very quickly. ;) Jukka On Oct 11, 2012, at 3:08 PM, Bob Briscoe wrote: > Jukka, >=20 > What I had in mind is all low level buffers in cheap pure L2 devices, in = cheap NATs etc. I was going to list some of these, but instead chose to say= "no-one expects AQM to be universally deployed". This clearly missed the m= ark. >=20 > Should we include some of these concrete examples of where AQM won't be d= eployed instead? >=20 > [I've cc'd the list, given we're starting to wordsmith significantly new = text added since WG last call.] >=20 >=20 > Bob >=20 > At 20:04 10/10/2012, Manner Jukka wrote: >> Hi, looked good to me. Just one comment, I wouldn't put that much emphas= is on what is a probably state of things, e.g. >>=20 >> "no-one expects AQM to ever be .." > in the future it might, we don't k= now, and since the paragraph says that it doesn't matter anyway, I would fo= rmulate this paragraph a bit towards that we have partial deployment now an= d even with a full deployment, ... >>=20 >> and similarly with the unrealistic deployment of AQM in the subsequent p= aragraph. >>=20 >> cheers, >> Jukka >>=20 >> On Oct 10, 2012, at 6:25 PM, Bob Briscoe wrote: >>=20 >> > Phil, >> > >> > Sorry for delay, my round-robin scheduler is taking so long to get rou= nd all the tasks that I keep finding dead robins (that reminds me of a bike= ride my grandmother took. On her return, she said there were a worryingly = large number of robins run over on the roads. It turned out that she had be= en going round the same small triangle of roads multiple times). >> > >> > I've done a complete re-write of 3.4. I hope you will agree that it re= ally is a motivating argument now and it can stay where it is - it is not j= ust a preamble. >> > >> > I've gone back to the very first version of 3.4 I wrote and I now real= ise that I had written the core of the argument so badly that even I forgot= what it was meant to say when we started editing it. In the draft-08 versi= on, the original meaning is lost and in your re-wording it is entirely lost= . The link with the draft-08 version is nearly unrecognisable, but it's the= argument I intended here. >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > 3.4. Permanent Partial Deployment of AQM >> > >> > In overview, the argument in this section runs as follows: >> > * Because the network will not and cannot always drop packets in propo= rtion to their size, it shouldn't be given the task of making drop signals = depend on packet size at all. >> > * Transports on the other hand don't always want to make their rate re= sponse proportional to the size of dropped packets, but if they want to, th= ey always can. >> > >> > The argument is similar to the end-to-end argument that says "Don't do= X in the network if end-systems can do X by themselves, and they want to b= e able to choose whether to do X anyway." Actually the following argument i= s stronger; in addition it says "Don't give the network task X that could b= e done by the end-systems, if X won't ever be deployed on all network nodes= , and end-systems won't be able to tell whether their network is doing X, o= r whether they need to do X themselves." In this case, the X in question is= "making the response to congestion depend on packet size". >> > >> > We will now re-run this argument taking each step in more depth. The a= rgument applies solely to drop, not ECN marking. >> > >> > A queue drops packets for either of two reasons: a) to signal to host = congestion controls that they should reduce the load and b) because there i= s no buffer left to store the packets. Active queue management tries to use= drops as a signal for hosts to slow down (case a) so that drop due to buff= er exhaustion (case b) should not be necessary. >> > >> > No-one expects AQM to ever be universally deployed in every queue in t= he Internet; and, even if AQM were universal, it has to be able to cope wit= h buffer exhaustion (by switching to a behaviour like tail-drop), in order = to cope with unresponsive or excessive transports. Therefore networks will = often be dropping packets as a last resort (case b) rather than under AQM c= ontrol (case a). >> > >> > When buffers are exhausted (case b), they don't naturally drop packets= in proportion to their size. The network can only reduce the probability o= f dropping smaller packets if it has enough space to store them somewhere w= hile it waits for a larger packet that it can drop. If the buffer is exhaus= ted, it does not have this choice. Admittedly tail-drop does naturally drop= somewhat fewer small packets, but exactly how few depends more on the mix = of sizes than the size of the packet in question. Nonetheless, in general, = if we wanted networks to do size-dependent drop, we would need universal de= ployment of (packet-size dependent) AQM code, which is unrealistic. >> > >> > A host transport cannot know whether any particular drop was a deliber= ate signal from an AQM or a sign of a queue shedding packets due to buffer = exhaustion. Therefore, because the network cannot universally do size-depen= dent drop, it should not do it all. >> > >> > Whereas universality is desirable in the network, diversity is desirab= le between different transport layer protocols - some, like NewReno TCP [RF= C5681], may not choose to make their rate response proportionate to the siz= e of each dropped packet, while others will (e.g. TFRC-SP [RFC4828]). >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> > >> > >> > >> > Bob >> > >> > At 13:13 04/10/2012, gorry@erg.abdn.ac.uk wrote: >> >> That would be brilliant! >> >> >> >> Gorry >> >> >> >> > Will try to look at this later today. >> >> > >> >> > >> >> > Bob >> >> > >> >> > At 10:42 02/10/2012, philip.eardley@bt.com wrote: >> >> >>Think the token is with bob >> >> >> >> >> >>Re your comment - yes, I think you could move 3.4 to the end of S3 = - >> >> >>or to the start - and do some re-phrasing, maybe something like I t= ried. >> >> >> >> >> >>-----Original Message----- >> >> >>From: Manner Jukka [mailto:jukka.manner@aalto.fi] >> >> >>Sent: 01 October 2012 20:18 >> >> >>To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,Bob,DUB8 R >> >> >>Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst >> >> >>Subject: Re: [REVISED I-D]: Document writeup for >> >> >>draft-ietf-tsvwg-byte-pkt-congest >> >> >> >> >> >>Phil, Bob, can we close this finally? It's three weeks now since >> >> >>this previous message. >> >> >> >> >> >>Jukka >> >> >> >> >> >>On Sep 10, 2012, at 4:42 PM, Jukka Manner wrote: >> >> >> >> >> >> > Ack, I'm getting there...;) >> >> >> > >> >> >> > So, we could move 3.4 at the end of Section 3 and rephrase it to >> >> >> not talk about scaling per se, but rather about how Req 2.2 >> >> >> eventually leads to Req 2.3? >> >> >> > >> >> >> > Jukka >> >> >> > >> >> >> > On Sep 7, 2012, at 4:07 PM, >> >> >> > wrote: >> >> >> > >> >> >> >> 3.4 is, in my mind, completely different from 3.1, 3.2, 3.3 and= 3.5. >> >> >> >> >> >> >> >> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for Recommen= dation >> >> >> >> 2.2 & a lesser extent 2.3 >> >> >> >> 3.4 makes doesn't make a motivating argument - it explains that= Rec >> >> >> >> 2.2 & 2.3 come as a pair (if you recommend one, then inevitably= you >> >> >> >> recommend the other) (delta some politeness about TCP) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> >> From: Manner Jukka [mailto:jukka.manner@aalto.fi] >> >> >> >> Sent: 07 September 2012 13:24 >> >> >> >> To: Eardley,PL,Philip,DUB8 R >> >> >> >> Cc: Briscoe,RJ,Bob,DUB8 R; ; >> >> >> >> >> >> >> >> Subject: Re: [REVISED I-D]: Document writeup for >> >> >> >> draft-ietf-tsvwg-byte-pkt-congest >> >> >> >> >> >> >> >> Hi, I'm trying to follow your reasoning, with little luck. ;) >> >> >> >> >> >> >> >> After having read Section 3 again, I could think of a few >> >> >> updates, but I'm not fully following what you want to see: >> >> >> >> >> >> >> >> - S3.5 is kind of small and lonely by itself. It could be eithe= r >> >> >> longer or merged somewhere. Not a major issue though and could rem= ain as >> >> >> is. >> >> >> >> >> >> >> >> - S3.3: Yes, probably could be turned upside down, good first, >> >> >> bad later. Don't have a strong opinion. >> >> >> >> >> >> >> >> - S3.4: Here the scaling is used many times and in the title, >> >> >> although we talk about the end host side. This could be rephrased >> >> >> and slightly reworded to talk about hosts and their operation >> >> >> altogether. Also the word scaling can turn the readers expectation >> >> >> into the wrong direction. >> >> >> >> >> >> >> >> - S3 altogether: It would help to have introductory text about >> >> >> networks vs. end host side, but I fail to see why (& how) to >> >> >> restructure everything. >> >> >> >> >> >> >> >> cheers, >> >> >> >> Jukka >> >> >> >> >> >> >> >> On Sep 6, 2012, at 6:18 PM, >> >> >> wrote: >> >> >> >> >> >> >> >>> Ps otherwise Bob's comments are fine, though I suggest for S3.= 5 you >> >> >> >>> give more context (ie are you knocking down what you recommend >> >> >> >>> against, or building up what you recommend?) and in S3.3 thin= k >> >> >> >>> would be better if you re-structured slightly [first talk abou= t what >> >> >> >>> you like - penult para + 1st sentence of last para - then talk= about >> >> >> >>> what you don't like - rest of text] >> >> >> >>> >> >> >> >>> From: Eardley,PL,Philip,DUB8 R >> >> >> >>> Sent: 06 September 2012 16:12 >> >> >> >>> To: Briscoe,RJ,Bob,DUB8 R; Manner Jukka >> >> >> >>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst >> >> >> >>> Subject: RE: [REVISED I-D]: Document writeup for >> >> >> >>> draft-ietf-tsvwg-byte-pkt-congest >> >> >> >>> >> >> >> >>> Thanks bob. Have now re-booted some state. >> >> >> >>> I don't like S3.4. My basic problem with it is that it isn't a >> >> >> "motivating argument" (S3 title). It's an explanation about the >> >> >> consequences of assuming either [option 1] do pkt-size biasing in >> >> >> the transport; [option 2]; do pkt-size biasing in the nw. >> >> >> >>> Perhaps your effort to buy peace with those who won't change >> >> >> TCP has obfuscated the basic point? >> >> >> >>> The title of S3.4 (Scaling...) and the early text "scaling >> >> >> argument" suggests that you're going to argue there is some reason >> >> >> why X scales as order N rather than N^2 or something like that - >> >> >> which isn't what S3.4 is about. >> >> >> >>> >> >> >> >>> I actually think it would be better to put S3.4 at the start o= f >> >> >> S3 - it's background where you say there are 2 options. After that= , >> >> >> you can explain the reasons why option 1 [pkt biasing in the >> >> >> transport] is better - the reasons being:- S3.1 (security etc >> >> >> attacks if small pkts get preferential treatment), S3.2 (really a >> >> >> side note to S3.1; ie doesn't really present a "motivating >> >> >> argument"), S3.3 (nw guessing MTU vs transport knowing pkt size), >> >> >> S3.5 (easier implementation). >> >> >> >>> >> >> >> >>> Something like... >> >> >> >>> The behaviour of the network and transport together needs to >> >> >> >>> alleviate congestion. We assume the network is bit-congestible >> >> >> (currently packet-congestible resources are rate). Therefore >> >> >> overall the response of the {network + transport} should be the >> >> >> same for the same congestion - whether the congestion is caused by >> >> >> a lot of small packets or a smaller number of larger packets. The >> >> >> implication is that the transport's behaviour should depend on >> >> >> whether the network takes account (or not) of packet size when it >> >> >> generates congestion indications:- Case 1: If the network >> >> >> implements packet-mode drop, ie its algorithm treats all packets >> >> >> equally regardless of their size, then the transport should take >> >> >> account of the size of the packet - in other words, the transport'= s >> >> >> congestion response should depend on the number of dropped bytes. >> >> >> >>> Case 2: If the network implements byte-mode drop, ie its >> >> >> algorithm treats packets differently depending on their size, then >> >> >> the transport should not take account of the size of the packet - >> >> >> in other words, the transport's congestion response should depend >> >> >> on the number of dropped packets. >> >> >> >>> >> >> >> >>> These cases are explained in more detail in sub-section below. >> >> >> >>> >> >> >> >>> In both cases the same discussion applies if packets are >> >> >> ECN-marked rather than dropped. >> >> >> >>> In the following sections we explain why Case 1 is preferable, >> >> >> and hence why we make the Recommendations of S2.2 and S3.3 >> >> >> (respectively, drop/mark pkts equally regardless of their size, an= d >> >> >> the strength of the transport's response should be proportionate t= o >> >> >> the size of the dropped/marked pkt). >> >> >> >>> Note that TCP responds to dropped or marked packets, which dif= fers >> >> >> >>> from our recommendation for transports. However, we are not >> >> >> >>> recommending that TCP should be changed; to date it hasn't be= en a >> >> >> >>> significant problem because most TCP implementations have bee= n >> >> >> used with similar packet sizes. But we do recommend that future >> >> >> transport protocols should respond to dropped or marked bytes (as >> >> >> for example TFRC-SP [RFC4828]effectively does). >> >> >> >>> >> >> >> >>> >> >> >> >>> Sub-section >> >> >> >>> You could use much of S3.3, I suggest supplement with numerica= l >> >> >> >>> examples continuing S1.2 >> >> >> >>> -- >> >> >> >>> << This gives a get-out clause to any transport that isn't >> >> >> >>> packet-size dependent (e.g. current TCP). Lacking packet-size >> >> >> >>> dependence just means they don't scale correctly with packet s= ize - >> >> >> >>> but they are at liberty not to scale with packet size (particu= larly >> >> >> >>> given MTU growth isn't often being used to increase link rates= at >> >> >> >>> this stage in history).>> >> >> >> >>> >> >> >> >>> This is introducing a different point. it's saying that your >> >> >> recommendation 2 [drop/mark pkts equally regardless of their size] >> >> >> is a really strong reco whilst recommendation 3 [strength of >> >> >> transport's response proportionate to the size of the >> >> >> dropped/marked pkt] is a much less important reco. I can see this >> >> >> might be true, but I don't think the i-d talks about this. >> >> >> >>> >> >> >> >>> -- >> >> >> >>> >> >> >> >>> From: Briscoe,RJ,Bob,DUB8 R >> >> >> >>> Sent: 05 September 2012 16:41 >> >> >> >>> To: Manner Jukka >> >> >> >>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst; Eardley,PL,Philip,= DUB8 R >> >> >> >>> Subject: Re: [REVISED I-D]: Document writeup for >> >> >> >>> draft-ietf-tsvwg-byte-pkt-congest >> >> >> >>> >> >> >> >>> Jukka, >> >> >> >>> >> >> >> >>> I've repeated Phil's suggestions as quoted email then made som= e >> >> >> alterations. >> >> >> >>> >> >> >> >>> Phil asked me to send this, then he will think about it. >> >> >> >>> >> >> >> >>> I'll respond about John Leslie's argument next... >> >> >> >>> >> >> >> >>> >> >> >> >>> 2.2. Recommendation on Encoding Congestion Notification >> >> >> >>> >> >> >> >>> [...] >> >> >> >>> >> >> >> >>> 1. AQM algorithms such as RED SHOULD use packet-mode drop, i= e they >> >> >> >>> SHOULD NOT use byte-mode drop. The latter is more complex= , >> >> >> >>> it creates the perverse incentive to fragment segments in= to >> >> >> tiny >> >> >> >>> pieces and it is vulnerable to floods of small packets. >> >> >> >>> >> >> >> >>> 2. If a vendor has implemented byte-mode drop, and an operat= or has >> >> >> >>> turned it on, it is RECOMMENDED to turn it off, after >> >> >> establishing >> >> >> >>> if there are any implications on the relative performance= of >> >> >> >>> applications using different packet sizes. >> >> >> >>> >> >> >> >>> RED as a whole SHOULD NOT be turned off. Without RED, a d= rop >> >> >> tail >> >> >> >>> queue biases against large packets >> >> >> >>> >> >> >> >>> [BB adds]: and it is vulnerabl= e to >> >> >> floods >> >> >> >>> of small-packets. >> >> >> >>> >> >> >> >>> (I suggest the last para just qualifies item 2. It doesn't war= rant >> >> >> >>> another item number.) >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> [PE:] S3.3 >> >> >> >>> The section could be slightly clearer. Starting with the secon= d >> >> >> para, where you start talking about something you don't recommend >> >> >> (ie you have to remember that you're talking about the consequence= s >> >> >> of not following your recommendation). >> >> >> >>> >> >> >> >>> 3.3 Transport-Independent Network >> >> >> >>> >> >> >> >>> TCP congestion control ensures that flows competing for the s= ame >> >> >> >>> resource each maintain the same number of segments in flight, >> >> >> >>> irrespective of segment size. So under similar conditions, fl= ows >> >> >> >>> with different segment sizes will get different bit-rates. >> >> >> >>> >> >> >> >>> [OLD:] >> >> >> >>> One motivation for the network biasing congestion notificatio= n by >> >> >> >>> packet size is to counter this effect and try to equalise the = bit- >> >> >> >>> rates of flows with different packet sizes. >> >> >> >>> [SUGGESTED:] >> >> >> >>> To counter this effect it seems tempting not to follow our >> >> >> >>> recommendation, and instead for the network to bias congestio= n >> >> >> >>> notification by packet size in order to equalise the bit-rate= s of >> >> >> >>> flows with different packet sizes. >> >> >> >>> [CONTINUE AS BEFORE:] >> >> >> >>> However, in order to do this, the queuing algo= rithm >> >> >> >>> has to make assumptions about the transport, which become emb= edded >> >> >> >>> in the network. Specifically: >> >> >> >>> [...] >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> S3.3 >> >> >> >>> o The queuing algorithm has to assume how aggressively the >> >> >> transport >> >> >> >>> will respond to congestion (see Section 4.2.4). If the ne= twork >> >> >> >>> assumes the transport responds as aggressively as TCP NewR= eno, >> >> >> it >> >> >> >>> will be wrong for Compound TCP and differently wrong for C= ubic >> >> >> >>> TCP, etc. To achieve equal bit-rates, each transport then= has >> >> >> to >> >> >> >>> guess what assumption the network made, and work out how t= o >> >> >> >>> replace this assumed aggressiveness with its own aggressiv= eness. >> >> >> >>> o Also, if the network biases congestion notification by pac= ket >> >> >> size >> >> >> >>> it has to assume a baseline packet size--all proposed algo= rithms >> >> >> >>> use the local MTU. Then transports have to guess which li= nk was >> >> >> >>> congested and what its local MTU was, in order to know how= to >> >> >> >>> tailor their congestion response to that link. >> >> >> >>> >> >> >> >>> So you're saying that for byte-mode drop, the network element >> >> >> has to compare the size of the current pkt with the MTU, and if >> >> >> it's 25* smaller then reduce the pkt loss probably by 25*? And if >> >> >> the MTU was bigger, then the current pkt would be dropped with >> >> >> greater probability? And both of these things are hard to do. >> >> >> >>> >> >> >> >>> [BB]: SUGGESTED REPLACEMENT to 2nd bullet: >> >> >> >>> >> >> >> >>> o Also, if the network biases congestion notification by pac= ket >> >> >> size >> >> >> >>> it has to assume a baseline packet size--all proposed algo= rithms >> >> >> >>> use the local MTU (for example see the byte-mode loss >> >> >> probability >> >> >> >>> formula in Table 1). Then if the non-Reno transports ment= ioned >> >> >> above >> >> >> >>> are trying to reverse engineer what the network assumed, t= hey >> >> >> also >> >> >> >>> have to guess the MTU of the congested link. >> >> >> >>> >> >> >> >>> [Aside for Phil: The byte-mode algo uses MTU as its baseline b= ecause >> >> >> >>> a link cannot send a packet bigger than its MTU so the algo wo= n't >> >> >> >>> ever give a drop probability >1).] >> >> >> >>> >> >> >> >>> >> >> >> >>> S3.4 (& knock-on effect on 3.3) >> >> >> >>> I think this could be better. >> >> >> >>> I agree with your arguments in S3.1 & 3.2 that dropping or >> >> >> marking should be independent of pkt size. >> >> >> >>> You now go into a couple of pages, which I think could be boil= ed >> >> >> >>> down to a paragraph, saying something like:- >> >> >> >>> * the overall system (network + transport) has to be packet-si= ze >> >> >> >>> dependent in order to drive out the right amount of traffic so= the >> >> >> >>> resource becomes uncongested (since we assume all resources ar= e in >> >> >> >>> practice byte rather than packet limited) >> >> >> >>> * from S3.1 and S3.2 the IETF is convinced that the network >> >> >> should notify independent of packet-size. >> >> >> >>> * therefore the transport must act dependent on packet-size. >> >> >> >>> >> >> >> >>> It seems to me this is a necessary consequence of your earlier >> >> >> assumptions /arguments. >> >> >> >>> >> >> >> >>> [BB:] This isn't at all obvious. Until I worked it through, it >> >> >> wasn't obvious to me. I think it needs to be spelled out. >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> [On the other hand, if someone disagrees with the arguments an= d >> >> >> >>> thinks that the network should notify dependent on packet-size= , then >> >> >> >>> it follows that the transport can act independent of packet-si= ze.] >> >> >> >>> >> >> >> >>> I think in S3.3 you're trying to make another argument (?):- >> >> >> >>> * we can either do packet-size biasing in the network element = or on >> >> >> >>> the end host transport (see argument above) >> >> >> >>> * packet-size biasing in the network is quite tricky, because >> >> >> then both the network element & the transport have to make some >> >> >> guesses about MTU - whereas with packet-size biasing in the >> >> >> transport, neither network element nor transport needs to know wha= t the >> >> >> MTU is. >> >> >> >>> * it is also easier to implement packet-size biasing in the >> >> >> transport than in the network. >> >> >> >>> >> >> >> >>> [BB] ...and all the other arguments about vulnerability to >> >> >> flooding etc, transport-independence etc. >> >> >> >>> >> >> >> >>> Our argument is sort of like how Phil summarises it, but with >> >> >> an added nuance. It's also saying no-one has to do packet-size >> >> >> biasing anyway. It's not saying "The transport should given the >> >> >> network shouldn't". It's saying "*If the transport wants to claim >> >> >> to be scalable wrt packet size* it should if the network shouldn't= ". >> >> >> >>> >> >> >> >>> This gives a get-out clause to any transport that isn't >> >> >> packet-size dependent (e.g. current TCP). Lacking packet-size >> >> >> dependence just means they don't scale correctly with packet size = - >> >> >> but they are at liberty not to scale with packet size (particularl= y >> >> >> given MTU growth isn't often being used to increase link rates at >> >> >> this stage in history). >> >> >> >>> >> >> >> >>> None of what Phil says convinces me we could say 3.4 (or 3.3) >> >> >> any more briefly or differently. It's easier to summarise what you >> >> >> understand having read something. But that's not the same as >> >> >> writing the thing that helped you understand. There doesn't seem t= o >> >> >> be any argument for why anything needs to be changed, so I'm going >> >> >> to leave it as is, unless pushed. >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> On the last bullet, I didn't really follow your argument in >> >> >> S3.5. Might be easier to follow if S3.5 also talked about how a >> >> >> network element would take account of pkt size? >> >> >> >>> Also, does the following argument also apply?: >> >> >> >>> * if pkt-size biasing is done in the transport, then the work = (to do >> >> >> >>> the biasing) is spread over many end hosts, >> >> >> >>> * whereas if pkt-size biasing is done in the network, then the >> >> >> work is concentrated in just the congested network element, which >> >> >> has to operate on all the traffic at line speed. >> >> >> >>> >> >> >> >>> [BB]: 3.5. Implementation Efficiency >> >> >> >>> >> >> >> >>> [ADD:] >> >> >> >>> Biasing against large packets typically requires an extra mul= tiply >> >> >> >>> and divide in the network (see the example byte-mode drop >> >> >> formula in table 1). >> >> >> >>> [CONTINUE AS BEFORE:] >> >> >> >>> Allowing for packet size at the transport rather than in the >> >> >> >>> network ensures that neither the network nor the transport ne= eds to >> >> >> >>> do a multiply operation--multiplication by packet size is >> >> >> >>> effectively achieved as a repeated add when the transport add= s to >> >> >> >>> its count of marked bytes as each congestion event is fed to = it. >> >> >> >>> [ADD:] >> >> >> >>> Also the work to do the biasing is spread over many hosts, ra= ther >> >> >> >>> than concentrated in just the congested network element. >> >> >> >>> [CONTINUE AS BEFORE:] >> >> >> >>> These are= n't >> >> >> >>> principled reasons in themselves, but they are a happy consequ= ence >> >> >> >>> of the other principled reasons. >> >> >> >>> >> >> >> >>> >> >> >> >>> Bob >> >> >> >>> >> >> >> >>> At 13:36 05/09/2012, Manner Jukka wrote: >> >> >> >>> >> >> >> >>> Hi Bob, >> >> >> >>> >> >> >> >>> Since Phil is your colleague at BT, even at Ipswich (?), can >> >> >> you check those and agree with Phil how to go forward? Some of >> >> >> those are clear, others need discussion with Phil. >> >> >> >>> >> >> >> >>> Gorry, on point 2) below, I don't follow Leslie's arguments. I >> >> >> asked from him detailed comments and resolutions months ago, and n= othing >> >> >> came. >> >> >> >>> >> >> >> >>> cheers, >> >> >> >>> Jukka >> >> >> >>> >> >> >> >>> On Sep 5, 2012, at 3:26 PM, Gorry Fairhurst wrote: >> >> >> >>> >> >> >> >>>> Bob and Jukka, >> >> >> >>>> >> >> >> >>>> I think I need your help to resolve this... Some of the >> >> >> comments raised by John Leslie appear to have substance, and I'm >> >> >> not sure what you plan to do to address these. >> >> >> >>>> >> >> >> >>>> It would be good to do something quick so that I can complete >> >> >> the submission to the IESG. >> >> >> >>>> >> >> >> >>>> The issues I particularly note are: >> >> >> >>>> >> >> >> >>>> 1) This contribution from Phil appears to be within scope and >> >> >> it seems may have been overlooked (sorry): >> >> >> >>>> http://www.ietf.org/mail-archive/web/tsvwg/current/msg11234.h= tml >> >> >> >>>> >> >> >> >>>> 2) Can you be clear here about what is actually been said - >> >> >> because the point below seems to be a misunderstanding of language >> >> >> to me, and I hoped we did not claim this: >> >> >> >>>> >> >> >> >>>>>> ] Alas, when I read it carefully this week, I find that Bob= is >> >> >> >>>>>> actually ] saying that transport-layer should _only_ consid= er >> >> >> >>>>>> "congested bytes", not ] "congested packets". >> >> >> >>>>>> ] >> >> >> >>>> >> >> >> >>>> 3) You'll need to post the updated draft and send a note to >> >> >> the group to confirm that the new version indeed concludes the >> >> >> WGLC. I'll add a note to the writeup to indicate the draft content >> >> >> has been stable since Oct 2011. >> >> >> >>>> >> >> >> >>>> Gorry (with my TSVWG Documnent Shepherd hat) >> >> >> >>>> cc: Co-Chairs for info. >> >> >> >>>> >> >> >> >>>>> >> >> >> >>>>>> -----Original Message----- >> >> >> >>>>>> From: Gorry Fairhurst [ mailto:gorry@erg.abdn.ac.uk] >> >> >> >>>>>> Sent: Mittwoch, 15. August 2012 21:41 >> >> >> >>>>>> To: tsvwg chair >> >> >> >>>>>> Subject: Fwd: Re: [tsvwg] FYI: Document writeup for >> >> >> >>>>>> draft-ietf-tsvwg- byte-pkt-congest >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> Hi guys, >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> Apart form the usual rhetoric, there are some points here t= hat we >> >> >> >>>>>> should note as chairs. What are you own thoughts? And was >> >> >> >>>>>> anything noted at the IETF in Vancouver concerning this dra= ft? >> >> >> >>>>>> >> >> >> >>>>>> Gorry >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> -------- Original Message -------- >> >> >> >>>>>> Subject: Re: [tsvwg] FYI: Document writeup for >> >> >> >>>>>> draft-ietf-tsvwg-byte- pkt-congest >> >> >> >>>>>> Date: Wed, 15 Aug 2012 15:07:28 -0400 >> >> >> >>>>>> From: John Leslie >> >> >> >>>>>> To: Gorry Fairhurst >> >> >> >>>>>> CC: tsvwg@ietf.org >> >> >> >>>>>> >> >> >> >>>>>> Gorry Fairhurst wrote: >> >> >> >>>>>>> >> >> >> >>>>>>> The following document has been revised after receiving >> >> >> WGLC comments. >> >> >> >>>>>> >> >> >> >>>>>> The changes are mostly refreshing a document scheduled to >> >> >> >>>>>> expire this month. >> >> >> >>>>>> >> >> >> >>>>>>> No issues were found: >> >> >> >>>>>> >> >> >> >>>>>> Is that with WGC-hat-on? >> >> >> >>>>>> >> >> >> >>>>>> Neither my issues nor Philip Eardley's comments were addr= essed. >> >> >> >>>>>> In fact, not even the changes Bob Briscoe mentioned on-list= have >> >> >> >>>>>> been included. >> >> >> >>>>>> >> >> >> >>>>>>> As required by RFC 4858, this is the current template for = the >> >> >> >>>>>> Document >> >> >> >>>>>>> Shepherd Write-Up. >> >> >> >>>>>>> ... >> >> >> >>>>>>> (1) What type of RFC is being requested (BCP, Proposed Sta= ndard, >> >> >> >>>>>>> Internet Standard, Informational, Experimental, or Histori= c)? >> >> >> >>>>>>> Why is this the proper type of RFC? Is this type of RFC >> >> >> >>>>>>> indicated in the title page header? >> >> >> >>>>>>> >> >> >> >>>>>>> This document is intended as BCP. (This was discussed at I= ETF-81 >> >> >> >>>>>>> and that the status changed from Informational to BCP sinc= e it >> >> >> >>>>>>> provides guidance to implementors and people configuring >> >> >> routers and hosts). >> >> >> >>>>>> >> >> >> >>>>>> Thank you for finally answering my question about BCP sta= tus. >> >> >> >>>>>> >> >> >> >>>>>>> ... >> >> >> >>>>>>> Working Group Summary >> >> >> >>>>>>> >> >> >> >>>>>>> There was consensus to publish this as a WG document and >> >> >> >>>>>>> agreement at >> >> >> >>>>>>> IETF-82 that the document was now complete. >> >> >> >>>>>> >> >> >> >>>>>> Was that reviewed on-list? >> >> >> >>>>>> >> >> >> >>>>>>> ... >> >> >> >>>>>>> (3) Briefly describe the review of this document that was >> >> >> >>>>>>> performed >> >> >> >>>>>> by >> >> >> >>>>>>> the Document Shepherd. If this version of the document is = not >> >> >> >>>>>>> ready for publication, please explain why the document is = being >> >> >> >>>>>>> forwarded to the IESG. >> >> >> >>>>>>> >> >> >> >>>>>>> The document was presented at IEWTF-82 (Taipei), with a re= quest >> >> >> >>>>>>> for >> >> >> >>>>>> WGLC. >> >> >> >>>>>>> WGLC concluded with some discussion but no substantive cha= nges >> >> >> >>>>>>> on Friday 30th March 2012. >> >> >> >>>>>> >> >> >> >>>>>> Yes, I guess that is true; but ignoring substantive comme= nts >> >> >> >>>>>> isn't a good practice IMHO. >> >> >> >>>>>> >> >> >> >>>>>>> (4) Does the document Shepherd have any concerns about the= depth >> >> >> >>>>>>> or breadth of the reviews that have been performed? >> >> >> >>>>>>> >> >> >> >>>>>>> No - the original draft had a lot of background material, = much >> >> >> >>>>>>> of >> >> >> >>>>>> this >> >> >> >>>>>>> has been condensed or removed, resulting in a smaller docu= ment. >> >> >> >>>>>> >> >> >> >>>>>> That is indeed what I basically asked for, but I don't se= e any >> >> >> >>>>>> evidence of it: >> >> >> >>>>>> >> >> >> >>>>>> - diff(07,08) 48 lines changed or deleted; 53 lines chang= ed or >> >> >> added >> >> >> >>>>>> - diff(06,07) 8 lines changed or deleted; 13 lines chang= ed or >> >> >> added >> >> >> >>>>>> - diff(05,06) 64 lines changed or deleted; 69 lines chang= ed or >> >> >> >>>>>> added >> >> >> >>>>>> - diff(04,05) 823 lines changed or deleted; 864 lines chang= ed or >> >> >> >>>>>> added >> >> >> >>>>>> >> >> >> >>>>>> (Need I go farther? That gets us back to March 2011...) >> >> >> >>>>>> >> >> >> >>>>>>> (9) How solid is the WG consensus behind this document? Do= es it >> >> >> >>>>>>> represent the strong concurrence of a few individuals, wit= h >> >> >> >>>>>>> others being silent, or does the WG as a whole understand >> >> >> and agree with it? >> >> >> >>>>>>> >> >> >> >>>>>>> The document has WG support and there is consensus to publ= ish. >> >> >> >>>>>> >> >> >> >>>>>> This, IMHO, doesn't answer the question. :^( >> >> >> >>>>>> >> >> >> >>>>>> Does it represent the concurrence of a few individuals, o= r does >> >> >> >>>>>> the WG as a whole understand and agree with it? >> >> >> >>>>>> >> >> >> >>>>>> For reference, my comments included: >> >> >> >>>>>> ] >> >> >> >>>>>> ] When I previously skimmed this document, I believed it >> >> >> >>>>>> contained only ] common ground: that AQM should drop/mark p= ackets >> >> >> >>>>>> without favoring small ] packets, and that to whatever exte= nt >> >> >> >>>>>> packet size _is_ considered, that ] should be a >> >> >> transport-layer responsibility. >> >> >> >>>>>> ] >> >> >> >>>>>> ] Alas, when I read it carefully this week, I find that Bob= is >> >> >> >>>>>> actually ] saying that transport-layer should _only_ consid= er >> >> >> >>>>>> "congested bytes", not ] "congested packets". >> >> >> >>>>>> ] >> >> >> >>>>>> ] In fact, Bob openly endorses replacing TCP congestion-con= trol >> >> >> >>>>>> with an ] algorithm which calculates "fair-share bytes" and >> >> >> >>>>>> doesn't back off at all ] (even in the presence of 20% pack= et >> >> >> >>>>>> loss) unless you're already sending ] more than this >> >> >> "fair-share". >> >> >> >>>>>> ] >> >> >> >>>>>> ] I do not believe that is the consensus of this WG; and= I >> >> >> believe >> >> >> >>>>>> if >> >> >> >>>>>> ] that were the consensus it would exceed our charter. >> >> >> >>>>>> ] >> >> >> >>>>>> ] The draft contains a number of things I _do_ support; and= I'd >> >> >> >>>>>> be happy ] to support a considerably shorter draft which >> >> >> >>>>>> concentrates on the AQM ] recommendation, omitting any >> >> >> >>>>>> suggestions of modifying TCP congestion ] control. >> >> >> >>>>>> >> >> >> >>>>>> and Philip's comments included: >> >> >> >>>>>> ] >> >> >> >>>>>> ] S2.2 I thought the numbered bullets could be better phras= ed, >> >> >> >>>>>> something like ] +this:- ] >> >> >> >>>>>> ] 1. AQM algorithms such as RED SHOULD use packet-mode >> >> >> drop, ie they >> >> >> >>>>>> SHOULD NOT >> >> >> >>>>>> ] +use byte-mode drop. The latter ] is more complex, >> >> >> >>>>>> ] it creates the perverse incentive to fragment segm= ents >> >> >> into >> >> >> >>>>>> tiny >> >> >> >>>>>> ] pieces and it is vulnerable to floods of small- >> >> >> >>>>>> ] packets. >> >> >> >>>>>> ] >> >> >> >>>>>> ] 2. If a vendor has implemented byte-mode drop, and an >> >> >> operator >> >> >> >>>>>> has >> >> >> >>>>>> ] turned it on, it is RECOMMENDED to turn it off, af= ter >> >> >> >>>>>> establishing if >> >> >> >>>>>> ] +there are any implications on >> >> >> >>>>>> ] the relative performance of >> >> >> >>>>>> ] applications using different packet sizes. >> >> >> >>>>>> ] >> >> >> >>>>>> ] 3. RED SHOULD NOT be turned off. Without RED, a drop t= ail >> >> >> >>>>>> ] queue biases against large packets. >> >> >> >>>>>> ] >> >> >> >>>>>> ] Nit - the following paragraph shouldn't be indented (Note= well >> >> >> >>>>>> that >> >> >> >>>>>> RED's...) >> >> >> >>>>>> ] >> >> >> >>>>>> ] S3.3 >> >> >> >>>>>> ] The section could be slightly clearer. Starting with the = second >> >> >> >>>>>> para, where you ] +start talking about something you don't >> >> >> >>>>>> recommend (ie you have to remember that ] +you're talking a= bout >> >> >> >>>>>> the consequences of not following your recommendation). >> >> >> >>>>>> ] >> >> >> >>>>>> ] S3.3 >> >> >> >>>>>> ] o Also, if the network biases congestion notification= by >> >> >> packet >> >> >> >>>>>> size >> >> >> >>>>>> ] it has to assume a baseline packet size--all propos= ed >> >> >> >>>>>> algorithms >> >> >> >>>>>> ] use the local MTU. Then transports have to guess w= hich >> >> >> link >> >> >> >>>>>> was >> >> >> >>>>>> ] congested and what its local MTU was, in order to k= now >> >> >> how to >> >> >> >>>>>> ] tailor their congestion response to that link. >> >> >> >>>>>> ] So you're saying that for byte-mode drop, the network ele= ment >> >> >> >>>>>> has to compare the ] +size of the current pkt with the MTU,= and >> >> >> >>>>>> if it's 25* smaller then reduce the ] +pkt loss probably by= 25*? >> >> >> >>>>>> And if the MTU was bigger, then the current pkt would ] +be >> >> >> >>>>>> dropped with greater probability? And both of these things >> >> >> are hard to do. >> >> >> >>>>>> ] >> >> >> >>>>>> ] S3.4 (& knock-on effect on 3.3) ] I think this could be b= etter. >> >> >> >>>>>> ] I agree with your arguments in S3.1 & 3.2 that dropping o= r >> >> >> >>>>>> marking should be ] +independent of pkt size. >> >> >> >>>>>> ] You now go into a couple of pages, which I think could be >> >> >> >>>>>> boiled down to a ] +paragraph, saying something like:- ] * = the >> >> >> >>>>>> overall system (network + transport) has to be packet-size >> >> >> >>>>>> dependent in ] >> >> >> >>>>>> +order to drive out the right amount of traffic so the reso= urce >> >> >> >>>>>> becomes ] >> >> >> >>>>>> +uncongested (since we assume all resources are in practice= byte >> >> >> >>>>>> +rather >> >> >> >>>>>> than ] +packet limited) ] * from S3.1 and S3.2 the IETF is >> >> >> >>>>>> convinced that the network should notify ] +independent of >> >> >> packet-size. >> >> >> >>>>>> ] * therefore the transport must act dependent on packet-si= ze. >> >> >> >>>>>> ] >> >> >> >>>>>> ] It seems to me this is a necessary consequence of your ea= rlier >> >> >> >>>>>> assumptions ] +/arguments. >> >> >> >>>>>> ] >> >> >> >>>>>> ] [On the other hand, if someone disagrees with the argumen= ts and >> >> >> >>>>>> thinks that the ] +network should notify dependent on >> >> >> >>>>>> packet-size, then it follows that the ] +transport can act >> >> >> >>>>>> independent of >> >> >> >>>>>> packet- size.] ] ] I think in S3.3 you're trying to make an= other >> >> >> >>>>>> argument (?):- ] * we can either do packet-size biasing in= the >> >> >> >>>>>> network element or on the end host ] +transport (see argume= nt >> >> >> >>>>>> above) ] * packet-size biasing in the network is quite tric= ky, >> >> >> >>>>>> because then both the ] +network element & the transport ha= ve to >> >> >> >>>>>> make some guesses about MTU - whereas ] >> >> >> >>>>>> +with packet-size biasing in the transport, neither network >> >> >> >>>>>> +element >> >> >> >>>>>> nor ] +transport needs to know what the MTU is. >> >> >> >>>>>> ] * it is also easier to implement packet-size biasing in t= he >> >> >> >>>>>> transport than in ] +the network. >> >> >> >>>>>> ] >> >> >> >>>>>> ] On the last bullet, I didn't really follow your argument = in >> >> >> S3.5. >> >> >> >>>>>> Might be ] +easier to follow if S3.5 also talked about how = a >> >> >> >>>>>> network element would take ] +account of pkt size? Also, do= es the >> >> >> >>>>>> following argument also apply?: >> >> >> >>>>>> ] * if pkt-size biasing is done in the transport, then the = work >> >> >> >>>>>> (to do the ] +biasing) is spread over many end hosts, ] * w= hereas >> >> >> >>>>>> if pkt-size biasing is done in the network, then the work i= s ] >> >> >> >>>>>> +concentrated in just the congested network element, which = has to >> >> >> >>>>>> operate on all ] +the traffic at line speed. >> >> >> >>>>>> >> >> >> >>>>>> (Has there perhaps been some confusion about what went in= to the >> >> >> >>>>>> -08 >> >> >> >>>>>> version?) >> >> >> >>>>>> >> >> >> >>>>>> -- >> >> >> >>>>>> John Leslie >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>> >> >> >> >>>> >> >> >> >>> ______________________________________________________________= __ >> >> >> >>> Bob Briscoe, BT Innovate & Desi= gn >> >> >> >>> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________________________________________ >> >> > Bob Briscoe, BT Innovate & Design >> >> > >> > >> > ________________________________________________________________ >> > Bob Briscoe, BT Innovate & Design >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 From hannes.tschofenig@nsn.com Thu Oct 11 05:45:04 2012 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 4F29621F8625; Thu, 11 Oct 2012 05:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.192 X-Spam-Level: X-Spam-Status: No, score=-106.192 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpfBOal6yPn5; Thu, 11 Oct 2012 05:45:01 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 90E2021F8617; Thu, 11 Oct 2012 05:45:00 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q9BCiu8E024975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Oct 2012 14:44:56 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q9BCipRO021558; Thu, 11 Oct 2012 14:44:56 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Oct 2012 14:44:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Oct 2012 15:44:31 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D01F360CF@FIESEXC035.nsn-intra.net> In-Reply-To: <3A5279D338C75C40B4B3DA15BA47D6330B6FD072@EXMDB04.org.aalto.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest Thread-Index: AQHNp6lsRPJg5MIAXUex2DyM9GzvLZez196AgAA0x7A= References: <20120815190728.GQ15012@verdi> <502BFB47.7010803@erg.abdn.ac.uk><791AD3077F94194BB2BDD13565B6295D45A6212A@PALLENE.office.hd><15181_1346848013_5047450C_15181_645_1_50474507.3090706@erg.abdn.ac.uk><3A5279D338C75C40B4B3DA15BA47D6330B616BD2@EXMDB04.org.aalto.fi><201209051541.q85FfCs0019699@bagheera.jungle.bt.co.uk><9510D26531EF184D9017DF24659BB87F33D793B351@EMV65-UKRD.domain1.systemhost.net><3A5279D338C75C40B4B3DA15BA47D6330B69261A@EXMDB04.org.aalto.fi><9510D26531EF184D9017DF24659BB87F33D793B845@EMV65-UKRD.domain1.systemhost.net><04AC95B5-A2B1-4DD2-B765-E20A4C1A69A3@aalto.fi><3A5279D338C75C40B4B3DA15BA47D6330B6E81E4@EXMDB04.org.aalto.fi><9510D26531EF184D9017DF24659BB87F33DCE34251@EMV65-UKRD.domain1.systemhost.net><201210041126.q94BQ0hx002951@bagheera.jungle.bt.co.uk><1904eec816d080f886f5bf8685358ddc.squirrel@www.erg.abdn.ac.uk><201210101525.q9AFP4Mi008013@bagheera.jungle.bt.co.uk><3A5279D338C75C40B4B3DA15BA47D6330B6FC2BB@EXMDB04.org.aalto.fi><201210111208.q9BC8BAU012! 305@baghe era.jungle.b t.co.uk> <3A5279D338C75C40B4B3DA15BA47D6330B6FD072@EXMDB04.org.aalto.fi> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Manner Jukka" , "Bob Briscoe" X-OriginalArrivalTime: 11 Oct 2012 12:44:33.0398 (UTC) FILETIME=[29F98960:01CDA7AE] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 45693 X-purgate-ID: 151667::1349959496-000048BF-39A707ED/0-0/0-0 Cc: gorry@erg.abdn.ac.uk, philip.eardley@bt.com, tsvwg-chairs@ietf.org, tsvwg IETF list Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest 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, 11 Oct 2012 12:45:04 -0000 Hi Jukka, Hi Bob,=20 having listened to the presentations about CoDel I am wondering whether this document may have taken over by events and is obsolete by now. What's your view on that?=20 Ciao Hannes > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf > Of ext Manner Jukka > Sent: Thursday, October 11, 2012 3:34 PM > To: Bob Briscoe > Cc: ; ; chairs@ietf.org>; tsvwg IETF list > Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf- > tsvwg-byte-pkt-congest >=20 > Hi, >=20 > Yeah, please at the point about cheap devices, still, I wonder what the > cost of AQM is on those devices. Maybe 1 cnt in mass production? Thus, > I still wonder if it is worth arguing something about the future that > strongly. >=20 > Sorry, but the same goes for AQM in general, and where it is, or will > not be deployed. I understand technical reasons why not something is > feasible, but business or monetary reasons can change very quickly. ;) >=20 > Jukka >=20 > On Oct 11, 2012, at 3:08 PM, Bob Briscoe wrote: >=20 > > Jukka, > > > > What I had in mind is all low level buffers in cheap pure L2 devices, > in cheap NATs etc. I was going to list some of these, but instead chose > to say "no-one expects AQM to be universally deployed". This clearly > missed the mark. > > > > Should we include some of these concrete examples of where AQM won't > be deployed instead? > > > > [I've cc'd the list, given we're starting to wordsmith significantly > new text added since WG last call.] > > > > > > Bob > > > > At 20:04 10/10/2012, Manner Jukka wrote: > >> Hi, looked good to me. Just one comment, I wouldn't put that much > emphasis on what is a probably state of things, e.g. > >> > >> "no-one expects AQM to ever be .." > in the future it might, we > don't know, and since the paragraph says that it doesn't matter anyway, > I would formulate this paragraph a bit towards that we have partial > deployment now and even with a full deployment, ... > >> > >> and similarly with the unrealistic deployment of AQM in the > subsequent paragraph. > >> > >> cheers, > >> Jukka > >> > >> On Oct 10, 2012, at 6:25 PM, Bob Briscoe wrote: > >> > >> > Phil, > >> > > >> > Sorry for delay, my round-robin scheduler is taking so long to get > round all the tasks that I keep finding dead robins (that reminds me of > a bike ride my grandmother took. On her return, she said there were a > worryingly large number of robins run over on the roads. It turned out > that she had been going round the same small triangle of roads multiple > times). > >> > > >> > I've done a complete re-write of 3.4. I hope you will agree that > it really is a motivating argument now and it can stay where it is - it > is not just a preamble. > >> > > >> > I've gone back to the very first version of 3.4 I wrote and I now > realise that I had written the core of the argument so badly that even > I forgot what it was meant to say when we started editing it. In the > draft-08 version, the original meaning is lost and in your re-wording > it is entirely lost. The link with the draft-08 version is nearly > unrecognisable, but it's the argument I intended here. > >> > > >> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > 3.4. Permanent Partial Deployment of AQM > >> > > >> > In overview, the argument in this section runs as follows: > >> > * Because the network will not and cannot always drop packets in > proportion to their size, it shouldn't be given the task of making drop > signals depend on packet size at all. > >> > * Transports on the other hand don't always want to make their > rate response proportional to the size of dropped packets, but if they > want to, they always can. > >> > > >> > The argument is similar to the end-to-end argument that says > "Don't do X in the network if end-systems can do X by themselves, and > they want to be able to choose whether to do X anyway." Actually the > following argument is stronger; in addition it says "Don't give the > network task X that could be done by the end-systems, if X won't ever > be deployed on all network nodes, and end-systems won't be able to tell > whether their network is doing X, or whether they need to do X > themselves." In this case, the X in question is "making the response to > congestion depend on packet size". > >> > > >> > We will now re-run this argument taking each step in more depth. > The argument applies solely to drop, not ECN marking. > >> > > >> > A queue drops packets for either of two reasons: a) to signal to > host congestion controls that they should reduce the load and b) > because there is no buffer left to store the packets. Active queue > management tries to use drops as a signal for hosts to slow down (case > a) so that drop due to buffer exhaustion (case b) should not be > necessary. > >> > > >> > No-one expects AQM to ever be universally deployed in every queue > in the Internet; and, even if AQM were universal, it has to be able to > cope with buffer exhaustion (by switching to a behaviour like tail- > drop), in order to cope with unresponsive or excessive transports. > Therefore networks will often be dropping packets as a last resort > (case b) rather than under AQM control (case a). > >> > > >> > When buffers are exhausted (case b), they don't naturally drop > packets in proportion to their size. The network can only reduce the > probability of dropping smaller packets if it has enough space to store > them somewhere while it waits for a larger packet that it can drop. If > the buffer is exhausted, it does not have this choice. Admittedly tail- > drop does naturally drop somewhat fewer small packets, but exactly how > few depends more on the mix of sizes than the size of the packet in > question. Nonetheless, in general, if we wanted networks to do size- > dependent drop, we would need universal deployment of (packet-size > dependent) AQM code, which is unrealistic. > >> > > >> > A host transport cannot know whether any particular drop was a > deliberate signal from an AQM or a sign of a queue shedding packets due > to buffer exhaustion. Therefore, because the network cannot universally > do size-dependent drop, it should not do it all. > >> > > >> > Whereas universality is desirable in the network, diversity is > desirable between different transport layer protocols - some, like > NewReno TCP [RFC5681], may not choose to make their rate response > proportionate to the size of each dropped packet, while others will > (e.g. TFRC-SP [RFC4828]). > >> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > > >> > > >> > > >> > > >> > Bob > >> > > >> > At 13:13 04/10/2012, gorry@erg.abdn.ac.uk wrote: > >> >> That would be brilliant! > >> >> > >> >> Gorry > >> >> > >> >> > Will try to look at this later today. > >> >> > > >> >> > > >> >> > Bob > >> >> > > >> >> > At 10:42 02/10/2012, philip.eardley@bt.com wrote: > >> >> >>Think the token is with bob > >> >> >> > >> >> >>Re your comment - yes, I think you could move 3.4 to the end of > S3 - > >> >> >>or to the start - and do some re-phrasing, maybe something like > I tried. > >> >> >> > >> >> >>-----Original Message----- > >> >> >>From: Manner Jukka [mailto:jukka.manner@aalto.fi] > >> >> >>Sent: 01 October 2012 20:18 > >> >> >>To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,Bob,DUB8 R > >> >> >>Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst > >> >> >>Subject: Re: [REVISED I-D]: Document writeup for > >> >> >>draft-ietf-tsvwg-byte-pkt-congest > >> >> >> > >> >> >>Phil, Bob, can we close this finally? It's three weeks now > since > >> >> >>this previous message. > >> >> >> > >> >> >>Jukka > >> >> >> > >> >> >>On Sep 10, 2012, at 4:42 PM, Jukka Manner wrote: > >> >> >> > >> >> >> > Ack, I'm getting there...;) > >> >> >> > > >> >> >> > So, we could move 3.4 at the end of Section 3 and rephrase > it to > >> >> >> not talk about scaling per se, but rather about how Req 2.2 > >> >> >> eventually leads to Req 2.3? > >> >> >> > > >> >> >> > Jukka > >> >> >> > > >> >> >> > On Sep 7, 2012, at 4:07 PM, > >> >> >> > wrote: > >> >> >> > > >> >> >> >> 3.4 is, in my mind, completely different from 3.1, 3.2, 3.3 > and 3.5. > >> >> >> >> > >> >> >> >> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for > Recommendation > >> >> >> >> 2.2 & a lesser extent 2.3 > >> >> >> >> 3.4 makes doesn't make a motivating argument - it explains > that Rec > >> >> >> >> 2.2 & 2.3 come as a pair (if you recommend one, then > inevitably you > >> >> >> >> recommend the other) (delta some politeness about TCP) > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> -----Original Message----- > >> >> >> >> From: Manner Jukka [mailto:jukka.manner@aalto.fi] > >> >> >> >> Sent: 07 September 2012 13:24 > >> >> >> >> To: Eardley,PL,Philip,DUB8 R > >> >> >> >> Cc: Briscoe,RJ,Bob,DUB8 R; ; > >> >> >> >> > >> >> >> >> Subject: Re: [REVISED I-D]: Document writeup for > >> >> >> >> draft-ietf-tsvwg-byte-pkt-congest > >> >> >> >> > >> >> >> >> Hi, I'm trying to follow your reasoning, with little luck. > ;) > >> >> >> >> > >> >> >> >> After having read Section 3 again, I could think of a few > >> >> >> updates, but I'm not fully following what you want to see: > >> >> >> >> > >> >> >> >> - S3.5 is kind of small and lonely by itself. It could be > either > >> >> >> longer or merged somewhere. Not a major issue though and could > remain as > >> >> >> is. > >> >> >> >> > >> >> >> >> - S3.3: Yes, probably could be turned upside down, good > first, > >> >> >> bad later. Don't have a strong opinion. > >> >> >> >> > >> >> >> >> - S3.4: Here the scaling is used many times and in the > title, > >> >> >> although we talk about the end host side. This could be > rephrased > >> >> >> and slightly reworded to talk about hosts and their operation > >> >> >> altogether. Also the word scaling can turn the readers > expectation > >> >> >> into the wrong direction. > >> >> >> >> > >> >> >> >> - S3 altogether: It would help to have introductory text > about > >> >> >> networks vs. end host side, but I fail to see why (& how) to > >> >> >> restructure everything. > >> >> >> >> > >> >> >> >> cheers, > >> >> >> >> Jukka > >> >> >> >> > >> >> >> >> On Sep 6, 2012, at 6:18 PM, > >> >> >> wrote: > >> >> >> >> > >> >> >> >>> Ps otherwise Bob's comments are fine, though I suggest for > S3.5 you > >> >> >> >>> give more context (ie are you knocking down what you > recommend > >> >> >> >>> against, or building up what you recommend?) and in S3.3 > think > >> >> >> >>> would be better if you re-structured slightly [first talk > about what > >> >> >> >>> you like - penult para + 1st sentence of last para - then > talk about > >> >> >> >>> what you don't like - rest of text] > >> >> >> >>> > >> >> >> >>> From: Eardley,PL,Philip,DUB8 R > >> >> >> >>> Sent: 06 September 2012 16:12 > >> >> >> >>> To: Briscoe,RJ,Bob,DUB8 R; Manner Jukka > >> >> >> >>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst > >> >> >> >>> Subject: RE: [REVISED I-D]: Document writeup for > >> >> >> >>> draft-ietf-tsvwg-byte-pkt-congest > >> >> >> >>> > >> >> >> >>> Thanks bob. Have now re-booted some state. > >> >> >> >>> I don't like S3.4. My basic problem with it is that it > isn't a > >> >> >> "motivating argument" (S3 title). It's an explanation about > the > >> >> >> consequences of assuming either [option 1] do pkt-size biasing > in > >> >> >> the transport; [option 2]; do pkt-size biasing in the nw. > >> >> >> >>> Perhaps your effort to buy peace with those who won't > change > >> >> >> TCP has obfuscated the basic point? > >> >> >> >>> The title of S3.4 (Scaling...) and the early text "scaling > >> >> >> argument" suggests that you're going to argue there is some > reason > >> >> >> why X scales as order N rather than N^2 or something like that > - > >> >> >> which isn't what S3.4 is about. > >> >> >> >>> > >> >> >> >>> I actually think it would be better to put S3.4 at the > start of > >> >> >> S3 - it's background where you say there are 2 options. After > that, > >> >> >> you can explain the reasons why option 1 [pkt biasing in the > >> >> >> transport] is better - the reasons being:- S3.1 (security etc > >> >> >> attacks if small pkts get preferential treatment), S3.2 > (really a > >> >> >> side note to S3.1; ie doesn't really present a "motivating > >> >> >> argument"), S3.3 (nw guessing MTU vs transport knowing pkt > size), > >> >> >> S3.5 (easier implementation). > >> >> >> >>> > >> >> >> >>> Something like... > >> >> >> >>> The behaviour of the network and transport together needs > to > >> >> >> >>> alleviate congestion. We assume the network is bit- > congestible > >> >> >> (currently packet-congestible resources are rate). Therefore > >> >> >> overall the response of the {network + transport} should be > the > >> >> >> same for the same congestion - whether the congestion is > caused by > >> >> >> a lot of small packets or a smaller number of larger packets. > The > >> >> >> implication is that the transport's behaviour should depend on > >> >> >> whether the network takes account (or not) of packet size when > it > >> >> >> generates congestion indications:- Case 1: If the network > >> >> >> implements packet-mode drop, ie its algorithm treats all > packets > >> >> >> equally regardless of their size, then the transport should > take > >> >> >> account of the size of the packet - in other words, the > transport's > >> >> >> congestion response should depend on the number of dropped > bytes. > >> >> >> >>> Case 2: If the network implements byte-mode drop, ie its > >> >> >> algorithm treats packets differently depending on their size, > then > >> >> >> the transport should not take account of the size of the > packet - > >> >> >> in other words, the transport's congestion response should > depend > >> >> >> on the number of dropped packets. > >> >> >> >>> > >> >> >> >>> These cases are explained in more detail in sub-section > below. > >> >> >> >>> > >> >> >> >>> In both cases the same discussion applies if packets are > >> >> >> ECN-marked rather than dropped. > >> >> >> >>> In the following sections we explain why Case 1 is > preferable, > >> >> >> and hence why we make the Recommendations of S2.2 and S3.3 > >> >> >> (respectively, drop/mark pkts equally regardless of their > size, and > >> >> >> the strength of the transport's response should be > proportionate to > >> >> >> the size of the dropped/marked pkt). > >> >> >> >>> Note that TCP responds to dropped or marked packets, which > differs > >> >> >> >>> from our recommendation for transports. However, we are > not > >> >> >> >>> recommending that TCP should be changed; to date it > hasn't been a > >> >> >> >>> significant problem because most TCP implementations have > been > >> >> >> used with similar packet sizes. But we do recommend that > future > >> >> >> transport protocols should respond to dropped or marked bytes > (as > >> >> >> for example TFRC-SP [RFC4828]effectively does). > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> Sub-section > >> >> >> >>> You could use much of S3.3, I suggest supplement with > numerical > >> >> >> >>> examples continuing S1.2 > >> >> >> >>> -- > >> >> >> >>> << This gives a get-out clause to any transport that isn't > >> >> >> >>> packet-size dependent (e.g. current TCP). Lacking packet- > size > >> >> >> >>> dependence just means they don't scale correctly with > packet size - > >> >> >> >>> but they are at liberty not to scale with packet size > (particularly > >> >> >> >>> given MTU growth isn't often being used to increase link > rates at > >> >> >> >>> this stage in history).>> > >> >> >> >>> > >> >> >> >>> This is introducing a different point. it's saying that > your > >> >> >> recommendation 2 [drop/mark pkts equally regardless of their > size] > >> >> >> is a really strong reco whilst recommendation 3 [strength of > >> >> >> transport's response proportionate to the size of the > >> >> >> dropped/marked pkt] is a much less important reco. I can see > this > >> >> >> might be true, but I don't think the i-d talks about this. > >> >> >> >>> > >> >> >> >>> -- > >> >> >> >>> > >> >> >> >>> From: Briscoe,RJ,Bob,DUB8 R > >> >> >> >>> Sent: 05 September 2012 16:41 > >> >> >> >>> To: Manner Jukka > >> >> >> >>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst; > Eardley,PL,Philip,DUB8 R > >> >> >> >>> Subject: Re: [REVISED I-D]: Document writeup for > >> >> >> >>> draft-ietf-tsvwg-byte-pkt-congest > >> >> >> >>> > >> >> >> >>> Jukka, > >> >> >> >>> > >> >> >> >>> I've repeated Phil's suggestions as quoted email then made > some > >> >> >> alterations. > >> >> >> >>> > >> >> >> >>> Phil asked me to send this, then he will think about it. > >> >> >> >>> > >> >> >> >>> I'll respond about John Leslie's argument next... > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> 2.2. Recommendation on Encoding Congestion Notification > >> >> >> >>> > >> >> >> >>> [...] > >> >> >> >>> > >> >> >> >>> 1. AQM algorithms such as RED SHOULD use packet-mode > drop, ie they > >> >> >> >>> SHOULD NOT use byte-mode drop. The latter is more > complex, > >> >> >> >>> it creates the perverse incentive to fragment > segments into > >> >> >> tiny > >> >> >> >>> pieces and it is vulnerable to floods of small > packets. > >> >> >> >>> > >> >> >> >>> 2. If a vendor has implemented byte-mode drop, and an > operator has > >> >> >> >>> turned it on, it is RECOMMENDED to turn it off, after > >> >> >> establishing > >> >> >> >>> if there are any implications on the relative > performance of > >> >> >> >>> applications using different packet sizes. > >> >> >> >>> > >> >> >> >>> RED as a whole SHOULD NOT be turned off. Without RED, > a drop > >> >> >> tail > >> >> >> >>> queue biases against large packets > >> >> >> >>> > >> >> >> >>> [BB adds]: and it is > vulnerable to > >> >> >> floods > >> >> >> >>> of small-packets. > >> >> >> >>> > >> >> >> >>> (I suggest the last para just qualifies item 2. It doesn't > warrant > >> >> >> >>> another item number.) > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> [PE:] S3.3 > >> >> >> >>> The section could be slightly clearer. Starting with the > second > >> >> >> para, where you start talking about something you don't > recommend > >> >> >> (ie you have to remember that you're talking about the > consequences > >> >> >> of not following your recommendation). > >> >> >> >>> > >> >> >> >>> 3.3 Transport-Independent Network > >> >> >> >>> > >> >> >> >>> TCP congestion control ensures that flows competing for > the same > >> >> >> >>> resource each maintain the same number of segments in > flight, > >> >> >> >>> irrespective of segment size. So under similar > conditions, flows > >> >> >> >>> with different segment sizes will get different bit-rates. > >> >> >> >>> > >> >> >> >>> [OLD:] > >> >> >> >>> One motivation for the network biasing congestion > notification by > >> >> >> >>> packet size is to counter this effect and try to equalise > the bit- > >> >> >> >>> rates of flows with different packet sizes. > >> >> >> >>> [SUGGESTED:] > >> >> >> >>> To counter this effect it seems tempting not to follow > our > >> >> >> >>> recommendation, and instead for the network to bias > congestion > >> >> >> >>> notification by packet size in order to equalise the bit- > rates of > >> >> >> >>> flows with different packet sizes. > >> >> >> >>> [CONTINUE AS BEFORE:] > >> >> >> >>> However, in order to do this, the queuing > algorithm > >> >> >> >>> has to make assumptions about the transport, which become > embedded > >> >> >> >>> in the network. Specifically: > >> >> >> >>> [...] > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> S3.3 > >> >> >> >>> o The queuing algorithm has to assume how aggressively > the > >> >> >> transport > >> >> >> >>> will respond to congestion (see Section 4.2.4). If > the network > >> >> >> >>> assumes the transport responds as aggressively as TCP > NewReno, > >> >> >> it > >> >> >> >>> will be wrong for Compound TCP and differently wrong > for Cubic > >> >> >> >>> TCP, etc. To achieve equal bit-rates, each transport > then has > >> >> >> to > >> >> >> >>> guess what assumption the network made, and work out > how to > >> >> >> >>> replace this assumed aggressiveness with its own > aggressiveness. > >> >> >> >>> o Also, if the network biases congestion notification by > packet > >> >> >> size > >> >> >> >>> it has to assume a baseline packet size--all proposed > algorithms > >> >> >> >>> use the local MTU. Then transports have to guess > which link was > >> >> >> >>> congested and what its local MTU was, in order to know > how to > >> >> >> >>> tailor their congestion response to that link. > >> >> >> >>> > >> >> >> >>> So you're saying that for byte-mode drop, the network > element > >> >> >> has to compare the size of the current pkt with the MTU, and > if > >> >> >> it's 25* smaller then reduce the pkt loss probably by 25*? And > if > >> >> >> the MTU was bigger, then the current pkt would be dropped with > >> >> >> greater probability? And both of these things are hard to do. > >> >> >> >>> > >> >> >> >>> [BB]: SUGGESTED REPLACEMENT to 2nd bullet: > >> >> >> >>> > >> >> >> >>> o Also, if the network biases congestion notification by > packet > >> >> >> size > >> >> >> >>> it has to assume a baseline packet size--all proposed > algorithms > >> >> >> >>> use the local MTU (for example see the byte-mode loss > >> >> >> probability > >> >> >> >>> formula in Table 1). Then if the non-Reno transports > mentioned > >> >> >> above > >> >> >> >>> are trying to reverse engineer what the network > assumed, they > >> >> >> also > >> >> >> >>> have to guess the MTU of the congested link. > >> >> >> >>> > >> >> >> >>> [Aside for Phil: The byte-mode algo uses MTU as its > baseline because > >> >> >> >>> a link cannot send a packet bigger than its MTU so the > algo won't > >> >> >> >>> ever give a drop probability >1).] > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> S3.4 (& knock-on effect on 3.3) > >> >> >> >>> I think this could be better. > >> >> >> >>> I agree with your arguments in S3.1 & 3.2 that dropping or > >> >> >> marking should be independent of pkt size. > >> >> >> >>> You now go into a couple of pages, which I think could be > boiled > >> >> >> >>> down to a paragraph, saying something like:- > >> >> >> >>> * the overall system (network + transport) has to be > packet-size > >> >> >> >>> dependent in order to drive out the right amount of > traffic so the > >> >> >> >>> resource becomes uncongested (since we assume all > resources are in > >> >> >> >>> practice byte rather than packet limited) > >> >> >> >>> * from S3.1 and S3.2 the IETF is convinced that the > network > >> >> >> should notify independent of packet-size. > >> >> >> >>> * therefore the transport must act dependent on packet- > size. > >> >> >> >>> > >> >> >> >>> It seems to me this is a necessary consequence of your > earlier > >> >> >> assumptions /arguments. > >> >> >> >>> > >> >> >> >>> [BB:] This isn't at all obvious. Until I worked it > through, it > >> >> >> wasn't obvious to me. I think it needs to be spelled out. > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> [On the other hand, if someone disagrees with the > arguments and > >> >> >> >>> thinks that the network should notify dependent on packet- > size, then > >> >> >> >>> it follows that the transport can act independent of > packet-size.] > >> >> >> >>> > >> >> >> >>> I think in S3.3 you're trying to make another argument > (?):- > >> >> >> >>> * we can either do packet-size biasing in the network > element or on > >> >> >> >>> the end host transport (see argument above) > >> >> >> >>> * packet-size biasing in the network is quite tricky, > because > >> >> >> then both the network element & the transport have to make > some > >> >> >> guesses about MTU - whereas with packet-size biasing in the > >> >> >> transport, neither network element nor transport needs to know > what the > >> >> >> MTU is. > >> >> >> >>> * it is also easier to implement packet-size biasing in > the > >> >> >> transport than in the network. > >> >> >> >>> > >> >> >> >>> [BB] ...and all the other arguments about vulnerability to > >> >> >> flooding etc, transport-independence etc. > >> >> >> >>> > >> >> >> >>> Our argument is sort of like how Phil summarises it, but > with > >> >> >> an added nuance. It's also saying no-one has to do packet-size > >> >> >> biasing anyway. It's not saying "The transport should given > the > >> >> >> network shouldn't". It's saying "*If the transport wants to > claim > >> >> >> to be scalable wrt packet size* it should if the network > shouldn't". > >> >> >> >>> > >> >> >> >>> This gives a get-out clause to any transport that isn't > >> >> >> packet-size dependent (e.g. current TCP). Lacking packet-size > >> >> >> dependence just means they don't scale correctly with packet > size - > >> >> >> but they are at liberty not to scale with packet size > (particularly > >> >> >> given MTU growth isn't often being used to increase link rates > at > >> >> >> this stage in history). > >> >> >> >>> > >> >> >> >>> None of what Phil says convinces me we could say 3.4 (or > 3.3) > >> >> >> any more briefly or differently. It's easier to summarise what > you > >> >> >> understand having read something. But that's not the same as > >> >> >> writing the thing that helped you understand. There doesn't > seem to > >> >> >> be any argument for why anything needs to be changed, so I'm > going > >> >> >> to leave it as is, unless pushed. > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> On the last bullet, I didn't really follow your argument > in > >> >> >> S3.5. Might be easier to follow if S3.5 also talked about how > a > >> >> >> network element would take account of pkt size? > >> >> >> >>> Also, does the following argument also apply?: > >> >> >> >>> * if pkt-size biasing is done in the transport, then the > work (to do > >> >> >> >>> the biasing) is spread over many end hosts, > >> >> >> >>> * whereas if pkt-size biasing is done in the network, then > the > >> >> >> work is concentrated in just the congested network element, > which > >> >> >> has to operate on all the traffic at line speed. > >> >> >> >>> > >> >> >> >>> [BB]: 3.5. Implementation Efficiency > >> >> >> >>> > >> >> >> >>> [ADD:] > >> >> >> >>> Biasing against large packets typically requires an extra > multiply > >> >> >> >>> and divide in the network (see the example byte-mode drop > >> >> >> formula in table 1). > >> >> >> >>> [CONTINUE AS BEFORE:] > >> >> >> >>> Allowing for packet size at the transport rather than in > the > >> >> >> >>> network ensures that neither the network nor the > transport needs to > >> >> >> >>> do a multiply operation--multiplication by packet size is > >> >> >> >>> effectively achieved as a repeated add when the transport > adds to > >> >> >> >>> its count of marked bytes as each congestion event is fed > to it. > >> >> >> >>> [ADD:] > >> >> >> >>> Also the work to do the biasing is spread over many > hosts, rather > >> >> >> >>> than concentrated in just the congested network element. > >> >> >> >>> [CONTINUE AS BEFORE:] > >> >> >> >>> These > aren't > >> >> >> >>> principled reasons in themselves, but they are a happy > consequence > >> >> >> >>> of the other principled reasons. > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> Bob > >> >> >> >>> > >> >> >> >>> At 13:36 05/09/2012, Manner Jukka wrote: > >> >> >> >>> > >> >> >> >>> Hi Bob, > >> >> >> >>> > >> >> >> >>> Since Phil is your colleague at BT, even at Ipswich (?), > can > >> >> >> you check those and agree with Phil how to go forward? Some of > >> >> >> those are clear, others need discussion with Phil. > >> >> >> >>> > >> >> >> >>> Gorry, on point 2) below, I don't follow Leslie's > arguments. I > >> >> >> asked from him detailed comments and resolutions months ago, > and nothing > >> >> >> came. > >> >> >> >>> > >> >> >> >>> cheers, > >> >> >> >>> Jukka > >> >> >> >>> > >> >> >> >>> On Sep 5, 2012, at 3:26 PM, Gorry Fairhurst wrote: > >> >> >> >>> > >> >> >> >>>> Bob and Jukka, > >> >> >> >>>> > >> >> >> >>>> I think I need your help to resolve this... Some of the > >> >> >> comments raised by John Leslie appear to have substance, and > I'm > >> >> >> not sure what you plan to do to address these. > >> >> >> >>>> > >> >> >> >>>> It would be good to do something quick so that I can > complete > >> >> >> the submission to the IESG. > >> >> >> >>>> > >> >> >> >>>> The issues I particularly note are: > >> >> >> >>>> > >> >> >> >>>> 1) This contribution from Phil appears to be within scope > and > >> >> >> it seems may have been overlooked (sorry): > >> >> >> >>>> http://www.ietf.org/mail- > archive/web/tsvwg/current/msg11234.html > >> >> >> >>>> > >> >> >> >>>> 2) Can you be clear here about what is actually been said > - > >> >> >> because the point below seems to be a misunderstanding of > language > >> >> >> to me, and I hoped we did not claim this: > >> >> >> >>>> > >> >> >> >>>>>> ] Alas, when I read it carefully this week, I find that > Bob is > >> >> >> >>>>>> actually ] saying that transport-layer should _only_ > consider > >> >> >> >>>>>> "congested bytes", not ] "congested packets". > >> >> >> >>>>>> ] > >> >> >> >>>> > >> >> >> >>>> 3) You'll need to post the updated draft and send a note > to > >> >> >> the group to confirm that the new version indeed concludes the > >> >> >> WGLC. I'll add a note to the writeup to indicate the draft > content > >> >> >> has been stable since Oct 2011. > >> >> >> >>>> > >> >> >> >>>> Gorry (with my TSVWG Documnent Shepherd hat) > >> >> >> >>>> cc: Co-Chairs for info. > >> >> >> >>>> > >> >> >> >>>>> > >> >> >> >>>>>> -----Original Message----- > >> >> >> >>>>>> From: Gorry Fairhurst [ mailto:gorry@erg.abdn.ac.uk] > >> >> >> >>>>>> Sent: Mittwoch, 15. August 2012 21:41 > >> >> >> >>>>>> To: tsvwg chair > >> >> >> >>>>>> Subject: Fwd: Re: [tsvwg] FYI: Document writeup for > >> >> >> >>>>>> draft-ietf-tsvwg- byte-pkt-congest > >> >> >> >>>>>> > >> >> >> >>>>>> > >> >> >> >>>>>> > >> >> >> >>>>>> Hi guys, > >> >> >> >>>>>> > >> >> >> >>>>>> > >> >> >> >>>>>> Apart form the usual rhetoric, there are some points > here that we > >> >> >> >>>>>> should note as chairs. What are you own thoughts? And > was > >> >> >> >>>>>> anything noted at the IETF in Vancouver concerning this > draft? > >> >> >> >>>>>> > >> >> >> >>>>>> Gorry > >> >> >> >>>>>> > >> >> >> >>>>>> > >> >> >> >>>>>> > >> >> >> >>>>>> -------- Original Message -------- > >> >> >> >>>>>> Subject: Re: [tsvwg] FYI: Document writeup for > >> >> >> >>>>>> draft-ietf-tsvwg-byte- pkt-congest > >> >> >> >>>>>> Date: Wed, 15 Aug 2012 15:07:28 -0400 > >> >> >> >>>>>> From: John Leslie > >> >> >> >>>>>> To: Gorry Fairhurst > >> >> >> >>>>>> CC: tsvwg@ietf.org > >> >> >> >>>>>> > >> >> >> >>>>>> Gorry Fairhurst wrote: > >> >> >> >>>>>>> > >> >> >> >>>>>>> The following document has been revised after > receiving > >> >> >> WGLC comments. > >> >> >> >>>>>> > >> >> >> >>>>>> The changes are mostly refreshing a document > scheduled to > >> >> >> >>>>>> expire this month. > >> >> >> >>>>>> > >> >> >> >>>>>>> No issues were found: > >> >> >> >>>>>> > >> >> >> >>>>>> Is that with WGC-hat-on? > >> >> >> >>>>>> > >> >> >> >>>>>> Neither my issues nor Philip Eardley's comments were > addressed. > >> >> >> >>>>>> In fact, not even the changes Bob Briscoe mentioned on- > list have > >> >> >> >>>>>> been included. > >> >> >> >>>>>> > >> >> >> >>>>>>> As required by RFC 4858, this is the current template > for the > >> >> >> >>>>>> Document > >> >> >> >>>>>>> Shepherd Write-Up. > >> >> >> >>>>>>> ... > >> >> >> >>>>>>> (1) What type of RFC is being requested (BCP, Proposed > Standard, > >> >> >> >>>>>>> Internet Standard, Informational, Experimental, or > Historic)? > >> >> >> >>>>>>> Why is this the proper type of RFC? Is this type of > RFC > >> >> >> >>>>>>> indicated in the title page header? > >> >> >> >>>>>>> > >> >> >> >>>>>>> This document is intended as BCP. (This was discussed > at IETF-81 > >> >> >> >>>>>>> and that the status changed from Informational to BCP > since it > >> >> >> >>>>>>> provides guidance to implementors and people > configuring > >> >> >> routers and hosts). > >> >> >> >>>>>> > >> >> >> >>>>>> Thank you for finally answering my question about BCP > status. > >> >> >> >>>>>> > >> >> >> >>>>>>> ... > >> >> >> >>>>>>> Working Group Summary > >> >> >> >>>>>>> > >> >> >> >>>>>>> There was consensus to publish this as a WG document > and > >> >> >> >>>>>>> agreement at > >> >> >> >>>>>>> IETF-82 that the document was now complete. > >> >> >> >>>>>> > >> >> >> >>>>>> Was that reviewed on-list? > >> >> >> >>>>>> > >> >> >> >>>>>>> ... > >> >> >> >>>>>>> (3) Briefly describe the review of this document that > was > >> >> >> >>>>>>> performed > >> >> >> >>>>>> by > >> >> >> >>>>>>> the Document Shepherd. If this version of the document > is not > >> >> >> >>>>>>> ready for publication, please explain why the document > is being > >> >> >> >>>>>>> forwarded to the IESG. > >> >> >> >>>>>>> > >> >> >> >>>>>>> The document was presented at IEWTF-82 (Taipei), with > a request > >> >> >> >>>>>>> for > >> >> >> >>>>>> WGLC. > >> >> >> >>>>>>> WGLC concluded with some discussion but no substantive > changes > >> >> >> >>>>>>> on Friday 30th March 2012. > >> >> >> >>>>>> > >> >> >> >>>>>> Yes, I guess that is true; but ignoring substantive > comments > >> >> >> >>>>>> isn't a good practice IMHO. > >> >> >> >>>>>> > >> >> >> >>>>>>> (4) Does the document Shepherd have any concerns about > the depth > >> >> >> >>>>>>> or breadth of the reviews that have been performed? > >> >> >> >>>>>>> > >> >> >> >>>>>>> No - the original draft had a lot of background > material, much > >> >> >> >>>>>>> of > >> >> >> >>>>>> this > >> >> >> >>>>>>> has been condensed or removed, resulting in a smaller > document. > >> >> >> >>>>>> > >> >> >> >>>>>> That is indeed what I basically asked for, but I > don't see any > >> >> >> >>>>>> evidence of it: > >> >> >> >>>>>> > >> >> >> >>>>>> - diff(07,08) 48 lines changed or deleted; 53 lines > changed or > >> >> >> added > >> >> >> >>>>>> - diff(06,07) 8 lines changed or deleted; 13 lines > changed or > >> >> >> added > >> >> >> >>>>>> - diff(05,06) 64 lines changed or deleted; 69 lines > changed or > >> >> >> >>>>>> added > >> >> >> >>>>>> - diff(04,05) 823 lines changed or deleted; 864 lines > changed or > >> >> >> >>>>>> added > >> >> >> >>>>>> > >> >> >> >>>>>> (Need I go farther? That gets us back to March 2011...) > >> >> >> >>>>>> > >> >> >> >>>>>>> (9) How solid is the WG consensus behind this > document? Does it > >> >> >> >>>>>>> represent the strong concurrence of a few individuals, > with > >> >> >> >>>>>>> others being silent, or does the WG as a whole > understand > >> >> >> and agree with it? > >> >> >> >>>>>>> > >> >> >> >>>>>>> The document has WG support and there is consensus to > publish. > >> >> >> >>>>>> > >> >> >> >>>>>> This, IMHO, doesn't answer the question. :^( > >> >> >> >>>>>> > >> >> >> >>>>>> Does it represent the concurrence of a few > individuals, or does > >> >> >> >>>>>> the WG as a whole understand and agree with it? > >> >> >> >>>>>> > >> >> >> >>>>>> For reference, my comments included: > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] When I previously skimmed this document, I believed > it > >> >> >> >>>>>> contained only ] common ground: that AQM should > drop/mark packets > >> >> >> >>>>>> without favoring small ] packets, and that to whatever > extent > >> >> >> >>>>>> packet size _is_ considered, that ] should be a > >> >> >> transport-layer responsibility. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] Alas, when I read it carefully this week, I find that > Bob is > >> >> >> >>>>>> actually ] saying that transport-layer should _only_ > consider > >> >> >> >>>>>> "congested bytes", not ] "congested packets". > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] In fact, Bob openly endorses replacing TCP > congestion-control > >> >> >> >>>>>> with an ] algorithm which calculates "fair-share bytes" > and > >> >> >> >>>>>> doesn't back off at all ] (even in the presence of 20% > packet > >> >> >> >>>>>> loss) unless you're already sending ] more than this > >> >> >> "fair-share". > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] I do not believe that is the consensus of this WG; > and I > >> >> >> believe > >> >> >> >>>>>> if > >> >> >> >>>>>> ] that were the consensus it would exceed our charter. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] The draft contains a number of things I _do_ support; > and I'd > >> >> >> >>>>>> be happy ] to support a considerably shorter draft > which > >> >> >> >>>>>> concentrates on the AQM ] recommendation, omitting any > >> >> >> >>>>>> suggestions of modifying TCP congestion ] control. > >> >> >> >>>>>> > >> >> >> >>>>>> and Philip's comments included: > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] S2.2 I thought the numbered bullets could be better > phrased, > >> >> >> >>>>>> something like ] +this:- ] > >> >> >> >>>>>> ] 1. AQM algorithms such as RED SHOULD use packet- > mode > >> >> >> drop, ie they > >> >> >> >>>>>> SHOULD NOT > >> >> >> >>>>>> ] +use byte-mode drop. The latter ] is more complex, > >> >> >> >>>>>> ] it creates the perverse incentive to fragment > segments > >> >> >> into > >> >> >> >>>>>> tiny > >> >> >> >>>>>> ] pieces and it is vulnerable to floods of > small- > >> >> >> >>>>>> ] packets. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] 2. If a vendor has implemented byte-mode drop, > and an > >> >> >> operator > >> >> >> >>>>>> has > >> >> >> >>>>>> ] turned it on, it is RECOMMENDED to turn it > off, after > >> >> >> >>>>>> establishing if > >> >> >> >>>>>> ] +there are any implications on > >> >> >> >>>>>> ] the relative performance of > >> >> >> >>>>>> ] applications using different packet sizes. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] 3. RED SHOULD NOT be turned off. Without RED, a > drop tail > >> >> >> >>>>>> ] queue biases against large packets. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] Nit - the following paragraph shouldn't be indented > (Note well > >> >> >> >>>>>> that > >> >> >> >>>>>> RED's...) > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] S3.3 > >> >> >> >>>>>> ] The section could be slightly clearer. Starting with > the second > >> >> >> >>>>>> para, where you ] +start talking about something you > don't > >> >> >> >>>>>> recommend (ie you have to remember that ] +you're > talking about > >> >> >> >>>>>> the consequences of not following your recommendation). > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] S3.3 > >> >> >> >>>>>> ] o Also, if the network biases congestion > notification by > >> >> >> packet > >> >> >> >>>>>> size > >> >> >> >>>>>> ] it has to assume a baseline packet size--all > proposed > >> >> >> >>>>>> algorithms > >> >> >> >>>>>> ] use the local MTU. Then transports have to > guess which > >> >> >> link > >> >> >> >>>>>> was > >> >> >> >>>>>> ] congested and what its local MTU was, in order > to know > >> >> >> how to > >> >> >> >>>>>> ] tailor their congestion response to that link. > >> >> >> >>>>>> ] So you're saying that for byte-mode drop, the network > element > >> >> >> >>>>>> has to compare the ] +size of the current pkt with the > MTU, and > >> >> >> >>>>>> if it's 25* smaller then reduce the ] +pkt loss > probably by 25*? > >> >> >> >>>>>> And if the MTU was bigger, then the current pkt would ] > +be > >> >> >> >>>>>> dropped with greater probability? And both of these > things > >> >> >> are hard to do. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] S3.4 (& knock-on effect on 3.3) ] I think this could > be better. > >> >> >> >>>>>> ] I agree with your arguments in S3.1 & 3.2 that > dropping or > >> >> >> >>>>>> marking should be ] +independent of pkt size. > >> >> >> >>>>>> ] You now go into a couple of pages, which I think > could be > >> >> >> >>>>>> boiled down to a ] +paragraph, saying something like:- > ] * the > >> >> >> >>>>>> overall system (network + transport) has to be packet- > size > >> >> >> >>>>>> dependent in ] > >> >> >> >>>>>> +order to drive out the right amount of traffic so the > resource > >> >> >> >>>>>> becomes ] > >> >> >> >>>>>> +uncongested (since we assume all resources are in > practice byte > >> >> >> >>>>>> +rather > >> >> >> >>>>>> than ] +packet limited) ] * from S3.1 and S3.2 the IETF > is > >> >> >> >>>>>> convinced that the network should notify ] +independent > of > >> >> >> packet-size. > >> >> >> >>>>>> ] * therefore the transport must act dependent on > packet-size. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] It seems to me this is a necessary consequence of > your earlier > >> >> >> >>>>>> assumptions ] +/arguments. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] [On the other hand, if someone disagrees with the > arguments and > >> >> >> >>>>>> thinks that the ] +network should notify dependent on > >> >> >> >>>>>> packet-size, then it follows that the ] +transport can > act > >> >> >> >>>>>> independent of > >> >> >> >>>>>> packet- size.] ] ] I think in S3.3 you're trying to > make another > >> >> >> >>>>>> argument (?):- ] * we can either do packet-size > biasing in the > >> >> >> >>>>>> network element or on the end host ] +transport (see > argument > >> >> >> >>>>>> above) ] * packet-size biasing in the network is quite > tricky, > >> >> >> >>>>>> because then both the ] +network element & the > transport have to > >> >> >> >>>>>> make some guesses about MTU - whereas ] > >> >> >> >>>>>> +with packet-size biasing in the transport, neither > network > >> >> >> >>>>>> +element > >> >> >> >>>>>> nor ] +transport needs to know what the MTU is. > >> >> >> >>>>>> ] * it is also easier to implement packet-size biasing > in the > >> >> >> >>>>>> transport than in ] +the network. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] On the last bullet, I didn't really follow your > argument in > >> >> >> S3.5. > >> >> >> >>>>>> Might be ] +easier to follow if S3.5 also talked about > how a > >> >> >> >>>>>> network element would take ] +account of pkt size? > Also, does the > >> >> >> >>>>>> following argument also apply?: > >> >> >> >>>>>> ] * if pkt-size biasing is done in the transport, then > the work > >> >> >> >>>>>> (to do the ] +biasing) is spread over many end hosts, ] > * whereas > >> >> >> >>>>>> if pkt-size biasing is done in the network, then the > work is ] > >> >> >> >>>>>> +concentrated in just the congested network element, > which has to > >> >> >> >>>>>> operate on all ] +the traffic at line speed. > >> >> >> >>>>>> > >> >> >> >>>>>> (Has there perhaps been some confusion about what > went into the > >> >> >> >>>>>> -08 > >> >> >> >>>>>> version?) > >> >> >> >>>>>> > >> >> >> >>>>>> -- > >> >> >> >>>>>> John Leslie > >> >> >> >>>>>> > >> >> >> >>>>>> > >> >> >> >>>>> > >> >> >> >>>> > >> >> >> >>> > ________________________________________________________________ > >> >> >> >>> Bob Briscoe, BT Innovate & > Design > >> >> >> >>> > >> >> >> >> > >> >> >> > > >> >> > > >> >> > > ________________________________________________________________ > >> >> > Bob Briscoe, BT Innovate & > Design > >> >> > > >> > > >> > ________________________________________________________________ > >> > Bob Briscoe, BT Innovate & Design > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design From jukka.manner@aalto.fi Thu Oct 11 05:49:48 2012 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 A745C21F8713; Thu, 11 Oct 2012 05:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iv+VZxxV3b75; Thu, 11 Oct 2012 05:49:46 -0700 (PDT) Received: from mx06.aalto.fi (mx06.aalto.fi [130.233.222.105]) by ietfa.amsl.com (Postfix) with ESMTP id 4993C21F8620; Thu, 11 Oct 2012 05:49:45 -0700 (PDT) Received: from mx06.aalto.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AC476807BB; Thu, 11 Oct 2012 15:49:43 +0300 (EEST) Received: from EXHUB03.org.aalto.fi (ex-hub03.org.aalto.fi [130.233.222.116]) by mx06.aalto.fi (Postfix) with ESMTP id 015DC807C6; Thu, 11 Oct 2012 15:49:42 +0300 (EEST) Received: from EXMDB04.org.aalto.fi ([169.254.1.56]) by EXHUB03.org.aalto.fi ([130.233.222.116]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 15:49:43 +0300 From: Manner Jukka To: "Tschofenig, Hannes (NSN - FI/Espoo)" Thread-Topic: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest Thread-Index: AQHNp64+FkrAkabfCEaD1jzPlkv4fJez3BoA Date: Thu, 11 Oct 2012 12:49:41 +0000 Message-ID: <3A5279D338C75C40B4B3DA15BA47D6330B6FD197@EXMDB04.org.aalto.fi> References: <20120815190728.GQ15012@verdi> <502BFB47.7010803@erg.abdn.ac.uk><791AD3077F94194BB2BDD13565B6295D45A6212A@PALLENE.office.hd><15181_1346848013_5047450C_15181_645_1_50474507.3090706@erg.abdn.ac.uk><3A5279D338C75C40B4B3DA15BA47D6330B616BD2@EXMDB04.org.aalto.fi><201209051541.q85FfCs0019699@bagheera.jungle.bt.co.uk><9510D26531EF184D9017DF24659BB87F33D793B351@EMV65-UKRD.domain1.systemhost.net><3A5279D338C75C40B4B3DA15BA47D6330B69261A@EXMDB04.org.aalto.fi><9510D26531EF184D9017DF24659BB87F33D793B845@EMV65-UKRD.domain1.systemhost.net><04AC95B5-A2B1-4DD2-B765-E20A4C1A69A3@aalto.fi><3A5279D338C75C40B4B3DA15BA47D6330B6E81E4@EXMDB04.org.aalto.fi><9510D26531EF184D9017DF24659BB87F33DCE34251@EMV65-UKRD.domain1.systemhost.net><201210041126.q94BQ0hx002951@bagheera.jungle.bt.co.uk><1904eec816d080f886f5bf8685358ddc.squirrel@www.erg.abdn.ac.uk><201210101525.q9AFP4Mi008013@bagheera.jungle.bt.co.uk><3A5279D338C75C40B4B3DA15BA47D6330B6FC2BB@EXMDB04.org.aalto.fi><201210111208.q9BC8BAU012! 305@baghe era.jungle.b t.co.uk> <3A5279D338C75C40B4B3DA15BA47D6330B6FD072@EXMDB04.org.aalto.fi> <999913AB42CC9341B05A99BBF358718D01F360CF@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D01F360CF@FIESEXC035.nsn-intra.net> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.152.186.160] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , tsvwg IETF list , "" Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest 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, 11 Oct 2012 12:49:48 -0000 Hi, this document talks about the current and short term goals and operatio= ns, while AFAIK CoDel is a more futuristic concept, interesting concept, su= re, but not deployed at large. cheers, Jukka On Oct 11, 2012, at 3:44 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Jukka, Hi Bob,=20 >=20 > having listened to the presentations about CoDel I am wondering whether > this document may have taken over by events and is obsolete by now. > What's your view on that?=20 >=20 > Ciao > Hannes >=20 >=20 >> -----Original Message----- >> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf >> Of ext Manner Jukka >> Sent: Thursday, October 11, 2012 3:34 PM >> To: Bob Briscoe >> Cc: ; ; > chairs@ietf.org>; tsvwg IETF list >> Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf- >> tsvwg-byte-pkt-congest >>=20 >> Hi, >>=20 >> Yeah, please at the point about cheap devices, still, I wonder what > the >> cost of AQM is on those devices. Maybe 1 cnt in mass production? Thus, >> I still wonder if it is worth arguing something about the future that >> strongly. >>=20 >> Sorry, but the same goes for AQM in general, and where it is, or will >> not be deployed. I understand technical reasons why not something is >> feasible, but business or monetary reasons can change very quickly. ;) >>=20 >> Jukka >>=20 >> On Oct 11, 2012, at 3:08 PM, Bob Briscoe wrote: >>=20 >>> Jukka, >>>=20 >>> What I had in mind is all low level buffers in cheap pure L2 > devices, >> in cheap NATs etc. I was going to list some of these, but instead > chose >> to say "no-one expects AQM to be universally deployed". This clearly >> missed the mark. >>>=20 >>> Should we include some of these concrete examples of where AQM won't >> be deployed instead? >>>=20 >>> [I've cc'd the list, given we're starting to wordsmith significantly >> new text added since WG last call.] >>>=20 >>>=20 >>> Bob >>>=20 >>> At 20:04 10/10/2012, Manner Jukka wrote: >>>> Hi, looked good to me. Just one comment, I wouldn't put that much >> emphasis on what is a probably state of things, e.g. >>>>=20 >>>> "no-one expects AQM to ever be .." > in the future it might, we >> don't know, and since the paragraph says that it doesn't matter > anyway, >> I would formulate this paragraph a bit towards that we have partial >> deployment now and even with a full deployment, ... >>>>=20 >>>> and similarly with the unrealistic deployment of AQM in the >> subsequent paragraph. >>>>=20 >>>> cheers, >>>> Jukka >>>>=20 >>>> On Oct 10, 2012, at 6:25 PM, Bob Briscoe wrote: >>>>=20 >>>>> Phil, >>>>>=20 >>>>> Sorry for delay, my round-robin scheduler is taking so long to > get >> round all the tasks that I keep finding dead robins (that reminds me > of >> a bike ride my grandmother took. On her return, she said there were a >> worryingly large number of robins run over on the roads. It turned out >> that she had been going round the same small triangle of roads > multiple >> times). >>>>>=20 >>>>> I've done a complete re-write of 3.4. I hope you will agree that >> it really is a motivating argument now and it can stay where it is - > it >> is not just a preamble. >>>>>=20 >>>>> I've gone back to the very first version of 3.4 I wrote and I now >> realise that I had written the core of the argument so badly that even >> I forgot what it was meant to say when we started editing it. In the >> draft-08 version, the original meaning is lost and in your re-wording >> it is entirely lost. The link with the draft-08 version is nearly >> unrecognisable, but it's the argument I intended here. >>>>>=20 >>>>>=20 >>=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> 3.4. Permanent Partial Deployment of AQM >>>>>=20 >>>>> In overview, the argument in this section runs as follows: >>>>> * Because the network will not and cannot always drop packets in >> proportion to their size, it shouldn't be given the task of making > drop >> signals depend on packet size at all. >>>>> * Transports on the other hand don't always want to make their >> rate response proportional to the size of dropped packets, but if they >> want to, they always can. >>>>>=20 >>>>> The argument is similar to the end-to-end argument that says >> "Don't do X in the network if end-systems can do X by themselves, and >> they want to be able to choose whether to do X anyway." Actually the >> following argument is stronger; in addition it says "Don't give the >> network task X that could be done by the end-systems, if X won't ever >> be deployed on all network nodes, and end-systems won't be able to > tell >> whether their network is doing X, or whether they need to do X >> themselves." In this case, the X in question is "making the response > to >> congestion depend on packet size". >>>>>=20 >>>>> We will now re-run this argument taking each step in more depth. >> The argument applies solely to drop, not ECN marking. >>>>>=20 >>>>> A queue drops packets for either of two reasons: a) to signal to >> host congestion controls that they should reduce the load and b) >> because there is no buffer left to store the packets. Active queue >> management tries to use drops as a signal for hosts to slow down (case >> a) so that drop due to buffer exhaustion (case b) should not be >> necessary. >>>>>=20 >>>>> No-one expects AQM to ever be universally deployed in every queue >> in the Internet; and, even if AQM were universal, it has to be able to >> cope with buffer exhaustion (by switching to a behaviour like tail- >> drop), in order to cope with unresponsive or excessive transports. >> Therefore networks will often be dropping packets as a last resort >> (case b) rather than under AQM control (case a). >>>>>=20 >>>>> When buffers are exhausted (case b), they don't naturally drop >> packets in proportion to their size. The network can only reduce the >> probability of dropping smaller packets if it has enough space to > store >> them somewhere while it waits for a larger packet that it can drop. If >> the buffer is exhausted, it does not have this choice. Admittedly > tail- >> drop does naturally drop somewhat fewer small packets, but exactly how >> few depends more on the mix of sizes than the size of the packet in >> question. Nonetheless, in general, if we wanted networks to do size- >> dependent drop, we would need universal deployment of (packet-size >> dependent) AQM code, which is unrealistic. >>>>>=20 >>>>> A host transport cannot know whether any particular drop was a >> deliberate signal from an AQM or a sign of a queue shedding packets > due >> to buffer exhaustion. Therefore, because the network cannot > universally >> do size-dependent drop, it should not do it all. >>>>>=20 >>>>> Whereas universality is desirable in the network, diversity is >> desirable between different transport layer protocols - some, like >> NewReno TCP [RFC5681], may not choose to make their rate response >> proportionate to the size of each dropped packet, while others will >> (e.g. TFRC-SP [RFC4828]). >>>>>=20 >>=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Bob >>>>>=20 >>>>> At 13:13 04/10/2012, gorry@erg.abdn.ac.uk wrote: >>>>>> That would be brilliant! >>>>>>=20 >>>>>> Gorry >>>>>>=20 >>>>>>> Will try to look at this later today. >>>>>>>=20 >>>>>>>=20 >>>>>>> Bob >>>>>>>=20 >>>>>>> At 10:42 02/10/2012, philip.eardley@bt.com wrote: >>>>>>>> Think the token is with bob >>>>>>>>=20 >>>>>>>> Re your comment - yes, I think you could move 3.4 to the end > of >> S3 - >>>>>>>> or to the start - and do some re-phrasing, maybe something > like >> I tried. >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Manner Jukka [mailto:jukka.manner@aalto.fi] >>>>>>>> Sent: 01 October 2012 20:18 >>>>>>>> To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,Bob,DUB8 R >>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst >>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for >>>>>>>> draft-ietf-tsvwg-byte-pkt-congest >>>>>>>>=20 >>>>>>>> Phil, Bob, can we close this finally? It's three weeks now >> since >>>>>>>> this previous message. >>>>>>>>=20 >>>>>>>> Jukka >>>>>>>>=20 >>>>>>>> On Sep 10, 2012, at 4:42 PM, Jukka Manner wrote: >>>>>>>>=20 >>>>>>>>> Ack, I'm getting there...;) >>>>>>>>>=20 >>>>>>>>> So, we could move 3.4 at the end of Section 3 and rephrase >> it to >>>>>>>> not talk about scaling per se, but rather about how Req 2.2 >>>>>>>> eventually leads to Req 2.3? >>>>>>>>>=20 >>>>>>>>> Jukka >>>>>>>>>=20 >>>>>>>>> On Sep 7, 2012, at 4:07 PM, >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> 3.4 is, in my mind, completely different from 3.1, 3.2, > 3.3 >> and 3.5. >>>>>>>>>>=20 >>>>>>>>>> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for >> Recommendation >>>>>>>>>> 2.2 & a lesser extent 2.3 >>>>>>>>>> 3.4 makes doesn't make a motivating argument - it explains >> that Rec >>>>>>>>>> 2.2 & 2.3 come as a pair (if you recommend one, then >> inevitably you >>>>>>>>>> recommend the other) (delta some politeness about TCP) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Manner Jukka [mailto:jukka.manner@aalto.fi] >>>>>>>>>> Sent: 07 September 2012 13:24 >>>>>>>>>> To: Eardley,PL,Philip,DUB8 R >>>>>>>>>> Cc: Briscoe,RJ,Bob,DUB8 R; ; >>>>>>>>>> >>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for >>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest >>>>>>>>>>=20 >>>>>>>>>> Hi, I'm trying to follow your reasoning, with little luck. >> ;) >>>>>>>>>>=20 >>>>>>>>>> After having read Section 3 again, I could think of a few >>>>>>>> updates, but I'm not fully following what you want to see: >>>>>>>>>>=20 >>>>>>>>>> - S3.5 is kind of small and lonely by itself. It could be >> either >>>>>>>> longer or merged somewhere. Not a major issue though and > could >> remain as >>>>>>>> is. >>>>>>>>>>=20 >>>>>>>>>> - S3.3: Yes, probably could be turned upside down, good >> first, >>>>>>>> bad later. Don't have a strong opinion. >>>>>>>>>>=20 >>>>>>>>>> - S3.4: Here the scaling is used many times and in the >> title, >>>>>>>> although we talk about the end host side. This could be >> rephrased >>>>>>>> and slightly reworded to talk about hosts and their operation >>>>>>>> altogether. Also the word scaling can turn the readers >> expectation >>>>>>>> into the wrong direction. >>>>>>>>>>=20 >>>>>>>>>> - S3 altogether: It would help to have introductory text >> about >>>>>>>> networks vs. end host side, but I fail to see why (& how) to >>>>>>>> restructure everything. >>>>>>>>>>=20 >>>>>>>>>> cheers, >>>>>>>>>> Jukka >>>>>>>>>>=20 >>>>>>>>>> On Sep 6, 2012, at 6:18 PM, >>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Ps otherwise Bob's comments are fine, though I suggest > for >> S3.5 you >>>>>>>>>>> give more context (ie are you knocking down what you >> recommend >>>>>>>>>>> against, or building up what you recommend?) and in S3.3 >> think >>>>>>>>>>> would be better if you re-structured slightly [first talk >> about what >>>>>>>>>>> you like - penult para + 1st sentence of last para - then >> talk about >>>>>>>>>>> what you don't like - rest of text] >>>>>>>>>>>=20 >>>>>>>>>>> From: Eardley,PL,Philip,DUB8 R >>>>>>>>>>> Sent: 06 September 2012 16:12 >>>>>>>>>>> To: Briscoe,RJ,Bob,DUB8 R; Manner Jukka >>>>>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst >>>>>>>>>>> Subject: RE: [REVISED I-D]: Document writeup for >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest >>>>>>>>>>>=20 >>>>>>>>>>> Thanks bob. Have now re-booted some state. >>>>>>>>>>> I don't like S3.4. My basic problem with it is that it >> isn't a >>>>>>>> "motivating argument" (S3 title). It's an explanation about >> the >>>>>>>> consequences of assuming either [option 1] do pkt-size > biasing >> in >>>>>>>> the transport; [option 2]; do pkt-size biasing in the nw. >>>>>>>>>>> Perhaps your effort to buy peace with those who won't >> change >>>>>>>> TCP has obfuscated the basic point? >>>>>>>>>>> The title of S3.4 (Scaling...) and the early text > "scaling >>>>>>>> argument" suggests that you're going to argue there is some >> reason >>>>>>>> why X scales as order N rather than N^2 or something like > that >> - >>>>>>>> which isn't what S3.4 is about. >>>>>>>>>>>=20 >>>>>>>>>>> I actually think it would be better to put S3.4 at the >> start of >>>>>>>> S3 - it's background where you say there are 2 options. After >> that, >>>>>>>> you can explain the reasons why option 1 [pkt biasing in the >>>>>>>> transport] is better - the reasons being:- S3.1 (security > etc >>>>>>>> attacks if small pkts get preferential treatment), S3.2 >> (really a >>>>>>>> side note to S3.1; ie doesn't really present a "motivating >>>>>>>> argument"), S3.3 (nw guessing MTU vs transport knowing pkt >> size), >>>>>>>> S3.5 (easier implementation). >>>>>>>>>>>=20 >>>>>>>>>>> Something like... >>>>>>>>>>> The behaviour of the network and transport together needs >> to >>>>>>>>>>> alleviate congestion. We assume the network is bit- >> congestible >>>>>>>> (currently packet-congestible resources are rate). Therefore >>>>>>>> overall the response of the {network + transport} should be >> the >>>>>>>> same for the same congestion - whether the congestion is >> caused by >>>>>>>> a lot of small packets or a smaller number of larger packets. >> The >>>>>>>> implication is that the transport's behaviour should depend > on >>>>>>>> whether the network takes account (or not) of packet size > when >> it >>>>>>>> generates congestion indications:- Case 1: If the network >>>>>>>> implements packet-mode drop, ie its algorithm treats all >> packets >>>>>>>> equally regardless of their size, then the transport should >> take >>>>>>>> account of the size of the packet - in other words, the >> transport's >>>>>>>> congestion response should depend on the number of dropped >> bytes. >>>>>>>>>>> Case 2: If the network implements byte-mode drop, ie its >>>>>>>> algorithm treats packets differently depending on their size, >> then >>>>>>>> the transport should not take account of the size of the >> packet - >>>>>>>> in other words, the transport's congestion response should >> depend >>>>>>>> on the number of dropped packets. >>>>>>>>>>>=20 >>>>>>>>>>> These cases are explained in more detail in sub-section >> below. >>>>>>>>>>>=20 >>>>>>>>>>> In both cases the same discussion applies if packets are >>>>>>>> ECN-marked rather than dropped. >>>>>>>>>>> In the following sections we explain why Case 1 is >> preferable, >>>>>>>> and hence why we make the Recommendations of S2.2 and S3.3 >>>>>>>> (respectively, drop/mark pkts equally regardless of their >> size, and >>>>>>>> the strength of the transport's response should be >> proportionate to >>>>>>>> the size of the dropped/marked pkt). >>>>>>>>>>> Note that TCP responds to dropped or marked packets, > which >> differs >>>>>>>>>>> from our recommendation for transports. However, we are >> not >>>>>>>>>>> recommending that TCP should be changed; to date it >> hasn't been a >>>>>>>>>>> significant problem because most TCP implementations > have >> been >>>>>>>> used with similar packet sizes. But we do recommend that >> future >>>>>>>> transport protocols should respond to dropped or marked > bytes >> (as >>>>>>>> for example TFRC-SP [RFC4828]effectively does). >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Sub-section >>>>>>>>>>> You could use much of S3.3, I suggest supplement with >> numerical >>>>>>>>>>> examples continuing S1.2 >>>>>>>>>>> -- >>>>>>>>>>> << This gives a get-out clause to any transport that > isn't >>>>>>>>>>> packet-size dependent (e.g. current TCP). Lacking packet- >> size >>>>>>>>>>> dependence just means they don't scale correctly with >> packet size - >>>>>>>>>>> but they are at liberty not to scale with packet size >> (particularly >>>>>>>>>>> given MTU growth isn't often being used to increase link >> rates at >>>>>>>>>>> this stage in history).>> >>>>>>>>>>>=20 >>>>>>>>>>> This is introducing a different point. it's saying that >> your >>>>>>>> recommendation 2 [drop/mark pkts equally regardless of their >> size] >>>>>>>> is a really strong reco whilst recommendation 3 [strength of >>>>>>>> transport's response proportionate to the size of the >>>>>>>> dropped/marked pkt] is a much less important reco. I can see >> this >>>>>>>> might be true, but I don't think the i-d talks about this. >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>>=20 >>>>>>>>>>> From: Briscoe,RJ,Bob,DUB8 R >>>>>>>>>>> Sent: 05 September 2012 16:41 >>>>>>>>>>> To: Manner Jukka >>>>>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst; >> Eardley,PL,Philip,DUB8 R >>>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest >>>>>>>>>>>=20 >>>>>>>>>>> Jukka, >>>>>>>>>>>=20 >>>>>>>>>>> I've repeated Phil's suggestions as quoted email then > made >> some >>>>>>>> alterations. >>>>>>>>>>>=20 >>>>>>>>>>> Phil asked me to send this, then he will think about it. >>>>>>>>>>>=20 >>>>>>>>>>> I'll respond about John Leslie's argument next... >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> 2.2. Recommendation on Encoding Congestion Notification >>>>>>>>>>>=20 >>>>>>>>>>> [...] >>>>>>>>>>>=20 >>>>>>>>>>> 1. AQM algorithms such as RED SHOULD use packet-mode >> drop, ie they >>>>>>>>>>> SHOULD NOT use byte-mode drop. The latter is more >> complex, >>>>>>>>>>> it creates the perverse incentive to fragment >> segments into >>>>>>>> tiny >>>>>>>>>>> pieces and it is vulnerable to floods of small >> packets. >>>>>>>>>>>=20 >>>>>>>>>>> 2. If a vendor has implemented byte-mode drop, and an >> operator has >>>>>>>>>>> turned it on, it is RECOMMENDED to turn it off, > after >>>>>>>> establishing >>>>>>>>>>> if there are any implications on the relative >> performance of >>>>>>>>>>> applications using different packet sizes. >>>>>>>>>>>=20 >>>>>>>>>>> RED as a whole SHOULD NOT be turned off. Without > RED, >> a drop >>>>>>>> tail >>>>>>>>>>> queue biases against large packets >>>>>>>>>>>=20 >>>>>>>>>>> [BB adds]: and it is >> vulnerable to >>>>>>>> floods >>>>>>>>>>> of small-packets. >>>>>>>>>>>=20 >>>>>>>>>>> (I suggest the last para just qualifies item 2. It > doesn't >> warrant >>>>>>>>>>> another item number.) >>>>>>>>>>>=20 >>>>>>>>>>> >>>>>>>>>>>=20 >>>>>>>>>>> [PE:] S3.3 >>>>>>>>>>> The section could be slightly clearer. Starting with the >> second >>>>>>>> para, where you start talking about something you don't >> recommend >>>>>>>> (ie you have to remember that you're talking about the >> consequences >>>>>>>> of not following your recommendation). >>>>>>>>>>>=20 >>>>>>>>>>> 3.3 Transport-Independent Network >>>>>>>>>>>=20 >>>>>>>>>>> TCP congestion control ensures that flows competing for >> the same >>>>>>>>>>> resource each maintain the same number of segments in >> flight, >>>>>>>>>>> irrespective of segment size. So under similar >> conditions, flows >>>>>>>>>>> with different segment sizes will get different > bit-rates. >>>>>>>>>>>=20 >>>>>>>>>>> [OLD:] >>>>>>>>>>> One motivation for the network biasing congestion >> notification by >>>>>>>>>>> packet size is to counter this effect and try to equalise >> the bit- >>>>>>>>>>> rates of flows with different packet sizes. >>>>>>>>>>> [SUGGESTED:] >>>>>>>>>>> To counter this effect it seems tempting not to follow >> our >>>>>>>>>>> recommendation, and instead for the network to bias >> congestion >>>>>>>>>>> notification by packet size in order to equalise the > bit- >> rates of >>>>>>>>>>> flows with different packet sizes. >>>>>>>>>>> [CONTINUE AS BEFORE:] >>>>>>>>>>> However, in order to do this, the queuing >> algorithm >>>>>>>>>>> has to make assumptions about the transport, which > become >> embedded >>>>>>>>>>> in the network. Specifically: >>>>>>>>>>> [...] >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> S3.3 >>>>>>>>>>> o The queuing algorithm has to assume how aggressively >> the >>>>>>>> transport >>>>>>>>>>> will respond to congestion (see Section 4.2.4). If >> the network >>>>>>>>>>> assumes the transport responds as aggressively as TCP >> NewReno, >>>>>>>> it >>>>>>>>>>> will be wrong for Compound TCP and differently wrong >> for Cubic >>>>>>>>>>> TCP, etc. To achieve equal bit-rates, each transport >> then has >>>>>>>> to >>>>>>>>>>> guess what assumption the network made, and work out >> how to >>>>>>>>>>> replace this assumed aggressiveness with its own >> aggressiveness. >>>>>>>>>>> o Also, if the network biases congestion notification > by >> packet >>>>>>>> size >>>>>>>>>>> it has to assume a baseline packet size--all proposed >> algorithms >>>>>>>>>>> use the local MTU. Then transports have to guess >> which link was >>>>>>>>>>> congested and what its local MTU was, in order to > know >> how to >>>>>>>>>>> tailor their congestion response to that link. >>>>>>>>>>>=20 >>>>>>>>>>> So you're saying that for byte-mode drop, the network >> element >>>>>>>> has to compare the size of the current pkt with the MTU, and >> if >>>>>>>> it's 25* smaller then reduce the pkt loss probably by 25*? > And >> if >>>>>>>> the MTU was bigger, then the current pkt would be dropped > with >>>>>>>> greater probability? And both of these things are hard to do. >>>>>>>>>>>=20 >>>>>>>>>>> [BB]: SUGGESTED REPLACEMENT to 2nd bullet: >>>>>>>>>>>=20 >>>>>>>>>>> o Also, if the network biases congestion notification > by >> packet >>>>>>>> size >>>>>>>>>>> it has to assume a baseline packet size--all proposed >> algorithms >>>>>>>>>>> use the local MTU (for example see the byte-mode loss >>>>>>>> probability >>>>>>>>>>> formula in Table 1). Then if the non-Reno transports >> mentioned >>>>>>>> above >>>>>>>>>>> are trying to reverse engineer what the network >> assumed, they >>>>>>>> also >>>>>>>>>>> have to guess the MTU of the congested link. >>>>>>>>>>>=20 >>>>>>>>>>> [Aside for Phil: The byte-mode algo uses MTU as its >> baseline because >>>>>>>>>>> a link cannot send a packet bigger than its MTU so the >> algo won't >>>>>>>>>>> ever give a drop probability >1).] >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> S3.4 (& knock-on effect on 3.3) >>>>>>>>>>> I think this could be better. >>>>>>>>>>> I agree with your arguments in S3.1 & 3.2 that dropping > or >>>>>>>> marking should be independent of pkt size. >>>>>>>>>>> You now go into a couple of pages, which I think could be >> boiled >>>>>>>>>>> down to a paragraph, saying something like:- >>>>>>>>>>> * the overall system (network + transport) has to be >> packet-size >>>>>>>>>>> dependent in order to drive out the right amount of >> traffic so the >>>>>>>>>>> resource becomes uncongested (since we assume all >> resources are in >>>>>>>>>>> practice byte rather than packet limited) >>>>>>>>>>> * from S3.1 and S3.2 the IETF is convinced that the >> network >>>>>>>> should notify independent of packet-size. >>>>>>>>>>> * therefore the transport must act dependent on packet- >> size. >>>>>>>>>>>=20 >>>>>>>>>>> It seems to me this is a necessary consequence of your >> earlier >>>>>>>> assumptions /arguments. >>>>>>>>>>>=20 >>>>>>>>>>> [BB:] This isn't at all obvious. Until I worked it >> through, it >>>>>>>> wasn't obvious to me. I think it needs to be spelled out. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> [On the other hand, if someone disagrees with the >> arguments and >>>>>>>>>>> thinks that the network should notify dependent on > packet- >> size, then >>>>>>>>>>> it follows that the transport can act independent of >> packet-size.] >>>>>>>>>>>=20 >>>>>>>>>>> I think in S3.3 you're trying to make another argument >> (?):- >>>>>>>>>>> * we can either do packet-size biasing in the network >> element or on >>>>>>>>>>> the end host transport (see argument above) >>>>>>>>>>> * packet-size biasing in the network is quite tricky, >> because >>>>>>>> then both the network element & the transport have to make >> some >>>>>>>> guesses about MTU - whereas with packet-size biasing in the >>>>>>>> transport, neither network element nor transport needs to > know >> what the >>>>>>>> MTU is. >>>>>>>>>>> * it is also easier to implement packet-size biasing in >> the >>>>>>>> transport than in the network. >>>>>>>>>>>=20 >>>>>>>>>>> [BB] ...and all the other arguments about vulnerability > to >>>>>>>> flooding etc, transport-independence etc. >>>>>>>>>>>=20 >>>>>>>>>>> Our argument is sort of like how Phil summarises it, but >> with >>>>>>>> an added nuance. It's also saying no-one has to do > packet-size >>>>>>>> biasing anyway. It's not saying "The transport should given >> the >>>>>>>> network shouldn't". It's saying "*If the transport wants to >> claim >>>>>>>> to be scalable wrt packet size* it should if the network >> shouldn't". >>>>>>>>>>>=20 >>>>>>>>>>> This gives a get-out clause to any transport that isn't >>>>>>>> packet-size dependent (e.g. current TCP). Lacking packet-size >>>>>>>> dependence just means they don't scale correctly with packet >> size - >>>>>>>> but they are at liberty not to scale with packet size >> (particularly >>>>>>>> given MTU growth isn't often being used to increase link > rates >> at >>>>>>>> this stage in history). >>>>>>>>>>>=20 >>>>>>>>>>> None of what Phil says convinces me we could say 3.4 (or >> 3.3) >>>>>>>> any more briefly or differently. It's easier to summarise > what >> you >>>>>>>> understand having read something. But that's not the same as >>>>>>>> writing the thing that helped you understand. There doesn't >> seem to >>>>>>>> be any argument for why anything needs to be changed, so I'm >> going >>>>>>>> to leave it as is, unless pushed. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On the last bullet, I didn't really follow your argument >> in >>>>>>>> S3.5. Might be easier to follow if S3.5 also talked about how >> a >>>>>>>> network element would take account of pkt size? >>>>>>>>>>> Also, does the following argument also apply?: >>>>>>>>>>> * if pkt-size biasing is done in the transport, then the >> work (to do >>>>>>>>>>> the biasing) is spread over many end hosts, >>>>>>>>>>> * whereas if pkt-size biasing is done in the network, > then >> the >>>>>>>> work is concentrated in just the congested network element, >> which >>>>>>>> has to operate on all the traffic at line speed. >>>>>>>>>>>=20 >>>>>>>>>>> [BB]: 3.5. Implementation Efficiency >>>>>>>>>>>=20 >>>>>>>>>>> [ADD:] >>>>>>>>>>> Biasing against large packets typically requires an > extra >> multiply >>>>>>>>>>> and divide in the network (see the example byte-mode > drop >>>>>>>> formula in table 1). >>>>>>>>>>> [CONTINUE AS BEFORE:] >>>>>>>>>>> Allowing for packet size at the transport rather than in >> the >>>>>>>>>>> network ensures that neither the network nor the >> transport needs to >>>>>>>>>>> do a multiply operation--multiplication by packet size > is >>>>>>>>>>> effectively achieved as a repeated add when the > transport >> adds to >>>>>>>>>>> its count of marked bytes as each congestion event is > fed >> to it. >>>>>>>>>>> [ADD:] >>>>>>>>>>> Also the work to do the biasing is spread over many >> hosts, rather >>>>>>>>>>> than concentrated in just the congested network element. >>>>>>>>>>> [CONTINUE AS BEFORE:] >>>>>>>>>>>=20 > These >> aren't >>>>>>>>>>> principled reasons in themselves, but they are a happy >> consequence >>>>>>>>>>> of the other principled reasons. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Bob >>>>>>>>>>>=20 >>>>>>>>>>> At 13:36 05/09/2012, Manner Jukka wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Hi Bob, >>>>>>>>>>>=20 >>>>>>>>>>> Since Phil is your colleague at BT, even at Ipswich (?), >> can >>>>>>>> you check those and agree with Phil how to go forward? Some > of >>>>>>>> those are clear, others need discussion with Phil. >>>>>>>>>>>=20 >>>>>>>>>>> Gorry, on point 2) below, I don't follow Leslie's >> arguments. I >>>>>>>> asked from him detailed comments and resolutions months ago, >> and nothing >>>>>>>> came. >>>>>>>>>>>=20 >>>>>>>>>>> cheers, >>>>>>>>>>> Jukka >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 5, 2012, at 3:26 PM, Gorry Fairhurst wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Bob and Jukka, >>>>>>>>>>>>=20 >>>>>>>>>>>> I think I need your help to resolve this... Some of the >>>>>>>> comments raised by John Leslie appear to have substance, and >> I'm >>>>>>>> not sure what you plan to do to address these. >>>>>>>>>>>>=20 >>>>>>>>>>>> It would be good to do something quick so that I can >> complete >>>>>>>> the submission to the IESG. >>>>>>>>>>>>=20 >>>>>>>>>>>> The issues I particularly note are: >>>>>>>>>>>>=20 >>>>>>>>>>>> 1) This contribution from Phil appears to be within > scope >> and >>>>>>>> it seems may have been overlooked (sorry): >>>>>>>>>>>> http://www.ietf.org/mail- >> archive/web/tsvwg/current/msg11234.html >>>>>>>>>>>>=20 >>>>>>>>>>>> 2) Can you be clear here about what is actually been > said >> - >>>>>>>> because the point below seems to be a misunderstanding of >> language >>>>>>>> to me, and I hoped we did not claim this: >>>>>>>>>>>>=20 >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find > that >> Bob is >>>>>>>>>>>>>> actually ] saying that transport-layer should _only_ >> consider >>>>>>>>>>>>>> "congested bytes", not ] "congested packets". >>>>>>>>>>>>>> ] >>>>>>>>>>>>=20 >>>>>>>>>>>> 3) You'll need to post the updated draft and send a note >> to >>>>>>>> the group to confirm that the new version indeed concludes > the >>>>>>>> WGLC. I'll add a note to the writeup to indicate the draft >> content >>>>>>>> has been stable since Oct 2011. >>>>>>>>>>>>=20 >>>>>>>>>>>> Gorry (with my TSVWG Documnent Shepherd hat) >>>>>>>>>>>> cc: Co-Chairs for info. >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Gorry Fairhurst [ mailto:gorry@erg.abdn.ac.uk] >>>>>>>>>>>>>> Sent: Mittwoch, 15. August 2012 21:41 >>>>>>>>>>>>>> To: tsvwg chair >>>>>>>>>>>>>> Subject: Fwd: Re: [tsvwg] FYI: Document writeup for >>>>>>>>>>>>>> draft-ietf-tsvwg- byte-pkt-congest >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hi guys, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Apart form the usual rhetoric, there are some points >> here that we >>>>>>>>>>>>>> should note as chairs. What are you own thoughts? And >> was >>>>>>>>>>>>>> anything noted at the IETF in Vancouver concerning > this >> draft? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Gorry >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -------- Original Message -------- >>>>>>>>>>>>>> Subject: Re: [tsvwg] FYI: Document writeup for >>>>>>>>>>>>>> draft-ietf-tsvwg-byte- pkt-congest >>>>>>>>>>>>>> Date: Wed, 15 Aug 2012 15:07:28 -0400 >>>>>>>>>>>>>> From: John Leslie >>>>>>>>>>>>>> To: Gorry Fairhurst >>>>>>>>>>>>>> CC: tsvwg@ietf.org >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Gorry Fairhurst wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The following document has been revised after >> receiving >>>>>>>> WGLC comments. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The changes are mostly refreshing a document >> scheduled to >>>>>>>>>>>>>> expire this month. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> No issues were found: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Is that with WGC-hat-on? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Neither my issues nor Philip Eardley's comments were >> addressed. >>>>>>>>>>>>>> In fact, not even the changes Bob Briscoe mentioned > on- >> list have >>>>>>>>>>>>>> been included. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> As required by RFC 4858, this is the current template >> for the >>>>>>>>>>>>>> Document >>>>>>>>>>>>>>> Shepherd Write-Up. >>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>> (1) What type of RFC is being requested (BCP, > Proposed >> Standard, >>>>>>>>>>>>>>> Internet Standard, Informational, Experimental, or >> Historic)? >>>>>>>>>>>>>>> Why is this the proper type of RFC? Is this type of >> RFC >>>>>>>>>>>>>>> indicated in the title page header? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> This document is intended as BCP. (This was discussed >> at IETF-81 >>>>>>>>>>>>>>> and that the status changed from Informational to BCP >> since it >>>>>>>>>>>>>>> provides guidance to implementors and people >> configuring >>>>>>>> routers and hosts). >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Thank you for finally answering my question about > BCP >> status. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>> Working Group Summary >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> There was consensus to publish this as a WG document >> and >>>>>>>>>>>>>>> agreement at >>>>>>>>>>>>>>> IETF-82 that the document was now complete. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Was that reviewed on-list? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>> (3) Briefly describe the review of this document that >> was >>>>>>>>>>>>>>> performed >>>>>>>>>>>>>> by >>>>>>>>>>>>>>> the Document Shepherd. If this version of the > document >> is not >>>>>>>>>>>>>>> ready for publication, please explain why the > document >> is being >>>>>>>>>>>>>>> forwarded to the IESG. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The document was presented at IEWTF-82 (Taipei), with >> a request >>>>>>>>>>>>>>> for >>>>>>>>>>>>>> WGLC. >>>>>>>>>>>>>>> WGLC concluded with some discussion but no > substantive >> changes >>>>>>>>>>>>>>> on Friday 30th March 2012. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Yes, I guess that is true; but ignoring substantive >> comments >>>>>>>>>>>>>> isn't a good practice IMHO. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> (4) Does the document Shepherd have any concerns > about >> the depth >>>>>>>>>>>>>>> or breadth of the reviews that have been performed? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> No - the original draft had a lot of background >> material, much >>>>>>>>>>>>>>> of >>>>>>>>>>>>>> this >>>>>>>>>>>>>>> has been condensed or removed, resulting in a smaller >> document. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> That is indeed what I basically asked for, but I >> don't see any >>>>>>>>>>>>>> evidence of it: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> - diff(07,08) 48 lines changed or deleted; 53 lines >> changed or >>>>>>>> added >>>>>>>>>>>>>> - diff(06,07) 8 lines changed or deleted; 13 lines >> changed or >>>>>>>> added >>>>>>>>>>>>>> - diff(05,06) 64 lines changed or deleted; 69 lines >> changed or >>>>>>>>>>>>>> added >>>>>>>>>>>>>> - diff(04,05) 823 lines changed or deleted; 864 lines >> changed or >>>>>>>>>>>>>> added >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> (Need I go farther? That gets us back to March > 2011...) >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> (9) How solid is the WG consensus behind this >> document? Does it >>>>>>>>>>>>>>> represent the strong concurrence of a few > individuals, >> with >>>>>>>>>>>>>>> others being silent, or does the WG as a whole >> understand >>>>>>>> and agree with it? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The document has WG support and there is consensus to >> publish. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> This, IMHO, doesn't answer the question. :^( >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Does it represent the concurrence of a few >> individuals, or does >>>>>>>>>>>>>> the WG as a whole understand and agree with it? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> For reference, my comments included: >>>>>>>>>>>>>> ] >>>>>>>>>>>>>> ] When I previously skimmed this document, I believed >> it >>>>>>>>>>>>>> contained only ] common ground: that AQM should >> drop/mark packets >>>>>>>>>>>>>> without favoring small ] packets, and that to whatever >> extent >>>>>>>>>>>>>> packet size _is_ considered, that ] should be a >>>>>>>> transport-layer responsibility. >>>>>>>>>>>>>> ] >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find > that >> Bob is >>>>>>>>>>>>>> actually ] saying that transport-layer should _only_ >> consider >>>>>>>>>>>>>> "congested bytes", not ] "congested packets". >>>>>>>>>>>>>> ] >>>>>>>>>>>>>> ] In fact, Bob openly endorses replacing TCP >> congestion-control >>>>>>>>>>>>>> with an ] algorithm which calculates "fair-share > bytes" >> and >>>>>>>>>>>>>> doesn't back off at all ] (even in the presence of 20% >> packet >>>>>>>>>>>>>> loss) unless you're already sending ] more than this >>>>>>>> "fair-share". >>>>>>>>>>>>>> ] >>>>>>>>>>>>>> ] I do not believe that is the consensus of this > WG; >> and I >>>>>>>> believe >>>>>>>>>>>>>> if >>>>>>>>>>>>>> ] that were the consensus it would exceed our charter. >>>>>>>>>>>>>> ] >>>>>>>>>>>>>> ] The draft contains a number of things I _do_ > support; >> and I'd >>>>>>>>>>>>>> be happy ] to support a considerably shorter draft >> which >>>>>>>>>>>>>> concentrates on the AQM ] recommendation, omitting any >>>>>>>>>>>>>> suggestions of modifying TCP congestion ] control. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> and Philip's comments included: >>>>>>>>>>>>>> ] >>>>>>>>>>>>>> ] S2.2 I thought the numbered bullets could be better >> phrased, >>>>>>>>>>>>>> something like ] +this:- ] >>>>>>>>>>>>>> ] 1. AQM algorithms such as RED SHOULD use packet- >> mode >>>>>>>> drop, ie they >>>>>>>>>>>>>> SHOULD NOT >>>>>>>>>>>>>> ] +use byte-mode drop. The latter ] is more complex, >>>>>>>>>>>>>> ] it creates the perverse incentive to fragment >> segments >>>>>>>> into >>>>>>>>>>>>>> tiny >>>>>>>>>>>>>> ] pieces and it is vulnerable to floods of >> small- >>>>>>>>>>>>>> ] packets. >>>>>>>>>>>>>> ] >>>>>>>>>>>>>> ] 2. If a vendor has implemented byte-mode drop, >> and an >>>>>>>> operator >>>>>>>>>>>>>> has >>>>>>>>>>>>>> ] turned it on, it is RECOMMENDED to turn it >> off, after >>>>>>>>>>>>>> establishing if >>>>>>>>>>>>>> ] +there are any implications on >>>>>>>>>>>>>> ] the relative performance of >>>>>>>>>>>>>> ] applications using different packet sizes. >>>>>>>>>>>>>> ] >>>>>>>>>>>>>> ] 3. RED SHOULD NOT be turned off. Without RED, a >> drop tail >>>>>>>>>>>>>> ] queue biases against large packets. >>>>>>>>>>>>>> ] >>>>>>>>>>>>>> ] Nit - the following paragraph shouldn't be indented >> (Note well >>>>>>>>>>>>>> that >>>>>>>>>>>>>> RED's...) >>>>>>>>>>>>>> ] >>>>>>>>>>>>>> ] S3.3 >>>>>>>>>>>>>> ] The section could be slightly clearer. Starting with >> the second >>>>>>>>>>>>>> para, where you ] +start talking about something you >> don't >>>>>>>>>>>>>> recommend (ie you have to remember that ] +you're >> talking about >>>>>>>>>>>>>> the consequences of not following your > recommendation). >>>>>>>>>>>>>> ] >>>>>>>>>>>>>> ] S3.3 >>>>>>>>>>>>>> ] o Also, if the network biases congestion >> notification by >>>>>>>> packet >>>>>>>>>>>>>> size >>>>>>>>>>>>>> ] it has to assume a baseline packet size--all >> proposed >>>>>>>>>>>>>> algorithms >>>>>>>>>>>>>> ] use the local MTU. Then transports have to >> guess which >>>>>>>> link >>>>>>>>>>>>>> was >>>>>>>>>>>>>> ] congested and what its local MTU was, in order >> to know >>>>>>>> how to >>>>>>>>>>>>>> ] tailor their congestion response to that link. >>>>>>>>>>>>>> ] So you're saying that for byte-mode drop, the > network >> element >>>>>>>>>>>>>> has to compare the ] +size of the current pkt with the >> MTU, and >>>>>>>>>>>>>> if it's 25* smaller then reduce the ] +pkt loss >> probably by 25*? >>>>>>>>>>>>>> And if the MTU was bigger, then the current pkt would > ] >> +be >>>>>>>>>>>>>> dropped with greater probability? And both of these >> things >>>>>>>> are hard to do. >>>>>>>>>>>>>> ] >>>>>>>>>>>>>> ] S3.4 (& knock-on effect on 3.3) ] I think this could >> be better. >>>>>>>>>>>>>> ] I agree with your arguments in S3.1 & 3.2 that >> dropping or >>>>>>>>>>>>>> marking should be ] +independent of pkt size. >>>>>>>>>>>>>> ] You now go into a couple of pages, which I think >> could be >>>>>>>>>>>>>> boiled down to a ] +paragraph, saying something like:- >> ] * the >>>>>>>>>>>>>> overall system (network + transport) has to be packet- >> size >>>>>>>>>>>>>> dependent in ] >>>>>>>>>>>>>> +order to drive out the right amount of traffic so the >> resource >>>>>>>>>>>>>> becomes ] >>>>>>>>>>>>>> +uncongested (since we assume all resources are in >> practice byte >>>>>>>>>>>>>> +rather >>>>>>>>>>>>>> than ] +packet limited) ] * from S3.1 and S3.2 the > IETF >> is >>>>>>>>>>>>>> convinced that the network should notify ] > +independent >> of >>>>>>>> packet-size. >>>>>>>>>>>>>> ] * therefore the transport must act dependent on >> packet-size. >>>>>>>>>>>>>> ] >>>>>>>>>>>>>> ] It seems to me this is a necessary consequence of >> your earlier >>>>>>>>>>>>>> assumptions ] +/arguments. >>>>>>>>>>>>>> ] >>>>>>>>>>>>>> ] [On the other hand, if someone disagrees with the >> arguments and >>>>>>>>>>>>>> thinks that the ] +network should notify dependent on >>>>>>>>>>>>>> packet-size, then it follows that the ] +transport can >> act >>>>>>>>>>>>>> independent of >>>>>>>>>>>>>> packet- size.] ] ] I think in S3.3 you're trying to >> make another >>>>>>>>>>>>>> argument (?):- ] * we can either do packet-size >> biasing in the >>>>>>>>>>>>>> network element or on the end host ] +transport (see >> argument >>>>>>>>>>>>>> above) ] * packet-size biasing in the network is quite >> tricky, >>>>>>>>>>>>>> because then both the ] +network element & the >> transport have to >>>>>>>>>>>>>> make some guesses about MTU - whereas ] >>>>>>>>>>>>>> +with packet-size biasing in the transport, neither >> network >>>>>>>>>>>>>> +element >>>>>>>>>>>>>> nor ] +transport needs to know what the MTU is. >>>>>>>>>>>>>> ] * it is also easier to implement packet-size biasing >> in the >>>>>>>>>>>>>> transport than in ] +the network. >>>>>>>>>>>>>> ] >>>>>>>>>>>>>> ] On the last bullet, I didn't really follow your >> argument in >>>>>>>> S3.5. >>>>>>>>>>>>>> Might be ] +easier to follow if S3.5 also talked about >> how a >>>>>>>>>>>>>> network element would take ] +account of pkt size? >> Also, does the >>>>>>>>>>>>>> following argument also apply?: >>>>>>>>>>>>>> ] * if pkt-size biasing is done in the transport, then >> the work >>>>>>>>>>>>>> (to do the ] +biasing) is spread over many end hosts, > ] >> * whereas >>>>>>>>>>>>>> if pkt-size biasing is done in the network, then the >> work is ] >>>>>>>>>>>>>> +concentrated in just the congested network element, >> which has to >>>>>>>>>>>>>> operate on all ] +the traffic at line speed. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> (Has there perhaps been some confusion about what >> went into the >>>>>>>>>>>>>> -08 >>>>>>>>>>>>>> version?) >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> John Leslie >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >> ________________________________________________________________ >>>>>>>>>>> Bob Briscoe, BT Innovate & >> Design >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >> ________________________________________________________________ >>>>>>> Bob Briscoe, BT Innovate & >> Design >>>>>>>=20 >>>>>=20 >>>>> ________________________________________________________________ >>>>> Bob Briscoe, BT Innovate & Design >>>=20 >>> ________________________________________________________________ >>> Bob Briscoe, BT Innovate & Design >=20 From hannes.tschofenig@nsn.com Thu Oct 11 05:57:55 2012 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 4BBFF11E809A; Thu, 11 Oct 2012 05:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.548 X-Spam-Level: X-Spam-Status: No, score=-105.548 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNWu5RsPJh8s; Thu, 11 Oct 2012 05:57:52 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6631F21F8779; Thu, 11 Oct 2012 05:57:51 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q9BCvmSD024014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Oct 2012 14:57:48 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q9BCvinv004533; Thu, 11 Oct 2012 14:57:47 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Oct 2012 14:57:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Oct 2012 15:57:43 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D01F360F7@FIESEXC035.nsn-intra.net> In-Reply-To: <3A5279D338C75C40B4B3DA15BA47D6330B6FD197@EXMDB04.org.aalto.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest Thread-Index: AQHNp64+FkrAkabfCEaD1jzPlkv4fJez3BoAgAAzNaA= References: <20120815190728.GQ15012@verdi> <502BFB47.7010803@erg.abdn.ac.uk><791AD3077F94194BB2BDD13565B6295D45A6212A@PALLENE.office.hd><15181_1346848013_5047450C_15181_645_1_50474507.3090706@erg.abdn.ac.uk><3A5279D338C75C40B4B3DA15BA47D6330B616BD2@EXMDB04.org.aalto.fi><201209051541.q85FfCs0019699@bagheera.jungle.bt.co.uk><9510D26531EF184D9017DF24659BB87F33D793B351@EMV65-UKRD.domain1.systemhost.net><3A5279D338C75C40B4B3DA15BA47D6330B69261A@EXMDB04.org.aalto.fi><9510D26531EF184D9017DF24659BB87F33D793B845@EMV65-UKRD.domain1.systemhost.net><04AC95B5-A2B1-4DD2-B765-E20A4C1A69A3@aalto.fi><3A5279D338C75C40B4B3DA15BA47D6330B6E81E4@EXMDB04.org.aalto.fi><9510D26531EF184D9017DF24659BB87F33DCE34251@EMV65-UKRD.domain1.systemhost.net><201210041126.q94BQ0hx002951@bagheera.jungle.bt.co.uk><1904eec816d080f886f5bf8685358ddc.squirrel@www.erg.abdn.ac.uk><201210101525.q9AFP4Mi008013@bagheera.jungle.bt.co.uk><3A5279D338C75C40B4B3DA15BA47D6330B6FC2BB@EXMDB04.org.aalto.fi><201210111208.q9BC8BAU012! ! 305@bag he era.jungl e.b t.co.uk> <3A5279D338C75C40B4B3DA15BA47D6330B6FD072@EXMDB04.org.aalto.fi> <999913AB42CC9341B05A99BBF358718D01F360CF@FIESEXC035.nsn-intra.net> <3A5279D338C75C40B4B3DA15BA47D6330B6FD197@EXMDB04.org.aalto.fi> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Manner Jukka" X-OriginalArrivalTime: 11 Oct 2012 12:57:45.0354 (UTC) FILETIME=[02046EA0:01CDA7B0] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 47886 X-purgate-ID: 151667::1349960268-000048BF-4504CB00/0-0/0-0 Cc: gorry@erg.abdn.ac.uk, philip.eardley@bt.com, tsvwg IETF list , tsvwg-chairs@ietf.org Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest 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, 11 Oct 2012 12:57:55 -0000 Hi Jukka,=20 With QoS there is no such thing as "short term" (as we already had to learn painfully).=20 That makes me wonder what is more useful: publish a document that describe how to configure RED correctly or to go for an AQM technique that (according to the authors) works almost zero configuration.=20 My take-away from the Vancouver congestion control workshop was that it is better to ignore RED. (Maybe my impression was wrong -- someone else should confirm.)=20 Ciao Hannes > -----Original Message----- > From: ext Manner Jukka [mailto:jukka.manner@aalto.fi] > Sent: Thursday, October 11, 2012 3:50 PM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: Bob Briscoe; ; ; > ; tsvwg IETF list > Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf- > tsvwg-byte-pkt-congest >=20 > Hi, this document talks about the current and short term goals and > operations, while AFAIK CoDel is a more futuristic concept, interesting > concept, sure, but not deployed at large. >=20 > cheers, > Jukka >=20 > On Oct 11, 2012, at 3:44 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >=20 > > Hi Jukka, Hi Bob, > > > > having listened to the presentations about CoDel I am wondering > whether > > this document may have taken over by events and is obsolete by now. > > What's your view on that? > > > > Ciao > > Hannes > > > > > >> -----Original Message----- > >> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On > Behalf > >> Of ext Manner Jukka > >> Sent: Thursday, October 11, 2012 3:34 PM > >> To: Bob Briscoe > >> Cc: ; ; >> chairs@ietf.org>; tsvwg IETF list > >> Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf- > >> tsvwg-byte-pkt-congest > >> > >> Hi, > >> > >> Yeah, please at the point about cheap devices, still, I wonder what > > the > >> cost of AQM is on those devices. Maybe 1 cnt in mass production? > Thus, > >> I still wonder if it is worth arguing something about the future > that > >> strongly. > >> > >> Sorry, but the same goes for AQM in general, and where it is, or > will > >> not be deployed. I understand technical reasons why not something is > >> feasible, but business or monetary reasons can change very quickly. > ;) > >> > >> Jukka > >> > >> On Oct 11, 2012, at 3:08 PM, Bob Briscoe wrote: > >> > >>> Jukka, > >>> > >>> What I had in mind is all low level buffers in cheap pure L2 > > devices, > >> in cheap NATs etc. I was going to list some of these, but instead > > chose > >> to say "no-one expects AQM to be universally deployed". This clearly > >> missed the mark. > >>> > >>> Should we include some of these concrete examples of where AQM > won't > >> be deployed instead? > >>> > >>> [I've cc'd the list, given we're starting to wordsmith > significantly > >> new text added since WG last call.] > >>> > >>> > >>> Bob > >>> > >>> At 20:04 10/10/2012, Manner Jukka wrote: > >>>> Hi, looked good to me. Just one comment, I wouldn't put that much > >> emphasis on what is a probably state of things, e.g. > >>>> > >>>> "no-one expects AQM to ever be .." > in the future it might, we > >> don't know, and since the paragraph says that it doesn't matter > > anyway, > >> I would formulate this paragraph a bit towards that we have partial > >> deployment now and even with a full deployment, ... > >>>> > >>>> and similarly with the unrealistic deployment of AQM in the > >> subsequent paragraph. > >>>> > >>>> cheers, > >>>> Jukka > >>>> > >>>> On Oct 10, 2012, at 6:25 PM, Bob Briscoe wrote: > >>>> > >>>>> Phil, > >>>>> > >>>>> Sorry for delay, my round-robin scheduler is taking so long to > > get > >> round all the tasks that I keep finding dead robins (that reminds me > > of > >> a bike ride my grandmother took. On her return, she said there were > a > >> worryingly large number of robins run over on the roads. It turned > out > >> that she had been going round the same small triangle of roads > > multiple > >> times). > >>>>> > >>>>> I've done a complete re-write of 3.4. I hope you will agree that > >> it really is a motivating argument now and it can stay where it is - > > it > >> is not just a preamble. > >>>>> > >>>>> I've gone back to the very first version of 3.4 I wrote and I now > >> realise that I had written the core of the argument so badly that > even > >> I forgot what it was meant to say when we started editing it. In the > >> draft-08 version, the original meaning is lost and in your re- > wording > >> it is entirely lost. The link with the draft-08 version is nearly > >> unrecognisable, but it's the argument I intended here. > >>>>> > >>>>> > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> 3.4. Permanent Partial Deployment of AQM > >>>>> > >>>>> In overview, the argument in this section runs as follows: > >>>>> * Because the network will not and cannot always drop packets in > >> proportion to their size, it shouldn't be given the task of making > > drop > >> signals depend on packet size at all. > >>>>> * Transports on the other hand don't always want to make their > >> rate response proportional to the size of dropped packets, but if > they > >> want to, they always can. > >>>>> > >>>>> The argument is similar to the end-to-end argument that says > >> "Don't do X in the network if end-systems can do X by themselves, > and > >> they want to be able to choose whether to do X anyway." Actually the > >> following argument is stronger; in addition it says "Don't give the > >> network task X that could be done by the end-systems, if X won't > ever > >> be deployed on all network nodes, and end-systems won't be able to > > tell > >> whether their network is doing X, or whether they need to do X > >> themselves." In this case, the X in question is "making the response > > to > >> congestion depend on packet size". > >>>>> > >>>>> We will now re-run this argument taking each step in more depth. > >> The argument applies solely to drop, not ECN marking. > >>>>> > >>>>> A queue drops packets for either of two reasons: a) to signal to > >> host congestion controls that they should reduce the load and b) > >> because there is no buffer left to store the packets. Active queue > >> management tries to use drops as a signal for hosts to slow down > (case > >> a) so that drop due to buffer exhaustion (case b) should not be > >> necessary. > >>>>> > >>>>> No-one expects AQM to ever be universally deployed in every queue > >> in the Internet; and, even if AQM were universal, it has to be able > to > >> cope with buffer exhaustion (by switching to a behaviour like tail- > >> drop), in order to cope with unresponsive or excessive transports. > >> Therefore networks will often be dropping packets as a last resort > >> (case b) rather than under AQM control (case a). > >>>>> > >>>>> When buffers are exhausted (case b), they don't naturally drop > >> packets in proportion to their size. The network can only reduce the > >> probability of dropping smaller packets if it has enough space to > > store > >> them somewhere while it waits for a larger packet that it can drop. > If > >> the buffer is exhausted, it does not have this choice. Admittedly > > tail- > >> drop does naturally drop somewhat fewer small packets, but exactly > how > >> few depends more on the mix of sizes than the size of the packet in > >> question. Nonetheless, in general, if we wanted networks to do size- > >> dependent drop, we would need universal deployment of (packet-size > >> dependent) AQM code, which is unrealistic. > >>>>> > >>>>> A host transport cannot know whether any particular drop was a > >> deliberate signal from an AQM or a sign of a queue shedding packets > > due > >> to buffer exhaustion. Therefore, because the network cannot > > universally > >> do size-dependent drop, it should not do it all. > >>>>> > >>>>> Whereas universality is desirable in the network, diversity is > >> desirable between different transport layer protocols - some, like > >> NewReno TCP [RFC5681], may not choose to make their rate response > >> proportionate to the size of each dropped packet, while others will > >> (e.g. TFRC-SP [RFC4828]). > >>>>> > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Bob > >>>>> > >>>>> At 13:13 04/10/2012, gorry@erg.abdn.ac.uk wrote: > >>>>>> That would be brilliant! > >>>>>> > >>>>>> Gorry > >>>>>> > >>>>>>> Will try to look at this later today. > >>>>>>> > >>>>>>> > >>>>>>> Bob > >>>>>>> > >>>>>>> At 10:42 02/10/2012, philip.eardley@bt.com wrote: > >>>>>>>> Think the token is with bob > >>>>>>>> > >>>>>>>> Re your comment - yes, I think you could move 3.4 to the end > > of > >> S3 - > >>>>>>>> or to the start - and do some re-phrasing, maybe something > > like > >> I tried. > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Manner Jukka [mailto:jukka.manner@aalto.fi] > >>>>>>>> Sent: 01 October 2012 20:18 > >>>>>>>> To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,Bob,DUB8 R > >>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst > >>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for > >>>>>>>> draft-ietf-tsvwg-byte-pkt-congest > >>>>>>>> > >>>>>>>> Phil, Bob, can we close this finally? It's three weeks now > >> since > >>>>>>>> this previous message. > >>>>>>>> > >>>>>>>> Jukka > >>>>>>>> > >>>>>>>> On Sep 10, 2012, at 4:42 PM, Jukka Manner wrote: > >>>>>>>> > >>>>>>>>> Ack, I'm getting there...;) > >>>>>>>>> > >>>>>>>>> So, we could move 3.4 at the end of Section 3 and rephrase > >> it to > >>>>>>>> not talk about scaling per se, but rather about how Req 2.2 > >>>>>>>> eventually leads to Req 2.3? > >>>>>>>>> > >>>>>>>>> Jukka > >>>>>>>>> > >>>>>>>>> On Sep 7, 2012, at 4:07 PM, > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> 3.4 is, in my mind, completely different from 3.1, 3.2, > > 3.3 > >> and 3.5. > >>>>>>>>>> > >>>>>>>>>> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for > >> Recommendation > >>>>>>>>>> 2.2 & a lesser extent 2.3 > >>>>>>>>>> 3.4 makes doesn't make a motivating argument - it explains > >> that Rec > >>>>>>>>>> 2.2 & 2.3 come as a pair (if you recommend one, then > >> inevitably you > >>>>>>>>>> recommend the other) (delta some politeness about TCP) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Manner Jukka [mailto:jukka.manner@aalto.fi] > >>>>>>>>>> Sent: 07 September 2012 13:24 > >>>>>>>>>> To: Eardley,PL,Philip,DUB8 R > >>>>>>>>>> Cc: Briscoe,RJ,Bob,DUB8 R; ; > >>>>>>>>>> > >>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for > >>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest > >>>>>>>>>> > >>>>>>>>>> Hi, I'm trying to follow your reasoning, with little luck. > >> ;) > >>>>>>>>>> > >>>>>>>>>> After having read Section 3 again, I could think of a few > >>>>>>>> updates, but I'm not fully following what you want to see: > >>>>>>>>>> > >>>>>>>>>> - S3.5 is kind of small and lonely by itself. It could be > >> either > >>>>>>>> longer or merged somewhere. Not a major issue though and > > could > >> remain as > >>>>>>>> is. > >>>>>>>>>> > >>>>>>>>>> - S3.3: Yes, probably could be turned upside down, good > >> first, > >>>>>>>> bad later. Don't have a strong opinion. > >>>>>>>>>> > >>>>>>>>>> - S3.4: Here the scaling is used many times and in the > >> title, > >>>>>>>> although we talk about the end host side. This could be > >> rephrased > >>>>>>>> and slightly reworded to talk about hosts and their operation > >>>>>>>> altogether. Also the word scaling can turn the readers > >> expectation > >>>>>>>> into the wrong direction. > >>>>>>>>>> > >>>>>>>>>> - S3 altogether: It would help to have introductory text > >> about > >>>>>>>> networks vs. end host side, but I fail to see why (& how) to > >>>>>>>> restructure everything. > >>>>>>>>>> > >>>>>>>>>> cheers, > >>>>>>>>>> Jukka > >>>>>>>>>> > >>>>>>>>>> On Sep 6, 2012, at 6:18 PM, > >>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Ps otherwise Bob's comments are fine, though I suggest > > for > >> S3.5 you > >>>>>>>>>>> give more context (ie are you knocking down what you > >> recommend > >>>>>>>>>>> against, or building up what you recommend?) and in S3.3 > >> think > >>>>>>>>>>> would be better if you re-structured slightly [first talk > >> about what > >>>>>>>>>>> you like - penult para + 1st sentence of last para - then > >> talk about > >>>>>>>>>>> what you don't like - rest of text] > >>>>>>>>>>> > >>>>>>>>>>> From: Eardley,PL,Philip,DUB8 R > >>>>>>>>>>> Sent: 06 September 2012 16:12 > >>>>>>>>>>> To: Briscoe,RJ,Bob,DUB8 R; Manner Jukka > >>>>>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst > >>>>>>>>>>> Subject: RE: [REVISED I-D]: Document writeup for > >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest > >>>>>>>>>>> > >>>>>>>>>>> Thanks bob. Have now re-booted some state. > >>>>>>>>>>> I don't like S3.4. My basic problem with it is that it > >> isn't a > >>>>>>>> "motivating argument" (S3 title). It's an explanation about > >> the > >>>>>>>> consequences of assuming either [option 1] do pkt-size > > biasing > >> in > >>>>>>>> the transport; [option 2]; do pkt-size biasing in the nw. > >>>>>>>>>>> Perhaps your effort to buy peace with those who won't > >> change > >>>>>>>> TCP has obfuscated the basic point? > >>>>>>>>>>> The title of S3.4 (Scaling...) and the early text > > "scaling > >>>>>>>> argument" suggests that you're going to argue there is some > >> reason > >>>>>>>> why X scales as order N rather than N^2 or something like > > that > >> - > >>>>>>>> which isn't what S3.4 is about. > >>>>>>>>>>> > >>>>>>>>>>> I actually think it would be better to put S3.4 at the > >> start of > >>>>>>>> S3 - it's background where you say there are 2 options. After > >> that, > >>>>>>>> you can explain the reasons why option 1 [pkt biasing in the > >>>>>>>> transport] is better - the reasons being:- S3.1 (security > > etc > >>>>>>>> attacks if small pkts get preferential treatment), S3.2 > >> (really a > >>>>>>>> side note to S3.1; ie doesn't really present a "motivating > >>>>>>>> argument"), S3.3 (nw guessing MTU vs transport knowing pkt > >> size), > >>>>>>>> S3.5 (easier implementation). > >>>>>>>>>>> > >>>>>>>>>>> Something like... > >>>>>>>>>>> The behaviour of the network and transport together needs > >> to > >>>>>>>>>>> alleviate congestion. We assume the network is bit- > >> congestible > >>>>>>>> (currently packet-congestible resources are rate). Therefore > >>>>>>>> overall the response of the {network + transport} should be > >> the > >>>>>>>> same for the same congestion - whether the congestion is > >> caused by > >>>>>>>> a lot of small packets or a smaller number of larger packets. > >> The > >>>>>>>> implication is that the transport's behaviour should depend > > on > >>>>>>>> whether the network takes account (or not) of packet size > > when > >> it > >>>>>>>> generates congestion indications:- Case 1: If the network > >>>>>>>> implements packet-mode drop, ie its algorithm treats all > >> packets > >>>>>>>> equally regardless of their size, then the transport should > >> take > >>>>>>>> account of the size of the packet - in other words, the > >> transport's > >>>>>>>> congestion response should depend on the number of dropped > >> bytes. > >>>>>>>>>>> Case 2: If the network implements byte-mode drop, ie its > >>>>>>>> algorithm treats packets differently depending on their size, > >> then > >>>>>>>> the transport should not take account of the size of the > >> packet - > >>>>>>>> in other words, the transport's congestion response should > >> depend > >>>>>>>> on the number of dropped packets. > >>>>>>>>>>> > >>>>>>>>>>> These cases are explained in more detail in sub-section > >> below. > >>>>>>>>>>> > >>>>>>>>>>> In both cases the same discussion applies if packets are > >>>>>>>> ECN-marked rather than dropped. > >>>>>>>>>>> In the following sections we explain why Case 1 is > >> preferable, > >>>>>>>> and hence why we make the Recommendations of S2.2 and S3.3 > >>>>>>>> (respectively, drop/mark pkts equally regardless of their > >> size, and > >>>>>>>> the strength of the transport's response should be > >> proportionate to > >>>>>>>> the size of the dropped/marked pkt). > >>>>>>>>>>> Note that TCP responds to dropped or marked packets, > > which > >> differs > >>>>>>>>>>> from our recommendation for transports. However, we are > >> not > >>>>>>>>>>> recommending that TCP should be changed; to date it > >> hasn't been a > >>>>>>>>>>> significant problem because most TCP implementations > > have > >> been > >>>>>>>> used with similar packet sizes. But we do recommend that > >> future > >>>>>>>> transport protocols should respond to dropped or marked > > bytes > >> (as > >>>>>>>> for example TFRC-SP [RFC4828]effectively does). > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Sub-section > >>>>>>>>>>> You could use much of S3.3, I suggest supplement with > >> numerical > >>>>>>>>>>> examples continuing S1.2 > >>>>>>>>>>> -- > >>>>>>>>>>> << This gives a get-out clause to any transport that > > isn't > >>>>>>>>>>> packet-size dependent (e.g. current TCP). Lacking packet- > >> size > >>>>>>>>>>> dependence just means they don't scale correctly with > >> packet size - > >>>>>>>>>>> but they are at liberty not to scale with packet size > >> (particularly > >>>>>>>>>>> given MTU growth isn't often being used to increase link > >> rates at > >>>>>>>>>>> this stage in history).>> > >>>>>>>>>>> > >>>>>>>>>>> This is introducing a different point. it's saying that > >> your > >>>>>>>> recommendation 2 [drop/mark pkts equally regardless of their > >> size] > >>>>>>>> is a really strong reco whilst recommendation 3 [strength of > >>>>>>>> transport's response proportionate to the size of the > >>>>>>>> dropped/marked pkt] is a much less important reco. I can see > >> this > >>>>>>>> might be true, but I don't think the i-d talks about this. > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> > >>>>>>>>>>> From: Briscoe,RJ,Bob,DUB8 R > >>>>>>>>>>> Sent: 05 September 2012 16:41 > >>>>>>>>>>> To: Manner Jukka > >>>>>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst; > >> Eardley,PL,Philip,DUB8 R > >>>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for > >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest > >>>>>>>>>>> > >>>>>>>>>>> Jukka, > >>>>>>>>>>> > >>>>>>>>>>> I've repeated Phil's suggestions as quoted email then > > made > >> some > >>>>>>>> alterations. > >>>>>>>>>>> > >>>>>>>>>>> Phil asked me to send this, then he will think about it. > >>>>>>>>>>> > >>>>>>>>>>> I'll respond about John Leslie's argument next... > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> 2.2. Recommendation on Encoding Congestion Notification > >>>>>>>>>>> > >>>>>>>>>>> [...] > >>>>>>>>>>> > >>>>>>>>>>> 1. AQM algorithms such as RED SHOULD use packet-mode > >> drop, ie they > >>>>>>>>>>> SHOULD NOT use byte-mode drop. The latter is more > >> complex, > >>>>>>>>>>> it creates the perverse incentive to fragment > >> segments into > >>>>>>>> tiny > >>>>>>>>>>> pieces and it is vulnerable to floods of small > >> packets. > >>>>>>>>>>> > >>>>>>>>>>> 2. If a vendor has implemented byte-mode drop, and an > >> operator has > >>>>>>>>>>> turned it on, it is RECOMMENDED to turn it off, > > after > >>>>>>>> establishing > >>>>>>>>>>> if there are any implications on the relative > >> performance of > >>>>>>>>>>> applications using different packet sizes. > >>>>>>>>>>> > >>>>>>>>>>> RED as a whole SHOULD NOT be turned off. Without > > RED, > >> a drop > >>>>>>>> tail > >>>>>>>>>>> queue biases against large packets > >>>>>>>>>>> > >>>>>>>>>>> [BB adds]: and it is > >> vulnerable to > >>>>>>>> floods > >>>>>>>>>>> of small-packets. > >>>>>>>>>>> > >>>>>>>>>>> (I suggest the last para just qualifies item 2. It > > doesn't > >> warrant > >>>>>>>>>>> another item number.) > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> [PE:] S3.3 > >>>>>>>>>>> The section could be slightly clearer. Starting with the > >> second > >>>>>>>> para, where you start talking about something you don't > >> recommend > >>>>>>>> (ie you have to remember that you're talking about the > >> consequences > >>>>>>>> of not following your recommendation). > >>>>>>>>>>> > >>>>>>>>>>> 3.3 Transport-Independent Network > >>>>>>>>>>> > >>>>>>>>>>> TCP congestion control ensures that flows competing for > >> the same > >>>>>>>>>>> resource each maintain the same number of segments in > >> flight, > >>>>>>>>>>> irrespective of segment size. So under similar > >> conditions, flows > >>>>>>>>>>> with different segment sizes will get different > > bit-rates. > >>>>>>>>>>> > >>>>>>>>>>> [OLD:] > >>>>>>>>>>> One motivation for the network biasing congestion > >> notification by > >>>>>>>>>>> packet size is to counter this effect and try to equalise > >> the bit- > >>>>>>>>>>> rates of flows with different packet sizes. > >>>>>>>>>>> [SUGGESTED:] > >>>>>>>>>>> To counter this effect it seems tempting not to follow > >> our > >>>>>>>>>>> recommendation, and instead for the network to bias > >> congestion > >>>>>>>>>>> notification by packet size in order to equalise the > > bit- > >> rates of > >>>>>>>>>>> flows with different packet sizes. > >>>>>>>>>>> [CONTINUE AS BEFORE:] > >>>>>>>>>>> However, in order to do this, the queuing > >> algorithm > >>>>>>>>>>> has to make assumptions about the transport, which > > become > >> embedded > >>>>>>>>>>> in the network. Specifically: > >>>>>>>>>>> [...] > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> S3.3 > >>>>>>>>>>> o The queuing algorithm has to assume how aggressively > >> the > >>>>>>>> transport > >>>>>>>>>>> will respond to congestion (see Section 4.2.4). If > >> the network > >>>>>>>>>>> assumes the transport responds as aggressively as TCP > >> NewReno, > >>>>>>>> it > >>>>>>>>>>> will be wrong for Compound TCP and differently wrong > >> for Cubic > >>>>>>>>>>> TCP, etc. To achieve equal bit-rates, each transport > >> then has > >>>>>>>> to > >>>>>>>>>>> guess what assumption the network made, and work out > >> how to > >>>>>>>>>>> replace this assumed aggressiveness with its own > >> aggressiveness. > >>>>>>>>>>> o Also, if the network biases congestion notification > > by > >> packet > >>>>>>>> size > >>>>>>>>>>> it has to assume a baseline packet size--all proposed > >> algorithms > >>>>>>>>>>> use the local MTU. Then transports have to guess > >> which link was > >>>>>>>>>>> congested and what its local MTU was, in order to > > know > >> how to > >>>>>>>>>>> tailor their congestion response to that link. > >>>>>>>>>>> > >>>>>>>>>>> So you're saying that for byte-mode drop, the network > >> element > >>>>>>>> has to compare the size of the current pkt with the MTU, and > >> if > >>>>>>>> it's 25* smaller then reduce the pkt loss probably by 25*? > > And > >> if > >>>>>>>> the MTU was bigger, then the current pkt would be dropped > > with > >>>>>>>> greater probability? And both of these things are hard to do. > >>>>>>>>>>> > >>>>>>>>>>> [BB]: SUGGESTED REPLACEMENT to 2nd bullet: > >>>>>>>>>>> > >>>>>>>>>>> o Also, if the network biases congestion notification > > by > >> packet > >>>>>>>> size > >>>>>>>>>>> it has to assume a baseline packet size--all proposed > >> algorithms > >>>>>>>>>>> use the local MTU (for example see the byte-mode loss > >>>>>>>> probability > >>>>>>>>>>> formula in Table 1). Then if the non-Reno transports > >> mentioned > >>>>>>>> above > >>>>>>>>>>> are trying to reverse engineer what the network > >> assumed, they > >>>>>>>> also > >>>>>>>>>>> have to guess the MTU of the congested link. > >>>>>>>>>>> > >>>>>>>>>>> [Aside for Phil: The byte-mode algo uses MTU as its > >> baseline because > >>>>>>>>>>> a link cannot send a packet bigger than its MTU so the > >> algo won't > >>>>>>>>>>> ever give a drop probability >1).] > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> S3.4 (& knock-on effect on 3.3) > >>>>>>>>>>> I think this could be better. > >>>>>>>>>>> I agree with your arguments in S3.1 & 3.2 that dropping > > or > >>>>>>>> marking should be independent of pkt size. > >>>>>>>>>>> You now go into a couple of pages, which I think could be > >> boiled > >>>>>>>>>>> down to a paragraph, saying something like:- > >>>>>>>>>>> * the overall system (network + transport) has to be > >> packet-size > >>>>>>>>>>> dependent in order to drive out the right amount of > >> traffic so the > >>>>>>>>>>> resource becomes uncongested (since we assume all > >> resources are in > >>>>>>>>>>> practice byte rather than packet limited) > >>>>>>>>>>> * from S3.1 and S3.2 the IETF is convinced that the > >> network > >>>>>>>> should notify independent of packet-size. > >>>>>>>>>>> * therefore the transport must act dependent on packet- > >> size. > >>>>>>>>>>> > >>>>>>>>>>> It seems to me this is a necessary consequence of your > >> earlier > >>>>>>>> assumptions /arguments. > >>>>>>>>>>> > >>>>>>>>>>> [BB:] This isn't at all obvious. Until I worked it > >> through, it > >>>>>>>> wasn't obvious to me. I think it needs to be spelled out. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> [On the other hand, if someone disagrees with the > >> arguments and > >>>>>>>>>>> thinks that the network should notify dependent on > > packet- > >> size, then > >>>>>>>>>>> it follows that the transport can act independent of > >> packet-size.] > >>>>>>>>>>> > >>>>>>>>>>> I think in S3.3 you're trying to make another argument > >> (?):- > >>>>>>>>>>> * we can either do packet-size biasing in the network > >> element or on > >>>>>>>>>>> the end host transport (see argument above) > >>>>>>>>>>> * packet-size biasing in the network is quite tricky, > >> because > >>>>>>>> then both the network element & the transport have to make > >> some > >>>>>>>> guesses about MTU - whereas with packet-size biasing in the > >>>>>>>> transport, neither network element nor transport needs to > > know > >> what the > >>>>>>>> MTU is. > >>>>>>>>>>> * it is also easier to implement packet-size biasing in > >> the > >>>>>>>> transport than in the network. > >>>>>>>>>>> > >>>>>>>>>>> [BB] ...and all the other arguments about vulnerability > > to > >>>>>>>> flooding etc, transport-independence etc. > >>>>>>>>>>> > >>>>>>>>>>> Our argument is sort of like how Phil summarises it, but > >> with > >>>>>>>> an added nuance. It's also saying no-one has to do > > packet-size > >>>>>>>> biasing anyway. It's not saying "The transport should given > >> the > >>>>>>>> network shouldn't". It's saying "*If the transport wants to > >> claim > >>>>>>>> to be scalable wrt packet size* it should if the network > >> shouldn't". > >>>>>>>>>>> > >>>>>>>>>>> This gives a get-out clause to any transport that isn't > >>>>>>>> packet-size dependent (e.g. current TCP). Lacking packet-size > >>>>>>>> dependence just means they don't scale correctly with packet > >> size - > >>>>>>>> but they are at liberty not to scale with packet size > >> (particularly > >>>>>>>> given MTU growth isn't often being used to increase link > > rates > >> at > >>>>>>>> this stage in history). > >>>>>>>>>>> > >>>>>>>>>>> None of what Phil says convinces me we could say 3.4 (or > >> 3.3) > >>>>>>>> any more briefly or differently. It's easier to summarise > > what > >> you > >>>>>>>> understand having read something. But that's not the same as > >>>>>>>> writing the thing that helped you understand. There doesn't > >> seem to > >>>>>>>> be any argument for why anything needs to be changed, so I'm > >> going > >>>>>>>> to leave it as is, unless pushed. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On the last bullet, I didn't really follow your argument > >> in > >>>>>>>> S3.5. Might be easier to follow if S3.5 also talked about how > >> a > >>>>>>>> network element would take account of pkt size? > >>>>>>>>>>> Also, does the following argument also apply?: > >>>>>>>>>>> * if pkt-size biasing is done in the transport, then the > >> work (to do > >>>>>>>>>>> the biasing) is spread over many end hosts, > >>>>>>>>>>> * whereas if pkt-size biasing is done in the network, > > then > >> the > >>>>>>>> work is concentrated in just the congested network element, > >> which > >>>>>>>> has to operate on all the traffic at line speed. > >>>>>>>>>>> > >>>>>>>>>>> [BB]: 3.5. Implementation Efficiency > >>>>>>>>>>> > >>>>>>>>>>> [ADD:] > >>>>>>>>>>> Biasing against large packets typically requires an > > extra > >> multiply > >>>>>>>>>>> and divide in the network (see the example byte-mode > > drop > >>>>>>>> formula in table 1). > >>>>>>>>>>> [CONTINUE AS BEFORE:] > >>>>>>>>>>> Allowing for packet size at the transport rather than in > >> the > >>>>>>>>>>> network ensures that neither the network nor the > >> transport needs to > >>>>>>>>>>> do a multiply operation--multiplication by packet size > > is > >>>>>>>>>>> effectively achieved as a repeated add when the > > transport > >> adds to > >>>>>>>>>>> its count of marked bytes as each congestion event is > > fed > >> to it. > >>>>>>>>>>> [ADD:] > >>>>>>>>>>> Also the work to do the biasing is spread over many > >> hosts, rather > >>>>>>>>>>> than concentrated in just the congested network element. > >>>>>>>>>>> [CONTINUE AS BEFORE:] > >>>>>>>>>>> > > These > >> aren't > >>>>>>>>>>> principled reasons in themselves, but they are a happy > >> consequence > >>>>>>>>>>> of the other principled reasons. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Bob > >>>>>>>>>>> > >>>>>>>>>>> At 13:36 05/09/2012, Manner Jukka wrote: > >>>>>>>>>>> > >>>>>>>>>>> Hi Bob, > >>>>>>>>>>> > >>>>>>>>>>> Since Phil is your colleague at BT, even at Ipswich (?), > >> can > >>>>>>>> you check those and agree with Phil how to go forward? Some > > of > >>>>>>>> those are clear, others need discussion with Phil. > >>>>>>>>>>> > >>>>>>>>>>> Gorry, on point 2) below, I don't follow Leslie's > >> arguments. I > >>>>>>>> asked from him detailed comments and resolutions months ago, > >> and nothing > >>>>>>>> came. > >>>>>>>>>>> > >>>>>>>>>>> cheers, > >>>>>>>>>>> Jukka > >>>>>>>>>>> > >>>>>>>>>>> On Sep 5, 2012, at 3:26 PM, Gorry Fairhurst wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Bob and Jukka, > >>>>>>>>>>>> > >>>>>>>>>>>> I think I need your help to resolve this... Some of the > >>>>>>>> comments raised by John Leslie appear to have substance, and > >> I'm > >>>>>>>> not sure what you plan to do to address these. > >>>>>>>>>>>> > >>>>>>>>>>>> It would be good to do something quick so that I can > >> complete > >>>>>>>> the submission to the IESG. > >>>>>>>>>>>> > >>>>>>>>>>>> The issues I particularly note are: > >>>>>>>>>>>> > >>>>>>>>>>>> 1) This contribution from Phil appears to be within > > scope > >> and > >>>>>>>> it seems may have been overlooked (sorry): > >>>>>>>>>>>> http://www.ietf.org/mail- > >> archive/web/tsvwg/current/msg11234.html > >>>>>>>>>>>> > >>>>>>>>>>>> 2) Can you be clear here about what is actually been > > said > >> - > >>>>>>>> because the point below seems to be a misunderstanding of > >> language > >>>>>>>> to me, and I hoped we did not claim this: > >>>>>>>>>>>> > >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find > > that > >> Bob is > >>>>>>>>>>>>>> actually ] saying that transport-layer should _only_ > >> consider > >>>>>>>>>>>>>> "congested bytes", not ] "congested packets". > >>>>>>>>>>>>>> ] > >>>>>>>>>>>> > >>>>>>>>>>>> 3) You'll need to post the updated draft and send a note > >> to > >>>>>>>> the group to confirm that the new version indeed concludes > > the > >>>>>>>> WGLC. I'll add a note to the writeup to indicate the draft > >> content > >>>>>>>> has been stable since Oct 2011. > >>>>>>>>>>>> > >>>>>>>>>>>> Gorry (with my TSVWG Documnent Shepherd hat) > >>>>>>>>>>>> cc: Co-Chairs for info. > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>> From: Gorry Fairhurst [ mailto:gorry@erg.abdn.ac.uk] > >>>>>>>>>>>>>> Sent: Mittwoch, 15. August 2012 21:41 > >>>>>>>>>>>>>> To: tsvwg chair > >>>>>>>>>>>>>> Subject: Fwd: Re: [tsvwg] FYI: Document writeup for > >>>>>>>>>>>>>> draft-ietf-tsvwg- byte-pkt-congest > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi guys, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Apart form the usual rhetoric, there are some points > >> here that we > >>>>>>>>>>>>>> should note as chairs. What are you own thoughts? And > >> was > >>>>>>>>>>>>>> anything noted at the IETF in Vancouver concerning > > this > >> draft? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Gorry > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -------- Original Message -------- > >>>>>>>>>>>>>> Subject: Re: [tsvwg] FYI: Document writeup for > >>>>>>>>>>>>>> draft-ietf-tsvwg-byte- pkt-congest > >>>>>>>>>>>>>> Date: Wed, 15 Aug 2012 15:07:28 -0400 > >>>>>>>>>>>>>> From: John Leslie > >>>>>>>>>>>>>> To: Gorry Fairhurst > >>>>>>>>>>>>>> CC: tsvwg@ietf.org > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Gorry Fairhurst wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The following document has been revised after > >> receiving > >>>>>>>> WGLC comments. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The changes are mostly refreshing a document > >> scheduled to > >>>>>>>>>>>>>> expire this month. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> No issues were found: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Is that with WGC-hat-on? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Neither my issues nor Philip Eardley's comments were > >> addressed. > >>>>>>>>>>>>>> In fact, not even the changes Bob Briscoe mentioned > > on- > >> list have > >>>>>>>>>>>>>> been included. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> As required by RFC 4858, this is the current template > >> for the > >>>>>>>>>>>>>> Document > >>>>>>>>>>>>>>> Shepherd Write-Up. > >>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>> (1) What type of RFC is being requested (BCP, > > Proposed > >> Standard, > >>>>>>>>>>>>>>> Internet Standard, Informational, Experimental, or > >> Historic)? > >>>>>>>>>>>>>>> Why is this the proper type of RFC? Is this type of > >> RFC > >>>>>>>>>>>>>>> indicated in the title page header? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> This document is intended as BCP. (This was discussed > >> at IETF-81 > >>>>>>>>>>>>>>> and that the status changed from Informational to BCP > >> since it > >>>>>>>>>>>>>>> provides guidance to implementors and people > >> configuring > >>>>>>>> routers and hosts). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thank you for finally answering my question about > > BCP > >> status. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>> Working Group Summary > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> There was consensus to publish this as a WG document > >> and > >>>>>>>>>>>>>>> agreement at > >>>>>>>>>>>>>>> IETF-82 that the document was now complete. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Was that reviewed on-list? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>> (3) Briefly describe the review of this document that > >> was > >>>>>>>>>>>>>>> performed > >>>>>>>>>>>>>> by > >>>>>>>>>>>>>>> the Document Shepherd. If this version of the > > document > >> is not > >>>>>>>>>>>>>>> ready for publication, please explain why the > > document > >> is being > >>>>>>>>>>>>>>> forwarded to the IESG. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The document was presented at IEWTF-82 (Taipei), with > >> a request > >>>>>>>>>>>>>>> for > >>>>>>>>>>>>>> WGLC. > >>>>>>>>>>>>>>> WGLC concluded with some discussion but no > > substantive > >> changes > >>>>>>>>>>>>>>> on Friday 30th March 2012. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Yes, I guess that is true; but ignoring substantive > >> comments > >>>>>>>>>>>>>> isn't a good practice IMHO. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> (4) Does the document Shepherd have any concerns > > about > >> the depth > >>>>>>>>>>>>>>> or breadth of the reviews that have been performed? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> No - the original draft had a lot of background > >> material, much > >>>>>>>>>>>>>>> of > >>>>>>>>>>>>>> this > >>>>>>>>>>>>>>> has been condensed or removed, resulting in a smaller > >> document. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> That is indeed what I basically asked for, but I > >> don't see any > >>>>>>>>>>>>>> evidence of it: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> - diff(07,08) 48 lines changed or deleted; 53 lines > >> changed or > >>>>>>>> added > >>>>>>>>>>>>>> - diff(06,07) 8 lines changed or deleted; 13 lines > >> changed or > >>>>>>>> added > >>>>>>>>>>>>>> - diff(05,06) 64 lines changed or deleted; 69 lines > >> changed or > >>>>>>>>>>>>>> added > >>>>>>>>>>>>>> - diff(04,05) 823 lines changed or deleted; 864 lines > >> changed or > >>>>>>>>>>>>>> added > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> (Need I go farther? That gets us back to March > > 2011...) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> (9) How solid is the WG consensus behind this > >> document? Does it > >>>>>>>>>>>>>>> represent the strong concurrence of a few > > individuals, > >> with > >>>>>>>>>>>>>>> others being silent, or does the WG as a whole > >> understand > >>>>>>>> and agree with it? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The document has WG support and there is consensus to > >> publish. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> This, IMHO, doesn't answer the question. :^( > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Does it represent the concurrence of a few > >> individuals, or does > >>>>>>>>>>>>>> the WG as a whole understand and agree with it? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> For reference, my comments included: > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] When I previously skimmed this document, I believed > >> it > >>>>>>>>>>>>>> contained only ] common ground: that AQM should > >> drop/mark packets > >>>>>>>>>>>>>> without favoring small ] packets, and that to whatever > >> extent > >>>>>>>>>>>>>> packet size _is_ considered, that ] should be a > >>>>>>>> transport-layer responsibility. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find > > that > >> Bob is > >>>>>>>>>>>>>> actually ] saying that transport-layer should _only_ > >> consider > >>>>>>>>>>>>>> "congested bytes", not ] "congested packets". > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] In fact, Bob openly endorses replacing TCP > >> congestion-control > >>>>>>>>>>>>>> with an ] algorithm which calculates "fair-share > > bytes" > >> and > >>>>>>>>>>>>>> doesn't back off at all ] (even in the presence of 20% > >> packet > >>>>>>>>>>>>>> loss) unless you're already sending ] more than this > >>>>>>>> "fair-share". > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] I do not believe that is the consensus of this > > WG; > >> and I > >>>>>>>> believe > >>>>>>>>>>>>>> if > >>>>>>>>>>>>>> ] that were the consensus it would exceed our charter. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] The draft contains a number of things I _do_ > > support; > >> and I'd > >>>>>>>>>>>>>> be happy ] to support a considerably shorter draft > >> which > >>>>>>>>>>>>>> concentrates on the AQM ] recommendation, omitting any > >>>>>>>>>>>>>> suggestions of modifying TCP congestion ] control. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> and Philip's comments included: > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] S2.2 I thought the numbered bullets could be better > >> phrased, > >>>>>>>>>>>>>> something like ] +this:- ] > >>>>>>>>>>>>>> ] 1. AQM algorithms such as RED SHOULD use packet- > >> mode > >>>>>>>> drop, ie they > >>>>>>>>>>>>>> SHOULD NOT > >>>>>>>>>>>>>> ] +use byte-mode drop. The latter ] is more complex, > >>>>>>>>>>>>>> ] it creates the perverse incentive to fragment > >> segments > >>>>>>>> into > >>>>>>>>>>>>>> tiny > >>>>>>>>>>>>>> ] pieces and it is vulnerable to floods of > >> small- > >>>>>>>>>>>>>> ] packets. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] 2. If a vendor has implemented byte-mode drop, > >> and an > >>>>>>>> operator > >>>>>>>>>>>>>> has > >>>>>>>>>>>>>> ] turned it on, it is RECOMMENDED to turn it > >> off, after > >>>>>>>>>>>>>> establishing if > >>>>>>>>>>>>>> ] +there are any implications on > >>>>>>>>>>>>>> ] the relative performance of > >>>>>>>>>>>>>> ] applications using different packet sizes. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] 3. RED SHOULD NOT be turned off. Without RED, a > >> drop tail > >>>>>>>>>>>>>> ] queue biases against large packets. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] Nit - the following paragraph shouldn't be indented > >> (Note well > >>>>>>>>>>>>>> that > >>>>>>>>>>>>>> RED's...) > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] S3.3 > >>>>>>>>>>>>>> ] The section could be slightly clearer. Starting with > >> the second > >>>>>>>>>>>>>> para, where you ] +start talking about something you > >> don't > >>>>>>>>>>>>>> recommend (ie you have to remember that ] +you're > >> talking about > >>>>>>>>>>>>>> the consequences of not following your > > recommendation). > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] S3.3 > >>>>>>>>>>>>>> ] o Also, if the network biases congestion > >> notification by > >>>>>>>> packet > >>>>>>>>>>>>>> size > >>>>>>>>>>>>>> ] it has to assume a baseline packet size--all > >> proposed > >>>>>>>>>>>>>> algorithms > >>>>>>>>>>>>>> ] use the local MTU. Then transports have to > >> guess which > >>>>>>>> link > >>>>>>>>>>>>>> was > >>>>>>>>>>>>>> ] congested and what its local MTU was, in order > >> to know > >>>>>>>> how to > >>>>>>>>>>>>>> ] tailor their congestion response to that link. > >>>>>>>>>>>>>> ] So you're saying that for byte-mode drop, the > > network > >> element > >>>>>>>>>>>>>> has to compare the ] +size of the current pkt with the > >> MTU, and > >>>>>>>>>>>>>> if it's 25* smaller then reduce the ] +pkt loss > >> probably by 25*? > >>>>>>>>>>>>>> And if the MTU was bigger, then the current pkt would > > ] > >> +be > >>>>>>>>>>>>>> dropped with greater probability? And both of these > >> things > >>>>>>>> are hard to do. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] S3.4 (& knock-on effect on 3.3) ] I think this could > >> be better. > >>>>>>>>>>>>>> ] I agree with your arguments in S3.1 & 3.2 that > >> dropping or > >>>>>>>>>>>>>> marking should be ] +independent of pkt size. > >>>>>>>>>>>>>> ] You now go into a couple of pages, which I think > >> could be > >>>>>>>>>>>>>> boiled down to a ] +paragraph, saying something like:- > >> ] * the > >>>>>>>>>>>>>> overall system (network + transport) has to be packet- > >> size > >>>>>>>>>>>>>> dependent in ] > >>>>>>>>>>>>>> +order to drive out the right amount of traffic so the > >> resource > >>>>>>>>>>>>>> becomes ] > >>>>>>>>>>>>>> +uncongested (since we assume all resources are in > >> practice byte > >>>>>>>>>>>>>> +rather > >>>>>>>>>>>>>> than ] +packet limited) ] * from S3.1 and S3.2 the > > IETF > >> is > >>>>>>>>>>>>>> convinced that the network should notify ] > > +independent > >> of > >>>>>>>> packet-size. > >>>>>>>>>>>>>> ] * therefore the transport must act dependent on > >> packet-size. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] It seems to me this is a necessary consequence of > >> your earlier > >>>>>>>>>>>>>> assumptions ] +/arguments. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] [On the other hand, if someone disagrees with the > >> arguments and > >>>>>>>>>>>>>> thinks that the ] +network should notify dependent on > >>>>>>>>>>>>>> packet-size, then it follows that the ] +transport can > >> act > >>>>>>>>>>>>>> independent of > >>>>>>>>>>>>>> packet- size.] ] ] I think in S3.3 you're trying to > >> make another > >>>>>>>>>>>>>> argument (?):- ] * we can either do packet-size > >> biasing in the > >>>>>>>>>>>>>> network element or on the end host ] +transport (see > >> argument > >>>>>>>>>>>>>> above) ] * packet-size biasing in the network is quite > >> tricky, > >>>>>>>>>>>>>> because then both the ] +network element & the > >> transport have to > >>>>>>>>>>>>>> make some guesses about MTU - whereas ] > >>>>>>>>>>>>>> +with packet-size biasing in the transport, neither > >> network > >>>>>>>>>>>>>> +element > >>>>>>>>>>>>>> nor ] +transport needs to know what the MTU is. > >>>>>>>>>>>>>> ] * it is also easier to implement packet-size biasing > >> in the > >>>>>>>>>>>>>> transport than in ] +the network. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] On the last bullet, I didn't really follow your > >> argument in > >>>>>>>> S3.5. > >>>>>>>>>>>>>> Might be ] +easier to follow if S3.5 also talked about > >> how a > >>>>>>>>>>>>>> network element would take ] +account of pkt size? > >> Also, does the > >>>>>>>>>>>>>> following argument also apply?: > >>>>>>>>>>>>>> ] * if pkt-size biasing is done in the transport, then > >> the work > >>>>>>>>>>>>>> (to do the ] +biasing) is spread over many end hosts, > > ] > >> * whereas > >>>>>>>>>>>>>> if pkt-size biasing is done in the network, then the > >> work is ] > >>>>>>>>>>>>>> +concentrated in just the congested network element, > >> which has to > >>>>>>>>>>>>>> operate on all ] +the traffic at line speed. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> (Has there perhaps been some confusion about what > >> went into the > >>>>>>>>>>>>>> -08 > >>>>>>>>>>>>>> version?) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>> John Leslie > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >> ________________________________________________________________ > >>>>>>>>>>> Bob Briscoe, BT Innovate & > >> Design > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >> ________________________________________________________________ > >>>>>>> Bob Briscoe, BT Innovate & > >> Design > >>>>>>> > >>>>> > >>>>> ________________________________________________________________ > >>>>> Bob Briscoe, BT Innovate & Design > >>> > >>> ________________________________________________________________ > >>> Bob Briscoe, BT Innovate & Design > > From Ruediger.Geib@telekom.de Thu Oct 11 07:48:33 2012 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 F067221F8496; Thu, 11 Oct 2012 07:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.409 X-Spam-Level: X-Spam-Status: No, score=-1.409 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGMNDSsAwcWm; Thu, 11 Oct 2012 07:48:30 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 2331621F847D; Thu, 11 Oct 2012 07:48:28 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 11 Oct 2012 16:48:26 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 11 Oct 2012 16:48:26 +0200 From: To: Date: Thu, 11 Oct 2012 16:48:25 +0200 Thread-Topic: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest Thread-Index: AQHNp64+FkrAkabfCEaD1jzPlkv4fJez3BoAgAAzNaCAAB4rIA== Message-ID: References: <20120815190728.GQ15012@verdi> <502BFB47.7010803@erg.abdn.ac.uk><791AD3077F94194BB2BDD13565B6295D45A6212A@PALLENE.office.hd><15181_1346848013_5047450C_15181_645_1_50474507.3090706@erg.abdn.ac.uk><3A5279D338C75C40B4B3DA15BA47D6330B616BD2@EXMDB04.org.aalto.fi><201209051541.q85FfCs0019699@bagheera.jungle.bt.co.uk><9510D26531EF184D9017DF24659BB87F33D793B351@EMV65-UKRD.domain1.systemhost.net><3A5279D338C75C40B4B3DA15BA47D6330B69261A@EXMDB04.org.aalto.fi><9510D26531EF184D9017DF24659BB87F33D793B845@EMV65-UKRD.domain1.systemhost.net><04AC95B5-A2B1-4DD2-B765-E20A4C1A69A3@aalto.fi><3A5279D338C75C40B4B3DA15BA47D6330B6E81E4@EXMDB04.org.aalto.fi><9510D26531EF184D9017DF24659BB87F33DCE34251@EMV65-UKRD.domain1.systemhost.net><201210041126.q94BQ0hx002951@bagheera.jungle.bt.co.uk><1904eec816d080f886f5bf8685358ddc.squirrel@www.erg.abdn.ac.uk><201210101525.q9AFP4Mi008013@bagheera.jungle.bt.co.uk><3A5279D338C75C40B4B3DA15BA47D6330B6FC2BB@EXMDB04.org.aalto.fi><201210111208.q9BC8BAU012! ! 305@bag he era.jungl e.b t.co.uk> <3A5279D338C75C40B4B3DA15BA47D6330B6FD072@EXMDB04.org.aalto.fi> <999913AB42CC9341B05A99BBF358718D01F360CF@FIESEXC035.nsn-intra.net> <3A5279D338C75C40B4B3DA15BA47D6330B6FD197@EXMDB04.org.aalto.fi> <999913AB42CC9341B05A99BBF358718D01F360F7@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D01F360F7@FIESEXC035.nsn-intra.net> 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: gorry@erg.abdn.ac.uk, philip.eardley@bt.com, tsvwg@ietf.org, tsvwg-chairs@ietf.org Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest 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, 11 Oct 2012 14:48:33 -0000 Hi Hannes, haven't been at the workshop or last IETF, read into the draft and into Codel: - it is unclear to me, whether codel is dealing with CPE issues or RED in general. - I've understood Bobs/Jukkas draft to deal with RED in general. If Codel is about RED in general, backbone router vendor support is required. Has there been feedback from this community? It may be a good idea to try to finalise the work of Bob and Jukka. Regards, R=FCdiger -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of T= schofenig, Hannes (NSN - FI/Espoo) Sent: Thursday, October 11, 2012 2:58 PM To: ext Manner Jukka Cc: gorry@erg.abdn.ac.uk; philip.eardley@bt.com; tsvwg IETF list; tsvwg-cha= irs@ietf.org Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-b= yte-pkt-congest Hi Jukka, With QoS there is no such thing as "short term" (as we already had to learn painfully). That makes me wonder what is more useful: publish a document that describe how to configure RED correctly or to go for an AQM technique that (according to the authors) works almost zero configuration. My take-away from the Vancouver congestion control workshop was that it is better to ignore RED. (Maybe my impression was wrong -- someone else should confirm.) Ciao Hannes > -----Original Message----- > From: ext Manner Jukka [mailto:jukka.manner@aalto.fi] > Sent: Thursday, October 11, 2012 3:50 PM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: Bob Briscoe; ; ; > ; tsvwg IETF list > Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf- > tsvwg-byte-pkt-congest > > Hi, this document talks about the current and short term goals and > operations, while AFAIK CoDel is a more futuristic concept, interesting > concept, sure, but not deployed at large. > > cheers, > Jukka > > On Oct 11, 2012, at 3:44 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > > Hi Jukka, Hi Bob, > > > > having listened to the presentations about CoDel I am wondering > whether > > this document may have taken over by events and is obsolete by now. > > What's your view on that? > > > > Ciao > > Hannes > > > > > >> -----Original Message----- > >> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On > Behalf > >> Of ext Manner Jukka > >> Sent: Thursday, October 11, 2012 3:34 PM > >> To: Bob Briscoe > >> Cc: ; ; >> chairs@ietf.org>; tsvwg IETF list > >> Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf- > >> tsvwg-byte-pkt-congest > >> > >> Hi, > >> > >> Yeah, please at the point about cheap devices, still, I wonder what > > the > >> cost of AQM is on those devices. Maybe 1 cnt in mass production? > Thus, > >> I still wonder if it is worth arguing something about the future > that > >> strongly. > >> > >> Sorry, but the same goes for AQM in general, and where it is, or > will > >> not be deployed. I understand technical reasons why not something is > >> feasible, but business or monetary reasons can change very quickly. > ;) > >> > >> Jukka > >> > >> On Oct 11, 2012, at 3:08 PM, Bob Briscoe wrote: > >> > >>> Jukka, > >>> > >>> What I had in mind is all low level buffers in cheap pure L2 > > devices, > >> in cheap NATs etc. I was going to list some of these, but instead > > chose > >> to say "no-one expects AQM to be universally deployed". This clearly > >> missed the mark. > >>> > >>> Should we include some of these concrete examples of where AQM > won't > >> be deployed instead? > >>> > >>> [I've cc'd the list, given we're starting to wordsmith > significantly > >> new text added since WG last call.] > >>> > >>> > >>> Bob > >>> > >>> At 20:04 10/10/2012, Manner Jukka wrote: > >>>> Hi, looked good to me. Just one comment, I wouldn't put that much > >> emphasis on what is a probably state of things, e.g. > >>>> > >>>> "no-one expects AQM to ever be .." > in the future it might, we > >> don't know, and since the paragraph says that it doesn't matter > > anyway, > >> I would formulate this paragraph a bit towards that we have partial > >> deployment now and even with a full deployment, ... > >>>> > >>>> and similarly with the unrealistic deployment of AQM in the > >> subsequent paragraph. > >>>> > >>>> cheers, > >>>> Jukka > >>>> > >>>> On Oct 10, 2012, at 6:25 PM, Bob Briscoe wrote: > >>>> > >>>>> Phil, > >>>>> > >>>>> Sorry for delay, my round-robin scheduler is taking so long to > > get > >> round all the tasks that I keep finding dead robins (that reminds me > > of > >> a bike ride my grandmother took. On her return, she said there were > a > >> worryingly large number of robins run over on the roads. It turned > out > >> that she had been going round the same small triangle of roads > > multiple > >> times). > >>>>> > >>>>> I've done a complete re-write of 3.4. I hope you will agree that > >> it really is a motivating argument now and it can stay where it is - > > it > >> is not just a preamble. > >>>>> > >>>>> I've gone back to the very first version of 3.4 I wrote and I now > >> realise that I had written the core of the argument so badly that > even > >> I forgot what it was meant to say when we started editing it. In the > >> draft-08 version, the original meaning is lost and in your re- > wording > >> it is entirely lost. The link with the draft-08 version is nearly > >> unrecognisable, but it's the argument I intended here. > >>>>> > >>>>> > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> 3.4. Permanent Partial Deployment of AQM > >>>>> > >>>>> In overview, the argument in this section runs as follows: > >>>>> * Because the network will not and cannot always drop packets in > >> proportion to their size, it shouldn't be given the task of making > > drop > >> signals depend on packet size at all. > >>>>> * Transports on the other hand don't always want to make their > >> rate response proportional to the size of dropped packets, but if > they > >> want to, they always can. > >>>>> > >>>>> The argument is similar to the end-to-end argument that says > >> "Don't do X in the network if end-systems can do X by themselves, > and > >> they want to be able to choose whether to do X anyway." Actually the > >> following argument is stronger; in addition it says "Don't give the > >> network task X that could be done by the end-systems, if X won't > ever > >> be deployed on all network nodes, and end-systems won't be able to > > tell > >> whether their network is doing X, or whether they need to do X > >> themselves." In this case, the X in question is "making the response > > to > >> congestion depend on packet size". > >>>>> > >>>>> We will now re-run this argument taking each step in more depth. > >> The argument applies solely to drop, not ECN marking. > >>>>> > >>>>> A queue drops packets for either of two reasons: a) to signal to > >> host congestion controls that they should reduce the load and b) > >> because there is no buffer left to store the packets. Active queue > >> management tries to use drops as a signal for hosts to slow down > (case > >> a) so that drop due to buffer exhaustion (case b) should not be > >> necessary. > >>>>> > >>>>> No-one expects AQM to ever be universally deployed in every queue > >> in the Internet; and, even if AQM were universal, it has to be able > to > >> cope with buffer exhaustion (by switching to a behaviour like tail- > >> drop), in order to cope with unresponsive or excessive transports. > >> Therefore networks will often be dropping packets as a last resort > >> (case b) rather than under AQM control (case a). > >>>>> > >>>>> When buffers are exhausted (case b), they don't naturally drop > >> packets in proportion to their size. The network can only reduce the > >> probability of dropping smaller packets if it has enough space to > > store > >> them somewhere while it waits for a larger packet that it can drop. > If > >> the buffer is exhausted, it does not have this choice. Admittedly > > tail- > >> drop does naturally drop somewhat fewer small packets, but exactly > how > >> few depends more on the mix of sizes than the size of the packet in > >> question. Nonetheless, in general, if we wanted networks to do size- > >> dependent drop, we would need universal deployment of (packet-size > >> dependent) AQM code, which is unrealistic. > >>>>> > >>>>> A host transport cannot know whether any particular drop was a > >> deliberate signal from an AQM or a sign of a queue shedding packets > > due > >> to buffer exhaustion. Therefore, because the network cannot > > universally > >> do size-dependent drop, it should not do it all. > >>>>> > >>>>> Whereas universality is desirable in the network, diversity is > >> desirable between different transport layer protocols - some, like > >> NewReno TCP [RFC5681], may not choose to make their rate response > >> proportionate to the size of each dropped packet, while others will > >> (e.g. TFRC-SP [RFC4828]). > >>>>> > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Bob > >>>>> > >>>>> At 13:13 04/10/2012, gorry@erg.abdn.ac.uk wrote: > >>>>>> That would be brilliant! > >>>>>> > >>>>>> Gorry > >>>>>> > >>>>>>> Will try to look at this later today. > >>>>>>> > >>>>>>> > >>>>>>> Bob > >>>>>>> > >>>>>>> At 10:42 02/10/2012, philip.eardley@bt.com wrote: > >>>>>>>> Think the token is with bob > >>>>>>>> > >>>>>>>> Re your comment - yes, I think you could move 3.4 to the end > > of > >> S3 - > >>>>>>>> or to the start - and do some re-phrasing, maybe something > > like > >> I tried. > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Manner Jukka [mailto:jukka.manner@aalto.fi] > >>>>>>>> Sent: 01 October 2012 20:18 > >>>>>>>> To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,Bob,DUB8 R > >>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst > >>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for > >>>>>>>> draft-ietf-tsvwg-byte-pkt-congest > >>>>>>>> > >>>>>>>> Phil, Bob, can we close this finally? It's three weeks now > >> since > >>>>>>>> this previous message. > >>>>>>>> > >>>>>>>> Jukka > >>>>>>>> > >>>>>>>> On Sep 10, 2012, at 4:42 PM, Jukka Manner wrote: > >>>>>>>> > >>>>>>>>> Ack, I'm getting there...;) > >>>>>>>>> > >>>>>>>>> So, we could move 3.4 at the end of Section 3 and rephrase > >> it to > >>>>>>>> not talk about scaling per se, but rather about how Req 2.2 > >>>>>>>> eventually leads to Req 2.3? > >>>>>>>>> > >>>>>>>>> Jukka > >>>>>>>>> > >>>>>>>>> On Sep 7, 2012, at 4:07 PM, > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> 3.4 is, in my mind, completely different from 3.1, 3.2, > > 3.3 > >> and 3.5. > >>>>>>>>>> > >>>>>>>>>> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for > >> Recommendation > >>>>>>>>>> 2.2 & a lesser extent 2.3 > >>>>>>>>>> 3.4 makes doesn't make a motivating argument - it explains > >> that Rec > >>>>>>>>>> 2.2 & 2.3 come as a pair (if you recommend one, then > >> inevitably you > >>>>>>>>>> recommend the other) (delta some politeness about TCP) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Manner Jukka [mailto:jukka.manner@aalto.fi] > >>>>>>>>>> Sent: 07 September 2012 13:24 > >>>>>>>>>> To: Eardley,PL,Philip,DUB8 R > >>>>>>>>>> Cc: Briscoe,RJ,Bob,DUB8 R; ; > >>>>>>>>>> > >>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for > >>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest > >>>>>>>>>> > >>>>>>>>>> Hi, I'm trying to follow your reasoning, with little luck. > >> ;) > >>>>>>>>>> > >>>>>>>>>> After having read Section 3 again, I could think of a few > >>>>>>>> updates, but I'm not fully following what you want to see: > >>>>>>>>>> > >>>>>>>>>> - S3.5 is kind of small and lonely by itself. It could be > >> either > >>>>>>>> longer or merged somewhere. Not a major issue though and > > could > >> remain as > >>>>>>>> is. > >>>>>>>>>> > >>>>>>>>>> - S3.3: Yes, probably could be turned upside down, good > >> first, > >>>>>>>> bad later. Don't have a strong opinion. > >>>>>>>>>> > >>>>>>>>>> - S3.4: Here the scaling is used many times and in the > >> title, > >>>>>>>> although we talk about the end host side. This could be > >> rephrased > >>>>>>>> and slightly reworded to talk about hosts and their operation > >>>>>>>> altogether. Also the word scaling can turn the readers > >> expectation > >>>>>>>> into the wrong direction. > >>>>>>>>>> > >>>>>>>>>> - S3 altogether: It would help to have introductory text > >> about > >>>>>>>> networks vs. end host side, but I fail to see why (& how) to > >>>>>>>> restructure everything. > >>>>>>>>>> > >>>>>>>>>> cheers, > >>>>>>>>>> Jukka > >>>>>>>>>> > >>>>>>>>>> On Sep 6, 2012, at 6:18 PM, > >>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Ps otherwise Bob's comments are fine, though I suggest > > for > >> S3.5 you > >>>>>>>>>>> give more context (ie are you knocking down what you > >> recommend > >>>>>>>>>>> against, or building up what you recommend?) and in S3.3 > >> think > >>>>>>>>>>> would be better if you re-structured slightly [first talk > >> about what > >>>>>>>>>>> you like - penult para + 1st sentence of last para - then > >> talk about > >>>>>>>>>>> what you don't like - rest of text] > >>>>>>>>>>> > >>>>>>>>>>> From: Eardley,PL,Philip,DUB8 R > >>>>>>>>>>> Sent: 06 September 2012 16:12 > >>>>>>>>>>> To: Briscoe,RJ,Bob,DUB8 R; Manner Jukka > >>>>>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst > >>>>>>>>>>> Subject: RE: [REVISED I-D]: Document writeup for > >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest > >>>>>>>>>>> > >>>>>>>>>>> Thanks bob. Have now re-booted some state. > >>>>>>>>>>> I don't like S3.4. My basic problem with it is that it > >> isn't a > >>>>>>>> "motivating argument" (S3 title). It's an explanation about > >> the > >>>>>>>> consequences of assuming either [option 1] do pkt-size > > biasing > >> in > >>>>>>>> the transport; [option 2]; do pkt-size biasing in the nw. > >>>>>>>>>>> Perhaps your effort to buy peace with those who won't > >> change > >>>>>>>> TCP has obfuscated the basic point? > >>>>>>>>>>> The title of S3.4 (Scaling...) and the early text > > "scaling > >>>>>>>> argument" suggests that you're going to argue there is some > >> reason > >>>>>>>> why X scales as order N rather than N^2 or something like > > that > >> - > >>>>>>>> which isn't what S3.4 is about. > >>>>>>>>>>> > >>>>>>>>>>> I actually think it would be better to put S3.4 at the > >> start of > >>>>>>>> S3 - it's background where you say there are 2 options. After > >> that, > >>>>>>>> you can explain the reasons why option 1 [pkt biasing in the > >>>>>>>> transport] is better - the reasons being:- S3.1 (security > > etc > >>>>>>>> attacks if small pkts get preferential treatment), S3.2 > >> (really a > >>>>>>>> side note to S3.1; ie doesn't really present a "motivating > >>>>>>>> argument"), S3.3 (nw guessing MTU vs transport knowing pkt > >> size), > >>>>>>>> S3.5 (easier implementation). > >>>>>>>>>>> > >>>>>>>>>>> Something like... > >>>>>>>>>>> The behaviour of the network and transport together needs > >> to > >>>>>>>>>>> alleviate congestion. We assume the network is bit- > >> congestible > >>>>>>>> (currently packet-congestible resources are rate). Therefore > >>>>>>>> overall the response of the {network + transport} should be > >> the > >>>>>>>> same for the same congestion - whether the congestion is > >> caused by > >>>>>>>> a lot of small packets or a smaller number of larger packets. > >> The > >>>>>>>> implication is that the transport's behaviour should depend > > on > >>>>>>>> whether the network takes account (or not) of packet size > > when > >> it > >>>>>>>> generates congestion indications:- Case 1: If the network > >>>>>>>> implements packet-mode drop, ie its algorithm treats all > >> packets > >>>>>>>> equally regardless of their size, then the transport should > >> take > >>>>>>>> account of the size of the packet - in other words, the > >> transport's > >>>>>>>> congestion response should depend on the number of dropped > >> bytes. > >>>>>>>>>>> Case 2: If the network implements byte-mode drop, ie its > >>>>>>>> algorithm treats packets differently depending on their size, > >> then > >>>>>>>> the transport should not take account of the size of the > >> packet - > >>>>>>>> in other words, the transport's congestion response should > >> depend > >>>>>>>> on the number of dropped packets. > >>>>>>>>>>> > >>>>>>>>>>> These cases are explained in more detail in sub-section > >> below. > >>>>>>>>>>> > >>>>>>>>>>> In both cases the same discussion applies if packets are > >>>>>>>> ECN-marked rather than dropped. > >>>>>>>>>>> In the following sections we explain why Case 1 is > >> preferable, > >>>>>>>> and hence why we make the Recommendations of S2.2 and S3.3 > >>>>>>>> (respectively, drop/mark pkts equally regardless of their > >> size, and > >>>>>>>> the strength of the transport's response should be > >> proportionate to > >>>>>>>> the size of the dropped/marked pkt). > >>>>>>>>>>> Note that TCP responds to dropped or marked packets, > > which > >> differs > >>>>>>>>>>> from our recommendation for transports. However, we are > >> not > >>>>>>>>>>> recommending that TCP should be changed; to date it > >> hasn't been a > >>>>>>>>>>> significant problem because most TCP implementations > > have > >> been > >>>>>>>> used with similar packet sizes. But we do recommend that > >> future > >>>>>>>> transport protocols should respond to dropped or marked > > bytes > >> (as > >>>>>>>> for example TFRC-SP [RFC4828]effectively does). > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Sub-section > >>>>>>>>>>> You could use much of S3.3, I suggest supplement with > >> numerical > >>>>>>>>>>> examples continuing S1.2 > >>>>>>>>>>> -- > >>>>>>>>>>> << This gives a get-out clause to any transport that > > isn't > >>>>>>>>>>> packet-size dependent (e.g. current TCP). Lacking packet- > >> size > >>>>>>>>>>> dependence just means they don't scale correctly with > >> packet size - > >>>>>>>>>>> but they are at liberty not to scale with packet size > >> (particularly > >>>>>>>>>>> given MTU growth isn't often being used to increase link > >> rates at > >>>>>>>>>>> this stage in history).>> > >>>>>>>>>>> > >>>>>>>>>>> This is introducing a different point. it's saying that > >> your > >>>>>>>> recommendation 2 [drop/mark pkts equally regardless of their > >> size] > >>>>>>>> is a really strong reco whilst recommendation 3 [strength of > >>>>>>>> transport's response proportionate to the size of the > >>>>>>>> dropped/marked pkt] is a much less important reco. I can see > >> this > >>>>>>>> might be true, but I don't think the i-d talks about this. > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> > >>>>>>>>>>> From: Briscoe,RJ,Bob,DUB8 R > >>>>>>>>>>> Sent: 05 September 2012 16:41 > >>>>>>>>>>> To: Manner Jukka > >>>>>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst; > >> Eardley,PL,Philip,DUB8 R > >>>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for > >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest > >>>>>>>>>>> > >>>>>>>>>>> Jukka, > >>>>>>>>>>> > >>>>>>>>>>> I've repeated Phil's suggestions as quoted email then > > made > >> some > >>>>>>>> alterations. > >>>>>>>>>>> > >>>>>>>>>>> Phil asked me to send this, then he will think about it. > >>>>>>>>>>> > >>>>>>>>>>> I'll respond about John Leslie's argument next... > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> 2.2. Recommendation on Encoding Congestion Notification > >>>>>>>>>>> > >>>>>>>>>>> [...] > >>>>>>>>>>> > >>>>>>>>>>> 1. AQM algorithms such as RED SHOULD use packet-mode > >> drop, ie they > >>>>>>>>>>> SHOULD NOT use byte-mode drop. The latter is more > >> complex, > >>>>>>>>>>> it creates the perverse incentive to fragment > >> segments into > >>>>>>>> tiny > >>>>>>>>>>> pieces and it is vulnerable to floods of small > >> packets. > >>>>>>>>>>> > >>>>>>>>>>> 2. If a vendor has implemented byte-mode drop, and an > >> operator has > >>>>>>>>>>> turned it on, it is RECOMMENDED to turn it off, > > after > >>>>>>>> establishing > >>>>>>>>>>> if there are any implications on the relative > >> performance of > >>>>>>>>>>> applications using different packet sizes. > >>>>>>>>>>> > >>>>>>>>>>> RED as a whole SHOULD NOT be turned off. Without > > RED, > >> a drop > >>>>>>>> tail > >>>>>>>>>>> queue biases against large packets > >>>>>>>>>>> > >>>>>>>>>>> [BB adds]: and it is > >> vulnerable to > >>>>>>>> floods > >>>>>>>>>>> of small-packets. > >>>>>>>>>>> > >>>>>>>>>>> (I suggest the last para just qualifies item 2. It > > doesn't > >> warrant > >>>>>>>>>>> another item number.) > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> [PE:] S3.3 > >>>>>>>>>>> The section could be slightly clearer. Starting with the > >> second > >>>>>>>> para, where you start talking about something you don't > >> recommend > >>>>>>>> (ie you have to remember that you're talking about the > >> consequences > >>>>>>>> of not following your recommendation). > >>>>>>>>>>> > >>>>>>>>>>> 3.3 Transport-Independent Network > >>>>>>>>>>> > >>>>>>>>>>> TCP congestion control ensures that flows competing for > >> the same > >>>>>>>>>>> resource each maintain the same number of segments in > >> flight, > >>>>>>>>>>> irrespective of segment size. So under similar > >> conditions, flows > >>>>>>>>>>> with different segment sizes will get different > > bit-rates. > >>>>>>>>>>> > >>>>>>>>>>> [OLD:] > >>>>>>>>>>> One motivation for the network biasing congestion > >> notification by > >>>>>>>>>>> packet size is to counter this effect and try to equalise > >> the bit- > >>>>>>>>>>> rates of flows with different packet sizes. > >>>>>>>>>>> [SUGGESTED:] > >>>>>>>>>>> To counter this effect it seems tempting not to follow > >> our > >>>>>>>>>>> recommendation, and instead for the network to bias > >> congestion > >>>>>>>>>>> notification by packet size in order to equalise the > > bit- > >> rates of > >>>>>>>>>>> flows with different packet sizes. > >>>>>>>>>>> [CONTINUE AS BEFORE:] > >>>>>>>>>>> However, in order to do this, the queuing > >> algorithm > >>>>>>>>>>> has to make assumptions about the transport, which > > become > >> embedded > >>>>>>>>>>> in the network. Specifically: > >>>>>>>>>>> [...] > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> S3.3 > >>>>>>>>>>> o The queuing algorithm has to assume how aggressively > >> the > >>>>>>>> transport > >>>>>>>>>>> will respond to congestion (see Section 4.2.4). If > >> the network > >>>>>>>>>>> assumes the transport responds as aggressively as TCP > >> NewReno, > >>>>>>>> it > >>>>>>>>>>> will be wrong for Compound TCP and differently wrong > >> for Cubic > >>>>>>>>>>> TCP, etc. To achieve equal bit-rates, each transport > >> then has > >>>>>>>> to > >>>>>>>>>>> guess what assumption the network made, and work out > >> how to > >>>>>>>>>>> replace this assumed aggressiveness with its own > >> aggressiveness. > >>>>>>>>>>> o Also, if the network biases congestion notification > > by > >> packet > >>>>>>>> size > >>>>>>>>>>> it has to assume a baseline packet size--all proposed > >> algorithms > >>>>>>>>>>> use the local MTU. Then transports have to guess > >> which link was > >>>>>>>>>>> congested and what its local MTU was, in order to > > know > >> how to > >>>>>>>>>>> tailor their congestion response to that link. > >>>>>>>>>>> > >>>>>>>>>>> So you're saying that for byte-mode drop, the network > >> element > >>>>>>>> has to compare the size of the current pkt with the MTU, and > >> if > >>>>>>>> it's 25* smaller then reduce the pkt loss probably by 25*? > > And > >> if > >>>>>>>> the MTU was bigger, then the current pkt would be dropped > > with > >>>>>>>> greater probability? And both of these things are hard to do. > >>>>>>>>>>> > >>>>>>>>>>> [BB]: SUGGESTED REPLACEMENT to 2nd bullet: > >>>>>>>>>>> > >>>>>>>>>>> o Also, if the network biases congestion notification > > by > >> packet > >>>>>>>> size > >>>>>>>>>>> it has to assume a baseline packet size--all proposed > >> algorithms > >>>>>>>>>>> use the local MTU (for example see the byte-mode loss > >>>>>>>> probability > >>>>>>>>>>> formula in Table 1). Then if the non-Reno transports > >> mentioned > >>>>>>>> above > >>>>>>>>>>> are trying to reverse engineer what the network > >> assumed, they > >>>>>>>> also > >>>>>>>>>>> have to guess the MTU of the congested link. > >>>>>>>>>>> > >>>>>>>>>>> [Aside for Phil: The byte-mode algo uses MTU as its > >> baseline because > >>>>>>>>>>> a link cannot send a packet bigger than its MTU so the > >> algo won't > >>>>>>>>>>> ever give a drop probability >1).] > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> S3.4 (& knock-on effect on 3.3) > >>>>>>>>>>> I think this could be better. > >>>>>>>>>>> I agree with your arguments in S3.1 & 3.2 that dropping > > or > >>>>>>>> marking should be independent of pkt size. > >>>>>>>>>>> You now go into a couple of pages, which I think could be > >> boiled > >>>>>>>>>>> down to a paragraph, saying something like:- > >>>>>>>>>>> * the overall system (network + transport) has to be > >> packet-size > >>>>>>>>>>> dependent in order to drive out the right amount of > >> traffic so the > >>>>>>>>>>> resource becomes uncongested (since we assume all > >> resources are in > >>>>>>>>>>> practice byte rather than packet limited) > >>>>>>>>>>> * from S3.1 and S3.2 the IETF is convinced that the > >> network > >>>>>>>> should notify independent of packet-size. > >>>>>>>>>>> * therefore the transport must act dependent on packet- > >> size. > >>>>>>>>>>> > >>>>>>>>>>> It seems to me this is a necessary consequence of your > >> earlier > >>>>>>>> assumptions /arguments. > >>>>>>>>>>> > >>>>>>>>>>> [BB:] This isn't at all obvious. Until I worked it > >> through, it > >>>>>>>> wasn't obvious to me. I think it needs to be spelled out. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> [On the other hand, if someone disagrees with the > >> arguments and > >>>>>>>>>>> thinks that the network should notify dependent on > > packet- > >> size, then > >>>>>>>>>>> it follows that the transport can act independent of > >> packet-size.] > >>>>>>>>>>> > >>>>>>>>>>> I think in S3.3 you're trying to make another argument > >> (?):- > >>>>>>>>>>> * we can either do packet-size biasing in the network > >> element or on > >>>>>>>>>>> the end host transport (see argument above) > >>>>>>>>>>> * packet-size biasing in the network is quite tricky, > >> because > >>>>>>>> then both the network element & the transport have to make > >> some > >>>>>>>> guesses about MTU - whereas with packet-size biasing in the > >>>>>>>> transport, neither network element nor transport needs to > > know > >> what the > >>>>>>>> MTU is. > >>>>>>>>>>> * it is also easier to implement packet-size biasing in > >> the > >>>>>>>> transport than in the network. > >>>>>>>>>>> > >>>>>>>>>>> [BB] ...and all the other arguments about vulnerability > > to > >>>>>>>> flooding etc, transport-independence etc. > >>>>>>>>>>> > >>>>>>>>>>> Our argument is sort of like how Phil summarises it, but > >> with > >>>>>>>> an added nuance. It's also saying no-one has to do > > packet-size > >>>>>>>> biasing anyway. It's not saying "The transport should given > >> the > >>>>>>>> network shouldn't". It's saying "*If the transport wants to > >> claim > >>>>>>>> to be scalable wrt packet size* it should if the network > >> shouldn't". > >>>>>>>>>>> > >>>>>>>>>>> This gives a get-out clause to any transport that isn't > >>>>>>>> packet-size dependent (e.g. current TCP). Lacking packet-size > >>>>>>>> dependence just means they don't scale correctly with packet > >> size - > >>>>>>>> but they are at liberty not to scale with packet size > >> (particularly > >>>>>>>> given MTU growth isn't often being used to increase link > > rates > >> at > >>>>>>>> this stage in history). > >>>>>>>>>>> > >>>>>>>>>>> None of what Phil says convinces me we could say 3.4 (or > >> 3.3) > >>>>>>>> any more briefly or differently. It's easier to summarise > > what > >> you > >>>>>>>> understand having read something. But that's not the same as > >>>>>>>> writing the thing that helped you understand. There doesn't > >> seem to > >>>>>>>> be any argument for why anything needs to be changed, so I'm > >> going > >>>>>>>> to leave it as is, unless pushed. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On the last bullet, I didn't really follow your argument > >> in > >>>>>>>> S3.5. Might be easier to follow if S3.5 also talked about how > >> a > >>>>>>>> network element would take account of pkt size? > >>>>>>>>>>> Also, does the following argument also apply?: > >>>>>>>>>>> * if pkt-size biasing is done in the transport, then the > >> work (to do > >>>>>>>>>>> the biasing) is spread over many end hosts, > >>>>>>>>>>> * whereas if pkt-size biasing is done in the network, > > then > >> the > >>>>>>>> work is concentrated in just the congested network element, > >> which > >>>>>>>> has to operate on all the traffic at line speed. > >>>>>>>>>>> > >>>>>>>>>>> [BB]: 3.5. Implementation Efficiency > >>>>>>>>>>> > >>>>>>>>>>> [ADD:] > >>>>>>>>>>> Biasing against large packets typically requires an > > extra > >> multiply > >>>>>>>>>>> and divide in the network (see the example byte-mode > > drop > >>>>>>>> formula in table 1). > >>>>>>>>>>> [CONTINUE AS BEFORE:] > >>>>>>>>>>> Allowing for packet size at the transport rather than in > >> the > >>>>>>>>>>> network ensures that neither the network nor the > >> transport needs to > >>>>>>>>>>> do a multiply operation--multiplication by packet size > > is > >>>>>>>>>>> effectively achieved as a repeated add when the > > transport > >> adds to > >>>>>>>>>>> its count of marked bytes as each congestion event is > > fed > >> to it. > >>>>>>>>>>> [ADD:] > >>>>>>>>>>> Also the work to do the biasing is spread over many > >> hosts, rather > >>>>>>>>>>> than concentrated in just the congested network element. > >>>>>>>>>>> [CONTINUE AS BEFORE:] > >>>>>>>>>>> > > These > >> aren't > >>>>>>>>>>> principled reasons in themselves, but they are a happy > >> consequence > >>>>>>>>>>> of the other principled reasons. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Bob > >>>>>>>>>>> > >>>>>>>>>>> At 13:36 05/09/2012, Manner Jukka wrote: > >>>>>>>>>>> > >>>>>>>>>>> Hi Bob, > >>>>>>>>>>> > >>>>>>>>>>> Since Phil is your colleague at BT, even at Ipswich (?), > >> can > >>>>>>>> you check those and agree with Phil how to go forward? Some > > of > >>>>>>>> those are clear, others need discussion with Phil. > >>>>>>>>>>> > >>>>>>>>>>> Gorry, on point 2) below, I don't follow Leslie's > >> arguments. I > >>>>>>>> asked from him detailed comments and resolutions months ago, > >> and nothing > >>>>>>>> came. > >>>>>>>>>>> > >>>>>>>>>>> cheers, > >>>>>>>>>>> Jukka > >>>>>>>>>>> > >>>>>>>>>>> On Sep 5, 2012, at 3:26 PM, Gorry Fairhurst wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Bob and Jukka, > >>>>>>>>>>>> > >>>>>>>>>>>> I think I need your help to resolve this... Some of the > >>>>>>>> comments raised by John Leslie appear to have substance, and > >> I'm > >>>>>>>> not sure what you plan to do to address these. > >>>>>>>>>>>> > >>>>>>>>>>>> It would be good to do something quick so that I can > >> complete > >>>>>>>> the submission to the IESG. > >>>>>>>>>>>> > >>>>>>>>>>>> The issues I particularly note are: > >>>>>>>>>>>> > >>>>>>>>>>>> 1) This contribution from Phil appears to be within > > scope > >> and > >>>>>>>> it seems may have been overlooked (sorry): > >>>>>>>>>>>> http://www.ietf.org/mail- > >> archive/web/tsvwg/current/msg11234.html > >>>>>>>>>>>> > >>>>>>>>>>>> 2) Can you be clear here about what is actually been > > said > >> - > >>>>>>>> because the point below seems to be a misunderstanding of > >> language > >>>>>>>> to me, and I hoped we did not claim this: > >>>>>>>>>>>> > >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find > > that > >> Bob is > >>>>>>>>>>>>>> actually ] saying that transport-layer should _only_ > >> consider > >>>>>>>>>>>>>> "congested bytes", not ] "congested packets". > >>>>>>>>>>>>>> ] > >>>>>>>>>>>> > >>>>>>>>>>>> 3) You'll need to post the updated draft and send a note > >> to > >>>>>>>> the group to confirm that the new version indeed concludes > > the > >>>>>>>> WGLC. I'll add a note to the writeup to indicate the draft > >> content > >>>>>>>> has been stable since Oct 2011. > >>>>>>>>>>>> > >>>>>>>>>>>> Gorry (with my TSVWG Documnent Shepherd hat) > >>>>>>>>>>>> cc: Co-Chairs for info. > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>> From: Gorry Fairhurst [ mailto:gorry@erg.abdn.ac.uk] > >>>>>>>>>>>>>> Sent: Mittwoch, 15. August 2012 21:41 > >>>>>>>>>>>>>> To: tsvwg chair > >>>>>>>>>>>>>> Subject: Fwd: Re: [tsvwg] FYI: Document writeup for > >>>>>>>>>>>>>> draft-ietf-tsvwg- byte-pkt-congest > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi guys, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Apart form the usual rhetoric, there are some points > >> here that we > >>>>>>>>>>>>>> should note as chairs. What are you own thoughts? And > >> was > >>>>>>>>>>>>>> anything noted at the IETF in Vancouver concerning > > this > >> draft? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Gorry > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -------- Original Message -------- > >>>>>>>>>>>>>> Subject: Re: [tsvwg] FYI: Document writeup for > >>>>>>>>>>>>>> draft-ietf-tsvwg-byte- pkt-congest > >>>>>>>>>>>>>> Date: Wed, 15 Aug 2012 15:07:28 -0400 > >>>>>>>>>>>>>> From: John Leslie > >>>>>>>>>>>>>> To: Gorry Fairhurst > >>>>>>>>>>>>>> CC: tsvwg@ietf.org > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Gorry Fairhurst wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The following document has been revised after > >> receiving > >>>>>>>> WGLC comments. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The changes are mostly refreshing a document > >> scheduled to > >>>>>>>>>>>>>> expire this month. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> No issues were found: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Is that with WGC-hat-on? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Neither my issues nor Philip Eardley's comments were > >> addressed. > >>>>>>>>>>>>>> In fact, not even the changes Bob Briscoe mentioned > > on- > >> list have > >>>>>>>>>>>>>> been included. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> As required by RFC 4858, this is the current template > >> for the > >>>>>>>>>>>>>> Document > >>>>>>>>>>>>>>> Shepherd Write-Up. > >>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>> (1) What type of RFC is being requested (BCP, > > Proposed > >> Standard, > >>>>>>>>>>>>>>> Internet Standard, Informational, Experimental, or > >> Historic)? > >>>>>>>>>>>>>>> Why is this the proper type of RFC? Is this type of > >> RFC > >>>>>>>>>>>>>>> indicated in the title page header? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> This document is intended as BCP. (This was discussed > >> at IETF-81 > >>>>>>>>>>>>>>> and that the status changed from Informational to BCP > >> since it > >>>>>>>>>>>>>>> provides guidance to implementors and people > >> configuring > >>>>>>>> routers and hosts). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thank you for finally answering my question about > > BCP > >> status. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>> Working Group Summary > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> There was consensus to publish this as a WG document > >> and > >>>>>>>>>>>>>>> agreement at > >>>>>>>>>>>>>>> IETF-82 that the document was now complete. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Was that reviewed on-list? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>> (3) Briefly describe the review of this document that > >> was > >>>>>>>>>>>>>>> performed > >>>>>>>>>>>>>> by > >>>>>>>>>>>>>>> the Document Shepherd. If this version of the > > document > >> is not > >>>>>>>>>>>>>>> ready for publication, please explain why the > > document > >> is being > >>>>>>>>>>>>>>> forwarded to the IESG. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The document was presented at IEWTF-82 (Taipei), with > >> a request > >>>>>>>>>>>>>>> for > >>>>>>>>>>>>>> WGLC. > >>>>>>>>>>>>>>> WGLC concluded with some discussion but no > > substantive > >> changes > >>>>>>>>>>>>>>> on Friday 30th March 2012. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Yes, I guess that is true; but ignoring substantive > >> comments > >>>>>>>>>>>>>> isn't a good practice IMHO. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> (4) Does the document Shepherd have any concerns > > about > >> the depth > >>>>>>>>>>>>>>> or breadth of the reviews that have been performed? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> No - the original draft had a lot of background > >> material, much > >>>>>>>>>>>>>>> of > >>>>>>>>>>>>>> this > >>>>>>>>>>>>>>> has been condensed or removed, resulting in a smaller > >> document. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> That is indeed what I basically asked for, but I > >> don't see any > >>>>>>>>>>>>>> evidence of it: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> - diff(07,08) 48 lines changed or deleted; 53 lines > >> changed or > >>>>>>>> added > >>>>>>>>>>>>>> - diff(06,07) 8 lines changed or deleted; 13 lines > >> changed or > >>>>>>>> added > >>>>>>>>>>>>>> - diff(05,06) 64 lines changed or deleted; 69 lines > >> changed or > >>>>>>>>>>>>>> added > >>>>>>>>>>>>>> - diff(04,05) 823 lines changed or deleted; 864 lines > >> changed or > >>>>>>>>>>>>>> added > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> (Need I go farther? That gets us back to March > > 2011...) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> (9) How solid is the WG consensus behind this > >> document? Does it > >>>>>>>>>>>>>>> represent the strong concurrence of a few > > individuals, > >> with > >>>>>>>>>>>>>>> others being silent, or does the WG as a whole > >> understand > >>>>>>>> and agree with it? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The document has WG support and there is consensus to > >> publish. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> This, IMHO, doesn't answer the question. :^( > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Does it represent the concurrence of a few > >> individuals, or does > >>>>>>>>>>>>>> the WG as a whole understand and agree with it? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> For reference, my comments included: > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] When I previously skimmed this document, I believed > >> it > >>>>>>>>>>>>>> contained only ] common ground: that AQM should > >> drop/mark packets > >>>>>>>>>>>>>> without favoring small ] packets, and that to whatever > >> extent > >>>>>>>>>>>>>> packet size _is_ considered, that ] should be a > >>>>>>>> transport-layer responsibility. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find > > that > >> Bob is > >>>>>>>>>>>>>> actually ] saying that transport-layer should _only_ > >> consider > >>>>>>>>>>>>>> "congested bytes", not ] "congested packets". > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] In fact, Bob openly endorses replacing TCP > >> congestion-control > >>>>>>>>>>>>>> with an ] algorithm which calculates "fair-share > > bytes" > >> and > >>>>>>>>>>>>>> doesn't back off at all ] (even in the presence of 20% > >> packet > >>>>>>>>>>>>>> loss) unless you're already sending ] more than this > >>>>>>>> "fair-share". > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] I do not believe that is the consensus of this > > WG; > >> and I > >>>>>>>> believe > >>>>>>>>>>>>>> if > >>>>>>>>>>>>>> ] that were the consensus it would exceed our charter. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] The draft contains a number of things I _do_ > > support; > >> and I'd > >>>>>>>>>>>>>> be happy ] to support a considerably shorter draft > >> which > >>>>>>>>>>>>>> concentrates on the AQM ] recommendation, omitting any > >>>>>>>>>>>>>> suggestions of modifying TCP congestion ] control. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> and Philip's comments included: > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] S2.2 I thought the numbered bullets could be better > >> phrased, > >>>>>>>>>>>>>> something like ] +this:- ] > >>>>>>>>>>>>>> ] 1. AQM algorithms such as RED SHOULD use packet- > >> mode > >>>>>>>> drop, ie they > >>>>>>>>>>>>>> SHOULD NOT > >>>>>>>>>>>>>> ] +use byte-mode drop. The latter ] is more complex, > >>>>>>>>>>>>>> ] it creates the perverse incentive to fragment > >> segments > >>>>>>>> into > >>>>>>>>>>>>>> tiny > >>>>>>>>>>>>>> ] pieces and it is vulnerable to floods of > >> small- > >>>>>>>>>>>>>> ] packets. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] 2. If a vendor has implemented byte-mode drop, > >> and an > >>>>>>>> operator > >>>>>>>>>>>>>> has > >>>>>>>>>>>>>> ] turned it on, it is RECOMMENDED to turn it > >> off, after > >>>>>>>>>>>>>> establishing if > >>>>>>>>>>>>>> ] +there are any implications on > >>>>>>>>>>>>>> ] the relative performance of > >>>>>>>>>>>>>> ] applications using different packet sizes. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] 3. RED SHOULD NOT be turned off. Without RED, a > >> drop tail > >>>>>>>>>>>>>> ] queue biases against large packets. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] Nit - the following paragraph shouldn't be indented > >> (Note well > >>>>>>>>>>>>>> that > >>>>>>>>>>>>>> RED's...) > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] S3.3 > >>>>>>>>>>>>>> ] The section could be slightly clearer. Starting with > >> the second > >>>>>>>>>>>>>> para, where you ] +start talking about something you > >> don't > >>>>>>>>>>>>>> recommend (ie you have to remember that ] +you're > >> talking about > >>>>>>>>>>>>>> the consequences of not following your > > recommendation). > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] S3.3 > >>>>>>>>>>>>>> ] o Also, if the network biases congestion > >> notification by > >>>>>>>> packet > >>>>>>>>>>>>>> size > >>>>>>>>>>>>>> ] it has to assume a baseline packet size--all > >> proposed > >>>>>>>>>>>>>> algorithms > >>>>>>>>>>>>>> ] use the local MTU. Then transports have to > >> guess which > >>>>>>>> link > >>>>>>>>>>>>>> was > >>>>>>>>>>>>>> ] congested and what its local MTU was, in order > >> to know > >>>>>>>> how to > >>>>>>>>>>>>>> ] tailor their congestion response to that link. > >>>>>>>>>>>>>> ] So you're saying that for byte-mode drop, the > > network > >> element > >>>>>>>>>>>>>> has to compare the ] +size of the current pkt with the > >> MTU, and > >>>>>>>>>>>>>> if it's 25* smaller then reduce the ] +pkt loss > >> probably by 25*? > >>>>>>>>>>>>>> And if the MTU was bigger, then the current pkt would > > ] > >> +be > >>>>>>>>>>>>>> dropped with greater probability? And both of these > >> things > >>>>>>>> are hard to do. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] S3.4 (& knock-on effect on 3.3) ] I think this could > >> be better. > >>>>>>>>>>>>>> ] I agree with your arguments in S3.1 & 3.2 that > >> dropping or > >>>>>>>>>>>>>> marking should be ] +independent of pkt size. > >>>>>>>>>>>>>> ] You now go into a couple of pages, which I think > >> could be > >>>>>>>>>>>>>> boiled down to a ] +paragraph, saying something like:- > >> ] * the > >>>>>>>>>>>>>> overall system (network + transport) has to be packet- > >> size > >>>>>>>>>>>>>> dependent in ] > >>>>>>>>>>>>>> +order to drive out the right amount of traffic so the > >> resource > >>>>>>>>>>>>>> becomes ] > >>>>>>>>>>>>>> +uncongested (since we assume all resources are in > >> practice byte > >>>>>>>>>>>>>> +rather > >>>>>>>>>>>>>> than ] +packet limited) ] * from S3.1 and S3.2 the > > IETF > >> is > >>>>>>>>>>>>>> convinced that the network should notify ] > > +independent > >> of > >>>>>>>> packet-size. > >>>>>>>>>>>>>> ] * therefore the transport must act dependent on > >> packet-size. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] It seems to me this is a necessary consequence of > >> your earlier > >>>>>>>>>>>>>> assumptions ] +/arguments. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] [On the other hand, if someone disagrees with the > >> arguments and > >>>>>>>>>>>>>> thinks that the ] +network should notify dependent on > >>>>>>>>>>>>>> packet-size, then it follows that the ] +transport can > >> act > >>>>>>>>>>>>>> independent of > >>>>>>>>>>>>>> packet- size.] ] ] I think in S3.3 you're trying to > >> make another > >>>>>>>>>>>>>> argument (?):- ] * we can either do packet-size > >> biasing in the > >>>>>>>>>>>>>> network element or on the end host ] +transport (see > >> argument > >>>>>>>>>>>>>> above) ] * packet-size biasing in the network is quite > >> tricky, > >>>>>>>>>>>>>> because then both the ] +network element & the > >> transport have to > >>>>>>>>>>>>>> make some guesses about MTU - whereas ] > >>>>>>>>>>>>>> +with packet-size biasing in the transport, neither > >> network > >>>>>>>>>>>>>> +element > >>>>>>>>>>>>>> nor ] +transport needs to know what the MTU is. > >>>>>>>>>>>>>> ] * it is also easier to implement packet-size biasing > >> in the > >>>>>>>>>>>>>> transport than in ] +the network. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] On the last bullet, I didn't really follow your > >> argument in > >>>>>>>> S3.5. > >>>>>>>>>>>>>> Might be ] +easier to follow if S3.5 also talked about > >> how a > >>>>>>>>>>>>>> network element would take ] +account of pkt size? > >> Also, does the > >>>>>>>>>>>>>> following argument also apply?: > >>>>>>>>>>>>>> ] * if pkt-size biasing is done in the transport, then > >> the work > >>>>>>>>>>>>>> (to do the ] +biasing) is spread over many end hosts, > > ] > >> * whereas > >>>>>>>>>>>>>> if pkt-size biasing is done in the network, then the > >> work is ] > >>>>>>>>>>>>>> +concentrated in just the congested network element, > >> which has to > >>>>>>>>>>>>>> operate on all ] +the traffic at line speed. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> (Has there perhaps been some confusion about what > >> went into the > >>>>>>>>>>>>>> -08 > >>>>>>>>>>>>>> version?) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>> John Leslie > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >> ________________________________________________________________ > >>>>>>>>>>> Bob Briscoe, BT Innovate & > >> Design > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >> ________________________________________________________________ > >>>>>>> Bob Briscoe, BT Innovate & > >> Design > >>>>>>> > >>>>> > >>>>> ________________________________________________________________ > >>>>> Bob Briscoe, BT Innovate & Design > >>> > >>> ________________________________________________________________ > >>> Bob Briscoe, BT Innovate & Design > > From hannes.tschofenig@gmx.net Thu Oct 11 09:15:22 2012 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 2759121F8620 for ; Thu, 11 Oct 2012 09:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.511 X-Spam-Level: X-Spam-Status: No, score=-101.511 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plco0aCoWrkp for ; Thu, 11 Oct 2012 09:15:19 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 84FA821F8613 for ; Thu, 11 Oct 2012 09:15:18 -0700 (PDT) Received: (qmail invoked by alias); 11 Oct 2012 16:14:33 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.112]) [88.115.216.191] by mail.gmx.net (mp016) with SMTP; 11 Oct 2012 18:14:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/u1qYhHD7uxvV/zR0GOuY3AuqZ65vlriq1zKu4S1 r5eBdtJxM9s6/v Date: Thu, 11 Oct 2012 19:14:22 +0300 Message-ID: <3b13x6brvbug1h4iu56gedbv.1349972062765@email.android.com> From: Hannes Tschofenig To: Ruediger.Geib@telekom.de MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Y-GMX-Trusted: 0 Cc: gorry@erg.abdn.ac.uk, philip.eardley@bt.com, tsvwg@ietf.org, tsvwg-chairs@ietf.org Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest 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, 11 Oct 2012 16:15:22 -0000 SGkgUnVlZGlnZXIsCgpDb0RlbCBpcyBhbiBBUU0gdGhhdCByZXBsYWNlcyBSRUQgKGF0IGxlYXN0 IHRoYXQncyB3aGF0IEkgdW5kZXJzdGFuZCBmcm9tIHJlYWRpbmcgdGhlIGF2YWlsYWJsZSBwdWJs aWNhdGlvbnMpLgoKSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgZm9yIHRoZSB0cmFuc3BvcnQg YXJlYSB0byB0aGluayBhYm91dCB3aGF0IHN0b3J5IGl0IHdhbnRzIHRvIGNvbW11bmljYXRlIHRv IHRoZSBJbnRlcm5ldCBjb21tdW5pdHkgd2hlbiBpdCBjb21lcyB0byBBUU0uIFJFRCwgQ29EZWws IGJvdGgsIHNvbWV0aGluZyBlbHNlPyAKCkNpYW8KSGFubmVzCgpQUzogSSBkb24ndCB3YW50IHRv IHByZXZlbnQgSnVra2EgYW5kIEJvYiBmcm9tIHB1Ymxpc2hpbmcgdGhlaXIgZG9jdW1lbnRzIChp biBmYWN0IHlvdSBjYW5ub3QgZXZlbiBkbyB0aGF0IGluIHRoZSBJRVRGIGFueXdheSkuIAoKU2Vu dCBmcm9tIG15IEFTVVMgUGFkCgpSdWVkaWdlci5HZWliQHRlbGVrb20uZGUgd3JvdGU6Cgo+SGkg SGFubmVzLAo+Cj5oYXZlbid0IGJlZW4gYXQgdGhlIHdvcmtzaG9wIG9yIGxhc3QgSUVURiwgcmVh ZCBpbnRvIHRoZSBkcmFmdAo+YW5kIGludG8gQ29kZWw6Cj4tIGl0IGlzIHVuY2xlYXIgdG8gbWUs IHdoZXRoZXIgY29kZWwgaXMgZGVhbGluZyB3aXRoIENQRSBpc3N1ZXMKPiAgb3IgUkVEIGluIGdl bmVyYWwuCj4tIEkndmUgdW5kZXJzdG9vZCBCb2JzL0p1a2thcyBkcmFmdCB0byBkZWFsIHdpdGgg UkVEIGluIGdlbmVyYWwuCj4KPklmIENvZGVsIGlzIGFib3V0IFJFRCBpbiBnZW5lcmFsLCBiYWNr Ym9uZSByb3V0ZXIgdmVuZG9yIHN1cHBvcnQKPmlzIHJlcXVpcmVkLiBIYXMgdGhlcmUgYmVlbiBm ZWVkYmFjayBmcm9tIHRoaXMgY29tbXVuaXR5Pwo+Cj5JdCBtYXkgYmUgYSBnb29kIGlkZWEgdG8g dHJ5IHRvIGZpbmFsaXNlIHRoZSB3b3JrIG9mIEJvYiBhbmQgSnVra2EuCj4KPlJlZ2FyZHMsCj4K PlLDvGRpZ2VyCj4KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj5Gcm9tOiB0c3Z3Zy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFRzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNwb28pCj5TZW50OiBUaHVyc2RheSwgT2N0 b2JlciAxMSwgMjAxMiAyOjU4IFBNCj5UbzogZXh0IE1hbm5lciBKdWtrYQo+Q2M6IGdvcnJ5QGVy Zy5hYmRuLmFjLnVrOyBwaGlsaXAuZWFyZGxleUBidC5jb207IHRzdndnIElFVEYgbGlzdDsgdHN2 d2ctY2hhaXJzQGlldGYub3JnCj5TdWJqZWN0OiBSZTogW3RzdndnXSBbUkVWSVNFRCBJLURdOiBE b2N1bWVudCB3cml0ZXVwIGZvciBkcmFmdC1pZXRmLXRzdndnLWJ5dGUtcGt0LWNvbmdlc3QKPgo+ SGkgSnVra2EsCj4KPldpdGggUW9TIHRoZXJlIGlzIG5vIHN1Y2ggdGhpbmcgYXMgInNob3J0IHRl cm0iIChhcyB3ZSBhbHJlYWR5IGhhZCB0bwo+bGVhcm4gcGFpbmZ1bGx5KS4KPgo+VGhhdCBtYWtl cyBtZSB3b25kZXIgd2hhdCBpcyBtb3JlIHVzZWZ1bDogcHVibGlzaCBhIGRvY3VtZW50IHRoYXQK PmRlc2NyaWJlIGhvdyB0byBjb25maWd1cmUgUkVEIGNvcnJlY3RseSBvciB0byBnbyBmb3IgYW4g QVFNIHRlY2huaXF1ZQo+dGhhdCAoYWNjb3JkaW5nIHRvIHRoZSBhdXRob3JzKSB3b3JrcyBhbG1v c3QgemVybyBjb25maWd1cmF0aW9uLgo+Cj5NeSB0YWtlLWF3YXkgZnJvbSB0aGUgVmFuY291dmVy IGNvbmdlc3Rpb24gY29udHJvbCB3b3Jrc2hvcCB3YXMgdGhhdCBpdAo+aXMgYmV0dGVyIHRvIGln bm9yZSBSRUQuIChNYXliZSBteSBpbXByZXNzaW9uIHdhcyB3cm9uZyAtLSBzb21lb25lIGVsc2UK PnNob3VsZCBjb25maXJtLikKPgo+Q2lhbwo+SGFubmVzCj4KPgo+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQo+PiBGcm9tOiBleHQgTWFubmVyIEp1a2thIFttYWlsdG86anVra2EubWFubmVy QGFhbHRvLmZpXQo+PiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxMSwgMjAxMiAzOjUwIFBNCj4+ IFRvOiBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJL0VzcG9vKQo+PiBDYzogQm9iIEJyaXNj b2U7IDxnb3JyeUBlcmcuYWJkbi5hYy51az47IDxwaGlsaXAuZWFyZGxleUBidC5jb20+Owo+PiA8 dHN2d2ctY2hhaXJzQGlldGYub3JnPjsgdHN2d2cgSUVURiBsaXN0Cj4+IFN1YmplY3Q6IFJlOiBb dHN2d2ddIFtSRVZJU0VEIEktRF06IERvY3VtZW50IHdyaXRldXAgZm9yIGRyYWZ0LWlldGYtCj4+ IHRzdndnLWJ5dGUtcGt0LWNvbmdlc3QKPj4KPj4gSGksIHRoaXMgZG9jdW1lbnQgdGFsa3MgYWJv dXQgdGhlIGN1cnJlbnQgYW5kIHNob3J0IHRlcm0gZ29hbHMgYW5kCj4+IG9wZXJhdGlvbnMsIHdo aWxlIEFGQUlLIENvRGVsIGlzIGEgbW9yZSBmdXR1cmlzdGljIGNvbmNlcHQsCj5pbnRlcmVzdGlu Zwo+PiBjb25jZXB0LCBzdXJlLCBidXQgbm90IGRlcGxveWVkIGF0IGxhcmdlLgo+Pgo+PiBjaGVl cnMsCj4+IEp1a2thCj4+Cj4+IE9uIE9jdCAxMSwgMjAxMiwgYXQgMzo0NCBQTSwgVHNjaG9mZW5p ZywgSGFubmVzIChOU04gLSBGSS9Fc3BvbykKPndyb3RlOgo+Pgo+PiA+IEhpIEp1a2thLCBIaSBC b2IsCj4+ID4KPj4gPiBoYXZpbmcgbGlzdGVuZWQgdG8gdGhlIHByZXNlbnRhdGlvbnMgYWJvdXQg Q29EZWwgSSBhbSB3b25kZXJpbmcKPj4gd2hldGhlcgo+PiA+IHRoaXMgZG9jdW1lbnQgbWF5IGhh dmUgdGFrZW4gb3ZlciBieSBldmVudHMgYW5kIGlzIG9ic29sZXRlIGJ5IG5vdy4KPj4gPiBXaGF0 J3MgeW91ciB2aWV3IG9uIHRoYXQ/Cj4+ID4KPj4gPiBDaWFvCj4+ID4gSGFubmVzCj4+ID4KPj4g Pgo+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+PiA+PiBGcm9tOiB0c3Z3Zy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24KPj4gQmVoYWxm Cj4+ID4+IE9mIGV4dCBNYW5uZXIgSnVra2EKPj4gPj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIg MTEsIDIwMTIgMzozNCBQTQo+PiA+PiBUbzogQm9iIEJyaXNjb2UKPj4gPj4gQ2M6IDxnb3JyeUBl cmcuYWJkbi5hYy51az47IDxwaGlsaXAuZWFyZGxleUBidC5jb20+OyA8dHN2d2ctCj4+ID4+IGNo YWlyc0BpZXRmLm9yZz47IHRzdndnIElFVEYgbGlzdAo+PiA+PiBTdWJqZWN0OiBSZTogW3Rzdndn XSBbUkVWSVNFRCBJLURdOiBEb2N1bWVudCB3cml0ZXVwIGZvcgo+ZHJhZnQtaWV0Zi0KPj4gPj4g dHN2d2ctYnl0ZS1wa3QtY29uZ2VzdAo+PiA+Pgo+PiA+PiBIaSwKPj4gPj4KPj4gPj4gWWVhaCwg cGxlYXNlIGF0IHRoZSBwb2ludCBhYm91dCBjaGVhcCBkZXZpY2VzLCBzdGlsbCwgSSB3b25kZXIg d2hhdAo+PiA+IHRoZQo+PiA+PiBjb3N0IG9mIEFRTSBpcyBvbiB0aG9zZSBkZXZpY2VzLiBNYXli ZSAxIGNudCBpbiBtYXNzIHByb2R1Y3Rpb24/Cj4+IFRodXMsCj4+ID4+IEkgc3RpbGwgd29uZGVy IGlmIGl0IGlzIHdvcnRoIGFyZ3Vpbmcgc29tZXRoaW5nIGFib3V0IHRoZSBmdXR1cmUKPj4gdGhh dAo+PiA+PiBzdHJvbmdseS4KPj4gPj4KPj4gPj4gU29ycnksIGJ1dCB0aGUgc2FtZSBnb2VzIGZv ciBBUU0gaW4gZ2VuZXJhbCwgYW5kIHdoZXJlIGl0IGlzLCBvcgo+PiB3aWxsCj4+ID4+IG5vdCBi ZSBkZXBsb3llZC4gSSB1bmRlcnN0YW5kIHRlY2huaWNhbCByZWFzb25zIHdoeSBub3Qgc29tZXRo aW5nCj5pcwo+PiA+PiBmZWFzaWJsZSwgYnV0IGJ1c2luZXNzIG9yIG1vbmV0YXJ5IHJlYXNvbnMg Y2FuIGNoYW5nZSB2ZXJ5IHF1aWNrbHkuCj4+IDspCj4+ID4+Cj4+ID4+IEp1a2thCj4+ID4+Cj4+ ID4+IE9uIE9jdCAxMSwgMjAxMiwgYXQgMzowOCBQTSwgQm9iIEJyaXNjb2Ugd3JvdGU6Cj4+ID4+ Cj4+ID4+PiBKdWtrYSwKPj4gPj4+Cj4+ID4+PiBXaGF0IEkgaGFkIGluIG1pbmQgaXMgYWxsIGxv dyBsZXZlbCBidWZmZXJzIGluIGNoZWFwIHB1cmUgTDIKPj4gPiBkZXZpY2VzLAo+PiA+PiBpbiBj aGVhcCBOQVRzIGV0Yy4gSSB3YXMgZ29pbmcgdG8gbGlzdCBzb21lIG9mIHRoZXNlLCBidXQgaW5z dGVhZAo+PiA+IGNob3NlCj4+ID4+IHRvIHNheSAibm8tb25lIGV4cGVjdHMgQVFNIHRvIGJlIHVu aXZlcnNhbGx5IGRlcGxveWVkIi4gVGhpcwo+Y2xlYXJseQo+PiA+PiBtaXNzZWQgdGhlIG1hcmsu Cj4+ID4+Pgo+PiA+Pj4gU2hvdWxkIHdlIGluY2x1ZGUgc29tZSBvZiB0aGVzZSBjb25jcmV0ZSBl eGFtcGxlcyBvZiB3aGVyZSBBUU0KPj4gd29uJ3QKPj4gPj4gYmUgZGVwbG95ZWQgaW5zdGVhZD8K Pj4gPj4+Cj4+ID4+PiBbSSd2ZSBjYydkIHRoZSBsaXN0LCBnaXZlbiB3ZSdyZSBzdGFydGluZyB0 byB3b3Jkc21pdGgKPj4gc2lnbmlmaWNhbnRseQo+PiA+PiBuZXcgdGV4dCBhZGRlZCBzaW5jZSBX RyBsYXN0IGNhbGwuXQo+PiA+Pj4KPj4gPj4+Cj4+ID4+PiBCb2IKPj4gPj4+Cj4+ID4+PiBBdCAy MDowNCAxMC8xMC8yMDEyLCBNYW5uZXIgSnVra2Egd3JvdGU6Cj4+ID4+Pj4gSGksIGxvb2tlZCBn b29kIHRvIG1lLiBKdXN0IG9uZSBjb21tZW50LCBJIHdvdWxkbid0IHB1dCB0aGF0IG11Y2gKPj4g Pj4gZW1waGFzaXMgb24gd2hhdCBpcyBhIHByb2JhYmx5IHN0YXRlIG9mIHRoaW5ncywgZS5nLgo+ PiA+Pj4+Cj4+ID4+Pj4gIm5vLW9uZSBleHBlY3RzIEFRTSB0byBldmVyIGJlIC4uIiAgPiBpbiB0 aGUgZnV0dXJlIGl0IG1pZ2h0LCB3ZQo+PiA+PiBkb24ndCBrbm93LCBhbmQgc2luY2UgdGhlIHBh cmFncmFwaCBzYXlzIHRoYXQgaXQgZG9lc24ndCBtYXR0ZXIKPj4gPiBhbnl3YXksCj4+ID4+IEkg d291bGQgZm9ybXVsYXRlIHRoaXMgcGFyYWdyYXBoIGEgYml0IHRvd2FyZHMgdGhhdCB3ZSBoYXZl IHBhcnRpYWwKPj4gPj4gZGVwbG95bWVudCBub3cgYW5kICBldmVuIHdpdGggYSBmdWxsIGRlcGxv eW1lbnQsIC4uLgo+PiA+Pj4+Cj4+ID4+Pj4gYW5kIHNpbWlsYXJseSB3aXRoIHRoZSB1bnJlYWxp c3RpYyBkZXBsb3ltZW50IG9mIEFRTSBpbiB0aGUKPj4gPj4gc3Vic2VxdWVudCBwYXJhZ3JhcGgu Cj4+ID4+Pj4KPj4gPj4+PiBjaGVlcnMsCj4+ID4+Pj4gSnVra2EKPj4gPj4+Pgo+PiA+Pj4+IE9u IE9jdCAxMCwgMjAxMiwgYXQgNjoyNSBQTSwgQm9iIEJyaXNjb2Ugd3JvdGU6Cj4+ID4+Pj4KPj4g Pj4+Pj4gUGhpbCwKPj4gPj4+Pj4KPj4gPj4+Pj4gU29ycnkgZm9yIGRlbGF5LCBteSByb3VuZC1y b2JpbiBzY2hlZHVsZXIgaXMgdGFraW5nIHNvIGxvbmcgdG8KPj4gPiBnZXQKPj4gPj4gcm91bmQg YWxsIHRoZSB0YXNrcyB0aGF0IEkga2VlcCBmaW5kaW5nIGRlYWQgcm9iaW5zICh0aGF0IHJlbWlu ZHMKPm1lCj4+ID4gb2YKPj4gPj4gYSBiaWtlIHJpZGUgbXkgZ3JhbmRtb3RoZXIgdG9vay4gT24g aGVyIHJldHVybiwgc2hlIHNhaWQgdGhlcmUgd2VyZQo+PiBhCj4+ID4+IHdvcnJ5aW5nbHkgbGFy Z2UgbnVtYmVyIG9mIHJvYmlucyBydW4gb3ZlciBvbiB0aGUgcm9hZHMuIEl0IHR1cm5lZAo+PiBv dXQKPj4gPj4gdGhhdCBzaGUgaGFkIGJlZW4gZ29pbmcgcm91bmQgdGhlIHNhbWUgc21hbGwgdHJp YW5nbGUgb2Ygcm9hZHMKPj4gPiBtdWx0aXBsZQo+PiA+PiB0aW1lcykuCj4+ID4+Pj4+Cj4+ID4+ Pj4+IEkndmUgZG9uZSBhIGNvbXBsZXRlIHJlLXdyaXRlIG9mIDMuNC4gSSBob3BlIHlvdSB3aWxs IGFncmVlIHRoYXQKPj4gPj4gaXQgcmVhbGx5IGlzIGEgbW90aXZhdGluZyBhcmd1bWVudCBub3cg YW5kIGl0IGNhbiBzdGF5IHdoZXJlIGl0IGlzCj4tCj4+ID4gaXQKPj4gPj4gaXMgbm90IGp1c3Qg YSBwcmVhbWJsZS4KPj4gPj4+Pj4KPj4gPj4+Pj4gSSd2ZSBnb25lIGJhY2sgdG8gdGhlIHZlcnkg Zmlyc3QgdmVyc2lvbiBvZiAzLjQgSSB3cm90ZSBhbmQgSQo+bm93Cj4+ID4+IHJlYWxpc2UgdGhh dCBJIGhhZCB3cml0dGVuIHRoZSBjb3JlIG9mIHRoZSBhcmd1bWVudCBzbyBiYWRseSB0aGF0Cj4+ IGV2ZW4KPj4gPj4gSSBmb3Jnb3Qgd2hhdCBpdCB3YXMgbWVhbnQgdG8gc2F5IHdoZW4gd2Ugc3Rh cnRlZCBlZGl0aW5nIGl0LiBJbgo+dGhlCj4+ID4+IGRyYWZ0LTA4IHZlcnNpb24sIHRoZSBvcmln aW5hbCBtZWFuaW5nIGlzIGxvc3QgYW5kIGluIHlvdXIgcmUtCj4+IHdvcmRpbmcKPj4gPj4gaXQg aXMgZW50aXJlbHkgbG9zdC4gVGhlIGxpbmsgd2l0aCB0aGUgZHJhZnQtMDggdmVyc2lvbiBpcyBu ZWFybHkKPj4gPj4gdW5yZWNvZ25pc2FibGUsIGJ1dCBpdCdzIHRoZSBhcmd1bWVudCBJIGludGVu ZGVkIGhlcmUuCj4+ID4+Pj4+Cj4+ID4+Pj4+Cj4+ID4+Cj4+ID4KPj4KPj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Cj4+ID4+ID09PT09PT09PT09PT09PQo+PiA+Pj4+PiAzLjQuICBQZXJtYW5lbnQgUGFydGlhbCBE ZXBsb3ltZW50IG9mIEFRTQo+PiA+Pj4+Pgo+PiA+Pj4+PiBJbiBvdmVydmlldywgdGhlIGFyZ3Vt ZW50IGluIHRoaXMgc2VjdGlvbiBydW5zIGFzIGZvbGxvd3M6Cj4+ID4+Pj4+ICogQmVjYXVzZSB0 aGUgbmV0d29yayB3aWxsIG5vdCBhbmQgY2Fubm90IGFsd2F5cyBkcm9wIHBhY2tldHMgaW4KPj4g Pj4gcHJvcG9ydGlvbiB0byB0aGVpciBzaXplLCBpdCBzaG91bGRuJ3QgYmUgZ2l2ZW4gdGhlIHRh c2sgb2YgbWFraW5nCj4+ID4gZHJvcAo+PiA+PiBzaWduYWxzIGRlcGVuZCBvbiBwYWNrZXQgc2l6 ZSBhdCBhbGwuCj4+ID4+Pj4+ICogVHJhbnNwb3J0cyBvbiB0aGUgb3RoZXIgaGFuZCBkb24ndCBh bHdheXMgd2FudCB0byBtYWtlIHRoZWlyCj4+ID4+IHJhdGUgcmVzcG9uc2UgcHJvcG9ydGlvbmFs IHRvIHRoZSBzaXplIG9mIGRyb3BwZWQgcGFja2V0cywgYnV0IGlmCj4+IHRoZXkKPj4gPj4gd2Fu dCB0bywgdGhleSBhbHdheXMgY2FuLgo+PiA+Pj4+Pgo+PiA+Pj4+PiBUaGUgYXJndW1lbnQgaXMg c2ltaWxhciB0byB0aGUgZW5kLXRvLWVuZCBhcmd1bWVudCB0aGF0IHNheXMKPj4gPj4gIkRvbid0 IGRvIFggaW4gdGhlIG5ldHdvcmsgaWYgZW5kLXN5c3RlbXMgY2FuIGRvIFggYnkgdGhlbXNlbHZl cywKPj4gYW5kCj4+ID4+IHRoZXkgd2FudCB0byBiZSBhYmxlIHRvIGNob29zZSB3aGV0aGVyIHRv IGRvIFggYW55d2F5LiIgQWN0dWFsbHkKPnRoZQo+PiA+PiBmb2xsb3dpbmcgYXJndW1lbnQgaXMg c3Ryb25nZXI7IGluIGFkZGl0aW9uIGl0IHNheXMgIkRvbid0IGdpdmUgdGhlCj4+ID4+IG5ldHdv cmsgdGFzayBYIHRoYXQgY291bGQgYmUgZG9uZSBieSB0aGUgZW5kLXN5c3RlbXMsIGlmIFggd29u J3QKPj4gZXZlcgo+PiA+PiBiZSBkZXBsb3llZCBvbiBhbGwgbmV0d29yayBub2RlcywgYW5kIGVu ZC1zeXN0ZW1zIHdvbid0IGJlIGFibGUgdG8KPj4gPiB0ZWxsCj4+ID4+IHdoZXRoZXIgdGhlaXIg bmV0d29yayBpcyBkb2luZyBYLCBvciB3aGV0aGVyIHRoZXkgbmVlZCB0byBkbyBYCj4+ID4+IHRo ZW1zZWx2ZXMuIiBJbiB0aGlzIGNhc2UsIHRoZSBYIGluIHF1ZXN0aW9uIGlzICJtYWtpbmcgdGhl Cj5yZXNwb25zZQo+PiA+IHRvCj4+ID4+IGNvbmdlc3Rpb24gZGVwZW5kIG9uIHBhY2tldCBzaXpl Ii4KPj4gPj4+Pj4KPj4gPj4+Pj4gV2Ugd2lsbCBub3cgcmUtcnVuIHRoaXMgYXJndW1lbnQgdGFr aW5nIGVhY2ggc3RlcCBpbiBtb3JlIGRlcHRoLgo+PiA+PiBUaGUgYXJndW1lbnQgYXBwbGllcyBz b2xlbHkgdG8gZHJvcCwgbm90IEVDTiBtYXJraW5nLgo+PiA+Pj4+Pgo+PiA+Pj4+PiBBIHF1ZXVl IGRyb3BzIHBhY2tldHMgZm9yIGVpdGhlciBvZiB0d28gcmVhc29uczogYSkgdG8gc2lnbmFsIHRv Cj4+ID4+IGhvc3QgY29uZ2VzdGlvbiBjb250cm9scyB0aGF0IHRoZXkgc2hvdWxkIHJlZHVjZSB0 aGUgbG9hZCBhbmQgYikKPj4gPj4gYmVjYXVzZSB0aGVyZSBpcyBubyBidWZmZXIgbGVmdCB0byBz dG9yZSB0aGUgcGFja2V0cy4gQWN0aXZlIHF1ZXVlCj4+ID4+IG1hbmFnZW1lbnQgdHJpZXMgdG8g dXNlIGRyb3BzIGFzIGEgc2lnbmFsIGZvciBob3N0cyB0byBzbG93IGRvd24KPj4gKGNhc2UKPj4g Pj4gYSkgc28gdGhhdCBkcm9wIGR1ZSB0byBidWZmZXIgZXhoYXVzdGlvbiAoY2FzZSBiKSBzaG91 bGQgbm90IGJlCj4+ID4+IG5lY2Vzc2FyeS4KPj4gPj4+Pj4KPj4gPj4+Pj4gTm8tb25lIGV4cGVj dHMgQVFNIHRvIGV2ZXIgYmUgdW5pdmVyc2FsbHkgZGVwbG95ZWQgaW4gZXZlcnkKPnF1ZXVlCj4+ ID4+IGluIHRoZSBJbnRlcm5ldDsgYW5kLCBldmVuIGlmIEFRTSB3ZXJlIHVuaXZlcnNhbCwgaXQg aGFzIHRvIGJlIGFibGUKPj4gdG8KPj4gPj4gY29wZSB3aXRoIGJ1ZmZlciBleGhhdXN0aW9uIChi eSBzd2l0Y2hpbmcgdG8gYSBiZWhhdmlvdXIgbGlrZSB0YWlsLQo+PiA+PiBkcm9wKSwgaW4gb3Jk ZXIgdG8gY29wZSB3aXRoIHVucmVzcG9uc2l2ZSBvciBleGNlc3NpdmUgdHJhbnNwb3J0cy4KPj4g Pj4gVGhlcmVmb3JlIG5ldHdvcmtzIHdpbGwgb2Z0ZW4gYmUgZHJvcHBpbmcgcGFja2V0cyBhcyBh IGxhc3QgcmVzb3J0Cj4+ID4+IChjYXNlIGIpIHJhdGhlciB0aGFuIHVuZGVyIEFRTSBjb250cm9s IChjYXNlIGEpLgo+PiA+Pj4+Pgo+PiA+Pj4+PiBXaGVuIGJ1ZmZlcnMgYXJlIGV4aGF1c3RlZCAo Y2FzZSBiKSwgdGhleSBkb24ndCBuYXR1cmFsbHkgZHJvcAo+PiA+PiBwYWNrZXRzIGluIHByb3Bv cnRpb24gdG8gdGhlaXIgc2l6ZS4gVGhlIG5ldHdvcmsgY2FuIG9ubHkgcmVkdWNlCj50aGUKPj4g Pj4gcHJvYmFiaWxpdHkgb2YgZHJvcHBpbmcgc21hbGxlciBwYWNrZXRzIGlmIGl0IGhhcyBlbm91 Z2ggc3BhY2UgdG8KPj4gPiBzdG9yZQo+PiA+PiB0aGVtIHNvbWV3aGVyZSB3aGlsZSBpdCB3YWl0 cyBmb3IgYSBsYXJnZXIgcGFja2V0IHRoYXQgaXQgY2FuIGRyb3AuCj4+IElmCj4+ID4+IHRoZSBi dWZmZXIgaXMgZXhoYXVzdGVkLCBpdCBkb2VzIG5vdCBoYXZlIHRoaXMgY2hvaWNlLiBBZG1pdHRl ZGx5Cj4+ID4gdGFpbC0KPj4gPj4gZHJvcCBkb2VzIG5hdHVyYWxseSBkcm9wIHNvbWV3aGF0IGZl d2VyIHNtYWxsIHBhY2tldHMsIGJ1dCBleGFjdGx5Cj4+IGhvdwo+PiA+PiBmZXcgZGVwZW5kcyBt b3JlIG9uIHRoZSBtaXggb2Ygc2l6ZXMgdGhhbiB0aGUgc2l6ZSBvZiB0aGUgcGFja2V0IGluCj4+ ID4+IHF1ZXN0aW9uLiBOb25ldGhlbGVzcywgaW4gZ2VuZXJhbCwgaWYgd2Ugd2FudGVkIG5ldHdv cmtzIHRvIGRvCj5zaXplLQo+PiA+PiBkZXBlbmRlbnQgZHJvcCwgd2Ugd291bGQgbmVlZCB1bml2 ZXJzYWwgZGVwbG95bWVudCBvZiAocGFja2V0LXNpemUKPj4gPj4gZGVwZW5kZW50KSBBUU0gY29k ZSwgd2hpY2ggaXMgdW5yZWFsaXN0aWMuCj4+ID4+Pj4+Cj4+ID4+Pj4+IEEgaG9zdCB0cmFuc3Bv cnQgY2Fubm90IGtub3cgd2hldGhlciBhbnkgcGFydGljdWxhciBkcm9wIHdhcyBhCj4+ID4+IGRl bGliZXJhdGUgc2lnbmFsIGZyb20gYW4gQVFNIG9yIGEgc2lnbiBvZiBhIHF1ZXVlIHNoZWRkaW5n IHBhY2tldHMKPj4gPiBkdWUKPj4gPj4gdG8gYnVmZmVyIGV4aGF1c3Rpb24uIFRoZXJlZm9yZSwg YmVjYXVzZSB0aGUgbmV0d29yayBjYW5ub3QKPj4gPiB1bml2ZXJzYWxseQo+PiA+PiBkbyBzaXpl LWRlcGVuZGVudCBkcm9wLCBpdCBzaG91bGQgbm90IGRvIGl0IGFsbC4KPj4gPj4+Pj4KPj4gPj4+ Pj4gV2hlcmVhcyB1bml2ZXJzYWxpdHkgaXMgZGVzaXJhYmxlIGluIHRoZSBuZXR3b3JrLCBkaXZl cnNpdHkgaXMKPj4gPj4gZGVzaXJhYmxlIGJldHdlZW4gZGlmZmVyZW50IHRyYW5zcG9ydCBsYXll ciBwcm90b2NvbHMgLSBzb21lLCBsaWtlCj4+ID4+IE5ld1Jlbm8gVENQIFtSRkM1NjgxXSwgbWF5 IG5vdCBjaG9vc2UgdG8gbWFrZSB0aGVpciByYXRlIHJlc3BvbnNlCj4+ID4+IHByb3BvcnRpb25h dGUgdG8gdGhlIHNpemUgb2YgZWFjaCBkcm9wcGVkIHBhY2tldCwgd2hpbGUgb3RoZXJzIHdpbGwK Pj4gPj4gKGUuZy4gVEZSQy1TUCBbUkZDNDgyOF0pLgo+PiA+Pj4+Pgo+PiA+Pgo+PiA+Cj4+Cj49 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQo+PiA+PiA9PT09PT09PT09PT09PT0KPj4gPj4+Pj4KPj4gPj4+Pj4KPj4g Pj4+Pj4KPj4gPj4+Pj4KPj4gPj4+Pj4gQm9iCj4+ID4+Pj4+Cj4+ID4+Pj4+IEF0IDEzOjEzIDA0 LzEwLzIwMTIsIGdvcnJ5QGVyZy5hYmRuLmFjLnVrIHdyb3RlOgo+PiA+Pj4+Pj4gVGhhdCB3b3Vs ZCBiZSBicmlsbGlhbnQhCj4+ID4+Pj4+Pgo+PiA+Pj4+Pj4gR29ycnkKPj4gPj4+Pj4+Cj4+ID4+ Pj4+Pj4gV2lsbCB0cnkgdG8gbG9vayBhdCB0aGlzIGxhdGVyIHRvZGF5Lgo+PiA+Pj4+Pj4+Cj4+ ID4+Pj4+Pj4KPj4gPj4+Pj4+PiBCb2IKPj4gPj4+Pj4+Pgo+PiA+Pj4+Pj4+IEF0IDEwOjQyIDAy LzEwLzIwMTIsIHBoaWxpcC5lYXJkbGV5QGJ0LmNvbSB3cm90ZToKPj4gPj4+Pj4+Pj4gVGhpbmsg dGhlIHRva2VuIGlzIHdpdGggYm9iCj4+ID4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+IFJlIHlvdXIgY29t bWVudCAtIHllcywgSSB0aGluayB5b3UgY291bGQgbW92ZSAzLjQgdG8gdGhlIGVuZAo+PiA+IG9m Cj4+ID4+IFMzIC0KPj4gPj4+Pj4+Pj4gb3IgdG8gdGhlIHN0YXJ0IC0gYW5kIGRvIHNvbWUgcmUt cGhyYXNpbmcsIG1heWJlIHNvbWV0aGluZwo+PiA+IGxpa2UKPj4gPj4gSSB0cmllZC4KPj4gPj4+ Pj4+Pj4KPj4gPj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPj4gPj4+Pj4+Pj4g RnJvbTogTWFubmVyIEp1a2thIFttYWlsdG86anVra2EubWFubmVyQGFhbHRvLmZpXQo+PiA+Pj4+ Pj4+PiBTZW50OiAwMSBPY3RvYmVyIDIwMTIgMjA6MTgKPj4gPj4+Pj4+Pj4gVG86IEVhcmRsZXks UEwsUGhpbGlwLERVQjggUjsgQnJpc2NvZSxSSixCb2IsRFVCOCBSCj4+ID4+Pj4+Pj4+IENjOiB0 c3Z3Zy1jaGFpcnNAaWV0Zi5vcmc7IEdvcnJ5IEZhaXJodXJzdAo+PiA+Pj4+Pj4+PiBTdWJqZWN0 OiBSZTogW1JFVklTRUQgSS1EXTogRG9jdW1lbnQgd3JpdGV1cCBmb3IKPj4gPj4+Pj4+Pj4gZHJh ZnQtaWV0Zi10c3Z3Zy1ieXRlLXBrdC1jb25nZXN0Cj4+ID4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+IFBo aWwsIEJvYiwgY2FuIHdlIGNsb3NlIHRoaXMgZmluYWxseT8gSXQncyB0aHJlZSB3ZWVrcyBub3cK Pj4gPj4gc2luY2UKPj4gPj4+Pj4+Pj4gdGhpcyBwcmV2aW91cyBtZXNzYWdlLgo+PiA+Pj4+Pj4+ Pgo+PiA+Pj4+Pj4+PiBKdWtrYQo+PiA+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+PiBPbiBTZXAgMTAsIDIw MTIsIGF0IDQ6NDIgUE0sIEp1a2thIE1hbm5lciB3cm90ZToKPj4gPj4+Pj4+Pj4KPj4gPj4+Pj4+ Pj4+IEFjaywgSSdtIGdldHRpbmcgdGhlcmUuLi47KQo+PiA+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+ IFNvLCB3ZSBjb3VsZCBtb3ZlIDMuNCBhdCB0aGUgZW5kIG9mIFNlY3Rpb24gMyBhbmQgcmVwaHJh c2UKPj4gPj4gaXQgdG8KPj4gPj4+Pj4+Pj4gbm90IHRhbGsgYWJvdXQgc2NhbGluZyBwZXIgc2Us IGJ1dCByYXRoZXIgYWJvdXQgaG93IFJlcSAyLjIKPj4gPj4+Pj4+Pj4gZXZlbnR1YWxseSBsZWFk cyB0byBSZXEgMi4zPwo+PiA+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+IEp1a2thCj4+ID4+Pj4+Pj4+ Pgo+PiA+Pj4+Pj4+Pj4gT24gU2VwIDcsIDIwMTIsIGF0IDQ6MDcgUE0sIDxwaGlsaXAuZWFyZGxl eUBidC5jb20+Cj4+ID4+Pj4+Pj4+PiA8cGhpbGlwLmVhcmRsZXlAYnQuY29tPiB3cm90ZToKPj4g Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4gMy40IGlzLCBpbiBteSBtaW5kLCBjb21wbGV0ZWx5IGRp ZmZlcmVudCBmcm9tIDMuMSwgMy4yLAo+PiA+IDMuMwo+PiA+PiBhbmQgMy41Lgo+PiA+Pj4+Pj4+ Pj4+Cj4+ID4+Pj4+Pj4+Pj4gMy4xLCAzLjIsIDMuMyBhbmQgMy41IHByZXNlbnQgbW90aXZhdGlu ZyBhcmd1bWVudHMgZm9yCj4+ID4+IFJlY29tbWVuZGF0aW9uCj4+ID4+Pj4+Pj4+Pj4gMi4yICYg YSBsZXNzZXIgZXh0ZW50IDIuMwo+PiA+Pj4+Pj4+Pj4+IDMuNCBtYWtlcyBkb2Vzbid0IG1ha2Ug YSBtb3RpdmF0aW5nIGFyZ3VtZW50IC0gaXQgZXhwbGFpbnMKPj4gPj4gdGhhdCAgUmVjCj4+ID4+ Pj4+Pj4+Pj4gMi4yICYgMi4zIGNvbWUgYXMgYSBwYWlyIChpZiB5b3UgcmVjb21tZW5kIG9uZSwg dGhlbgo+PiA+PiBpbmV2aXRhYmx5IHlvdQo+PiA+Pj4+Pj4+Pj4+IHJlY29tbWVuZCB0aGUgb3Ro ZXIpIChkZWx0YSBzb21lIHBvbGl0ZW5lc3MgYWJvdXQgVENQKQo+PiA+Pj4+Pj4+Pj4+Cj4+ID4+ Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tCj4+ID4+Pj4+Pj4+Pj4gRnJvbTogTWFubmVyIEp1a2thIFttYWlsdG86anVra2EubWFu bmVyQGFhbHRvLmZpXQo+PiA+Pj4+Pj4+Pj4+IFNlbnQ6IDA3IFNlcHRlbWJlciAyMDEyIDEzOjI0 Cj4+ID4+Pj4+Pj4+Pj4gVG86IEVhcmRsZXksUEwsUGhpbGlwLERVQjggUgo+PiA+Pj4+Pj4+Pj4+ IENjOiBCcmlzY29lLFJKLEJvYixEVUI4IFI7IDx0c3Z3Zy1jaGFpcnNAaWV0Zi5vcmc+Owo+PiA+ Pj4+Pj4+Pj4+IDxnb3JyeUBlcmcuYWJkbi5hYy51az4KPj4gPj4+Pj4+Pj4+PiBTdWJqZWN0OiBS ZTogW1JFVklTRUQgSS1EXTogRG9jdW1lbnQgd3JpdGV1cCBmb3IKPj4gPj4+Pj4+Pj4+PiBkcmFm dC1pZXRmLXRzdndnLWJ5dGUtcGt0LWNvbmdlc3QKPj4gPj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+ IEhpLCBJJ20gdHJ5aW5nIHRvIGZvbGxvdyB5b3VyIHJlYXNvbmluZywgd2l0aCBsaXR0bGUgbHVj ay4KPj4gPj4gOykKPj4gPj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+IEFmdGVyIGhhdmluZyByZWFk IFNlY3Rpb24gMyBhZ2FpbiwgSSBjb3VsZCB0aGluayBvZiBhIGZldwo+PiA+Pj4+Pj4+PiB1cGRh dGVzLCBidXQgSSdtIG5vdCBmdWxseSBmb2xsb3dpbmcgd2hhdCB5b3Ugd2FudCB0byBzZWU6Cj4+ ID4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+PiAtIFMzLjUgaXMga2luZCBvZiBzbWFsbCBhbmQgbG9u ZWx5IGJ5IGl0c2VsZi4gSXQgY291bGQgYmUKPj4gPj4gZWl0aGVyCj4+ID4+Pj4+Pj4+IGxvbmdl ciBvciBtZXJnZWQgc29tZXdoZXJlLiBOb3QgYSBtYWpvciBpc3N1ZSB0aG91Z2ggYW5kCj4+ID4g Y291bGQKPj4gPj4gcmVtYWluIGFzCj4+ID4+Pj4+Pj4+IGlzLgo+PiA+Pj4+Pj4+Pj4+Cj4+ID4+ Pj4+Pj4+Pj4gLSBTMy4zOiBZZXMsIHByb2JhYmx5IGNvdWxkIGJlIHR1cm5lZCB1cHNpZGUgZG93 biwgZ29vZAo+PiA+PiBmaXJzdCwKPj4gPj4+Pj4+Pj4gYmFkIGxhdGVyLiBEb24ndCBoYXZlIGEg c3Ryb25nIG9waW5pb24uCj4+ID4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+PiAtIFMzLjQ6IEhlcmUg dGhlIHNjYWxpbmcgaXMgdXNlZCBtYW55IHRpbWVzIGFuZCBpbiB0aGUKPj4gPj4gdGl0bGUsCj4+ ID4+Pj4+Pj4+IGFsdGhvdWdoIHdlIHRhbGsgYWJvdXQgdGhlIGVuZCBob3N0IHNpZGUuIFRoaXMg Y291bGQgYmUKPj4gPj4gcmVwaHJhc2VkCj4+ID4+Pj4+Pj4+IGFuZCBzbGlnaHRseSByZXdvcmRl ZCB0byB0YWxrIGFib3V0IGhvc3RzIGFuZCB0aGVpciBvcGVyYXRpb24KPj4gPj4+Pj4+Pj4gYWx0 b2dldGhlci4gQWxzbyB0aGUgd29yZCBzY2FsaW5nIGNhbiB0dXJuIHRoZSByZWFkZXJzCj4+ID4+ IGV4cGVjdGF0aW9uCj4+ID4+Pj4+Pj4+IGludG8gdGhlIHdyb25nIGRpcmVjdGlvbi4KPj4gPj4+ Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+IC0gUzMgYWx0b2dldGhlcjogSXQgd291bGQgaGVscCB0byBo YXZlIGludHJvZHVjdG9yeSB0ZXh0Cj4+ID4+IGFib3V0Cj4+ID4+Pj4+Pj4+IG5ldHdvcmtzIHZz LiBlbmQgaG9zdCBzaWRlLCBidXQgSSBmYWlsIHRvIHNlZSB3aHkgICgmIGhvdykgdG8KPj4gPj4+ Pj4+Pj4gcmVzdHJ1Y3R1cmUgZXZlcnl0aGluZy4KPj4gPj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+ IGNoZWVycywKPj4gPj4+Pj4+Pj4+PiBKdWtrYQo+PiA+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4g T24gU2VwIDYsIDIwMTIsIGF0IDY6MTggUE0sCj4+ID4+Pj4+Pj4+IDxwaGlsaXAuZWFyZGxleUBi dC5jb20+ICA8cGhpbGlwLmVhcmRsZXlAYnQuY29tPiB3cm90ZToKPj4gPj4+Pj4+Pj4+Pgo+PiA+ Pj4+Pj4+Pj4+PiBQcyBvdGhlcndpc2UgQm9iJ3MgY29tbWVudHMgYXJlIGZpbmUsIHRob3VnaCBJ IHN1Z2dlc3QKPj4gPiBmb3IKPj4gPj4gUzMuNSB5b3UKPj4gPj4+Pj4+Pj4+Pj4gZ2l2ZSBtb3Jl IGNvbnRleHQgKGllIGFyZSB5b3Uga25vY2tpbmcgZG93biB3aGF0IHlvdQo+PiA+PiByZWNvbW1l bmQKPj4gPj4+Pj4+Pj4+Pj4gYWdhaW5zdCwgb3IgYnVpbGRpbmcgdXAgd2hhdCB5b3UgcmVjb21t ZW5kPykgIGFuZCBpbiBTMy4zCj4+ID4+IHRoaW5rCj4+ID4+Pj4+Pj4+Pj4+IHdvdWxkIGJlIGJl dHRlciBpZiB5b3UgcmUtc3RydWN0dXJlZCBzbGlnaHRseSBbZmlyc3QgdGFsawo+PiA+PiBhYm91 dCB3aGF0Cj4+ID4+Pj4+Pj4+Pj4+IHlvdSBsaWtlIC0gcGVudWx0IHBhcmEgKyAxc3Qgc2VudGVu Y2Ugb2YgbGFzdCBwYXJhIC0gdGhlbgo+PiA+PiB0YWxrIGFib3V0Cj4+ID4+Pj4+Pj4+Pj4+IHdo YXQgeW91IGRvbid0IGxpa2UgLSByZXN0IG9mIHRleHRdCj4+ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+ Pj4+Pj4+IEZyb206IEVhcmRsZXksUEwsUGhpbGlwLERVQjggUgo+PiA+Pj4+Pj4+Pj4+PiBTZW50 OiAwNiBTZXB0ZW1iZXIgMjAxMiAxNjoxMgo+PiA+Pj4+Pj4+Pj4+PiBUbzogQnJpc2NvZSxSSixC b2IsRFVCOCBSOyBNYW5uZXIgSnVra2EKPj4gPj4+Pj4+Pj4+Pj4gQ2M6IHRzdndnLWNoYWlyc0Bp ZXRmLm9yZzsgR29ycnkgRmFpcmh1cnN0Cj4+ID4+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJFOiBbUkVW SVNFRCBJLURdOiBEb2N1bWVudCB3cml0ZXVwIGZvcgo+PiA+Pj4+Pj4+Pj4+PiBkcmFmdC1pZXRm LXRzdndnLWJ5dGUtcGt0LWNvbmdlc3QKPj4gPj4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+Pj4gVGhh bmtzIGJvYi4gSGF2ZSBub3cgcmUtYm9vdGVkIHNvbWUgc3RhdGUuCj4+ID4+Pj4+Pj4+Pj4+IEkg ZG9uJ3QgbGlrZSBTMy40LiBNeSBiYXNpYyBwcm9ibGVtIHdpdGggaXQgaXMgdGhhdCBpdAo+PiA+ PiBpc24ndCBhCj4+ID4+Pj4+Pj4+ICJtb3RpdmF0aW5nIGFyZ3VtZW50IiAoUzMgdGl0bGUpLiBJ dCdzIGFuIGV4cGxhbmF0aW9uIGFib3V0Cj4+ID4+IHRoZQo+PiA+Pj4+Pj4+PiBjb25zZXF1ZW5j ZXMgb2YgYXNzdW1pbmcgZWl0aGVyIFtvcHRpb24gMV0gZG8gcGt0LXNpemUKPj4gPiBiaWFzaW5n Cj4+ID4+IGluCj4+ID4+Pj4+Pj4+IHRoZSB0cmFuc3BvcnQ7IFtvcHRpb24gMl07IGRvIHBrdC1z aXplIGJpYXNpbmcgaW4gdGhlIG53Lgo+PiA+Pj4+Pj4+Pj4+PiBQZXJoYXBzIHlvdXIgZWZmb3J0 IHRvIGJ1eSBwZWFjZSB3aXRoIHRob3NlIHdobyB3b24ndAo+PiA+PiBjaGFuZ2UKPj4gPj4+Pj4+ Pj4gVENQIGhhcyBvYmZ1c2NhdGVkIHRoZSBiYXNpYyBwb2ludD8KPj4gPj4+Pj4+Pj4+Pj4gVGhl IHRpdGxlIG9mIFMzLjQgKFNjYWxpbmcuLi4pIGFuZCB0aGUgZWFybHkgdGV4dAo+PiA+ICJzY2Fs aW5nCj4+ID4+Pj4+Pj4+IGFyZ3VtZW50IiBzdWdnZXN0cyB0aGF0IHlvdSdyZSBnb2luZyB0byBh cmd1ZSB0aGVyZSBpcyBzb21lCj4+ID4+IHJlYXNvbgo+PiA+Pj4+Pj4+PiB3aHkgWCBzY2FsZXMg YXMgb3JkZXIgTiByYXRoZXIgdGhhbiBOXjIgb3Igc29tZXRoaW5nIGxpa2UKPj4gPiB0aGF0Cj4+ ID4+IC0KPj4gPj4+Pj4+Pj4gd2hpY2ggaXNuJ3Qgd2hhdCBTMy40IGlzIGFib3V0Lgo+PiA+Pj4+ Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+PiBJIGFjdHVhbGx5IHRoaW5rIGl0IHdvdWxkIGJlIGJldHRl ciB0byBwdXQgUzMuNCBhdCB0aGUKPj4gPj4gc3RhcnQgb2YKPj4gPj4+Pj4+Pj4gUzMgLSBpdCdz IGJhY2tncm91bmQgd2hlcmUgeW91IHNheSB0aGVyZSBhcmUgMiBvcHRpb25zLiBBZnRlcgo+PiA+ PiB0aGF0LAo+PiA+Pj4+Pj4+PiB5b3UgY2FuIGV4cGxhaW4gdGhlIHJlYXNvbnMgd2h5IG9wdGlv biAxIFtwa3QgYmlhc2luZyBpbiB0aGUKPj4gPj4+Pj4+Pj4gdHJhbnNwb3J0XSBpcyBiZXR0ZXIg LSB0aGUgcmVhc29ucyBiZWluZzotICBTMy4xIChzZWN1cml0eQo+PiA+IGV0Ywo+PiA+Pj4+Pj4+ PiBhdHRhY2tzIGlmIHNtYWxsIHBrdHMgZ2V0IHByZWZlcmVudGlhbCB0cmVhdG1lbnQpLCBTMy4y Cj4+ID4+IChyZWFsbHkgYQo+PiA+Pj4+Pj4+PiBzaWRlIG5vdGUgdG8gUzMuMTsgaWUgZG9lc24n dCByZWFsbHkgcHJlc2VudCBhICJtb3RpdmF0aW5nCj4+ID4+Pj4+Pj4+IGFyZ3VtZW50IiksIFMz LjMgKG53IGd1ZXNzaW5nIE1UVSB2cyB0cmFuc3BvcnQga25vd2luZyBwa3QKPj4gPj4gc2l6ZSks Cj4+ID4+Pj4+Pj4+IFMzLjUgKGVhc2llciBpbXBsZW1lbnRhdGlvbikuCj4+ID4+Pj4+Pj4+Pj4+ Cj4+ID4+Pj4+Pj4+Pj4+IFNvbWV0aGluZyBsaWtlLi4uCj4+ID4+Pj4+Pj4+Pj4+IFRoZSBiZWhh dmlvdXIgb2YgdGhlIG5ldHdvcmsgYW5kIHRyYW5zcG9ydCB0b2dldGhlciBuZWVkcwo+PiA+PiB0 bwo+PiA+Pj4+Pj4+Pj4+PiBhbGxldmlhdGUgY29uZ2VzdGlvbi4gV2UgYXNzdW1lIHRoZSBuZXR3 b3JrIGlzIGJpdC0KPj4gPj4gY29uZ2VzdGlibGUKPj4gPj4+Pj4+Pj4gKGN1cnJlbnRseSBwYWNr ZXQtY29uZ2VzdGlibGUgcmVzb3VyY2VzIGFyZSByYXRlKS4gVGhlcmVmb3JlCj4+ID4+Pj4+Pj4+ IG92ZXJhbGwgdGhlIHJlc3BvbnNlIG9mIHRoZSB7bmV0d29yayArIHRyYW5zcG9ydH0gc2hvdWxk IGJlCj4+ID4+IHRoZQo+PiA+Pj4+Pj4+PiBzYW1lIGZvciB0aGUgc2FtZSBjb25nZXN0aW9uIC0g d2hldGhlciB0aGUgY29uZ2VzdGlvbiBpcwo+PiA+PiBjYXVzZWQgYnkKPj4gPj4+Pj4+Pj4gYSBs b3Qgb2Ygc21hbGwgcGFja2V0cyBvciBhIHNtYWxsZXIgbnVtYmVyIG9mIGxhcmdlciBwYWNrZXRz Lgo+PiA+PiBUaGUKPj4gPj4+Pj4+Pj4gaW1wbGljYXRpb24gaXMgdGhhdCB0aGUgdHJhbnNwb3J0 J3MgYmVoYXZpb3VyIHNob3VsZCBkZXBlbmQKPj4gPiBvbgo+PiA+Pj4+Pj4+PiB3aGV0aGVyIHRo ZSBuZXR3b3JrIHRha2VzIGFjY291bnQgKG9yIG5vdCkgb2YgcGFja2V0IHNpemUKPj4gPiB3aGVu Cj4+ID4+IGl0Cj4+ID4+Pj4+Pj4+IGdlbmVyYXRlcyBjb25nZXN0aW9uIGluZGljYXRpb25zOi0g Q2FzZSAxOiBJZiB0aGUgbmV0d29yawo+PiA+Pj4+Pj4+PiBpbXBsZW1lbnRzIHBhY2tldC1tb2Rl IGRyb3AsIGllIGl0cyBhbGdvcml0aG0gdHJlYXRzIGFsbAo+PiA+PiBwYWNrZXRzCj4+ID4+Pj4+ Pj4+IGVxdWFsbHkgcmVnYXJkbGVzcyBvZiB0aGVpciBzaXplLCB0aGVuIHRoZSB0cmFuc3BvcnQg c2hvdWxkCj4+ID4+IHRha2UKPj4gPj4+Pj4+Pj4gYWNjb3VudCBvZiB0aGUgc2l6ZSBvZiB0aGUg cGFja2V0IC0gaW4gb3RoZXIgd29yZHMsIHRoZQo+PiA+PiB0cmFuc3BvcnQncwo+PiA+Pj4+Pj4+ PiBjb25nZXN0aW9uIHJlc3BvbnNlIHNob3VsZCBkZXBlbmQgb24gdGhlIG51bWJlciBvZiBkcm9w cGVkCj4+ID4+IGJ5dGVzLgo+PiA+Pj4+Pj4+Pj4+PiBDYXNlIDI6IElmIHRoZSBuZXR3b3JrIGlt cGxlbWVudHMgYnl0ZS1tb2RlIGRyb3AsIGllIGl0cwo+PiA+Pj4+Pj4+PiBhbGdvcml0aG0gdHJl YXRzIHBhY2tldHMgZGlmZmVyZW50bHkgZGVwZW5kaW5nIG9uIHRoZWlyIHNpemUsCj4+ID4+IHRo ZW4KPj4gPj4+Pj4+Pj4gdGhlIHRyYW5zcG9ydCBzaG91bGQgbm90IHRha2UgYWNjb3VudCBvZiB0 aGUgc2l6ZSBvZiB0aGUKPj4gPj4gcGFja2V0IC0KPj4gPj4+Pj4+Pj4gaW4gb3RoZXIgd29yZHMs IHRoZSB0cmFuc3BvcnQncyBjb25nZXN0aW9uIHJlc3BvbnNlIHNob3VsZAo+PiA+PiBkZXBlbmQK Pj4gPj4+Pj4+Pj4gb24gdGhlIG51bWJlciBvZiBkcm9wcGVkIHBhY2tldHMuCj4+ID4+Pj4+Pj4+ Pj4+Cj4+ID4+Pj4+Pj4+Pj4+IFRoZXNlIGNhc2VzIGFyZSBleHBsYWluZWQgaW4gbW9yZSBkZXRh aWwgaW4gc3ViLXNlY3Rpb24KPj4gPj4gYmVsb3cuCj4+ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+ Pj4+IEluIGJvdGggY2FzZXMgdGhlIHNhbWUgZGlzY3Vzc2lvbiBhcHBsaWVzIGlmIHBhY2tldHMg YXJlCj4+ID4+Pj4+Pj4+IEVDTi1tYXJrZWQgcmF0aGVyIHRoYW4gZHJvcHBlZC4KPj4gPj4+Pj4+ Pj4+Pj4gSW4gdGhlIGZvbGxvd2luZyBzZWN0aW9ucyB3ZSBleHBsYWluIHdoeSBDYXNlIDEgaXMK Pj4gPj4gcHJlZmVyYWJsZSwKPj4gPj4+Pj4+Pj4gYW5kIGhlbmNlIHdoeSB3ZSBtYWtlIHRoZSBS ZWNvbW1lbmRhdGlvbnMgb2YgUzIuMiBhbmQgUzMuMwo+PiA+Pj4+Pj4+PiAocmVzcGVjdGl2ZWx5 LCBkcm9wL21hcmsgcGt0cyBlcXVhbGx5IHJlZ2FyZGxlc3Mgb2YgdGhlaXIKPj4gPj4gc2l6ZSwg YW5kCj4+ID4+Pj4+Pj4+IHRoZSBzdHJlbmd0aCBvZiB0aGUgdHJhbnNwb3J0J3MgcmVzcG9uc2Ug c2hvdWxkIGJlCj4+ID4+IHByb3BvcnRpb25hdGUgdG8KPj4gPj4+Pj4+Pj4gdGhlIHNpemUgb2Yg dGhlIGRyb3BwZWQvbWFya2VkIHBrdCkuCj4+ID4+Pj4+Pj4+Pj4+IE5vdGUgdGhhdCBUQ1AgcmVz cG9uZHMgdG8gZHJvcHBlZCBvciBtYXJrZWQgcGFja2V0cywKPj4gPiB3aGljaAo+PiA+PiBkaWZm ZXJzCj4+ID4+Pj4+Pj4+Pj4+IGZyb20gb3VyIHJlY29tbWVuZGF0aW9uIGZvciB0cmFuc3BvcnRz LiBIb3dldmVyLCB3ZSBhcmUKPj4gPj4gbm90Cj4+ID4+Pj4+Pj4+Pj4+IHJlY29tbWVuZGluZyB0 aGF0IFRDUCAgc2hvdWxkIGJlIGNoYW5nZWQ7IHRvIGRhdGUgaXQKPj4gPj4gaGFzbid0IGJlZW4g YQo+PiA+Pj4+Pj4+Pj4+PiBzaWduaWZpY2FudCBwcm9ibGVtIGJlY2F1c2UgbW9zdCBUQ1AgaW1w bGVtZW50YXRpb25zCj4+ID4gaGF2ZQo+PiA+PiBiZWVuCj4+ID4+Pj4+Pj4+IHVzZWQgd2l0aCBz aW1pbGFyIHBhY2tldCBzaXplcy4gQnV0IHdlIGRvIHJlY29tbWVuZCB0aGF0Cj4+ID4+IGZ1dHVy ZQo+PiA+Pj4+Pj4+PiB0cmFuc3BvcnQgcHJvdG9jb2xzIHNob3VsZCAgcmVzcG9uZCB0byBkcm9w cGVkIG9yIG1hcmtlZAo+PiA+IGJ5dGVzCj4+ID4+IChhcwo+PiA+Pj4+Pj4+PiBmb3IgZXhhbXBs ZSBURlJDLVNQIFtSRkM0ODI4XWVmZmVjdGl2ZWx5IGRvZXMpLgo+PiA+Pj4+Pj4+Pj4+Pgo+PiA+ Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+PiBTdWItc2VjdGlvbgo+PiA+Pj4+Pj4+Pj4+PiBZb3Ug Y291bGQgdXNlIG11Y2ggb2YgUzMuMywgSSBzdWdnZXN0IHN1cHBsZW1lbnQgd2l0aAo+PiA+PiBu dW1lcmljYWwKPj4gPj4+Pj4+Pj4+Pj4gZXhhbXBsZXMgY29udGludWluZyBTMS4yCj4+ID4+Pj4+ Pj4+Pj4+IC0tCj4+ID4+Pj4+Pj4+Pj4+IDw8IFRoaXMgZ2l2ZXMgYSBnZXQtb3V0IGNsYXVzZSB0 byBhbnkgdHJhbnNwb3J0IHRoYXQKPj4gPiBpc24ndAo+PiA+Pj4+Pj4+Pj4+PiBwYWNrZXQtc2l6 ZSBkZXBlbmRlbnQgKGUuZy4gY3VycmVudCBUQ1ApLiBMYWNraW5nIHBhY2tldC0KPj4gPj4gc2l6 ZQo+PiA+Pj4+Pj4+Pj4+PiBkZXBlbmRlbmNlIGp1c3QgbWVhbnMgdGhleSBkb24ndCBzY2FsZSBj b3JyZWN0bHkgd2l0aAo+PiA+PiBwYWNrZXQgc2l6ZSAtCj4+ID4+Pj4+Pj4+Pj4+IGJ1dCB0aGV5 IGFyZSBhdCBsaWJlcnR5IG5vdCB0byBzY2FsZSB3aXRoIHBhY2tldCBzaXplCj4+ID4+IChwYXJ0 aWN1bGFybHkKPj4gPj4+Pj4+Pj4+Pj4gZ2l2ZW4gTVRVIGdyb3d0aCBpc24ndCBvZnRlbiBiZWlu ZyB1c2VkIHRvIGluY3JlYXNlIGxpbmsKPj4gPj4gcmF0ZXMgYXQKPj4gPj4+Pj4+Pj4+Pj4gdGhp cyBzdGFnZSBpbiBoaXN0b3J5KS4+Pgo+PiA+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+PiBUaGlz IGlzIGludHJvZHVjaW5nIGEgZGlmZmVyZW50IHBvaW50LiBpdCdzIHNheWluZyB0aGF0Cj4+ID4+ IHlvdXIKPj4gPj4+Pj4+Pj4gcmVjb21tZW5kYXRpb24gMiBbZHJvcC9tYXJrIHBrdHMgZXF1YWxs eSByZWdhcmRsZXNzIG9mIHRoZWlyCj4+ID4+IHNpemVdCj4+ID4+Pj4+Pj4+IGlzIGEgcmVhbGx5 IHN0cm9uZyByZWNvIHdoaWxzdCByZWNvbW1lbmRhdGlvbiAzIFtzdHJlbmd0aCBvZgo+PiA+Pj4+ Pj4+PiB0cmFuc3BvcnQncyByZXNwb25zZSBwcm9wb3J0aW9uYXRlIHRvIHRoZSBzaXplIG9mIHRo ZQo+PiA+Pj4+Pj4+PiBkcm9wcGVkL21hcmtlZCBwa3RdIGlzIGEgbXVjaCBsZXNzIGltcG9ydGFu dCByZWNvLiAgSSBjYW4gc2VlCj4+ID4+IHRoaXMKPj4gPj4+Pj4+Pj4gbWlnaHQgYmUgdHJ1ZSwg YnV0IEkgZG9uJ3QgdGhpbmsgdGhlIGktZCB0YWxrcyBhYm91dCB0aGlzLgo+PiA+Pj4+Pj4+Pj4+ Pgo+PiA+Pj4+Pj4+Pj4+PiAtLQo+PiA+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+PiBGcm9tOiBC cmlzY29lLFJKLEJvYixEVUI4IFIKPj4gPj4+Pj4+Pj4+Pj4gU2VudDogMDUgU2VwdGVtYmVyIDIw MTIgMTY6NDEKPj4gPj4+Pj4+Pj4+Pj4gVG86IE1hbm5lciBKdWtrYQo+PiA+Pj4+Pj4+Pj4+PiBD YzogdHN2d2ctY2hhaXJzQGlldGYub3JnOyBHb3JyeSBGYWlyaHVyc3Q7Cj4+ID4+IEVhcmRsZXks UEwsUGhpbGlwLERVQjggUgo+PiA+Pj4+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW1JFVklTRUQgSS1E XTogRG9jdW1lbnQgd3JpdGV1cCBmb3IKPj4gPj4+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi10c3Z3Zy1i eXRlLXBrdC1jb25nZXN0Cj4+ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+IEp1a2thLAo+PiA+ Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+PiBJJ3ZlIHJlcGVhdGVkIFBoaWwncyBzdWdnZXN0aW9u cyBhcyBxdW90ZWQgZW1haWwgdGhlbgo+PiA+IG1hZGUKPj4gPj4gc29tZQo+PiA+Pj4+Pj4+PiBh bHRlcmF0aW9ucy4KPj4gPj4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+Pj4gUGhpbCBhc2tlZCBtZSB0 byBzZW5kIHRoaXMsIHRoZW4gaGUgd2lsbCB0aGluayBhYm91dCBpdC4KPj4gPj4+Pj4+Pj4+Pj4K Pj4gPj4+Pj4+Pj4+Pj4gSSdsbCByZXNwb25kIGFib3V0IEpvaG4gTGVzbGllJ3MgYXJndW1lbnQg bmV4dC4uLgo+PiA+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+PiAyLjIu IFJlY29tbWVuZGF0aW9uIG9uIEVuY29kaW5nIENvbmdlc3Rpb24gTm90aWZpY2F0aW9uCj4+ID4+ Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+IFsuLi5dCj4+ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+ Pj4+IDEuICBBUU0gYWxnb3JpdGhtcyBzdWNoIGFzIFJFRCBTSE9VTEQgdXNlIHBhY2tldC1tb2Rl Cj4+ID4+IGRyb3AsIGllIHRoZXkKPj4gPj4+Pj4+Pj4+Pj4gICAgIFNIT1VMRCBOT1QgdXNlIGJ5 dGUtbW9kZSBkcm9wLiBUaGUgbGF0dGVyIGlzIG1vcmUKPj4gPj4gY29tcGxleCwKPj4gPj4+Pj4+ Pj4+Pj4gICAgIGl0IGNyZWF0ZXMgdGhlIHBlcnZlcnNlIGluY2VudGl2ZSB0byBmcmFnbWVudAo+ PiA+PiBzZWdtZW50cyBpbnRvCj4+ID4+Pj4+Pj4+IHRpbnkKPj4gPj4+Pj4+Pj4+Pj4gICAgIHBp ZWNlcyBhbmQgaXQgaXMgdnVsbmVyYWJsZSB0byBmbG9vZHMgb2Ygc21hbGwKPj4gPj4gcGFja2V0 cy4KPj4gPj4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+Pj4gMi4gIElmIGEgdmVuZG9yIGhhcyBpbXBs ZW1lbnRlZCBieXRlLW1vZGUgZHJvcCwgYW5kIGFuCj4+ID4+IG9wZXJhdG9yIGhhcwo+PiA+Pj4+ Pj4+Pj4+PiAgICAgdHVybmVkIGl0IG9uLCBpdCBpcyBSRUNPTU1FTkRFRCB0byB0dXJuIGl0IG9m ZiwKPj4gPiBhZnRlcgo+PiA+Pj4+Pj4+PiBlc3RhYmxpc2hpbmcKPj4gPj4+Pj4+Pj4+Pj4gICAg IGlmIHRoZXJlIGFyZSBhbnkgaW1wbGljYXRpb25zIG9uIHRoZSByZWxhdGl2ZQo+PiA+PiBwZXJm b3JtYW5jZSBvZgo+PiA+Pj4+Pj4+Pj4+PiAgICAgYXBwbGljYXRpb25zIHVzaW5nIGRpZmZlcmVu dCBwYWNrZXQgc2l6ZXMuCj4+ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+ICAgICBSRUQgYXMg YSB3aG9sZSBTSE9VTEQgTk9UIGJlIHR1cm5lZCBvZmYuIFdpdGhvdXQKPj4gPiBSRUQsCj4+ID4+ IGEgZHJvcAo+PiA+Pj4+Pj4+PiB0YWlsCj4+ID4+Pj4+Pj4+Pj4+ICAgICBxdWV1ZSBiaWFzZXMg YWdhaW5zdCBsYXJnZSBwYWNrZXRzCj4+ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+IFtCQiBh ZGRzXTogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbmQgaXQgaXMKPj4gPj4gdnVs bmVyYWJsZSB0bwo+PiA+Pj4+Pj4+PiBmbG9vZHMKPj4gPj4+Pj4+Pj4+Pj4gICAgICBvZiBzbWFs bC1wYWNrZXRzLgo+PiA+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+PiAoSSBzdWdnZXN0IHRoZSBs YXN0IHBhcmEganVzdCBxdWFsaWZpZXMgaXRlbSAyLiBJdAo+PiA+IGRvZXNuJ3QKPj4gPj4gd2Fy cmFudAo+PiA+Pj4+Pj4+Pj4+PiBhbm90aGVyIGl0ZW0gbnVtYmVyLikKPj4gPj4+Pj4+Pj4+Pj4K Pj4gPj4+Pj4+Pj4+Pj4gPEFncmVlIHdpdGggUGhpbDsgRG9uJ3QgaW5kZW50ICJOb3RlIHdlbGwu Li4iPgo+PiA+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+PiBbUEU6XSBTMy4zCj4+ID4+Pj4+Pj4+ Pj4+IFRoZSBzZWN0aW9uIGNvdWxkIGJlIHNsaWdodGx5IGNsZWFyZXIuIFN0YXJ0aW5nIHdpdGgg dGhlCj4+ID4+IHNlY29uZAo+PiA+Pj4+Pj4+PiBwYXJhLCB3aGVyZSB5b3Ugc3RhcnQgdGFsa2lu ZyBhYm91dCBzb21ldGhpbmcgeW91IGRvbid0Cj4+ID4+IHJlY29tbWVuZAo+PiA+Pj4+Pj4+PiAo aWUgeW91IGhhdmUgdG8gcmVtZW1iZXIgdGhhdCB5b3UncmUgdGFsa2luZyBhYm91dCB0aGUKPj4g Pj4gY29uc2VxdWVuY2VzCj4+ID4+Pj4+Pj4+IG9mIG5vdCBmb2xsb3dpbmcgeW91ciByZWNvbW1l bmRhdGlvbikuCj4+ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+IDMuMyBUcmFuc3BvcnQtSW5k ZXBlbmRlbnQgTmV0d29yawo+PiA+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+PiBUQ1AgY29uZ2Vz dGlvbiBjb250cm9sIGVuc3VyZXMgdGhhdCBmbG93cyBjb21wZXRpbmcgZm9yCj4+ID4+IHRoZSBz YW1lCj4+ID4+Pj4+Pj4+Pj4+IHJlc291cmNlIGVhY2ggbWFpbnRhaW4gdGhlIHNhbWUgbnVtYmVy IG9mIHNlZ21lbnRzIGluCj4+ID4+IGZsaWdodCwKPj4gPj4+Pj4+Pj4+Pj4gaXJyZXNwZWN0aXZl IG9mIHNlZ21lbnQgc2l6ZS4gIFNvIHVuZGVyIHNpbWlsYXIKPj4gPj4gY29uZGl0aW9ucywgZmxv d3MKPj4gPj4+Pj4+Pj4+Pj4gd2l0aCBkaWZmZXJlbnQgc2VnbWVudCBzaXplcyB3aWxsIGdldCBk aWZmZXJlbnQKPj4gPiBiaXQtcmF0ZXMuCj4+ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+IFtP TEQ6XQo+PiA+Pj4+Pj4+Pj4+PiBPbmUgbW90aXZhdGlvbiBmb3IgdGhlIG5ldHdvcmsgYmlhc2lu ZyBjb25nZXN0aW9uCj4+ID4+IG5vdGlmaWNhdGlvbiBieQo+PiA+Pj4+Pj4+Pj4+PiBwYWNrZXQg c2l6ZSBpcyB0byBjb3VudGVyIHRoaXMgZWZmZWN0IGFuZCB0cnkgdG8gZXF1YWxpc2UKPj4gPj4g dGhlIGJpdC0KPj4gPj4+Pj4+Pj4+Pj4gcmF0ZXMgb2YgZmxvd3Mgd2l0aCBkaWZmZXJlbnQgcGFj a2V0IHNpemVzLgo+PiA+Pj4+Pj4+Pj4+PiBbU1VHR0VTVEVEOl0KPj4gPj4+Pj4+Pj4+Pj4gVG8g Y291bnRlciB0aGlzIGVmZmVjdCBpdCBzZWVtcyB0ZW1wdGluZyBub3QgdG8gZm9sbG93Cj4+ID4+ IG91cgo+PiA+Pj4+Pj4+Pj4+PiByZWNvbW1lbmRhdGlvbiwgIGFuZCBpbnN0ZWFkIGZvciB0aGUg bmV0d29yayB0byBiaWFzCj4+ID4+IGNvbmdlc3Rpb24KPj4gPj4+Pj4+Pj4+Pj4gbm90aWZpY2F0 aW9uIGJ5ICBwYWNrZXQgc2l6ZSBpbiBvcmRlciB0byBlcXVhbGlzZSB0aGUKPj4gPiBiaXQtCj4+ ID4+IHJhdGVzIG9mCj4+ID4+Pj4+Pj4+Pj4+IGZsb3dzIHdpdGggZGlmZmVyZW50ICBwYWNrZXQg c2l6ZXMuCj4+ID4+Pj4+Pj4+Pj4+IFtDT05USU5VRSBBUyBCRUZPUkU6XQo+PiA+Pj4+Pj4+Pj4+ PiAgICAgICAgICAgICAgIEhvd2V2ZXIsIGluIG9yZGVyIHRvIGRvICB0aGlzLCB0aGUgcXVldWlu Zwo+PiA+PiBhbGdvcml0aG0KPj4gPj4+Pj4+Pj4+Pj4gaGFzIHRvIG1ha2UgYXNzdW1wdGlvbnMg YWJvdXQgdGhlICB0cmFuc3BvcnQsIHdoaWNoCj4+ID4gYmVjb21lCj4+ID4+IGVtYmVkZGVkCj4+ ID4+Pj4+Pj4+Pj4+IGluIHRoZSBuZXR3b3JrLiAgU3BlY2lmaWNhbGx5Ogo+PiA+Pj4+Pj4+Pj4+ PiBbLi4uXQo+PiA+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+Pgo+PiA+ Pj4+Pj4+Pj4+PiBTMy4zCj4+ID4+Pj4+Pj4+Pj4+IG8gIFRoZSBxdWV1aW5nIGFsZ29yaXRobSBo YXMgdG8gYXNzdW1lIGhvdyBhZ2dyZXNzaXZlbHkKPj4gPj4gdGhlCj4+ID4+Pj4+Pj4+IHRyYW5z cG9ydAo+PiA+Pj4+Pj4+Pj4+PiAgICB3aWxsIHJlc3BvbmQgdG8gY29uZ2VzdGlvbiAoc2VlIFNl Y3Rpb24gNC4yLjQpLiAgSWYKPj4gPj4gdGhlIG5ldHdvcmsKPj4gPj4+Pj4+Pj4+Pj4gICAgYXNz dW1lcyB0aGUgdHJhbnNwb3J0IHJlc3BvbmRzIGFzIGFnZ3Jlc3NpdmVseSBhcyBUQ1AKPj4gPj4g TmV3UmVubywKPj4gPj4+Pj4+Pj4gaXQKPj4gPj4+Pj4+Pj4+Pj4gICAgd2lsbCBiZSB3cm9uZyBm b3IgQ29tcG91bmQgVENQIGFuZCBkaWZmZXJlbnRseSB3cm9uZwo+PiA+PiBmb3IgQ3ViaWMKPj4g Pj4+Pj4+Pj4+Pj4gICAgVENQLCBldGMuICBUbyBhY2hpZXZlIGVxdWFsIGJpdC1yYXRlcywgZWFj aCB0cmFuc3BvcnQKPj4gPj4gdGhlbiBoYXMKPj4gPj4+Pj4+Pj4gdG8KPj4gPj4+Pj4+Pj4+Pj4g ICAgZ3Vlc3Mgd2hhdCBhc3N1bXB0aW9uIHRoZSBuZXR3b3JrIG1hZGUsIGFuZCB3b3JrIG91dAo+ PiA+PiBob3cgdG8KPj4gPj4+Pj4+Pj4+Pj4gICAgcmVwbGFjZSB0aGlzIGFzc3VtZWQgYWdncmVz c2l2ZW5lc3Mgd2l0aCBpdHMgb3duCj4+ID4+IGFnZ3Jlc3NpdmVuZXNzLgo+PiA+Pj4+Pj4+Pj4+ PiBvICBBbHNvLCBpZiB0aGUgbmV0d29yayBiaWFzZXMgY29uZ2VzdGlvbiBub3RpZmljYXRpb24K Pj4gPiBieQo+PiA+PiBwYWNrZXQKPj4gPj4+Pj4+Pj4gc2l6ZQo+PiA+Pj4+Pj4+Pj4+PiAgICBp dCBoYXMgdG8gYXNzdW1lIGEgYmFzZWxpbmUgcGFja2V0IHNpemUtLWFsbCBwcm9wb3NlZAo+PiA+ PiBhbGdvcml0aG1zCj4+ID4+Pj4+Pj4+Pj4+ICAgIHVzZSB0aGUgbG9jYWwgTVRVLiAgVGhlbiB0 cmFuc3BvcnRzIGhhdmUgdG8gZ3Vlc3MKPj4gPj4gd2hpY2ggbGluayB3YXMKPj4gPj4+Pj4+Pj4+ Pj4gICAgY29uZ2VzdGVkIGFuZCB3aGF0IGl0cyBsb2NhbCBNVFUgd2FzLCBpbiBvcmRlciB0bwo+ PiA+IGtub3cKPj4gPj4gaG93IHRvCj4+ID4+Pj4+Pj4+Pj4+ICAgIHRhaWxvciB0aGVpciBjb25n ZXN0aW9uIHJlc3BvbnNlIHRvIHRoYXQgbGluay4KPj4gPj4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+ Pj4gU28geW91J3JlIHNheWluZyB0aGF0IGZvciBieXRlLW1vZGUgZHJvcCwgdGhlIG5ldHdvcmsK Pj4gPj4gZWxlbWVudAo+PiA+Pj4+Pj4+PiBoYXMgdG8gY29tcGFyZSB0aGUgc2l6ZSBvZiB0aGUg Y3VycmVudCBwa3Qgd2l0aCB0aGUgTVRVLCBhbmQKPj4gPj4gaWYKPj4gPj4+Pj4+Pj4gaXQncyAy NSogc21hbGxlciB0aGVuIHJlZHVjZSB0aGUgcGt0IGxvc3MgcHJvYmFibHkgYnkgMjUqPwo+PiA+ IEFuZAo+PiA+PiBpZgo+PiA+Pj4+Pj4+PiB0aGUgTVRVIHdhcyBiaWdnZXIsIHRoZW4gdGhlIGN1 cnJlbnQgcGt0IHdvdWxkIGJlIGRyb3BwZWQKPj4gPiB3aXRoCj4+ID4+Pj4+Pj4+IGdyZWF0ZXIg cHJvYmFiaWxpdHk/IEFuZCBib3RoIG9mIHRoZXNlIHRoaW5ncyBhcmUgaGFyZCB0byBkby4KPj4g Pj4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+Pj4gW0JCXTogU1VHR0VTVEVEIFJFUExBQ0VNRU5UIHRv IDJuZCBidWxsZXQ6Cj4+ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+IG8gIEFsc28sIGlmIHRo ZSBuZXR3b3JrIGJpYXNlcyBjb25nZXN0aW9uIG5vdGlmaWNhdGlvbgo+PiA+IGJ5Cj4+ID4+IHBh Y2tldAo+PiA+Pj4+Pj4+PiBzaXplCj4+ID4+Pj4+Pj4+Pj4+ICAgIGl0IGhhcyB0byBhc3N1bWUg YSBiYXNlbGluZSBwYWNrZXQgc2l6ZS0tYWxsIHByb3Bvc2VkCj4+ID4+IGFsZ29yaXRobXMKPj4g Pj4+Pj4+Pj4+Pj4gICAgdXNlIHRoZSBsb2NhbCBNVFUgKGZvciBleGFtcGxlIHNlZSB0aGUgYnl0 ZS1tb2RlIGxvc3MKPj4gPj4+Pj4+Pj4gcHJvYmFiaWxpdHkKPj4gPj4+Pj4+Pj4+Pj4gICAgZm9y bXVsYSBpbiBUYWJsZSAxKS4gIFRoZW4gaWYgdGhlIG5vbi1SZW5vIHRyYW5zcG9ydHMKPj4gPj4g bWVudGlvbmVkCj4+ID4+Pj4+Pj4+IGFib3ZlCj4+ID4+Pj4+Pj4+Pj4+ICAgIGFyZSB0cnlpbmcg dG8gcmV2ZXJzZSBlbmdpbmVlciB3aGF0IHRoZSBuZXR3b3JrCj4+ID4+IGFzc3VtZWQsIHRoZXkK Pj4gPj4+Pj4+Pj4gYWxzbwo+PiA+Pj4+Pj4+Pj4+PiAgICBoYXZlIHRvIGd1ZXNzIHRoZSBNVFUg b2YgdGhlIGNvbmdlc3RlZCBsaW5rLgo+PiA+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+PiBbQXNp ZGUgZm9yIFBoaWw6IFRoZSBieXRlLW1vZGUgYWxnbyB1c2VzIE1UVSBhcyBpdHMKPj4gPj4gYmFz ZWxpbmUgYmVjYXVzZQo+PiA+Pj4+Pj4+Pj4+PiBhIGxpbmsgY2Fubm90IHNlbmQgYSBwYWNrZXQg YmlnZ2VyIHRoYW4gaXRzIE1UVSBzbyB0aGUKPj4gPj4gYWxnbyB3b24ndAo+PiA+Pj4+Pj4+Pj4+ PiBldmVyIGdpdmUgYSBkcm9wIHByb2JhYmlsaXR5ID4xKS5dCj4+ID4+Pj4+Pj4+Pj4+Cj4+ID4+ Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+IFMzLjQgKCYga25vY2stb24gZWZmZWN0IG9uIDMuMykK Pj4gPj4+Pj4+Pj4+Pj4gSSB0aGluayB0aGlzIGNvdWxkIGJlIGJldHRlci4KPj4gPj4+Pj4+Pj4+ Pj4gSSBhZ3JlZSB3aXRoIHlvdXIgYXJndW1lbnRzIGluIFMzLjEgJiAzLjIgdGhhdCBkcm9wcGlu Zwo+PiA+IG9yCj4+ID4+Pj4+Pj4+IG1hcmtpbmcgc2hvdWxkIGJlIGluZGVwZW5kZW50IG9mIHBr dCBzaXplLgo+PiA+Pj4+Pj4+Pj4+PiBZb3Ugbm93IGdvIGludG8gYSBjb3VwbGUgb2YgcGFnZXMs IHdoaWNoIEkgdGhpbmsgY291bGQgYmUKPj4gPj4gYm9pbGVkCj4+ID4+Pj4+Pj4+Pj4+IGRvd24g dG8gYSBwYXJhZ3JhcGgsIHNheWluZyBzb21ldGhpbmcgbGlrZTotCj4+ID4+Pj4+Pj4+Pj4+ICog dGhlIG92ZXJhbGwgc3lzdGVtIChuZXR3b3JrICsgdHJhbnNwb3J0KSBoYXMgdG8gYmUKPj4gPj4g cGFja2V0LXNpemUKPj4gPj4+Pj4+Pj4+Pj4gZGVwZW5kZW50IGluIG9yZGVyIHRvIGRyaXZlIG91 dCB0aGUgcmlnaHQgYW1vdW50IG9mCj4+ID4+IHRyYWZmaWMgc28gdGhlCj4+ID4+Pj4+Pj4+Pj4+ IHJlc291cmNlIGJlY29tZXMgdW5jb25nZXN0ZWQgKHNpbmNlIHdlIGFzc3VtZSBhbGwKPj4gPj4g cmVzb3VyY2VzIGFyZSBpbgo+PiA+Pj4+Pj4+Pj4+PiBwcmFjdGljZSBieXRlIHJhdGhlciB0aGFu IHBhY2tldCBsaW1pdGVkKQo+PiA+Pj4+Pj4+Pj4+PiAqIGZyb20gUzMuMSBhbmQgUzMuMiB0aGUg SUVURiBpcyBjb252aW5jZWQgdGhhdCB0aGUKPj4gPj4gbmV0d29yawo+PiA+Pj4+Pj4+PiBzaG91 bGQgbm90aWZ5IGluZGVwZW5kZW50IG9mIHBhY2tldC1zaXplLgo+PiA+Pj4+Pj4+Pj4+PiAqIHRo ZXJlZm9yZSB0aGUgdHJhbnNwb3J0IG11c3QgYWN0IGRlcGVuZGVudCBvbiBwYWNrZXQtCj4+ID4+ IHNpemUuCj4+ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+IEl0IHNlZW1zIHRvIG1lIHRoaXMg aXMgYSBuZWNlc3NhcnkgY29uc2VxdWVuY2Ugb2YgeW91cgo+PiA+PiBlYXJsaWVyCj4+ID4+Pj4+ Pj4+IGFzc3VtcHRpb25zIC9hcmd1bWVudHMuCj4+ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+ IFtCQjpdIFRoaXMgaXNuJ3QgYXQgYWxsIG9idmlvdXMuIFVudGlsIEkgd29ya2VkIGl0Cj4+ID4+ IHRocm91Z2gsIGl0Cj4+ID4+Pj4+Pj4+IHdhc24ndCBvYnZpb3VzIHRvIG1lLiBJIHRoaW5rIGl0 IG5lZWRzIHRvIGJlIHNwZWxsZWQgb3V0Lgo+PiA+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+Pgo+ PiA+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+PiBbT24gdGhlIG90aGVyIGhhbmQsIGlmIHNvbWVv bmUgZGlzYWdyZWVzIHdpdGggdGhlCj4+ID4+IGFyZ3VtZW50cyBhbmQKPj4gPj4+Pj4+Pj4+Pj4g dGhpbmtzIHRoYXQgdGhlIG5ldHdvcmsgc2hvdWxkIG5vdGlmeSBkZXBlbmRlbnQgb24KPj4gPiBw YWNrZXQtCj4+ID4+IHNpemUsIHRoZW4KPj4gPj4+Pj4+Pj4+Pj4gaXQgZm9sbG93cyB0aGF0IHRo ZSB0cmFuc3BvcnQgY2FuIGFjdCBpbmRlcGVuZGVudCBvZgo+PiA+PiBwYWNrZXQtc2l6ZS5dCj4+ ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+IEkgdGhpbmsgaW4gUzMuMyB5b3UncmUgdHJ5aW5n IHRvIG1ha2UgYW5vdGhlciBhcmd1bWVudAo+PiA+PiAoPyk6LQo+PiA+Pj4+Pj4+Pj4+PiAqIHdl IGNhbiBlaXRoZXIgZG8gcGFja2V0LXNpemUgYmlhc2luZyBpbiB0aGUgbmV0d29yawo+PiA+PiBl bGVtZW50IG9yIG9uCj4+ID4+Pj4+Pj4+Pj4+IHRoZSBlbmQgaG9zdCB0cmFuc3BvcnQgKHNlZSBh cmd1bWVudCBhYm92ZSkKPj4gPj4+Pj4+Pj4+Pj4gKiBwYWNrZXQtc2l6ZSBiaWFzaW5nIGluIHRo ZSBuZXR3b3JrIGlzIHF1aXRlIHRyaWNreSwKPj4gPj4gYmVjYXVzZQo+PiA+Pj4+Pj4+PiB0aGVu IGJvdGggdGhlIG5ldHdvcmsgZWxlbWVudCAmIHRoZSB0cmFuc3BvcnQgaGF2ZSB0byBtYWtlCj4+ ID4+IHNvbWUKPj4gPj4+Pj4+Pj4gZ3Vlc3NlcyBhYm91dCBNVFUgLSB3aGVyZWFzIHdpdGggcGFj a2V0LXNpemUgYmlhc2luZyBpbiB0aGUKPj4gPj4+Pj4+Pj4gdHJhbnNwb3J0LCBuZWl0aGVyIG5l dHdvcmsgZWxlbWVudCBub3IgdHJhbnNwb3J0IG5lZWRzIHRvCj4+ID4ga25vdwo+PiA+PiB3aGF0 IHRoZQo+PiA+Pj4+Pj4+PiBNVFUgaXMuCj4+ID4+Pj4+Pj4+Pj4+ICogaXQgaXMgYWxzbyBlYXNp ZXIgdG8gaW1wbGVtZW50IHBhY2tldC1zaXplIGJpYXNpbmcgaW4KPj4gPj4gdGhlCj4+ID4+Pj4+ Pj4+IHRyYW5zcG9ydCB0aGFuIGluIHRoZSBuZXR3b3JrLgo+PiA+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+ Pj4+Pj4+PiBbQkJdIC4uLmFuZCBhbGwgdGhlIG90aGVyIGFyZ3VtZW50cyBhYm91dCB2dWxuZXJh YmlsaXR5Cj4+ID4gdG8KPj4gPj4+Pj4+Pj4gZmxvb2RpbmcgZXRjLCB0cmFuc3BvcnQtaW5kZXBl bmRlbmNlIGV0Yy4KPj4gPj4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+Pj4gT3VyIGFyZ3VtZW50IGlz IHNvcnQgb2YgbGlrZSBob3cgUGhpbCBzdW1tYXJpc2VzIGl0LCBidXQKPj4gPj4gd2l0aAo+PiA+ Pj4+Pj4+PiBhbiBhZGRlZCBudWFuY2UuIEl0J3MgYWxzbyBzYXlpbmcgbm8tb25lIGhhcyB0byBk bwo+PiA+IHBhY2tldC1zaXplCj4+ID4+Pj4+Pj4+IGJpYXNpbmcgYW55d2F5LiBJdCdzIG5vdCBz YXlpbmcgIlRoZSB0cmFuc3BvcnQgc2hvdWxkIGdpdmVuCj4+ID4+IHRoZQo+PiA+Pj4+Pj4+PiBu ZXR3b3JrIHNob3VsZG4ndCIuIEl0J3Mgc2F5aW5nICIqSWYgdGhlIHRyYW5zcG9ydCB3YW50cyB0 bwo+PiA+PiBjbGFpbQo+PiA+Pj4+Pj4+PiB0byBiZSBzY2FsYWJsZSB3cnQgcGFja2V0IHNpemUq IGl0IHNob3VsZCBpZiB0aGUgbmV0d29yawo+PiA+PiBzaG91bGRuJ3QiLgo+PiA+Pj4+Pj4+Pj4+ Pgo+PiA+Pj4+Pj4+Pj4+PiBUaGlzIGdpdmVzIGEgZ2V0LW91dCBjbGF1c2UgdG8gYW55IHRyYW5z cG9ydCB0aGF0IGlzbid0Cj4+ID4+Pj4+Pj4+IHBhY2tldC1zaXplIGRlcGVuZGVudCAoZS5nLiBj dXJyZW50IFRDUCkuIExhY2tpbmcgcGFja2V0LXNpemUKPj4gPj4+Pj4+Pj4gZGVwZW5kZW5jZSBq dXN0IG1lYW5zIHRoZXkgZG9uJ3Qgc2NhbGUgY29ycmVjdGx5IHdpdGggcGFja2V0Cj4+ID4+IHNp emUgLQo+PiA+Pj4+Pj4+PiBidXQgdGhleSBhcmUgYXQgbGliZXJ0eSBub3QgdG8gc2NhbGUgd2l0 aCBwYWNrZXQgc2l6ZQo+PiA+PiAocGFydGljdWxhcmx5Cj4+ID4+Pj4+Pj4+IGdpdmVuIE1UVSBn cm93dGggaXNuJ3Qgb2Z0ZW4gYmVpbmcgdXNlZCB0byBpbmNyZWFzZSBsaW5rCj4+ID4gcmF0ZXMK Pj4gPj4gYXQKPj4gPj4+Pj4+Pj4gdGhpcyBzdGFnZSBpbiBoaXN0b3J5KS4KPj4gPj4+Pj4+Pj4+ Pj4KPj4gPj4+Pj4+Pj4+Pj4gTm9uZSBvZiB3aGF0IFBoaWwgc2F5cyBjb252aW5jZXMgbWUgd2Ug Y291bGQgc2F5IDMuNCAob3IKPj4gPj4gMy4zKQo+PiA+Pj4+Pj4+PiBhbnkgbW9yZSBicmllZmx5 IG9yIGRpZmZlcmVudGx5LiBJdCdzIGVhc2llciB0byBzdW1tYXJpc2UKPj4gPiB3aGF0Cj4+ID4+ IHlvdQo+PiA+Pj4+Pj4+PiB1bmRlcnN0YW5kIGhhdmluZyByZWFkIHNvbWV0aGluZy4gQnV0IHRo YXQncyBub3QgdGhlIHNhbWUgYXMKPj4gPj4+Pj4+Pj4gd3JpdGluZyB0aGUgdGhpbmcgdGhhdCBo ZWxwZWQgeW91IHVuZGVyc3RhbmQuIFRoZXJlIGRvZXNuJ3QKPj4gPj4gc2VlbSB0bwo+PiA+Pj4+ Pj4+PiBiZSBhbnkgYXJndW1lbnQgZm9yIHdoeSBhbnl0aGluZyBuZWVkcyB0byBiZSBjaGFuZ2Vk LCBzbyBJJ20KPj4gPj4gZ29pbmcKPj4gPj4+Pj4+Pj4gdG8gbGVhdmUgaXQgYXMgaXMsIHVubGVz cyBwdXNoZWQuCj4+ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+Cj4+ ID4+Pj4+Pj4+Pj4+IE9uIHRoZSBsYXN0IGJ1bGxldCwgSSBkaWRuJ3QgcmVhbGx5IGZvbGxvdyB5 b3VyIGFyZ3VtZW50Cj4+ID4+IGluCj4+ID4+Pj4+Pj4+IFMzLjUuIE1pZ2h0IGJlIGVhc2llciB0 byBmb2xsb3cgaWYgUzMuNSBhbHNvIHRhbGtlZCBhYm91dCBob3cKPj4gPj4gYQo+PiA+Pj4+Pj4+ PiBuZXR3b3JrIGVsZW1lbnQgd291bGQgdGFrZSBhY2NvdW50IG9mIHBrdCBzaXplPwo+PiA+Pj4+ Pj4+Pj4+PiBBbHNvLCBkb2VzIHRoZSBmb2xsb3dpbmcgYXJndW1lbnQgYWxzbyBhcHBseT86Cj4+ ID4+Pj4+Pj4+Pj4+ICogaWYgcGt0LXNpemUgYmlhc2luZyBpcyBkb25lIGluIHRoZSB0cmFuc3Bv cnQsIHRoZW4gdGhlCj4+ID4+IHdvcmsgKHRvIGRvCj4+ID4+Pj4+Pj4+Pj4+IHRoZSBiaWFzaW5n KSBpcyBzcHJlYWQgb3ZlciBtYW55IGVuZCBob3N0cywKPj4gPj4+Pj4+Pj4+Pj4gKiB3aGVyZWFz IGlmIHBrdC1zaXplIGJpYXNpbmcgaXMgZG9uZSBpbiB0aGUgbmV0d29yaywKPj4gPiB0aGVuCj4+ ID4+IHRoZQo+PiA+Pj4+Pj4+PiB3b3JrIGlzIGNvbmNlbnRyYXRlZCBpbiBqdXN0IHRoZSBjb25n ZXN0ZWQgbmV0d29yayBlbGVtZW50LAo+PiA+PiB3aGljaAo+PiA+Pj4+Pj4+PiBoYXMgdG8gb3Bl cmF0ZSBvbiBhbGwgdGhlIHRyYWZmaWMgYXQgbGluZSBzcGVlZC4KPj4gPj4+Pj4+Pj4+Pj4KPj4g Pj4+Pj4+Pj4+Pj4gW0JCXTogMy41LiBJbXBsZW1lbnRhdGlvbiBFZmZpY2llbmN5Cj4+ID4+Pj4+ Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+IFtBREQ6XQo+PiA+Pj4+Pj4+Pj4+PiBCaWFzaW5nIGFnYWlu c3QgbGFyZ2UgcGFja2V0cyB0eXBpY2FsbHkgcmVxdWlyZXMgYW4KPj4gPiBleHRyYQo+PiA+PiBt dWx0aXBseQo+PiA+Pj4+Pj4+Pj4+PiBhbmQgIGRpdmlkZSBpbiB0aGUgbmV0d29yayAoc2VlIHRo ZSBleGFtcGxlIGJ5dGUtbW9kZQo+PiA+IGRyb3AKPj4gPj4+Pj4+Pj4gZm9ybXVsYSBpbiB0YWJs ZSAxKS4KPj4gPj4+Pj4+Pj4+Pj4gW0NPTlRJTlVFIEFTIEJFRk9SRTpdCj4+ID4+Pj4+Pj4+Pj4+ IEFsbG93aW5nIGZvciBwYWNrZXQgc2l6ZSBhdCB0aGUgdHJhbnNwb3J0IHJhdGhlciB0aGFuIGlu Cj4+ID4+IHRoZQo+PiA+Pj4+Pj4+Pj4+PiBuZXR3b3JrICBlbnN1cmVzIHRoYXQgbmVpdGhlciB0 aGUgbmV0d29yayBub3IgdGhlCj4+ID4+IHRyYW5zcG9ydCBuZWVkcyB0bwo+PiA+Pj4+Pj4+Pj4+ PiBkbyBhICBtdWx0aXBseSBvcGVyYXRpb24tLW11bHRpcGxpY2F0aW9uIGJ5IHBhY2tldCBzaXpl Cj4+ID4gaXMKPj4gPj4+Pj4+Pj4+Pj4gZWZmZWN0aXZlbHkgIGFjaGlldmVkIGFzIGEgcmVwZWF0 ZWQgYWRkIHdoZW4gdGhlCj4+ID4gdHJhbnNwb3J0Cj4+ID4+IGFkZHMgdG8KPj4gPj4+Pj4+Pj4+ Pj4gaXRzIGNvdW50IG9mICBtYXJrZWQgYnl0ZXMgYXMgZWFjaCBjb25nZXN0aW9uIGV2ZW50IGlz Cj4+ID4gZmVkCj4+ID4+IHRvIGl0Lgo+PiA+Pj4+Pj4+Pj4+PiBbQUREOl0KPj4gPj4+Pj4+Pj4+ Pj4gQWxzbyB0aGUgd29yayB0byBkbyB0aGUgYmlhc2luZyBpcyBzcHJlYWQgb3ZlciBtYW55Cj4+ ID4+IGhvc3RzLCByYXRoZXIKPj4gPj4+Pj4+Pj4+Pj4gdGhhbiAgY29uY2VudHJhdGVkIGluIGp1 c3QgdGhlIGNvbmdlc3RlZCBuZXR3b3JrIGVsZW1lbnQuCj4+ID4+Pj4+Pj4+Pj4+IFtDT05USU5V RSBBUyBCRUZPUkU6XQo+PiA+Pj4+Pj4+Pj4+Pgo+PiA+IFRoZXNlCj4+ID4+IGFyZW4ndAo+PiA+ Pj4+Pj4+Pj4+PiBwcmluY2lwbGVkIHJlYXNvbnMgaW4gdGhlbXNlbHZlcywgYnV0IHRoZXkgYXJl IGEgaGFwcHkKPj4gPj4gY29uc2VxdWVuY2UKPj4gPj4+Pj4+Pj4+Pj4gb2YgdGhlICBvdGhlciBw cmluY2lwbGVkIHJlYXNvbnMuCj4+ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+ Pj4+Pj4+IEJvYgo+PiA+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+PiBBdCAxMzozNiAwNS8wOS8y MDEyLCBNYW5uZXIgSnVra2Egd3JvdGU6Cj4+ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+IEhp IEJvYiwKPj4gPj4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+Pj4gU2luY2UgUGhpbCBpcyB5b3VyIGNv bGxlYWd1ZSBhdCBCVCwgZXZlbiBhdCBJcHN3aWNoICg/KSwKPj4gPj4gY2FuCj4+ID4+Pj4+Pj4+ IHlvdSBjaGVjayB0aG9zZSBhbmQgYWdyZWUgd2l0aCBQaGlsIGhvdyB0byBnbyBmb3J3YXJkPyBT b21lCj4+ID4gb2YKPj4gPj4+Pj4+Pj4gdGhvc2UgYXJlIGNsZWFyLCBvdGhlcnMgbmVlZCBkaXNj dXNzaW9uIHdpdGggUGhpbC4KPj4gPj4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+Pj4gR29ycnksIG9u IHBvaW50IDIpIGJlbG93LCBJIGRvbid0IGZvbGxvdyBMZXNsaWUncwo+PiA+PiBhcmd1bWVudHMu IEkKPj4gPj4+Pj4+Pj4gYXNrZWQgZnJvbSBoaW0gZGV0YWlsZWQgY29tbWVudHMgYW5kIHJlc29s dXRpb25zIG1vbnRocyBhZ28sCj4+ID4+IGFuZCBub3RoaW5nCj4+ID4+Pj4+Pj4+IGNhbWUuCj4+ ID4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+IGNoZWVycywKPj4gPj4+Pj4+Pj4+Pj4gSnVra2EK Pj4gPj4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+Pj4gT24gU2VwIDUsIDIwMTIsIGF0IDM6MjYgUE0s IEdvcnJ5IEZhaXJodXJzdCB3cm90ZToKPj4gPj4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+Pj4+IEJv YiBhbmQgSnVra2EsCj4+ID4+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+Pj4gSSB0aGluayBJIG5l ZWQgeW91ciBoZWxwIHRvIHJlc29sdmUgdGhpcy4uLiBTb21lIG9mIHRoZQo+PiA+Pj4+Pj4+PiBj b21tZW50cyByYWlzZWQgYnkgSm9obiBMZXNsaWUgYXBwZWFyIHRvIGhhdmUgc3Vic3RhbmNlLCBh bmQKPj4gPj4gSSdtCj4+ID4+Pj4+Pj4+IG5vdCBzdXJlIHdoYXQgeW91IHBsYW4gdG8gZG8gdG8g YWRkcmVzcyB0aGVzZS4KPj4gPj4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+PiBJdCB3b3VsZCBi ZSBnb29kIHRvIGRvIHNvbWV0aGluZyBxdWljayBzbyB0aGF0IEkgY2FuCj4+ID4+IGNvbXBsZXRl Cj4+ID4+Pj4+Pj4+IHRoZSBzdWJtaXNzaW9uIHRvIHRoZSBJRVNHLgo+PiA+Pj4+Pj4+Pj4+Pj4K Pj4gPj4+Pj4+Pj4+Pj4+IFRoZSBpc3N1ZXMgSSBwYXJ0aWN1bGFybHkgbm90ZSBhcmU6Cj4+ID4+ Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+Pj4gMSkgVGhpcyBjb250cmlidXRpb24gZnJvbSBQaGls IGFwcGVhcnMgdG8gYmUgd2l0aGluCj4+ID4gc2NvcGUKPj4gPj4gYW5kCj4+ID4+Pj4+Pj4+IGl0 IHNlZW1zIG1heSBoYXZlIGJlZW4gb3Zlcmxvb2tlZCAoc29ycnkpOgo+PiA+Pj4+Pj4+Pj4+Pj4g aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLQo+PiA+PiBhcmNoaXZlL3dlYi90c3Z3Zy9jdXJyZW50 L21zZzExMjM0Lmh0bWwKPj4gPj4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+PiAyKSBDYW4geW91 IGJlIGNsZWFyIGhlcmUgYWJvdXQgd2hhdCBpcyBhY3R1YWxseSBiZWVuCj4+ID4gc2FpZAo+PiA+ PiAtCj4+ID4+Pj4+Pj4+IGJlY2F1c2UgdGhlIHBvaW50IGJlbG93IHNlZW1zIHRvIGJlIGEgbWlz dW5kZXJzdGFuZGluZyBvZgo+PiA+PiBsYW5ndWFnZQo+PiA+Pj4+Pj4+PiB0byBtZSwgYW5kIEkg aG9wZWQgd2UgZGlkIG5vdCBjbGFpbSB0aGlzOgo+PiA+Pj4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+ Pj4+Pj4gXSBBbGFzLCB3aGVuIEkgcmVhZCBpdCBjYXJlZnVsbHkgdGhpcyB3ZWVrLCBJIGZpbmQK Pj4gPiB0aGF0Cj4+ID4+IEJvYiBpcwo+PiA+Pj4+Pj4+Pj4+Pj4+PiBhY3R1YWxseSBdIHNheWlu ZyB0aGF0IHRyYW5zcG9ydC1sYXllciBzaG91bGQgX29ubHlfCj4+ID4+IGNvbnNpZGVyCj4+ID4+ Pj4+Pj4+Pj4+Pj4+ICJjb25nZXN0ZWQgYnl0ZXMiLCBub3QgXSAiY29uZ2VzdGVkIHBhY2tldHMi Lgo+PiA+Pj4+Pj4+Pj4+Pj4+PiBdCj4+ID4+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+Pj4gMykg WW91J2xsIG5lZWQgdG8gcG9zdCB0aGUgdXBkYXRlZCBkcmFmdCBhbmQgc2VuZCBhIG5vdGUKPj4g Pj4gdG8KPj4gPj4+Pj4+Pj4gdGhlIGdyb3VwIHRvIGNvbmZpcm0gdGhhdCB0aGUgbmV3IHZlcnNp b24gaW5kZWVkIGNvbmNsdWRlcwo+PiA+IHRoZQo+PiA+Pj4+Pj4+PiBXR0xDLiBJJ2xsIGFkZCBh IG5vdGUgdG8gdGhlIHdyaXRldXAgdG8gaW5kaWNhdGUgdGhlIGRyYWZ0Cj4+ID4+IGNvbnRlbnQK Pj4gPj4+Pj4+Pj4gaGFzIGJlZW4gc3RhYmxlIHNpbmNlIE9jdCAyMDExLgo+PiA+Pj4+Pj4+Pj4+ Pj4KPj4gPj4+Pj4+Pj4+Pj4+IEdvcnJ5ICh3aXRoIG15IFRTVldHIERvY3VtbmVudCBTaGVwaGVy ZCBoYXQpCj4+ID4+Pj4+Pj4+Pj4+PiBjYzogQ28tQ2hhaXJzIGZvciBpbmZvLgo+PiA+Pj4+Pj4+ Pj4+Pj4KPj4gPj4+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQo+PiA+Pj4+Pj4+Pj4+Pj4+PiBGcm9tOiBHb3JyeSBGYWlyaHVyc3QgWyBtYWls dG86Z29ycnlAZXJnLmFiZG4uYWMudWtdCj4+ID4+Pj4+Pj4+Pj4+Pj4+IFNlbnQ6IE1pdHR3b2No LCAxNS4gQXVndXN0IDIwMTIgMjE6NDEKPj4gPj4+Pj4+Pj4+Pj4+Pj4gVG86IHRzdndnIGNoYWly Cj4+ID4+Pj4+Pj4+Pj4+Pj4+IFN1YmplY3Q6IEZ3ZDogUmU6IFt0c3Z3Z10gRllJOiBEb2N1bWVu dCB3cml0ZXVwIGZvcgo+PiA+Pj4+Pj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLXRzdndnLSBieXRlLXBr dC1jb25nZXN0Cj4+ID4+Pj4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+ Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+Pj4+IEhpIGd1eXMsCj4+ID4+Pj4+Pj4+Pj4+Pj4+Cj4+ID4+ Pj4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+Pj4+IEFwYXJ0IGZvcm0gdGhlIHVzdWFsIHJoZXRv cmljLCB0aGVyZSBhcmUgc29tZSBwb2ludHMKPj4gPj4gaGVyZSB0aGF0IHdlCj4+ID4+Pj4+Pj4+ Pj4+Pj4+IHNob3VsZCBub3RlIGFzIGNoYWlycy4gV2hhdCBhcmUgeW91IG93biB0aG91Z2h0cz8g QW5kCj4+ID4+IHdhcwo+PiA+Pj4+Pj4+Pj4+Pj4+PiBhbnl0aGluZyBub3RlZCBhdCB0aGUgSUVU RiBpbiBWYW5jb3V2ZXIgY29uY2VybmluZwo+PiA+IHRoaXMKPj4gPj4gZHJhZnQ/Cj4+ID4+Pj4+ Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+Pj4+IEdvcnJ5Cj4+ID4+Pj4+Pj4+Pj4+Pj4+Cj4+ID4+ Pj4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+Pj4+IC0tLS0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0KPj4gPj4+Pj4+Pj4+Pj4+Pj4gU3ViamVjdDogUmU6 IFt0c3Z3Z10gRllJOiBEb2N1bWVudCB3cml0ZXVwIGZvcgo+PiA+Pj4+Pj4+Pj4+Pj4+PiBkcmFm dC1pZXRmLXRzdndnLWJ5dGUtIHBrdC1jb25nZXN0Cj4+ID4+Pj4+Pj4+Pj4+Pj4+IERhdGU6IFdl ZCwgMTUgQXVnIDIwMTIgMTU6MDc6MjggLTA0MDAKPj4gPj4+Pj4+Pj4+Pj4+Pj4gRnJvbTogSm9o biBMZXNsaWUgPGpvaG5AamxjLm5ldD4KPj4gPj4+Pj4+Pj4+Pj4+Pj4gVG86IEdvcnJ5IEZhaXJo dXJzdCA8Z29ycnlAZXJnLmFiZG4uYWMudWs+Cj4+ID4+Pj4+Pj4+Pj4+Pj4+IENDOiB0c3Z3Z0Bp ZXRmLm9yZwo+PiA+Pj4+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+Pj4+PiBHb3JyeSBGYWlyaHVy c3QgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPiB3cm90ZToKPj4gPj4+Pj4+Pj4+Pj4+Pj4+Cj4+ID4+ Pj4+Pj4+Pj4+Pj4+PiBUaGUgZm9sbG93aW5nIGRvY3VtZW50IGhhcyBiZWVuIHJldmlzZWQgYWZ0 ZXIKPj4gPj4gcmVjZWl2aW5nCj4+ID4+Pj4+Pj4+IFdHTEMgY29tbWVudHMuCj4+ID4+Pj4+Pj4+ Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+Pj4+ICBUaGUgY2hhbmdlcyBhcmUgbW9zdGx5IHJlZnJlc2hp bmcgYSBkb2N1bWVudAo+PiA+PiBzY2hlZHVsZWQgdG8KPj4gPj4+Pj4+Pj4+Pj4+Pj4gZXhwaXJl IHRoaXMgbW9udGguCj4+ID4+Pj4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+Pj4+PiBObyBpc3N1 ZXMgd2VyZSBmb3VuZDoKPj4gPj4+Pj4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+Pj4+Pj4gIElzIHRo YXQgd2l0aCBXR0MtaGF0LW9uPwo+PiA+Pj4+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+Pj4+PiAg TmVpdGhlciBteSBpc3N1ZXMgbm9yIFBoaWxpcCBFYXJkbGV5J3MgY29tbWVudHMgd2VyZQo+PiA+ PiBhZGRyZXNzZWQuCj4+ID4+Pj4+Pj4+Pj4+Pj4+IEluIGZhY3QsIG5vdCBldmVuIHRoZSBjaGFu Z2VzIEJvYiBCcmlzY29lIG1lbnRpb25lZAo+PiA+IG9uLQo+PiA+PiBsaXN0IGhhdmUKPj4gPj4+ Pj4+Pj4+Pj4+Pj4gYmVlbiBpbmNsdWRlZC4KPj4gPj4+Pj4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+ Pj4+Pj4+IEFzIHJlcXVpcmVkIGJ5IFJGQyA0ODU4LCB0aGlzIGlzIHRoZSBjdXJyZW50IHRlbXBs YXRlCj4+ID4+IGZvciB0aGUKPj4gPj4+Pj4+Pj4+Pj4+Pj4gRG9jdW1lbnQKPj4gPj4+Pj4+Pj4+ Pj4+Pj4+IFNoZXBoZXJkIFdyaXRlLVVwLgo+PiA+Pj4+Pj4+Pj4+Pj4+Pj4gLi4uCj4+ID4+Pj4+ Pj4+Pj4+Pj4+PiAoMSkgV2hhdCB0eXBlIG9mIFJGQyBpcyBiZWluZyByZXF1ZXN0ZWQgKEJDUCwK Pj4gPiBQcm9wb3NlZAo+PiA+PiBTdGFuZGFyZCwKPj4gPj4+Pj4+Pj4+Pj4+Pj4+IEludGVybmV0 IFN0YW5kYXJkLCBJbmZvcm1hdGlvbmFsLCBFeHBlcmltZW50YWwsIG9yCj4+ID4+IEhpc3Rvcmlj KT8KPj4gPj4+Pj4+Pj4+Pj4+Pj4+IFdoeSBpcyB0aGlzIHRoZSBwcm9wZXIgdHlwZSBvZiBSRkM/ IElzIHRoaXMgdHlwZSBvZgo+PiA+PiBSRkMKPj4gPj4+Pj4+Pj4+Pj4+Pj4+IGluZGljYXRlZCBp biB0aGUgdGl0bGUgcGFnZSBoZWFkZXI/Cj4+ID4+Pj4+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+ Pj4+Pj4gVGhpcyBkb2N1bWVudCBpcyBpbnRlbmRlZCBhcyBCQ1AuIChUaGlzIHdhcyBkaXNjdXNz ZWQKPj4gPj4gYXQgSUVURi04MQo+PiA+Pj4+Pj4+Pj4+Pj4+Pj4gYW5kIHRoYXQgdGhlIHN0YXR1 cyBjaGFuZ2VkIGZyb20gSW5mb3JtYXRpb25hbCB0byBCQ1AKPj4gPj4gc2luY2UgaXQKPj4gPj4+ Pj4+Pj4+Pj4+Pj4+IHByb3ZpZGVzIGd1aWRhbmNlIHRvIGltcGxlbWVudG9ycyBhbmQgcGVvcGxl Cj4+ID4+IGNvbmZpZ3VyaW5nCj4+ID4+Pj4+Pj4+IHJvdXRlcnMgYW5kIGhvc3RzKS4KPj4gPj4+ Pj4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+Pj4+Pj4gIFRoYW5rIHlvdSBmb3IgZmluYWxseSBhbnN3 ZXJpbmcgbXkgcXVlc3Rpb24gYWJvdXQKPj4gPiBCQ1AKPj4gPj4gc3RhdHVzLgo+PiA+Pj4+Pj4+ Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+Pj4+Pj4gLi4uCj4+ID4+Pj4+Pj4+Pj4+Pj4+PiBXb3JraW5n IEdyb3VwIFN1bW1hcnkKPj4gPj4+Pj4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+Pj4+PiBUaGVy ZSB3YXMgY29uc2Vuc3VzIHRvIHB1Ymxpc2ggdGhpcyBhcyBhIFdHIGRvY3VtZW50Cj4+ID4+IGFu ZAo+PiA+Pj4+Pj4+Pj4+Pj4+Pj4gYWdyZWVtZW50IGF0Cj4+ID4+Pj4+Pj4+Pj4+Pj4+PiBJRVRG LTgyIHRoYXQgdGhlIGRvY3VtZW50IHdhcyBub3cgY29tcGxldGUuCj4+ID4+Pj4+Pj4+Pj4+Pj4+ Cj4+ID4+Pj4+Pj4+Pj4+Pj4+ICBXYXMgdGhhdCByZXZpZXdlZCBvbi1saXN0Pwo+PiA+Pj4+Pj4+ Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+Pj4+Pj4gLi4uCj4+ID4+Pj4+Pj4+Pj4+Pj4+PiAoMykgQnJp ZWZseSBkZXNjcmliZSB0aGUgcmV2aWV3IG9mIHRoaXMgZG9jdW1lbnQgdGhhdAo+PiA+PiB3YXMK Pj4gPj4+Pj4+Pj4+Pj4+Pj4+IHBlcmZvcm1lZAo+PiA+Pj4+Pj4+Pj4+Pj4+PiBieQo+PiA+Pj4+ Pj4+Pj4+Pj4+Pj4gdGhlIERvY3VtZW50IFNoZXBoZXJkLiBJZiB0aGlzIHZlcnNpb24gb2YgdGhl Cj4+ID4gZG9jdW1lbnQKPj4gPj4gaXMgbm90Cj4+ID4+Pj4+Pj4+Pj4+Pj4+PiByZWFkeSBmb3Ig cHVibGljYXRpb24sIHBsZWFzZSBleHBsYWluIHdoeSB0aGUKPj4gPiBkb2N1bWVudAo+PiA+PiBp cyBiZWluZwo+PiA+Pj4+Pj4+Pj4+Pj4+Pj4gZm9yd2FyZGVkIHRvIHRoZSBJRVNHLgo+PiA+Pj4+ Pj4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBkb2N1bWVudCB3YXMgcHJlc2VudGVk IGF0IElFV1RGLTgyIChUYWlwZWkpLCB3aXRoCj4+ID4+IGEgcmVxdWVzdAo+PiA+Pj4+Pj4+Pj4+ Pj4+Pj4gZm9yCj4+ID4+Pj4+Pj4+Pj4+Pj4+IFdHTEMuCj4+ID4+Pj4+Pj4+Pj4+Pj4+PiBXR0xD IGNvbmNsdWRlZCB3aXRoIHNvbWUgZGlzY3Vzc2lvbiBidXQgbm8KPj4gPiBzdWJzdGFudGl2ZQo+ PiA+PiBjaGFuZ2VzCj4+ID4+Pj4+Pj4+Pj4+Pj4+PiBvbiBGcmlkYXkgMzB0aCBNYXJjaCAyMDEy Lgo+PiA+Pj4+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+Pj4+PiAgWWVzLCBJIGd1ZXNzIHRoYXQg aXMgdHJ1ZTsgYnV0IGlnbm9yaW5nIHN1YnN0YW50aXZlCj4+ID4+IGNvbW1lbnRzCj4+ID4+Pj4+ Pj4+Pj4+Pj4+IGlzbid0IGEgZ29vZCBwcmFjdGljZSBJTUhPLgo+PiA+Pj4+Pj4+Pj4+Pj4+Pgo+ PiA+Pj4+Pj4+Pj4+Pj4+Pj4gKDQpIERvZXMgdGhlIGRvY3VtZW50IFNoZXBoZXJkIGhhdmUgYW55 IGNvbmNlcm5zCj4+ID4gYWJvdXQKPj4gPj4gdGhlIGRlcHRoCj4+ID4+Pj4+Pj4+Pj4+Pj4+PiBv ciBicmVhZHRoIG9mIHRoZSByZXZpZXdzIHRoYXQgaGF2ZSBiZWVuIHBlcmZvcm1lZD8KPj4gPj4+ Pj4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+Pj4+PiBObyAtIHRoZSBvcmlnaW5hbCBkcmFmdCBo YWQgYSBsb3Qgb2YgYmFja2dyb3VuZAo+PiA+PiBtYXRlcmlhbCwgbXVjaAo+PiA+Pj4+Pj4+Pj4+ Pj4+Pj4gb2YKPj4gPj4+Pj4+Pj4+Pj4+Pj4gdGhpcwo+PiA+Pj4+Pj4+Pj4+Pj4+Pj4gaGFzIGJl ZW4gY29uZGVuc2VkIG9yIHJlbW92ZWQsIHJlc3VsdGluZyBpbiBhIHNtYWxsZXIKPj4gPj4gZG9j dW1lbnQuCj4+ID4+Pj4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+Pj4+ICBUaGF0IGlzIGluZGVl ZCB3aGF0IEkgYmFzaWNhbGx5IGFza2VkIGZvciwgYnV0IEkKPj4gPj4gZG9uJ3Qgc2VlIGFueQo+ PiA+Pj4+Pj4+Pj4+Pj4+PiBldmlkZW5jZSBvZiBpdDoKPj4gPj4+Pj4+Pj4+Pj4+Pj4KPj4gPj4+ Pj4+Pj4+Pj4+Pj4gLSBkaWZmKDA3LDA4KSAgNDggbGluZXMgY2hhbmdlZCBvciBkZWxldGVkOyAg NTMgbGluZXMKPj4gPj4gY2hhbmdlZCBvcgo+PiA+Pj4+Pj4+PiBhZGRlZAo+PiA+Pj4+Pj4+Pj4+ Pj4+PiAtIGRpZmYoMDYsMDcpICAgOCBsaW5lcyBjaGFuZ2VkIG9yIGRlbGV0ZWQ7ICAxMyBsaW5l cwo+PiA+PiBjaGFuZ2VkIG9yCj4+ID4+Pj4+Pj4+IGFkZGVkCj4+ID4+Pj4+Pj4+Pj4+Pj4+IC0g ZGlmZigwNSwwNikgIDY0IGxpbmVzIGNoYW5nZWQgb3IgZGVsZXRlZDsgIDY5IGxpbmVzCj4+ID4+ IGNoYW5nZWQgb3IKPj4gPj4+Pj4+Pj4+Pj4+Pj4gYWRkZWQKPj4gPj4+Pj4+Pj4+Pj4+Pj4gLSBk aWZmKDA0LDA1KSA4MjMgbGluZXMgY2hhbmdlZCBvciBkZWxldGVkOyA4NjQgbGluZXMKPj4gPj4g Y2hhbmdlZCBvcgo+PiA+Pj4+Pj4+Pj4+Pj4+PiBhZGRlZAo+PiA+Pj4+Pj4+Pj4+Pj4+Pgo+PiA+ Pj4+Pj4+Pj4+Pj4+PiAoTmVlZCBJIGdvIGZhcnRoZXI/IFRoYXQgZ2V0cyB1cyBiYWNrIHRvIE1h cmNoCj4+ID4gMjAxMS4uLikKPj4gPj4+Pj4+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+Pj4+Pj4+ICg5 KSBIb3cgc29saWQgaXMgdGhlIFdHIGNvbnNlbnN1cyBiZWhpbmQgdGhpcwo+PiA+PiBkb2N1bWVu dD8gRG9lcyBpdAo+PiA+Pj4+Pj4+Pj4+Pj4+Pj4gcmVwcmVzZW50IHRoZSBzdHJvbmcgY29uY3Vy cmVuY2Ugb2YgYSBmZXcKPj4gPiBpbmRpdmlkdWFscywKPj4gPj4gd2l0aAo+PiA+Pj4+Pj4+Pj4+ Pj4+Pj4gb3RoZXJzIGJlaW5nIHNpbGVudCwgb3IgZG9lcyB0aGUgV0cgYXMgYSB3aG9sZQo+PiA+ PiB1bmRlcnN0YW5kCj4+ID4+Pj4+Pj4+IGFuZCBhZ3JlZSB3aXRoIGl0Pwo+PiA+Pj4+Pj4+Pj4+ Pj4+Pj4KPj4gPj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBkb2N1bWVudCBoYXMgV0cgc3VwcG9ydCBhbmQg dGhlcmUgaXMgY29uc2Vuc3VzIHRvCj4+ID4+IHB1Ymxpc2guCj4+ID4+Pj4+Pj4+Pj4+Pj4+Cj4+ ID4+Pj4+Pj4+Pj4+Pj4+ICBUaGlzLCBJTUhPLCBkb2Vzbid0IGFuc3dlciB0aGUgcXVlc3Rpb24u IDpeKAo+PiA+Pj4+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+Pj4+PiAgRG9lcyBpdCByZXByZXNl bnQgdGhlIGNvbmN1cnJlbmNlIG9mIGEgZmV3Cj4+ID4+IGluZGl2aWR1YWxzLCBvciBkb2VzCj4+ ID4+Pj4+Pj4+Pj4+Pj4+IHRoZSBXRyBhcyBhIHdob2xlIHVuZGVyc3RhbmQgYW5kIGFncmVlIHdp dGggaXQ/Cj4+ID4+Pj4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+Pj4+IEZvciByZWZlcmVuY2Us IG15IGNvbW1lbnRzIGluY2x1ZGVkOgo+PiA+Pj4+Pj4+Pj4+Pj4+PiBdCj4+ID4+Pj4+Pj4+Pj4+ Pj4+IF0gV2hlbiBJIHByZXZpb3VzbHkgc2tpbW1lZCB0aGlzIGRvY3VtZW50LCBJIGJlbGlldmVk Cj4+ID4+IGl0Cj4+ID4+Pj4+Pj4+Pj4+Pj4+IGNvbnRhaW5lZCBvbmx5IF0gY29tbW9uIGdyb3Vu ZDogdGhhdCBBUU0gc2hvdWxkCj4+ID4+IGRyb3AvbWFyayBwYWNrZXRzCj4+ID4+Pj4+Pj4+Pj4+ Pj4+IHdpdGhvdXQgZmF2b3Jpbmcgc21hbGwgXSBwYWNrZXRzLCBhbmQgdGhhdCB0byB3aGF0ZXZl cgo+PiA+PiBleHRlbnQKPj4gPj4+Pj4+Pj4+Pj4+Pj4gcGFja2V0IHNpemUgX2lzXyBjb25zaWRl cmVkLCB0aGF0IF0gc2hvdWxkIGJlIGEKPj4gPj4+Pj4+Pj4gdHJhbnNwb3J0LWxheWVyIHJlc3Bv bnNpYmlsaXR5Lgo+PiA+Pj4+Pj4+Pj4+Pj4+PiBdCj4+ID4+Pj4+Pj4+Pj4+Pj4+IF0gQWxhcywg d2hlbiBJIHJlYWQgaXQgY2FyZWZ1bGx5IHRoaXMgd2VlaywgSSBmaW5kCj4+ID4gdGhhdAo+PiA+ PiBCb2IgaXMKPj4gPj4+Pj4+Pj4+Pj4+Pj4gYWN0dWFsbHkgXSBzYXlpbmcgdGhhdCB0cmFuc3Bv cnQtbGF5ZXIgc2hvdWxkIF9vbmx5Xwo+PiA+PiBjb25zaWRlcgo+PiA+Pj4+Pj4+Pj4+Pj4+PiAi Y29uZ2VzdGVkIGJ5dGVzIiwgbm90IF0gImNvbmdlc3RlZCBwYWNrZXRzIi4KPj4gPj4+Pj4+Pj4+ Pj4+Pj4gXQo+PiA+Pj4+Pj4+Pj4+Pj4+PiBdIEluIGZhY3QsIEJvYiBvcGVubHkgZW5kb3JzZXMg cmVwbGFjaW5nIFRDUAo+PiA+PiBjb25nZXN0aW9uLWNvbnRyb2wKPj4gPj4+Pj4+Pj4+Pj4+Pj4g d2l0aCBhbiBdIGFsZ29yaXRobSB3aGljaCBjYWxjdWxhdGVzICJmYWlyLXNoYXJlCj4+ID4gYnl0 ZXMiCj4+ID4+IGFuZAo+PiA+Pj4+Pj4+Pj4+Pj4+PiBkb2Vzbid0IGJhY2sgb2ZmIGF0IGFsbCBd IChldmVuIGluIHRoZSBwcmVzZW5jZSBvZiAyMCUKPj4gPj4gcGFja2V0Cj4+ID4+Pj4+Pj4+Pj4+ Pj4+IGxvc3MpIHVubGVzcyB5b3UncmUgYWxyZWFkeSBzZW5kaW5nIF0gbW9yZSB0aGFuIHRoaXMK Pj4gPj4+Pj4+Pj4gImZhaXItc2hhcmUiLgo+PiA+Pj4+Pj4+Pj4+Pj4+PiBdCj4+ID4+Pj4+Pj4+ Pj4+Pj4+IF0gICAgSSBkbyBub3QgYmVsaWV2ZSB0aGF0IGlzIHRoZSBjb25zZW5zdXMgb2YgdGhp cwo+PiA+IFdHOwo+PiA+PiBhbmQgSQo+PiA+Pj4+Pj4+PiBiZWxpZXZlCj4+ID4+Pj4+Pj4+Pj4+ Pj4+IGlmCj4+ID4+Pj4+Pj4+Pj4+Pj4+IF0gdGhhdCB3ZXJlIHRoZSBjb25zZW5zdXMgaXQgd291 bGQgZXhjZWVkIG91ciBjaGFydGVyLgo+PiA+Pj4+Pj4+Pj4+Pj4+PiBdCj4+ID4+Pj4+Pj4+Pj4+ Pj4+IF0gVGhlIGRyYWZ0IGNvbnRhaW5zIGEgbnVtYmVyIG9mIHRoaW5ncyBJIF9kb18KPj4gPiBz dXBwb3J0Owo+PiA+PiBhbmQgSSdkCj4+ID4+Pj4+Pj4+Pj4+Pj4+IGJlIGhhcHB5IF0gdG8gc3Vw cG9ydCBhIGNvbnNpZGVyYWJseSBzaG9ydGVyIGRyYWZ0Cj4+ID4+IHdoaWNoCj4+ID4+Pj4+Pj4+ Pj4+Pj4+IGNvbmNlbnRyYXRlcyBvbiB0aGUgQVFNIF0gcmVjb21tZW5kYXRpb24sIG9taXR0aW5n IGFueQo+PiA+Pj4+Pj4+Pj4+Pj4+PiBzdWdnZXN0aW9ucyBvZiBtb2RpZnlpbmcgVENQIGNvbmdl c3Rpb24gXSBjb250cm9sLgo+PiA+Pj4+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+Pj4+PiBhbmQg UGhpbGlwJ3MgY29tbWVudHMgaW5jbHVkZWQ6Cj4+ID4+Pj4+Pj4+Pj4+Pj4+IF0KPj4gPj4+Pj4+ Pj4+Pj4+Pj4gXSBTMi4yIEkgdGhvdWdodCB0aGUgbnVtYmVyZWQgYnVsbGV0cyBjb3VsZCBiZSBi ZXR0ZXIKPj4gPj4gcGhyYXNlZCwKPj4gPj4+Pj4+Pj4+Pj4+Pj4gc29tZXRoaW5nIGxpa2UgXSAr dGhpczotIF0KPj4gPj4+Pj4+Pj4+Pj4+Pj4gXSAgIDEuICBBUU0gYWxnb3JpdGhtcyBzdWNoIGFz IFJFRCBTSE9VTEQgdXNlIHBhY2tldC0KPj4gPj4gbW9kZQo+PiA+Pj4+Pj4+PiBkcm9wLCBpZSB0 aGV5Cj4+ID4+Pj4+Pj4+Pj4+Pj4+IFNIT1VMRCBOT1QKPj4gPj4+Pj4+Pj4+Pj4+Pj4gXSArdXNl IGJ5dGUtbW9kZSBkcm9wLiBUaGUgbGF0dGVyIF0gaXMgbW9yZSBjb21wbGV4LAo+PiA+Pj4+Pj4+ Pj4+Pj4+PiBdICAgICAgICBpdCBjcmVhdGVzIHRoZSBwZXJ2ZXJzZSBpbmNlbnRpdmUgdG8gZnJh Z21lbnQKPj4gPj4gc2VnbWVudHMKPj4gPj4+Pj4+Pj4gaW50bwo+PiA+Pj4+Pj4+Pj4+Pj4+PiB0 aW55Cj4+ID4+Pj4+Pj4+Pj4+Pj4+IF0gICAgICAgIHBpZWNlcyBhbmQgaXQgaXMgdnVsbmVyYWJs ZSB0byBmbG9vZHMgb2YKPj4gPj4gc21hbGwtCj4+ID4+Pj4+Pj4+Pj4+Pj4+IF0gICAgICAgIHBh Y2tldHMuCj4+ID4+Pj4+Pj4+Pj4+Pj4+IF0KPj4gPj4+Pj4+Pj4+Pj4+Pj4gXSAgICAyLiAgSWYg YSB2ZW5kb3IgaGFzIGltcGxlbWVudGVkIGJ5dGUtbW9kZSBkcm9wLAo+PiA+PiBhbmQgYW4KPj4g Pj4+Pj4+Pj4gb3BlcmF0b3IKPj4gPj4+Pj4+Pj4+Pj4+Pj4gaGFzCj4+ID4+Pj4+Pj4+Pj4+Pj4+ IF0gICAgICAgIHR1cm5lZCBpdCBvbiwgaXQgaXMgUkVDT01NRU5ERUQgdG8gdHVybiBpdAo+PiA+ PiBvZmYsIGFmdGVyCj4+ID4+Pj4+Pj4+Pj4+Pj4+IGVzdGFibGlzaGluZyBpZgo+PiA+Pj4+Pj4+ Pj4+Pj4+PiBdICt0aGVyZSBhcmUgYW55IGltcGxpY2F0aW9ucyBvbgo+PiA+Pj4+Pj4+Pj4+Pj4+ PiBdIHRoZSByZWxhdGl2ZSBwZXJmb3JtYW5jZSBvZgo+PiA+Pj4+Pj4+Pj4+Pj4+PiBdICAgICAg ICBhcHBsaWNhdGlvbnMgdXNpbmcgZGlmZmVyZW50IHBhY2tldCBzaXplcy4KPj4gPj4+Pj4+Pj4+ Pj4+Pj4gXQo+PiA+Pj4+Pj4+Pj4+Pj4+PiBdICAgMy4gIFJFRCBTSE9VTEQgTk9UIGJlIHR1cm5l ZCBvZmYuIFdpdGhvdXQgUkVELCBhCj4+ID4+IGRyb3AgdGFpbAo+PiA+Pj4+Pj4+Pj4+Pj4+PiBd ICAgICAgICBxdWV1ZSBiaWFzZXMgYWdhaW5zdCBsYXJnZSBwYWNrZXRzLgo+PiA+Pj4+Pj4+Pj4+ Pj4+PiBdCj4+ID4+Pj4+Pj4+Pj4+Pj4+IF0gTml0IC0gdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGgg c2hvdWxkbid0IGJlIGluZGVudGVkCj4+ID4+IChOb3RlIHdlbGwKPj4gPj4+Pj4+Pj4+Pj4+Pj4g dGhhdAo+PiA+Pj4+Pj4+Pj4+Pj4+PiBSRUQncy4uLikKPj4gPj4+Pj4+Pj4+Pj4+Pj4gXQo+PiA+ Pj4+Pj4+Pj4+Pj4+PiBdIFMzLjMKPj4gPj4+Pj4+Pj4+Pj4+Pj4gXSBUaGUgc2VjdGlvbiBjb3Vs ZCBiZSBzbGlnaHRseSBjbGVhcmVyLiBTdGFydGluZyB3aXRoCj4+ID4+IHRoZSBzZWNvbmQKPj4g Pj4+Pj4+Pj4+Pj4+Pj4gcGFyYSwgd2hlcmUgeW91IF0gK3N0YXJ0IHRhbGtpbmcgYWJvdXQgc29t ZXRoaW5nIHlvdQo+PiA+PiBkb24ndAo+PiA+Pj4+Pj4+Pj4+Pj4+PiByZWNvbW1lbmQgKGllIHlv dSBoYXZlIHRvIHJlbWVtYmVyIHRoYXQgXSAreW91J3JlCj4+ID4+IHRhbGtpbmcgYWJvdXQKPj4g Pj4+Pj4+Pj4+Pj4+Pj4gdGhlIGNvbnNlcXVlbmNlcyBvZiBub3QgZm9sbG93aW5nIHlvdXIKPj4g PiByZWNvbW1lbmRhdGlvbikuCj4+ID4+Pj4+Pj4+Pj4+Pj4+IF0KPj4gPj4+Pj4+Pj4+Pj4+Pj4g XSBTMy4zCj4+ID4+Pj4+Pj4+Pj4+Pj4+IF0gICAgbyAgQWxzbywgaWYgdGhlIG5ldHdvcmsgYmlh c2VzIGNvbmdlc3Rpb24KPj4gPj4gbm90aWZpY2F0aW9uIGJ5Cj4+ID4+Pj4+Pj4+IHBhY2tldAo+ PiA+Pj4+Pj4+Pj4+Pj4+PiBzaXplCj4+ID4+Pj4+Pj4+Pj4+Pj4+IF0gICAgICAgaXQgaGFzIHRv IGFzc3VtZSBhIGJhc2VsaW5lIHBhY2tldCBzaXplLS1hbGwKPj4gPj4gcHJvcG9zZWQKPj4gPj4+ Pj4+Pj4+Pj4+Pj4gYWxnb3JpdGhtcwo+PiA+Pj4+Pj4+Pj4+Pj4+PiBdICAgICAgIHVzZSB0aGUg bG9jYWwgTVRVLiAgVGhlbiB0cmFuc3BvcnRzIGhhdmUgdG8KPj4gPj4gZ3Vlc3Mgd2hpY2gKPj4g Pj4+Pj4+Pj4gbGluawo+PiA+Pj4+Pj4+Pj4+Pj4+PiB3YXMKPj4gPj4+Pj4+Pj4+Pj4+Pj4gXSAg ICAgICBjb25nZXN0ZWQgYW5kIHdoYXQgaXRzIGxvY2FsIE1UVSB3YXMsIGluIG9yZGVyCj4+ID4+ IHRvIGtub3cKPj4gPj4+Pj4+Pj4gaG93IHRvCj4+ID4+Pj4+Pj4+Pj4+Pj4+IF0gICAgICAgdGFp bG9yIHRoZWlyIGNvbmdlc3Rpb24gcmVzcG9uc2UgdG8gdGhhdCBsaW5rLgo+PiA+Pj4+Pj4+Pj4+ Pj4+PiBdIFNvIHlvdSdyZSBzYXlpbmcgdGhhdCBmb3IgYnl0ZS1tb2RlIGRyb3AsIHRoZQo+PiA+ IG5ldHdvcmsKPj4gPj4gZWxlbWVudAo+PiA+Pj4+Pj4+Pj4+Pj4+PiBoYXMgdG8gY29tcGFyZSB0 aGUgXSArc2l6ZSBvZiB0aGUgY3VycmVudCBwa3Qgd2l0aCB0aGUKPj4gPj4gTVRVLCBhbmQKPj4g Pj4+Pj4+Pj4+Pj4+Pj4gaWYgaXQncyAyNSogc21hbGxlciB0aGVuIHJlZHVjZSB0aGUgXSArcGt0 IGxvc3MKPj4gPj4gcHJvYmFibHkgYnkgMjUqPwo+PiA+Pj4+Pj4+Pj4+Pj4+PiBBbmQgaWYgdGhl IE1UVSB3YXMgYmlnZ2VyLCB0aGVuIHRoZSBjdXJyZW50IHBrdCB3b3VsZAo+PiA+IF0KPj4gPj4g K2JlCj4+ID4+Pj4+Pj4+Pj4+Pj4+IGRyb3BwZWQgd2l0aCBncmVhdGVyIHByb2JhYmlsaXR5PyBB bmQgYm90aCBvZiB0aGVzZQo+PiA+PiB0aGluZ3MKPj4gPj4+Pj4+Pj4gYXJlIGhhcmQgdG8gZG8u Cj4+ID4+Pj4+Pj4+Pj4+Pj4+IF0KPj4gPj4+Pj4+Pj4+Pj4+Pj4gXSBTMy40ICgmIGtub2NrLW9u IGVmZmVjdCBvbiAzLjMpIF0gSSB0aGluayB0aGlzIGNvdWxkCj4+ID4+IGJlIGJldHRlci4KPj4g Pj4+Pj4+Pj4+Pj4+Pj4gXSBJIGFncmVlIHdpdGggeW91ciBhcmd1bWVudHMgaW4gUzMuMSAmIDMu MiB0aGF0Cj4+ID4+IGRyb3BwaW5nIG9yCj4+ID4+Pj4+Pj4+Pj4+Pj4+IG1hcmtpbmcgc2hvdWxk IGJlIF0gK2luZGVwZW5kZW50IG9mIHBrdCBzaXplLgo+PiA+Pj4+Pj4+Pj4+Pj4+PiBdIFlvdSBu b3cgZ28gaW50byBhIGNvdXBsZSBvZiBwYWdlcywgd2hpY2ggSSB0aGluawo+PiA+PiBjb3VsZCBi ZQo+PiA+Pj4+Pj4+Pj4+Pj4+PiBib2lsZWQgZG93biB0byBhIF0gK3BhcmFncmFwaCwgc2F5aW5n IHNvbWV0aGluZyBsaWtlOi0KPj4gPj4gXSAqIHRoZQo+PiA+Pj4+Pj4+Pj4+Pj4+PiBvdmVyYWxs IHN5c3RlbSAobmV0d29yayArIHRyYW5zcG9ydCkgaGFzIHRvIGJlIHBhY2tldC0KPj4gPj4gc2l6 ZQo+PiA+Pj4+Pj4+Pj4+Pj4+PiBkZXBlbmRlbnQgaW4gXQo+PiA+Pj4+Pj4+Pj4+Pj4+PiArb3Jk ZXIgdG8gZHJpdmUgb3V0IHRoZSByaWdodCBhbW91bnQgb2YgdHJhZmZpYyBzbyB0aGUKPj4gPj4g cmVzb3VyY2UKPj4gPj4+Pj4+Pj4+Pj4+Pj4gYmVjb21lcyBdCj4+ID4+Pj4+Pj4+Pj4+Pj4+ICt1 bmNvbmdlc3RlZCAoc2luY2Ugd2UgYXNzdW1lIGFsbCByZXNvdXJjZXMgYXJlIGluCj4+ID4+IHBy YWN0aWNlIGJ5dGUKPj4gPj4+Pj4+Pj4+Pj4+Pj4gK3JhdGhlcgo+PiA+Pj4+Pj4+Pj4+Pj4+PiB0 aGFuIF0gK3BhY2tldCBsaW1pdGVkKSBdICogZnJvbSBTMy4xIGFuZCBTMy4yIHRoZQo+PiA+IElF VEYKPj4gPj4gaXMKPj4gPj4+Pj4+Pj4+Pj4+Pj4gY29udmluY2VkIHRoYXQgdGhlIG5ldHdvcmsg c2hvdWxkIG5vdGlmeSBdCj4+ID4gK2luZGVwZW5kZW50Cj4+ID4+IG9mCj4+ID4+Pj4+Pj4+IHBh Y2tldC1zaXplLgo+PiA+Pj4+Pj4+Pj4+Pj4+PiBdICogdGhlcmVmb3JlIHRoZSB0cmFuc3BvcnQg bXVzdCBhY3QgZGVwZW5kZW50IG9uCj4+ID4+IHBhY2tldC1zaXplLgo+PiA+Pj4+Pj4+Pj4+Pj4+ PiBdCj4+ID4+Pj4+Pj4+Pj4+Pj4+IF0gSXQgc2VlbXMgdG8gbWUgdGhpcyBpcyBhIG5lY2Vzc2Fy eSBjb25zZXF1ZW5jZSBvZgo+PiA+PiB5b3VyIGVhcmxpZXIKPj4gPj4+Pj4+Pj4+Pj4+Pj4gYXNz dW1wdGlvbnMgXSArL2FyZ3VtZW50cy4KPj4gPj4+Pj4+Pj4+Pj4+Pj4gXQo+PiA+Pj4+Pj4+Pj4+ Pj4+PiBdIFtPbiB0aGUgb3RoZXIgaGFuZCwgaWYgc29tZW9uZSBkaXNhZ3JlZXMgd2l0aCB0aGUK Pj4gPj4gYXJndW1lbnRzIGFuZAo+PiA+Pj4+Pj4+Pj4+Pj4+PiB0aGlua3MgdGhhdCB0aGUgXSAr bmV0d29yayBzaG91bGQgbm90aWZ5IGRlcGVuZGVudCBvbgo+PiA+Pj4+Pj4+Pj4+Pj4+PiBwYWNr ZXQtc2l6ZSwgdGhlbiBpdCBmb2xsb3dzIHRoYXQgdGhlIF0gK3RyYW5zcG9ydCBjYW4KPj4gPj4g YWN0Cj4+ID4+Pj4+Pj4+Pj4+Pj4+IGluZGVwZW5kZW50IG9mCj4+ID4+Pj4+Pj4+Pj4+Pj4+IHBh Y2tldC0gc2l6ZS5dIF0gXSBJIHRoaW5rIGluIFMzLjMgeW91J3JlIHRyeWluZyB0bwo+PiA+PiBt YWtlIGFub3RoZXIKPj4gPj4+Pj4+Pj4+Pj4+Pj4gYXJndW1lbnQgKD8pOi0gIF0gKiB3ZSBjYW4g ZWl0aGVyIGRvIHBhY2tldC1zaXplCj4+ID4+IGJpYXNpbmcgaW4gdGhlCj4+ID4+Pj4+Pj4+Pj4+ Pj4+IG5ldHdvcmsgZWxlbWVudCBvciBvbiB0aGUgZW5kIGhvc3QgXSArdHJhbnNwb3J0IChzZWUK Pj4gPj4gYXJndW1lbnQKPj4gPj4+Pj4+Pj4+Pj4+Pj4gYWJvdmUpIF0gKiBwYWNrZXQtc2l6ZSBi aWFzaW5nIGluIHRoZSBuZXR3b3JrIGlzIHF1aXRlCj4+ID4+IHRyaWNreSwKPj4gPj4+Pj4+Pj4+ Pj4+Pj4gYmVjYXVzZSB0aGVuIGJvdGggdGhlIF0gK25ldHdvcmsgZWxlbWVudCAmIHRoZQo+PiA+ PiB0cmFuc3BvcnQgaGF2ZSB0bwo+PiA+Pj4+Pj4+Pj4+Pj4+PiBtYWtlIHNvbWUgZ3Vlc3NlcyBh Ym91dCBNVFUgLSB3aGVyZWFzIF0KPj4gPj4+Pj4+Pj4+Pj4+Pj4gK3dpdGggcGFja2V0LXNpemUg Ymlhc2luZyBpbiB0aGUgdHJhbnNwb3J0LCBuZWl0aGVyCj4+ID4+IG5ldHdvcmsKPj4gPj4+Pj4+ Pj4+Pj4+Pj4gK2VsZW1lbnQKPj4gPj4+Pj4+Pj4+Pj4+Pj4gbm9yIF0gK3RyYW5zcG9ydCBuZWVk cyB0byBrbm93IHdoYXQgdGhlIE1UVSBpcy4KPj4gPj4+Pj4+Pj4+Pj4+Pj4gXSAqIGl0IGlzIGFs c28gZWFzaWVyIHRvIGltcGxlbWVudCBwYWNrZXQtc2l6ZSBiaWFzaW5nCj4+ID4+IGluIHRoZQo+ PiA+Pj4+Pj4+Pj4+Pj4+PiB0cmFuc3BvcnQgdGhhbiBpbiBdICt0aGUgbmV0d29yay4KPj4gPj4+ Pj4+Pj4+Pj4+Pj4gXQo+PiA+Pj4+Pj4+Pj4+Pj4+PiBdIE9uIHRoZSBsYXN0IGJ1bGxldCwgSSBk aWRuJ3QgcmVhbGx5IGZvbGxvdyB5b3VyCj4+ID4+IGFyZ3VtZW50IGluCj4+ID4+Pj4+Pj4+IFMz LjUuCj4+ID4+Pj4+Pj4+Pj4+Pj4+IE1pZ2h0IGJlIF0gK2Vhc2llciB0byBmb2xsb3cgaWYgUzMu NSBhbHNvIHRhbGtlZCBhYm91dAo+PiA+PiBob3cgYQo+PiA+Pj4+Pj4+Pj4+Pj4+PiBuZXR3b3Jr IGVsZW1lbnQgd291bGQgdGFrZSBdICthY2NvdW50IG9mIHBrdCBzaXplPwo+PiA+PiBBbHNvLCBk b2VzIHRoZQo+PiA+Pj4+Pj4+Pj4+Pj4+PiBmb2xsb3dpbmcgYXJndW1lbnQgYWxzbyBhcHBseT86 Cj4+ID4+Pj4+Pj4+Pj4+Pj4+IF0gKiBpZiBwa3Qtc2l6ZSBiaWFzaW5nIGlzIGRvbmUgaW4gdGhl IHRyYW5zcG9ydCwgdGhlbgo+PiA+PiB0aGUgd29yawo+PiA+Pj4+Pj4+Pj4+Pj4+PiAodG8gZG8g dGhlIF0gK2JpYXNpbmcpIGlzIHNwcmVhZCBvdmVyIG1hbnkgZW5kIGhvc3RzLAo+PiA+IF0KPj4g Pj4gKiB3aGVyZWFzCj4+ID4+Pj4+Pj4+Pj4+Pj4+IGlmIHBrdC1zaXplIGJpYXNpbmcgaXMgZG9u ZSBpbiB0aGUgbmV0d29yaywgdGhlbiB0aGUKPj4gPj4gd29yayBpcyBdCj4+ID4+Pj4+Pj4+Pj4+ Pj4+ICtjb25jZW50cmF0ZWQgaW4ganVzdCB0aGUgY29uZ2VzdGVkIG5ldHdvcmsgZWxlbWVudCwK Pj4gPj4gd2hpY2ggaGFzIHRvCj4+ID4+Pj4+Pj4+Pj4+Pj4+IG9wZXJhdGUgb24gYWxsIF0gK3Ro ZSB0cmFmZmljIGF0IGxpbmUgc3BlZWQuCj4+ID4+Pj4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+ Pj4+ICAoSGFzIHRoZXJlIHBlcmhhcHMgYmVlbiBzb21lIGNvbmZ1c2lvbiBhYm91dCB3aGF0Cj4+ ID4+IHdlbnQgaW50byB0aGUKPj4gPj4+Pj4+Pj4+Pj4+Pj4gLTA4Cj4+ID4+Pj4+Pj4+Pj4+Pj4+ IHZlcnNpb24/KQo+PiA+Pj4+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+Pj4+PiAtLQo+PiA+Pj4+ Pj4+Pj4+Pj4+PiBKb2huIExlc2xpZSA8am9obkBqbGMubmV0Pgo+PiA+Pj4+Pj4+Pj4+Pj4+Pgo+ PiA+Pj4+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4+Pj4+Cj4+ID4+Pj4+Pj4+Pj4+Pgo+PiA+Pj4+ Pj4+Pj4+Pgo+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj4+ID4+Pj4+Pj4+Pj4+IEJvYiBCcmlzY29lLCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQlQgSW5ub3ZhdGUgJgo+PiA+PiBEZXNpZ24KPj4gPj4+ Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pj4+Pgo+PiA+Pj4+Pj4+Pj4KPj4gPj4+Pj4+Pgo+PiA+Pj4+Pj4+ Cj4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KPj4gPj4+Pj4+PiBCb2IgQnJpc2NvZSwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEJUIElubm92YXRlICYKPj4gPj4gRGVzaWduCj4+ID4+Pj4+Pj4KPj4gPj4+ Pj4KPj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwo+PiA+Pj4+PiBCb2IgQnJpc2NvZSwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEJUIElubm92YXRlICYgRGVzaWduCj4+ID4+Pgo+PiA+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+PiA+Pj4gQm9iIEJyaXNjb2UsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCVCBJ bm5vdmF0ZSAmIERlc2lnbgo+PiA+Cj4K From philip.eardley@bt.com Thu Oct 11 09:16:45 2012 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 D686D21F8628; Thu, 11 Oct 2012 09:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.254 X-Spam-Level: X-Spam-Status: No, score=-102.254 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppPD56isLfN2; Thu, 11 Oct 2012 09:16:42 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 45B6B21F860D; Thu, 11 Oct 2012 09:16:41 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 11 Oct 2012 17:16:39 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.17]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Thu, 11 Oct 2012 17:16:40 +0100 From: To: , Date: Thu, 11 Oct 2012 17:16:40 +0100 Thread-Topic: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest Thread-Index: AQHNp64+FkrAkabfCEaD1jzPlkv4fJez3BoAgAAzNaCAAB4rIIAAGWLw Message-ID: <9510D26531EF184D9017DF24659BB87F33DD2D2CCA@EMV65-UKRD.domain1.systemhost.net> References: <20120815190728.GQ15012@verdi> <502BFB47.7010803@erg.abdn.ac.uk><791AD3077F94194BB2BDD13565B6295D45A6212A@PALLENE.office.hd><15181_1346848013_5047450C_15181_645_1_50474507.3090706@erg.abdn.ac.uk><3A5279D338C75C40B4B3DA15BA47D6330B616BD2@EXMDB04.org.aalto.fi><201209051541.q85FfCs0019699@bagheera.jungle.bt.co.uk><9510D26531EF184D9017DF24659BB87F33D793B351@EMV65-UKRD.domain1.systemhost.net><3A5279D338C75C40B4B3DA15BA47D6330B69261A@EXMDB04.org.aalto.fi><9510D26531EF184D9017DF24659BB87F33D793B845@EMV65-UKRD.domain1.systemhost.net><04AC95B5-A2B1-4DD2-B765-E20A4C1A69A3@aalto.fi><3A5279D338C75C40B4B3DA15BA47D6330B6E81E4@EXMDB04.org.aalto.fi><9510D26531EF184D9017DF24659BB87F33DCE34251@EMV65-UKRD.domain1.systemhost.net><201210041126.q94BQ0hx002951@bagheera.jungle.bt.co.uk><1904eec816d080f886f5bf8685358ddc.squirrel@www.erg.abdn.ac.uk><201210101525.q9AFP4Mi008013@bagheera.jungle.bt.co.uk><3A5279D338C75C40B4B3DA15BA47D6330B6FC2BB@EXMDB04.org.aalto.fi><201210111208.q9BC8BAU012! ! 305@bag he era.jungl e.b t.co.uk> <3A5279D338C75C40B4B3DA15BA47D6330B6FD072@EXMDB04.org.aalto.fi> <999913AB42CC9341B05A99BBF358718D01F360CF@FIESEXC035.nsn-intra.net> <3A5279D338C75C40B4B3DA15BA47D6330B6FD197@EXMDB04.org.aalto.fi> <999913AB42CC9341B05A99BBF358718D01F360F7@FIESEXC035.nsn-intra.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, tsvwg-chairs@ietf.org Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest 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, 11 Oct 2012 16:16:45 -0000 I also think it's a good idea to finalise draft-ietf-tsvwg-byte-pkt-congest= . Anyway, I think draft-nichols-tsvwg-codel is in reasonable alignment (my un= derstanding of codel is limited) - see the 3 recommendations in the abstrac= t of draft-ietf-tsvwg-byte-pkt-congest: " (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) the byte-mode packet drop variant of the RED AQM algorithm that drops fewer small packets should not be used." phil -----Original Message----- From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Sent: 11 October 2012 15:48 To: hannes.tschofenig@nsn.com Cc: gorry@erg.abdn.ac.uk; Eardley,PL,Philip,DUB8 R; tsvwg@ietf.org; tsvwg-c= hairs@ietf.org; jukka.manner@aalto.fi Subject: RE: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-b= yte-pkt-congest Hi Hannes, haven't been at the workshop or last IETF, read into the draft and into Cod= el: - it is unclear to me, whether codel is dealing with CPE issues or RED in general. - I've understood Bobs/Jukkas draft to deal with RED in general. If Codel is about RED in general, backbone router vendor support is require= d. Has there been feedback from this community? It may be a good idea to try to finalise the work of Bob and Jukka. Regards, R=FCdiger -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of T= schofenig, Hannes (NSN - FI/Espoo) Sent: Thursday, October 11, 2012 2:58 PM To: ext Manner Jukka Cc: gorry@erg.abdn.ac.uk; philip.eardley@bt.com; tsvwg IETF list; tsvwg-cha= irs@ietf.org Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-b= yte-pkt-congest Hi Jukka, With QoS there is no such thing as "short term" (as we already had to learn= painfully). That makes me wonder what is more useful: publish a document that describe = how to configure RED correctly or to go for an AQM technique that (accordin= g to the authors) works almost zero configuration. My take-away from the Vancouver congestion control workshop was that it is = better to ignore RED. (Maybe my impression was wrong -- someone else should= confirm.) Ciao Hannes > -----Original Message----- > From: ext Manner Jukka [mailto:jukka.manner@aalto.fi] > Sent: Thursday, October 11, 2012 3:50 PM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: Bob Briscoe; ; ; > ; tsvwg IETF list > Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf- > tsvwg-byte-pkt-congest > > Hi, this document talks about the current and short term goals and > operations, while AFAIK CoDel is a more futuristic concept, interesting > concept, sure, but not deployed at large. > > cheers, > Jukka > > On Oct 11, 2012, at 3:44 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > > Hi Jukka, Hi Bob, > > > > having listened to the presentations about CoDel I am wondering > whether > > this document may have taken over by events and is obsolete by now. > > What's your view on that? > > > > Ciao > > Hannes > > > > > >> -----Original Message----- > >> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On > Behalf > >> Of ext Manner Jukka > >> Sent: Thursday, October 11, 2012 3:34 PM > >> To: Bob Briscoe > >> Cc: ; ; >> chairs@ietf.org>; tsvwg IETF list > >> Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf- > >> tsvwg-byte-pkt-congest > >> > >> Hi, > >> > >> Yeah, please at the point about cheap devices, still, I wonder what > > the > >> cost of AQM is on those devices. Maybe 1 cnt in mass production? > Thus, > >> I still wonder if it is worth arguing something about the future > that > >> strongly. > >> > >> Sorry, but the same goes for AQM in general, and where it is, or > will > >> not be deployed. I understand technical reasons why not something is > >> feasible, but business or monetary reasons can change very quickly. > ;) > >> > >> Jukka > >> > >> On Oct 11, 2012, at 3:08 PM, Bob Briscoe wrote: > >> > >>> Jukka, > >>> > >>> What I had in mind is all low level buffers in cheap pure L2 > > devices, > >> in cheap NATs etc. I was going to list some of these, but instead > > chose > >> to say "no-one expects AQM to be universally deployed". This clearly > >> missed the mark. > >>> > >>> Should we include some of these concrete examples of where AQM > won't > >> be deployed instead? > >>> > >>> [I've cc'd the list, given we're starting to wordsmith > significantly > >> new text added since WG last call.] > >>> > >>> > >>> Bob > >>> > >>> At 20:04 10/10/2012, Manner Jukka wrote: > >>>> Hi, looked good to me. Just one comment, I wouldn't put that much > >> emphasis on what is a probably state of things, e.g. > >>>> > >>>> "no-one expects AQM to ever be .." > in the future it might, we > >> don't know, and since the paragraph says that it doesn't matter > > anyway, > >> I would formulate this paragraph a bit towards that we have partial > >> deployment now and even with a full deployment, ... > >>>> > >>>> and similarly with the unrealistic deployment of AQM in the > >> subsequent paragraph. > >>>> > >>>> cheers, > >>>> Jukka > >>>> > >>>> On Oct 10, 2012, at 6:25 PM, Bob Briscoe wrote: > >>>> > >>>>> Phil, > >>>>> > >>>>> Sorry for delay, my round-robin scheduler is taking so long to > > get > >> round all the tasks that I keep finding dead robins (that reminds me > > of > >> a bike ride my grandmother took. On her return, she said there were > a > >> worryingly large number of robins run over on the roads. It turned > out > >> that she had been going round the same small triangle of roads > > multiple > >> times). > >>>>> > >>>>> I've done a complete re-write of 3.4. I hope you will agree that > >> it really is a motivating argument now and it can stay where it is - > > it > >> is not just a preamble. > >>>>> > >>>>> I've gone back to the very first version of 3.4 I wrote and I now > >> realise that I had written the core of the argument so badly that > even > >> I forgot what it was meant to say when we started editing it. In the > >> draft-08 version, the original meaning is lost and in your re- > wording > >> it is entirely lost. The link with the draft-08 version is nearly > >> unrecognisable, but it's the argument I intended here. > >>>>> > >>>>> > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> 3.4. Permanent Partial Deployment of AQM > >>>>> > >>>>> In overview, the argument in this section runs as follows: > >>>>> * Because the network will not and cannot always drop packets in > >> proportion to their size, it shouldn't be given the task of making > > drop > >> signals depend on packet size at all. > >>>>> * Transports on the other hand don't always want to make their > >> rate response proportional to the size of dropped packets, but if > they > >> want to, they always can. > >>>>> > >>>>> The argument is similar to the end-to-end argument that says > >> "Don't do X in the network if end-systems can do X by themselves, > and > >> they want to be able to choose whether to do X anyway." Actually the > >> following argument is stronger; in addition it says "Don't give the > >> network task X that could be done by the end-systems, if X won't > ever > >> be deployed on all network nodes, and end-systems won't be able to > > tell > >> whether their network is doing X, or whether they need to do X > >> themselves." In this case, the X in question is "making the response > > to > >> congestion depend on packet size". > >>>>> > >>>>> We will now re-run this argument taking each step in more depth. > >> The argument applies solely to drop, not ECN marking. > >>>>> > >>>>> A queue drops packets for either of two reasons: a) to signal to > >> host congestion controls that they should reduce the load and b) > >> because there is no buffer left to store the packets. Active queue > >> management tries to use drops as a signal for hosts to slow down > (case > >> a) so that drop due to buffer exhaustion (case b) should not be > >> necessary. > >>>>> > >>>>> No-one expects AQM to ever be universally deployed in every queue > >> in the Internet; and, even if AQM were universal, it has to be able > to > >> cope with buffer exhaustion (by switching to a behaviour like tail- > >> drop), in order to cope with unresponsive or excessive transports. > >> Therefore networks will often be dropping packets as a last resort > >> (case b) rather than under AQM control (case a). > >>>>> > >>>>> When buffers are exhausted (case b), they don't naturally drop > >> packets in proportion to their size. The network can only reduce the > >> probability of dropping smaller packets if it has enough space to > > store > >> them somewhere while it waits for a larger packet that it can drop. > If > >> the buffer is exhausted, it does not have this choice. Admittedly > > tail- > >> drop does naturally drop somewhat fewer small packets, but exactly > how > >> few depends more on the mix of sizes than the size of the packet in > >> question. Nonetheless, in general, if we wanted networks to do size- > >> dependent drop, we would need universal deployment of (packet-size > >> dependent) AQM code, which is unrealistic. > >>>>> > >>>>> A host transport cannot know whether any particular drop was a > >> deliberate signal from an AQM or a sign of a queue shedding packets > > due > >> to buffer exhaustion. Therefore, because the network cannot > > universally > >> do size-dependent drop, it should not do it all. > >>>>> > >>>>> Whereas universality is desirable in the network, diversity is > >> desirable between different transport layer protocols - some, like > >> NewReno TCP [RFC5681], may not choose to make their rate response > >> proportionate to the size of each dropped packet, while others will > >> (e.g. TFRC-SP [RFC4828]). > >>>>> > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Bob > >>>>> > >>>>> At 13:13 04/10/2012, gorry@erg.abdn.ac.uk wrote: > >>>>>> That would be brilliant! > >>>>>> > >>>>>> Gorry > >>>>>> > >>>>>>> Will try to look at this later today. > >>>>>>> > >>>>>>> > >>>>>>> Bob > >>>>>>> > >>>>>>> At 10:42 02/10/2012, philip.eardley@bt.com wrote: > >>>>>>>> Think the token is with bob > >>>>>>>> > >>>>>>>> Re your comment - yes, I think you could move 3.4 to the end > > of > >> S3 - > >>>>>>>> or to the start - and do some re-phrasing, maybe something > > like > >> I tried. > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Manner Jukka [mailto:jukka.manner@aalto.fi] > >>>>>>>> Sent: 01 October 2012 20:18 > >>>>>>>> To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,Bob,DUB8 R > >>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst > >>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for > >>>>>>>> draft-ietf-tsvwg-byte-pkt-congest > >>>>>>>> > >>>>>>>> Phil, Bob, can we close this finally? It's three weeks now > >> since > >>>>>>>> this previous message. > >>>>>>>> > >>>>>>>> Jukka > >>>>>>>> > >>>>>>>> On Sep 10, 2012, at 4:42 PM, Jukka Manner wrote: > >>>>>>>> > >>>>>>>>> Ack, I'm getting there...;) > >>>>>>>>> > >>>>>>>>> So, we could move 3.4 at the end of Section 3 and rephrase > >> it to > >>>>>>>> not talk about scaling per se, but rather about how Req 2.2 > >>>>>>>> eventually leads to Req 2.3? > >>>>>>>>> > >>>>>>>>> Jukka > >>>>>>>>> > >>>>>>>>> On Sep 7, 2012, at 4:07 PM, > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> 3.4 is, in my mind, completely different from 3.1, 3.2, > > 3.3 > >> and 3.5. > >>>>>>>>>> > >>>>>>>>>> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for > >> Recommendation > >>>>>>>>>> 2.2 & a lesser extent 2.3 > >>>>>>>>>> 3.4 makes doesn't make a motivating argument - it explains > >> that Rec > >>>>>>>>>> 2.2 & 2.3 come as a pair (if you recommend one, then > >> inevitably you > >>>>>>>>>> recommend the other) (delta some politeness about TCP) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Manner Jukka [mailto:jukka.manner@aalto.fi] > >>>>>>>>>> Sent: 07 September 2012 13:24 > >>>>>>>>>> To: Eardley,PL,Philip,DUB8 R > >>>>>>>>>> Cc: Briscoe,RJ,Bob,DUB8 R; ; > >>>>>>>>>> > >>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for > >>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest > >>>>>>>>>> > >>>>>>>>>> Hi, I'm trying to follow your reasoning, with little luck. > >> ;) > >>>>>>>>>> > >>>>>>>>>> After having read Section 3 again, I could think of a few > >>>>>>>> updates, but I'm not fully following what you want to see: > >>>>>>>>>> > >>>>>>>>>> - S3.5 is kind of small and lonely by itself. It could be > >> either > >>>>>>>> longer or merged somewhere. Not a major issue though and > > could > >> remain as > >>>>>>>> is. > >>>>>>>>>> > >>>>>>>>>> - S3.3: Yes, probably could be turned upside down, good > >> first, > >>>>>>>> bad later. Don't have a strong opinion. > >>>>>>>>>> > >>>>>>>>>> - S3.4: Here the scaling is used many times and in the > >> title, > >>>>>>>> although we talk about the end host side. This could be > >> rephrased > >>>>>>>> and slightly reworded to talk about hosts and their operation > >>>>>>>> altogether. Also the word scaling can turn the readers > >> expectation > >>>>>>>> into the wrong direction. > >>>>>>>>>> > >>>>>>>>>> - S3 altogether: It would help to have introductory text > >> about > >>>>>>>> networks vs. end host side, but I fail to see why (& how) to > >>>>>>>> restructure everything. > >>>>>>>>>> > >>>>>>>>>> cheers, > >>>>>>>>>> Jukka > >>>>>>>>>> > >>>>>>>>>> On Sep 6, 2012, at 6:18 PM, > >>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Ps otherwise Bob's comments are fine, though I suggest > > for > >> S3.5 you > >>>>>>>>>>> give more context (ie are you knocking down what you > >> recommend > >>>>>>>>>>> against, or building up what you recommend?) and in S3.3 > >> think > >>>>>>>>>>> would be better if you re-structured slightly [first talk > >> about what > >>>>>>>>>>> you like - penult para + 1st sentence of last para - then > >> talk about > >>>>>>>>>>> what you don't like - rest of text] > >>>>>>>>>>> > >>>>>>>>>>> From: Eardley,PL,Philip,DUB8 R > >>>>>>>>>>> Sent: 06 September 2012 16:12 > >>>>>>>>>>> To: Briscoe,RJ,Bob,DUB8 R; Manner Jukka > >>>>>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst > >>>>>>>>>>> Subject: RE: [REVISED I-D]: Document writeup for > >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest > >>>>>>>>>>> > >>>>>>>>>>> Thanks bob. Have now re-booted some state. > >>>>>>>>>>> I don't like S3.4. My basic problem with it is that it > >> isn't a > >>>>>>>> "motivating argument" (S3 title). It's an explanation about > >> the > >>>>>>>> consequences of assuming either [option 1] do pkt-size > > biasing > >> in > >>>>>>>> the transport; [option 2]; do pkt-size biasing in the nw. > >>>>>>>>>>> Perhaps your effort to buy peace with those who won't > >> change > >>>>>>>> TCP has obfuscated the basic point? > >>>>>>>>>>> The title of S3.4 (Scaling...) and the early text > > "scaling > >>>>>>>> argument" suggests that you're going to argue there is some > >> reason > >>>>>>>> why X scales as order N rather than N^2 or something like > > that > >> - > >>>>>>>> which isn't what S3.4 is about. > >>>>>>>>>>> > >>>>>>>>>>> I actually think it would be better to put S3.4 at the > >> start of > >>>>>>>> S3 - it's background where you say there are 2 options. After > >> that, > >>>>>>>> you can explain the reasons why option 1 [pkt biasing in the > >>>>>>>> transport] is better - the reasons being:- S3.1 (security > > etc > >>>>>>>> attacks if small pkts get preferential treatment), S3.2 > >> (really a > >>>>>>>> side note to S3.1; ie doesn't really present a "motivating > >>>>>>>> argument"), S3.3 (nw guessing MTU vs transport knowing pkt > >> size), > >>>>>>>> S3.5 (easier implementation). > >>>>>>>>>>> > >>>>>>>>>>> Something like... > >>>>>>>>>>> The behaviour of the network and transport together needs > >> to > >>>>>>>>>>> alleviate congestion. We assume the network is bit- > >> congestible > >>>>>>>> (currently packet-congestible resources are rate). Therefore > >>>>>>>> overall the response of the {network + transport} should be > >> the > >>>>>>>> same for the same congestion - whether the congestion is > >> caused by > >>>>>>>> a lot of small packets or a smaller number of larger packets. > >> The > >>>>>>>> implication is that the transport's behaviour should depend > > on > >>>>>>>> whether the network takes account (or not) of packet size > > when > >> it > >>>>>>>> generates congestion indications:- Case 1: If the network > >>>>>>>> implements packet-mode drop, ie its algorithm treats all > >> packets > >>>>>>>> equally regardless of their size, then the transport should > >> take > >>>>>>>> account of the size of the packet - in other words, the > >> transport's > >>>>>>>> congestion response should depend on the number of dropped > >> bytes. > >>>>>>>>>>> Case 2: If the network implements byte-mode drop, ie its > >>>>>>>> algorithm treats packets differently depending on their size, > >> then > >>>>>>>> the transport should not take account of the size of the > >> packet - > >>>>>>>> in other words, the transport's congestion response should > >> depend > >>>>>>>> on the number of dropped packets. > >>>>>>>>>>> > >>>>>>>>>>> These cases are explained in more detail in sub-section > >> below. > >>>>>>>>>>> > >>>>>>>>>>> In both cases the same discussion applies if packets are > >>>>>>>> ECN-marked rather than dropped. > >>>>>>>>>>> In the following sections we explain why Case 1 is > >> preferable, > >>>>>>>> and hence why we make the Recommendations of S2.2 and S3.3 > >>>>>>>> (respectively, drop/mark pkts equally regardless of their > >> size, and > >>>>>>>> the strength of the transport's response should be > >> proportionate to > >>>>>>>> the size of the dropped/marked pkt). > >>>>>>>>>>> Note that TCP responds to dropped or marked packets, > > which > >> differs > >>>>>>>>>>> from our recommendation for transports. However, we are > >> not > >>>>>>>>>>> recommending that TCP should be changed; to date it > >> hasn't been a > >>>>>>>>>>> significant problem because most TCP implementations > > have > >> been > >>>>>>>> used with similar packet sizes. But we do recommend that > >> future > >>>>>>>> transport protocols should respond to dropped or marked > > bytes > >> (as > >>>>>>>> for example TFRC-SP [RFC4828]effectively does). > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Sub-section > >>>>>>>>>>> You could use much of S3.3, I suggest supplement with > >> numerical > >>>>>>>>>>> examples continuing S1.2 > >>>>>>>>>>> -- > >>>>>>>>>>> << This gives a get-out clause to any transport that > > isn't > >>>>>>>>>>> packet-size dependent (e.g. current TCP). Lacking packet- > >> size > >>>>>>>>>>> dependence just means they don't scale correctly with > >> packet size - > >>>>>>>>>>> but they are at liberty not to scale with packet size > >> (particularly > >>>>>>>>>>> given MTU growth isn't often being used to increase link > >> rates at > >>>>>>>>>>> this stage in history).>> > >>>>>>>>>>> > >>>>>>>>>>> This is introducing a different point. it's saying that > >> your > >>>>>>>> recommendation 2 [drop/mark pkts equally regardless of their > >> size] > >>>>>>>> is a really strong reco whilst recommendation 3 [strength of > >>>>>>>> transport's response proportionate to the size of the > >>>>>>>> dropped/marked pkt] is a much less important reco. I can see > >> this > >>>>>>>> might be true, but I don't think the i-d talks about this. > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> > >>>>>>>>>>> From: Briscoe,RJ,Bob,DUB8 R > >>>>>>>>>>> Sent: 05 September 2012 16:41 > >>>>>>>>>>> To: Manner Jukka > >>>>>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst; > >> Eardley,PL,Philip,DUB8 R > >>>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for > >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest > >>>>>>>>>>> > >>>>>>>>>>> Jukka, > >>>>>>>>>>> > >>>>>>>>>>> I've repeated Phil's suggestions as quoted email then > > made > >> some > >>>>>>>> alterations. > >>>>>>>>>>> > >>>>>>>>>>> Phil asked me to send this, then he will think about it. > >>>>>>>>>>> > >>>>>>>>>>> I'll respond about John Leslie's argument next... > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> 2.2. Recommendation on Encoding Congestion Notification > >>>>>>>>>>> > >>>>>>>>>>> [...] > >>>>>>>>>>> > >>>>>>>>>>> 1. AQM algorithms such as RED SHOULD use packet-mode > >> drop, ie they > >>>>>>>>>>> SHOULD NOT use byte-mode drop. The latter is more > >> complex, > >>>>>>>>>>> it creates the perverse incentive to fragment > >> segments into > >>>>>>>> tiny > >>>>>>>>>>> pieces and it is vulnerable to floods of small > >> packets. > >>>>>>>>>>> > >>>>>>>>>>> 2. If a vendor has implemented byte-mode drop, and an > >> operator has > >>>>>>>>>>> turned it on, it is RECOMMENDED to turn it off, > > after > >>>>>>>> establishing > >>>>>>>>>>> if there are any implications on the relative > >> performance of > >>>>>>>>>>> applications using different packet sizes. > >>>>>>>>>>> > >>>>>>>>>>> RED as a whole SHOULD NOT be turned off. Without > > RED, > >> a drop > >>>>>>>> tail > >>>>>>>>>>> queue biases against large packets > >>>>>>>>>>> > >>>>>>>>>>> [BB adds]: and it is > >> vulnerable to > >>>>>>>> floods > >>>>>>>>>>> of small-packets. > >>>>>>>>>>> > >>>>>>>>>>> (I suggest the last para just qualifies item 2. It > > doesn't > >> warrant > >>>>>>>>>>> another item number.) > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> [PE:] S3.3 > >>>>>>>>>>> The section could be slightly clearer. Starting with the > >> second > >>>>>>>> para, where you start talking about something you don't > >> recommend > >>>>>>>> (ie you have to remember that you're talking about the > >> consequences > >>>>>>>> of not following your recommendation). > >>>>>>>>>>> > >>>>>>>>>>> 3.3 Transport-Independent Network > >>>>>>>>>>> > >>>>>>>>>>> TCP congestion control ensures that flows competing for > >> the same > >>>>>>>>>>> resource each maintain the same number of segments in > >> flight, > >>>>>>>>>>> irrespective of segment size. So under similar > >> conditions, flows > >>>>>>>>>>> with different segment sizes will get different > > bit-rates. > >>>>>>>>>>> > >>>>>>>>>>> [OLD:] > >>>>>>>>>>> One motivation for the network biasing congestion > >> notification by > >>>>>>>>>>> packet size is to counter this effect and try to equalise > >> the bit- > >>>>>>>>>>> rates of flows with different packet sizes. > >>>>>>>>>>> [SUGGESTED:] > >>>>>>>>>>> To counter this effect it seems tempting not to follow > >> our > >>>>>>>>>>> recommendation, and instead for the network to bias > >> congestion > >>>>>>>>>>> notification by packet size in order to equalise the > > bit- > >> rates of > >>>>>>>>>>> flows with different packet sizes. > >>>>>>>>>>> [CONTINUE AS BEFORE:] > >>>>>>>>>>> However, in order to do this, the queuing > >> algorithm > >>>>>>>>>>> has to make assumptions about the transport, which > > become > >> embedded > >>>>>>>>>>> in the network. Specifically: > >>>>>>>>>>> [...] > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> S3.3 > >>>>>>>>>>> o The queuing algorithm has to assume how aggressively > >> the > >>>>>>>> transport > >>>>>>>>>>> will respond to congestion (see Section 4.2.4). If > >> the network > >>>>>>>>>>> assumes the transport responds as aggressively as TCP > >> NewReno, > >>>>>>>> it > >>>>>>>>>>> will be wrong for Compound TCP and differently wrong > >> for Cubic > >>>>>>>>>>> TCP, etc. To achieve equal bit-rates, each transport > >> then has > >>>>>>>> to > >>>>>>>>>>> guess what assumption the network made, and work out > >> how to > >>>>>>>>>>> replace this assumed aggressiveness with its own > >> aggressiveness. > >>>>>>>>>>> o Also, if the network biases congestion notification > > by > >> packet > >>>>>>>> size > >>>>>>>>>>> it has to assume a baseline packet size--all proposed > >> algorithms > >>>>>>>>>>> use the local MTU. Then transports have to guess > >> which link was > >>>>>>>>>>> congested and what its local MTU was, in order to > > know > >> how to > >>>>>>>>>>> tailor their congestion response to that link. > >>>>>>>>>>> > >>>>>>>>>>> So you're saying that for byte-mode drop, the network > >> element > >>>>>>>> has to compare the size of the current pkt with the MTU, and > >> if > >>>>>>>> it's 25* smaller then reduce the pkt loss probably by 25*? > > And > >> if > >>>>>>>> the MTU was bigger, then the current pkt would be dropped > > with > >>>>>>>> greater probability? And both of these things are hard to do. > >>>>>>>>>>> > >>>>>>>>>>> [BB]: SUGGESTED REPLACEMENT to 2nd bullet: > >>>>>>>>>>> > >>>>>>>>>>> o Also, if the network biases congestion notification > > by > >> packet > >>>>>>>> size > >>>>>>>>>>> it has to assume a baseline packet size--all proposed > >> algorithms > >>>>>>>>>>> use the local MTU (for example see the byte-mode loss > >>>>>>>> probability > >>>>>>>>>>> formula in Table 1). Then if the non-Reno transports > >> mentioned > >>>>>>>> above > >>>>>>>>>>> are trying to reverse engineer what the network > >> assumed, they > >>>>>>>> also > >>>>>>>>>>> have to guess the MTU of the congested link. > >>>>>>>>>>> > >>>>>>>>>>> [Aside for Phil: The byte-mode algo uses MTU as its > >> baseline because > >>>>>>>>>>> a link cannot send a packet bigger than its MTU so the > >> algo won't > >>>>>>>>>>> ever give a drop probability >1).] > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> S3.4 (& knock-on effect on 3.3) I think this could be > >>>>>>>>>>> better. > >>>>>>>>>>> I agree with your arguments in S3.1 & 3.2 that dropping > > or > >>>>>>>> marking should be independent of pkt size. > >>>>>>>>>>> You now go into a couple of pages, which I think could be > >> boiled > >>>>>>>>>>> down to a paragraph, saying something like:- > >>>>>>>>>>> * the overall system (network + transport) has to be > >> packet-size > >>>>>>>>>>> dependent in order to drive out the right amount of > >> traffic so the > >>>>>>>>>>> resource becomes uncongested (since we assume all > >> resources are in > >>>>>>>>>>> practice byte rather than packet limited) > >>>>>>>>>>> * from S3.1 and S3.2 the IETF is convinced that the > >> network > >>>>>>>> should notify independent of packet-size. > >>>>>>>>>>> * therefore the transport must act dependent on packet- > >> size. > >>>>>>>>>>> > >>>>>>>>>>> It seems to me this is a necessary consequence of your > >> earlier > >>>>>>>> assumptions /arguments. > >>>>>>>>>>> > >>>>>>>>>>> [BB:] This isn't at all obvious. Until I worked it > >> through, it > >>>>>>>> wasn't obvious to me. I think it needs to be spelled out. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> [On the other hand, if someone disagrees with the > >> arguments and > >>>>>>>>>>> thinks that the network should notify dependent on > > packet- > >> size, then > >>>>>>>>>>> it follows that the transport can act independent of > >> packet-size.] > >>>>>>>>>>> > >>>>>>>>>>> I think in S3.3 you're trying to make another argument > >> (?):- > >>>>>>>>>>> * we can either do packet-size biasing in the network > >> element or on > >>>>>>>>>>> the end host transport (see argument above) > >>>>>>>>>>> * packet-size biasing in the network is quite tricky, > >> because > >>>>>>>> then both the network element & the transport have to make > >> some > >>>>>>>> guesses about MTU - whereas with packet-size biasing in the > >>>>>>>> transport, neither network element nor transport needs to > > know > >> what the > >>>>>>>> MTU is. > >>>>>>>>>>> * it is also easier to implement packet-size biasing in > >> the > >>>>>>>> transport than in the network. > >>>>>>>>>>> > >>>>>>>>>>> [BB] ...and all the other arguments about vulnerability > > to > >>>>>>>> flooding etc, transport-independence etc. > >>>>>>>>>>> > >>>>>>>>>>> Our argument is sort of like how Phil summarises it, but > >> with > >>>>>>>> an added nuance. It's also saying no-one has to do > > packet-size > >>>>>>>> biasing anyway. It's not saying "The transport should given > >> the > >>>>>>>> network shouldn't". It's saying "*If the transport wants to > >> claim > >>>>>>>> to be scalable wrt packet size* it should if the network > >> shouldn't". > >>>>>>>>>>> > >>>>>>>>>>> This gives a get-out clause to any transport that isn't > >>>>>>>> packet-size dependent (e.g. current TCP). Lacking packet-size > >>>>>>>> dependence just means they don't scale correctly with packet > >> size - > >>>>>>>> but they are at liberty not to scale with packet size > >> (particularly > >>>>>>>> given MTU growth isn't often being used to increase link > > rates > >> at > >>>>>>>> this stage in history). > >>>>>>>>>>> > >>>>>>>>>>> None of what Phil says convinces me we could say 3.4 (or > >> 3.3) > >>>>>>>> any more briefly or differently. It's easier to summarise > > what > >> you > >>>>>>>> understand having read something. But that's not the same as > >>>>>>>> writing the thing that helped you understand. There doesn't > >> seem to > >>>>>>>> be any argument for why anything needs to be changed, so I'm > >> going > >>>>>>>> to leave it as is, unless pushed. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On the last bullet, I didn't really follow your argument > >> in > >>>>>>>> S3.5. Might be easier to follow if S3.5 also talked about how > >> a > >>>>>>>> network element would take account of pkt size? > >>>>>>>>>>> Also, does the following argument also apply?: > >>>>>>>>>>> * if pkt-size biasing is done in the transport, then the > >> work (to do > >>>>>>>>>>> the biasing) is spread over many end hosts, > >>>>>>>>>>> * whereas if pkt-size biasing is done in the network, > > then > >> the > >>>>>>>> work is concentrated in just the congested network element, > >> which > >>>>>>>> has to operate on all the traffic at line speed. > >>>>>>>>>>> > >>>>>>>>>>> [BB]: 3.5. Implementation Efficiency > >>>>>>>>>>> > >>>>>>>>>>> [ADD:] > >>>>>>>>>>> Biasing against large packets typically requires an > > extra > >> multiply > >>>>>>>>>>> and divide in the network (see the example byte-mode > > drop > >>>>>>>> formula in table 1). > >>>>>>>>>>> [CONTINUE AS BEFORE:] > >>>>>>>>>>> Allowing for packet size at the transport rather than in > >> the > >>>>>>>>>>> network ensures that neither the network nor the > >> transport needs to > >>>>>>>>>>> do a multiply operation--multiplication by packet size > > is > >>>>>>>>>>> effectively achieved as a repeated add when the > > transport > >> adds to > >>>>>>>>>>> its count of marked bytes as each congestion event is > > fed > >> to it. > >>>>>>>>>>> [ADD:] > >>>>>>>>>>> Also the work to do the biasing is spread over many > >> hosts, rather > >>>>>>>>>>> than concentrated in just the congested network element. > >>>>>>>>>>> [CONTINUE AS BEFORE:] > >>>>>>>>>>> > > These > >> aren't > >>>>>>>>>>> principled reasons in themselves, but they are a happy > >> consequence > >>>>>>>>>>> of the other principled reasons. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Bob > >>>>>>>>>>> > >>>>>>>>>>> At 13:36 05/09/2012, Manner Jukka wrote: > >>>>>>>>>>> > >>>>>>>>>>> Hi Bob, > >>>>>>>>>>> > >>>>>>>>>>> Since Phil is your colleague at BT, even at Ipswich (?), > >> can > >>>>>>>> you check those and agree with Phil how to go forward? Some > > of > >>>>>>>> those are clear, others need discussion with Phil. > >>>>>>>>>>> > >>>>>>>>>>> Gorry, on point 2) below, I don't follow Leslie's > >> arguments. I > >>>>>>>> asked from him detailed comments and resolutions months ago, > >> and nothing > >>>>>>>> came. > >>>>>>>>>>> > >>>>>>>>>>> cheers, > >>>>>>>>>>> Jukka > >>>>>>>>>>> > >>>>>>>>>>> On Sep 5, 2012, at 3:26 PM, Gorry Fairhurst wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Bob and Jukka, > >>>>>>>>>>>> > >>>>>>>>>>>> I think I need your help to resolve this... Some of the > >>>>>>>> comments raised by John Leslie appear to have substance, and > >> I'm > >>>>>>>> not sure what you plan to do to address these. > >>>>>>>>>>>> > >>>>>>>>>>>> It would be good to do something quick so that I can > >> complete > >>>>>>>> the submission to the IESG. > >>>>>>>>>>>> > >>>>>>>>>>>> The issues I particularly note are: > >>>>>>>>>>>> > >>>>>>>>>>>> 1) This contribution from Phil appears to be within > > scope > >> and > >>>>>>>> it seems may have been overlooked (sorry): > >>>>>>>>>>>> http://www.ietf.org/mail- > >> archive/web/tsvwg/current/msg11234.html > >>>>>>>>>>>> > >>>>>>>>>>>> 2) Can you be clear here about what is actually been > > said > >> - > >>>>>>>> because the point below seems to be a misunderstanding of > >> language > >>>>>>>> to me, and I hoped we did not claim this: > >>>>>>>>>>>> > >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find > > that > >> Bob is > >>>>>>>>>>>>>> actually ] saying that transport-layer should _only_ > >> consider > >>>>>>>>>>>>>> "congested bytes", not ] "congested packets". > >>>>>>>>>>>>>> ] > >>>>>>>>>>>> > >>>>>>>>>>>> 3) You'll need to post the updated draft and send a note > >> to > >>>>>>>> the group to confirm that the new version indeed concludes > > the > >>>>>>>> WGLC. I'll add a note to the writeup to indicate the draft > >> content > >>>>>>>> has been stable since Oct 2011. > >>>>>>>>>>>> > >>>>>>>>>>>> Gorry (with my TSVWG Documnent Shepherd hat) > >>>>>>>>>>>> cc: Co-Chairs for info. > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>> From: Gorry Fairhurst [ mailto:gorry@erg.abdn.ac.uk] > >>>>>>>>>>>>>> Sent: Mittwoch, 15. August 2012 21:41 > >>>>>>>>>>>>>> To: tsvwg chair > >>>>>>>>>>>>>> Subject: Fwd: Re: [tsvwg] FYI: Document writeup for > >>>>>>>>>>>>>> draft-ietf-tsvwg- byte-pkt-congest > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi guys, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Apart form the usual rhetoric, there are some points > >> here that we > >>>>>>>>>>>>>> should note as chairs. What are you own thoughts? And > >> was > >>>>>>>>>>>>>> anything noted at the IETF in Vancouver concerning > > this > >> draft? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Gorry > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -------- Original Message -------- > >>>>>>>>>>>>>> Subject: Re: [tsvwg] FYI: Document writeup for > >>>>>>>>>>>>>> draft-ietf-tsvwg-byte- pkt-congest > >>>>>>>>>>>>>> Date: Wed, 15 Aug 2012 15:07:28 -0400 > >>>>>>>>>>>>>> From: John Leslie > >>>>>>>>>>>>>> To: Gorry Fairhurst > >>>>>>>>>>>>>> CC: tsvwg@ietf.org > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Gorry Fairhurst wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The following document has been revised after > >> receiving > >>>>>>>> WGLC comments. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The changes are mostly refreshing a document > >> scheduled to > >>>>>>>>>>>>>> expire this month. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> No issues were found: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Is that with WGC-hat-on? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Neither my issues nor Philip Eardley's comments were > >> addressed. > >>>>>>>>>>>>>> In fact, not even the changes Bob Briscoe mentioned > > on- > >> list have > >>>>>>>>>>>>>> been included. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> As required by RFC 4858, this is the current template > >> for the > >>>>>>>>>>>>>> Document > >>>>>>>>>>>>>>> Shepherd Write-Up. > >>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>> (1) What type of RFC is being requested (BCP, > > Proposed > >> Standard, > >>>>>>>>>>>>>>> Internet Standard, Informational, Experimental, or > >> Historic)? > >>>>>>>>>>>>>>> Why is this the proper type of RFC? Is this type of > >> RFC > >>>>>>>>>>>>>>> indicated in the title page header? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> This document is intended as BCP. (This was discussed > >> at IETF-81 > >>>>>>>>>>>>>>> and that the status changed from Informational to BCP > >> since it > >>>>>>>>>>>>>>> provides guidance to implementors and people > >> configuring > >>>>>>>> routers and hosts). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thank you for finally answering my question about > > BCP > >> status. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>> Working Group Summary > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> There was consensus to publish this as a WG document > >> and > >>>>>>>>>>>>>>> agreement at > >>>>>>>>>>>>>>> IETF-82 that the document was now complete. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Was that reviewed on-list? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> ... > >>>>>>>>>>>>>>> (3) Briefly describe the review of this document that > >> was > >>>>>>>>>>>>>>> performed > >>>>>>>>>>>>>> by > >>>>>>>>>>>>>>> the Document Shepherd. If this version of the > > document > >> is not > >>>>>>>>>>>>>>> ready for publication, please explain why the > > document > >> is being > >>>>>>>>>>>>>>> forwarded to the IESG. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The document was presented at IEWTF-82 (Taipei), with > >> a request > >>>>>>>>>>>>>>> for > >>>>>>>>>>>>>> WGLC. > >>>>>>>>>>>>>>> WGLC concluded with some discussion but no > > substantive > >> changes > >>>>>>>>>>>>>>> on Friday 30th March 2012. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Yes, I guess that is true; but ignoring substantive > >> comments > >>>>>>>>>>>>>> isn't a good practice IMHO. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> (4) Does the document Shepherd have any concerns > > about > >> the depth > >>>>>>>>>>>>>>> or breadth of the reviews that have been performed? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> No - the original draft had a lot of background > >> material, much > >>>>>>>>>>>>>>> of > >>>>>>>>>>>>>> this > >>>>>>>>>>>>>>> has been condensed or removed, resulting in a smaller > >> document. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> That is indeed what I basically asked for, but I > >> don't see any > >>>>>>>>>>>>>> evidence of it: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> - diff(07,08) 48 lines changed or deleted; 53 lines > >> changed or > >>>>>>>> added > >>>>>>>>>>>>>> - diff(06,07) 8 lines changed or deleted; 13 lines > >> changed or > >>>>>>>> added > >>>>>>>>>>>>>> - diff(05,06) 64 lines changed or deleted; 69 lines > >> changed or > >>>>>>>>>>>>>> added > >>>>>>>>>>>>>> - diff(04,05) 823 lines changed or deleted; 864 lines > >> changed or > >>>>>>>>>>>>>> added > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> (Need I go farther? That gets us back to March > > 2011...) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> (9) How solid is the WG consensus behind this > >> document? Does it > >>>>>>>>>>>>>>> represent the strong concurrence of a few > > individuals, > >> with > >>>>>>>>>>>>>>> others being silent, or does the WG as a whole > >> understand > >>>>>>>> and agree with it? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The document has WG support and there is consensus to > >> publish. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> This, IMHO, doesn't answer the question. :^( > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Does it represent the concurrence of a few > >> individuals, or does > >>>>>>>>>>>>>> the WG as a whole understand and agree with it? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> For reference, my comments included: > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] When I previously skimmed this document, I believed > >> it > >>>>>>>>>>>>>> contained only ] common ground: that AQM should > >> drop/mark packets > >>>>>>>>>>>>>> without favoring small ] packets, and that to whatever > >> extent > >>>>>>>>>>>>>> packet size _is_ considered, that ] should be a > >>>>>>>> transport-layer responsibility. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find > > that > >> Bob is > >>>>>>>>>>>>>> actually ] saying that transport-layer should _only_ > >> consider > >>>>>>>>>>>>>> "congested bytes", not ] "congested packets". > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] In fact, Bob openly endorses replacing TCP > >> congestion-control > >>>>>>>>>>>>>> with an ] algorithm which calculates "fair-share > > bytes" > >> and > >>>>>>>>>>>>>> doesn't back off at all ] (even in the presence of 20% > >> packet > >>>>>>>>>>>>>> loss) unless you're already sending ] more than this > >>>>>>>> "fair-share". > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] I do not believe that is the consensus of this > > WG; > >> and I > >>>>>>>> believe > >>>>>>>>>>>>>> if > >>>>>>>>>>>>>> ] that were the consensus it would exceed our charter. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] The draft contains a number of things I _do_ > > support; > >> and I'd > >>>>>>>>>>>>>> be happy ] to support a considerably shorter draft > >> which > >>>>>>>>>>>>>> concentrates on the AQM ] recommendation, omitting any > >>>>>>>>>>>>>> suggestions of modifying TCP congestion ] control. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> and Philip's comments included: > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] S2.2 I thought the numbered bullets could be better > >> phrased, > >>>>>>>>>>>>>> something like ] +this:- ] > >>>>>>>>>>>>>> ] 1. AQM algorithms such as RED SHOULD use packet- > >> mode > >>>>>>>> drop, ie they > >>>>>>>>>>>>>> SHOULD NOT > >>>>>>>>>>>>>> ] +use byte-mode drop. The latter ] is more complex, > >>>>>>>>>>>>>> ] it creates the perverse incentive to fragment > >> segments > >>>>>>>> into > >>>>>>>>>>>>>> tiny > >>>>>>>>>>>>>> ] pieces and it is vulnerable to floods of > >> small- > >>>>>>>>>>>>>> ] packets. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] 2. If a vendor has implemented byte-mode drop, > >> and an > >>>>>>>> operator > >>>>>>>>>>>>>> has > >>>>>>>>>>>>>> ] turned it on, it is RECOMMENDED to turn it > >> off, after > >>>>>>>>>>>>>> establishing if > >>>>>>>>>>>>>> ] +there are any implications on ] the relative > >>>>>>>>>>>>>> performance of > >>>>>>>>>>>>>> ] applications using different packet sizes. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] 3. RED SHOULD NOT be turned off. Without RED, a > >> drop tail > >>>>>>>>>>>>>> ] queue biases against large packets. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] Nit - the following paragraph shouldn't be indented > >> (Note well > >>>>>>>>>>>>>> that > >>>>>>>>>>>>>> RED's...) > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] S3.3 > >>>>>>>>>>>>>> ] The section could be slightly clearer. Starting with > >> the second > >>>>>>>>>>>>>> para, where you ] +start talking about something you > >> don't > >>>>>>>>>>>>>> recommend (ie you have to remember that ] +you're > >> talking about > >>>>>>>>>>>>>> the consequences of not following your > > recommendation). > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] S3.3 > >>>>>>>>>>>>>> ] o Also, if the network biases congestion > >> notification by > >>>>>>>> packet > >>>>>>>>>>>>>> size > >>>>>>>>>>>>>> ] it has to assume a baseline packet size--all > >> proposed > >>>>>>>>>>>>>> algorithms > >>>>>>>>>>>>>> ] use the local MTU. Then transports have to > >> guess which > >>>>>>>> link > >>>>>>>>>>>>>> was > >>>>>>>>>>>>>> ] congested and what its local MTU was, in order > >> to know > >>>>>>>> how to > >>>>>>>>>>>>>> ] tailor their congestion response to that link. > >>>>>>>>>>>>>> ] So you're saying that for byte-mode drop, the > > network > >> element > >>>>>>>>>>>>>> has to compare the ] +size of the current pkt with the > >> MTU, and > >>>>>>>>>>>>>> if it's 25* smaller then reduce the ] +pkt loss > >> probably by 25*? > >>>>>>>>>>>>>> And if the MTU was bigger, then the current pkt would > > ] > >> +be > >>>>>>>>>>>>>> dropped with greater probability? And both of these > >> things > >>>>>>>> are hard to do. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] S3.4 (& knock-on effect on 3.3) ] I think this could > >> be better. > >>>>>>>>>>>>>> ] I agree with your arguments in S3.1 & 3.2 that > >> dropping or > >>>>>>>>>>>>>> marking should be ] +independent of pkt size. > >>>>>>>>>>>>>> ] You now go into a couple of pages, which I think > >> could be > >>>>>>>>>>>>>> boiled down to a ] +paragraph, saying something like:- > >> ] * the > >>>>>>>>>>>>>> overall system (network + transport) has to be packet- > >> size > >>>>>>>>>>>>>> dependent in ] > >>>>>>>>>>>>>> +order to drive out the right amount of traffic so the > >> resource > >>>>>>>>>>>>>> becomes ] > >>>>>>>>>>>>>> +uncongested (since we assume all resources are in > >> practice byte > >>>>>>>>>>>>>> +rather > >>>>>>>>>>>>>> than ] +packet limited) ] * from S3.1 and S3.2 the > > IETF > >> is > >>>>>>>>>>>>>> convinced that the network should notify ] > > +independent > >> of > >>>>>>>> packet-size. > >>>>>>>>>>>>>> ] * therefore the transport must act dependent on > >> packet-size. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] It seems to me this is a necessary consequence of > >> your earlier > >>>>>>>>>>>>>> assumptions ] +/arguments. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] [On the other hand, if someone disagrees with the > >> arguments and > >>>>>>>>>>>>>> thinks that the ] +network should notify dependent on > >>>>>>>>>>>>>> packet-size, then it follows that the ] +transport can > >> act > >>>>>>>>>>>>>> independent of > >>>>>>>>>>>>>> packet- size.] ] ] I think in S3.3 you're trying to > >> make another > >>>>>>>>>>>>>> argument (?):- ] * we can either do packet-size > >> biasing in the > >>>>>>>>>>>>>> network element or on the end host ] +transport (see > >> argument > >>>>>>>>>>>>>> above) ] * packet-size biasing in the network is quite > >> tricky, > >>>>>>>>>>>>>> because then both the ] +network element & the > >> transport have to > >>>>>>>>>>>>>> make some guesses about MTU - whereas ] > >>>>>>>>>>>>>> +with packet-size biasing in the transport, neither > >> network > >>>>>>>>>>>>>> +element > >>>>>>>>>>>>>> nor ] +transport needs to know what the MTU is. > >>>>>>>>>>>>>> ] * it is also easier to implement packet-size biasing > >> in the > >>>>>>>>>>>>>> transport than in ] +the network. > >>>>>>>>>>>>>> ] > >>>>>>>>>>>>>> ] On the last bullet, I didn't really follow your > >> argument in > >>>>>>>> S3.5. > >>>>>>>>>>>>>> Might be ] +easier to follow if S3.5 also talked about > >> how a > >>>>>>>>>>>>>> network element would take ] +account of pkt size? > >> Also, does the > >>>>>>>>>>>>>> following argument also apply?: > >>>>>>>>>>>>>> ] * if pkt-size biasing is done in the transport, then > >> the work > >>>>>>>>>>>>>> (to do the ] +biasing) is spread over many end hosts, > > ] > >> * whereas > >>>>>>>>>>>>>> if pkt-size biasing is done in the network, then the > >> work is ] > >>>>>>>>>>>>>> +concentrated in just the congested network element, > >> which has to > >>>>>>>>>>>>>> operate on all ] +the traffic at line speed. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> (Has there perhaps been some confusion about what > >> went into the > >>>>>>>>>>>>>> -08 > >>>>>>>>>>>>>> version?) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>> John Leslie > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >> ________________________________________________________________ > >>>>>>>>>>> Bob Briscoe, BT Innovate & > >> Design > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >> ________________________________________________________________ > >>>>>>> Bob Briscoe, BT Innovate & > >> Design > >>>>>>> > >>>>> > >>>>> ________________________________________________________________ > >>>>> Bob Briscoe, BT Innovate & Design > >>> > >>> ________________________________________________________________ > >>> Bob Briscoe, BT Innovate & Design > > From bob.briscoe@bt.com Thu Oct 11 09:58:53 2012 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 276BD21F84D8 for ; Thu, 11 Oct 2012 09:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lh-edv9qOf5K for ; Thu, 11 Oct 2012 09:58:50 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id CFA6421F8503 for ; Thu, 11 Oct 2012 09:58:49 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 11 Oct 2012 17:58:47 +0100 Received: from dyw02134app02.domain1.systemhost.net (193.113.249.14) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 11 Oct 2012 17:58:45 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app02.domain1.systemhost.net (10.35.25.215) with Microsoft SMTP Server id 14.2.309.2; Thu, 11 Oct 2012 17:58:36 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1349974508399; Thu, 11 Oct 2012 17:55:08 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.16.133]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q9BGt47l013369; Thu, 11 Oct 2012 17:55:04 +0100 Message-ID: <201210111655.q9BGt47l013369@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 11 Oct 2012 17:06:57 +0100 To: "Tschofenig, Hannes (NSN - FI/Espoo)" From: Bob Briscoe In-Reply-To: <999913AB42CC9341B05A99BBF358718D01F360F7@FIESEXC035.nsn-in tra.net> References: <20120815190728.GQ15012@verdi> <502BFB47.7010803@erg.abdn.ac.uk> <791AD3077F94194BB2BDD13565B6295D45A6212A@PALLENE.office.hd> <15181_1346848013_5047450C_15181_645_1_50474507.3090706@erg.abdn.ac.uk> <3A5279D338C75C40B4B3DA15BA47D6330B616BD2@EXMDB04.org.aalto.fi> <201209051541.q85FfCs0019699@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F33D793B351@EMV65-UKRD.domain1.systemhost.net> <3A5279D338C75C40B4B3DA15BA47D6330B69261A@EXMDB04.org.aalto.fi> <9510D26531EF184D9017DF24659BB87F33D793B845@EMV65-UKRD.domain1.systemhost.net> <04AC95B5-A2B1-4DD2-B765-E20A4C1A69A3@aalto.fi> <3A5279D338C75C40B4B3DA15BA47D6330B6E81E4@EXMDB04.org.aalto.fi> <9510D26531EF184D9017DF24659BB87F33DCE34251@EMV65-UKRD.domain1.systemhost.net> <201210041126.q94BQ0hx002951@bagheera.jungle.bt.co.uk> <1904eec816d080f886f5bf8685358ddc.squirrel@www.erg.abdn.ac.uk> <201210101525.q9AFP4Mi008013@bagheera.jungle.bt.co.uk> <3A5279D338C75C40B4B3DA15BA47D6330B6FC2BB@EXMDB04.org.aalto.fi> <201210111208.q9BC8BAU012! ! 305@bag he era.jungl e.b t.co.uk> <3A5279D338C75C40B4B3DA15BA47D6330B6FD072@EXMDB04.org.aalto.fi> <999913AB42CC9341B05A99BBF358718D01F360CF@FIESEXC035.nsn-intra.net> <3A5279D338C75C40B4B3DA15BA47D6330B6FD197@EXMDB04.org.aalto.fi> <999913AB42CC9341B05A99BBF358718D01F360F7@FIESEXC035.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: gorry@erg.abdn.ac.uk, philip.eardley@bt.com, tsvwg IETF list , tsvwg-chairs@ietf.org Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest 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, 11 Oct 2012 16:58:53 -0000 Hannes, This doc is very general. The advice on AQM not biasing for small packets applies equally to CoDel as to RED (it has already been applied to PCN, which is another AQM). The doc gives specific advice for RED as an exemplar, but it's not just about RED (it's worrying that you think it is - which text gave this impression?). Everywhere that RED is mentioned, the wording should carefully say it's an example. Similarly, it gives guidelines on end-to-end transports, and uses TCP as an concrete example. [Changing the subject to "Who said CoDel is a panacea anyway?" CoDel isn't really applicable on hi-speed links, certainly not if one wants the main benefit of being insensitive to the chosen hard-coded parameters. Even in the CoDel paper's simulations, CoDel gave higher queuing delay than RED in all the cases shown except the lowest link speed experiments. CoDel's 100ms target would be a crazy delay target in a high speed network. To deploy CoDel in hi-speed networks, you have to tune the parameters away from the hard-coded ones, which loses the only benefit it has. ] Bob At 13:57 11/10/2012, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >Hi Jukka, > >With QoS there is no such thing as "short term" (as we already had to >learn painfully). > >That makes me wonder what is more useful: publish a document that >describe how to configure RED correctly or to go for an AQM technique >that (according to the authors) works almost zero configuration. > >My take-away from the Vancouver congestion control workshop was that it >is better to ignore RED. (Maybe my impression was wrong -- someone else >should confirm.) > >Ciao >Hannes > > > > -----Original Message----- > > From: ext Manner Jukka [mailto:jukka.manner@aalto.fi] > > Sent: Thursday, October 11, 2012 3:50 PM > > To: Tschofenig, Hannes (NSN - FI/Espoo) > > Cc: Bob Briscoe; ; ; > > ; tsvwg IETF list > > Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf- > > tsvwg-byte-pkt-congest > > > > Hi, this document talks about the current and short term goals and > > operations, while AFAIK CoDel is a more futuristic concept, >interesting > > concept, sure, but not deployed at large. > > > > cheers, > > Jukka > > > > On Oct 11, 2012, at 3:44 PM, Tschofenig, Hannes (NSN - FI/Espoo) >wrote: > > > > > Hi Jukka, Hi Bob, > > > > > > having listened to the presentations about CoDel I am wondering > > whether > > > this document may have taken over by events and is obsolete by now. > > > What's your view on that? > > > > > > Ciao > > > Hannes > > > > > > > > >> -----Original Message----- > > >> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On > > Behalf > > >> Of ext Manner Jukka > > >> Sent: Thursday, October 11, 2012 3:34 PM > > >> To: Bob Briscoe > > >> Cc: ; ; > >> chairs@ietf.org>; tsvwg IETF list > > >> Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for >draft-ietf- > > >> tsvwg-byte-pkt-congest > > >> > > >> Hi, > > >> > > >> Yeah, please at the point about cheap devices, still, I wonder what > > > the > > >> cost of AQM is on those devices. Maybe 1 cnt in mass production? > > Thus, > > >> I still wonder if it is worth arguing something about the future > > that > > >> strongly. > > >> > > >> Sorry, but the same goes for AQM in general, and where it is, or > > will > > >> not be deployed. I understand technical reasons why not something >is > > >> feasible, but business or monetary reasons can change very quickly. > > ;) > > >> > > >> Jukka > > >> > > >> On Oct 11, 2012, at 3:08 PM, Bob Briscoe wrote: > > >> > > >>> Jukka, > > >>> > > >>> What I had in mind is all low level buffers in cheap pure L2 > > > devices, > > >> in cheap NATs etc. I was going to list some of these, but instead > > > chose > > >> to say "no-one expects AQM to be universally deployed". This >clearly > > >> missed the mark. > > >>> > > >>> Should we include some of these concrete examples of where AQM > > won't > > >> be deployed instead? > > >>> > > >>> [I've cc'd the list, given we're starting to wordsmith > > significantly > > >> new text added since WG last call.] > > >>> > > >>> > > >>> Bob > > >>> > > >>> At 20:04 10/10/2012, Manner Jukka wrote: > > >>>> Hi, looked good to me. Just one comment, I wouldn't put that much > > >> emphasis on what is a probably state of things, e.g. > > >>>> > > >>>> "no-one expects AQM to ever be .." > in the future it might, we > > >> don't know, and since the paragraph says that it doesn't matter > > > anyway, > > >> I would formulate this paragraph a bit towards that we have partial > > >> deployment now and even with a full deployment, ... > > >>>> > > >>>> and similarly with the unrealistic deployment of AQM in the > > >> subsequent paragraph. > > >>>> > > >>>> cheers, > > >>>> Jukka > > >>>> > > >>>> On Oct 10, 2012, at 6:25 PM, Bob Briscoe wrote: > > >>>> > > >>>>> Phil, > > >>>>> > > >>>>> Sorry for delay, my round-robin scheduler is taking so long to > > > get > > >> round all the tasks that I keep finding dead robins (that reminds >me > > > of > > >> a bike ride my grandmother took. On her return, she said there were > > a > > >> worryingly large number of robins run over on the roads. It turned > > out > > >> that she had been going round the same small triangle of roads > > > multiple > > >> times). > > >>>>> > > >>>>> I've done a complete re-write of 3.4. I hope you will agree that > > >> it really is a motivating argument now and it can stay where it is >- > > > it > > >> is not just a preamble. > > >>>>> > > >>>>> I've gone back to the very first version of 3.4 I wrote and I >now > > >> realise that I had written the core of the argument so badly that > > even > > >> I forgot what it was meant to say when we started editing it. In >the > > >> draft-08 version, the original meaning is lost and in your re- > > wording > > >> it is entirely lost. The link with the draft-08 version is nearly > > >> unrecognisable, but it's the argument I intended here. > > >>>>> > > >>>>> > > >> > > > > > >======================================================================= > > >> =============== > > >>>>> 3.4. Permanent Partial Deployment of AQM > > >>>>> > > >>>>> In overview, the argument in this section runs as follows: > > >>>>> * Because the network will not and cannot always drop packets in > > >> proportion to their size, it shouldn't be given the task of making > > > drop > > >> signals depend on packet size at all. > > >>>>> * Transports on the other hand don't always want to make their > > >> rate response proportional to the size of dropped packets, but if > > they > > >> want to, they always can. > > >>>>> > > >>>>> The argument is similar to the end-to-end argument that says > > >> "Don't do X in the network if end-systems can do X by themselves, > > and > > >> they want to be able to choose whether to do X anyway." Actually >the > > >> following argument is stronger; in addition it says "Don't give the > > >> network task X that could be done by the end-systems, if X won't > > ever > > >> be deployed on all network nodes, and end-systems won't be able to > > > tell > > >> whether their network is doing X, or whether they need to do X > > >> themselves." In this case, the X in question is "making the >response > > > to > > >> congestion depend on packet size". > > >>>>> > > >>>>> We will now re-run this argument taking each step in more depth. > > >> The argument applies solely to drop, not ECN marking. > > >>>>> > > >>>>> A queue drops packets for either of two reasons: a) to signal to > > >> host congestion controls that they should reduce the load and b) > > >> because there is no buffer left to store the packets. Active queue > > >> management tries to use drops as a signal for hosts to slow down > > (case > > >> a) so that drop due to buffer exhaustion (case b) should not be > > >> necessary. > > >>>>> > > >>>>> No-one expects AQM to ever be universally deployed in every >queue > > >> in the Internet; and, even if AQM were universal, it has to be able > > to > > >> cope with buffer exhaustion (by switching to a behaviour like tail- > > >> drop), in order to cope with unresponsive or excessive transports. > > >> Therefore networks will often be dropping packets as a last resort > > >> (case b) rather than under AQM control (case a). > > >>>>> > > >>>>> When buffers are exhausted (case b), they don't naturally drop > > >> packets in proportion to their size. The network can only reduce >the > > >> probability of dropping smaller packets if it has enough space to > > > store > > >> them somewhere while it waits for a larger packet that it can drop. > > If > > >> the buffer is exhausted, it does not have this choice. Admittedly > > > tail- > > >> drop does naturally drop somewhat fewer small packets, but exactly > > how > > >> few depends more on the mix of sizes than the size of the packet in > > >> question. Nonetheless, in general, if we wanted networks to do >size- > > >> dependent drop, we would need universal deployment of (packet-size > > >> dependent) AQM code, which is unrealistic. > > >>>>> > > >>>>> A host transport cannot know whether any particular drop was a > > >> deliberate signal from an AQM or a sign of a queue shedding packets > > > due > > >> to buffer exhaustion. Therefore, because the network cannot > > > universally > > >> do size-dependent drop, it should not do it all. > > >>>>> > > >>>>> Whereas universality is desirable in the network, diversity is > > >> desirable between different transport layer protocols - some, like > > >> NewReno TCP [RFC5681], may not choose to make their rate response > > >> proportionate to the size of each dropped packet, while others will > > >> (e.g. TFRC-SP [RFC4828]). > > >>>>> > > >> > > > > > >======================================================================= > > >> =============== > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> Bob > > >>>>> > > >>>>> At 13:13 04/10/2012, gorry@erg.abdn.ac.uk wrote: > > >>>>>> That would be brilliant! > > >>>>>> > > >>>>>> Gorry > > >>>>>> > > >>>>>>> Will try to look at this later today. > > >>>>>>> > > >>>>>>> > > >>>>>>> Bob > > >>>>>>> > > >>>>>>> At 10:42 02/10/2012, philip.eardley@bt.com wrote: > > >>>>>>>> Think the token is with bob > > >>>>>>>> > > >>>>>>>> Re your comment - yes, I think you could move 3.4 to the end > > > of > > >> S3 - > > >>>>>>>> or to the start - and do some re-phrasing, maybe something > > > like > > >> I tried. > > >>>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: Manner Jukka [mailto:jukka.manner@aalto.fi] > > >>>>>>>> Sent: 01 October 2012 20:18 > > >>>>>>>> To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,Bob,DUB8 R > > >>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst > > >>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for > > >>>>>>>> draft-ietf-tsvwg-byte-pkt-congest > > >>>>>>>> > > >>>>>>>> Phil, Bob, can we close this finally? It's three weeks now > > >> since > > >>>>>>>> this previous message. > > >>>>>>>> > > >>>>>>>> Jukka > > >>>>>>>> > > >>>>>>>> On Sep 10, 2012, at 4:42 PM, Jukka Manner wrote: > > >>>>>>>> > > >>>>>>>>> Ack, I'm getting there...;) > > >>>>>>>>> > > >>>>>>>>> So, we could move 3.4 at the end of Section 3 and rephrase > > >> it to > > >>>>>>>> not talk about scaling per se, but rather about how Req 2.2 > > >>>>>>>> eventually leads to Req 2.3? > > >>>>>>>>> > > >>>>>>>>> Jukka > > >>>>>>>>> > > >>>>>>>>> On Sep 7, 2012, at 4:07 PM, > > >>>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>>> 3.4 is, in my mind, completely different from 3.1, 3.2, > > > 3.3 > > >> and 3.5. > > >>>>>>>>>> > > >>>>>>>>>> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for > > >> Recommendation > > >>>>>>>>>> 2.2 & a lesser extent 2.3 > > >>>>>>>>>> 3.4 makes doesn't make a motivating argument - it explains > > >> that Rec > > >>>>>>>>>> 2.2 & 2.3 come as a pair (if you recommend one, then > > >> inevitably you > > >>>>>>>>>> recommend the other) (delta some politeness about TCP) > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> -----Original Message----- > > >>>>>>>>>> From: Manner Jukka [mailto:jukka.manner@aalto.fi] > > >>>>>>>>>> Sent: 07 September 2012 13:24 > > >>>>>>>>>> To: Eardley,PL,Philip,DUB8 R > > >>>>>>>>>> Cc: Briscoe,RJ,Bob,DUB8 R; ; > > >>>>>>>>>> > > >>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for > > >>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest > > >>>>>>>>>> > > >>>>>>>>>> Hi, I'm trying to follow your reasoning, with little luck. > > >> ;) > > >>>>>>>>>> > > >>>>>>>>>> After having read Section 3 again, I could think of a few > > >>>>>>>> updates, but I'm not fully following what you want to see: > > >>>>>>>>>> > > >>>>>>>>>> - S3.5 is kind of small and lonely by itself. It could be > > >> either > > >>>>>>>> longer or merged somewhere. Not a major issue though and > > > could > > >> remain as > > >>>>>>>> is. > > >>>>>>>>>> > > >>>>>>>>>> - S3.3: Yes, probably could be turned upside down, good > > >> first, > > >>>>>>>> bad later. Don't have a strong opinion. > > >>>>>>>>>> > > >>>>>>>>>> - S3.4: Here the scaling is used many times and in the > > >> title, > > >>>>>>>> although we talk about the end host side. This could be > > >> rephrased > > >>>>>>>> and slightly reworded to talk about hosts and their operation > > >>>>>>>> altogether. Also the word scaling can turn the readers > > >> expectation > > >>>>>>>> into the wrong direction. > > >>>>>>>>>> > > >>>>>>>>>> - S3 altogether: It would help to have introductory text > > >> about > > >>>>>>>> networks vs. end host side, but I fail to see why (& how) to > > >>>>>>>> restructure everything. > > >>>>>>>>>> > > >>>>>>>>>> cheers, > > >>>>>>>>>> Jukka > > >>>>>>>>>> > > >>>>>>>>>> On Sep 6, 2012, at 6:18 PM, > > >>>>>>>> wrote: > > >>>>>>>>>> > > >>>>>>>>>>> Ps otherwise Bob's comments are fine, though I suggest > > > for > > >> S3.5 you > > >>>>>>>>>>> give more context (ie are you knocking down what you > > >> recommend > > >>>>>>>>>>> against, or building up what you recommend?) and in S3.3 > > >> think > > >>>>>>>>>>> would be better if you re-structured slightly [first talk > > >> about what > > >>>>>>>>>>> you like - penult para + 1st sentence of last para - then > > >> talk about > > >>>>>>>>>>> what you don't like - rest of text] > > >>>>>>>>>>> > > >>>>>>>>>>> From: Eardley,PL,Philip,DUB8 R > > >>>>>>>>>>> Sent: 06 September 2012 16:12 > > >>>>>>>>>>> To: Briscoe,RJ,Bob,DUB8 R; Manner Jukka > > >>>>>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst > > >>>>>>>>>>> Subject: RE: [REVISED I-D]: Document writeup for > > >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest > > >>>>>>>>>>> > > >>>>>>>>>>> Thanks bob. Have now re-booted some state. > > >>>>>>>>>>> I don't like S3.4. My basic problem with it is that it > > >> isn't a > > >>>>>>>> "motivating argument" (S3 title). It's an explanation about > > >> the > > >>>>>>>> consequences of assuming either [option 1] do pkt-size > > > biasing > > >> in > > >>>>>>>> the transport; [option 2]; do pkt-size biasing in the nw. > > >>>>>>>>>>> Perhaps your effort to buy peace with those who won't > > >> change > > >>>>>>>> TCP has obfuscated the basic point? > > >>>>>>>>>>> The title of S3.4 (Scaling...) and the early text > > > "scaling > > >>>>>>>> argument" suggests that you're going to argue there is some > > >> reason > > >>>>>>>> why X scales as order N rather than N^2 or something like > > > that > > >> - > > >>>>>>>> which isn't what S3.4 is about. > > >>>>>>>>>>> > > >>>>>>>>>>> I actually think it would be better to put S3.4 at the > > >> start of > > >>>>>>>> S3 - it's background where you say there are 2 options. After > > >> that, > > >>>>>>>> you can explain the reasons why option 1 [pkt biasing in the > > >>>>>>>> transport] is better - the reasons being:- S3.1 (security > > > etc > > >>>>>>>> attacks if small pkts get preferential treatment), S3.2 > > >> (really a > > >>>>>>>> side note to S3.1; ie doesn't really present a "motivating > > >>>>>>>> argument"), S3.3 (nw guessing MTU vs transport knowing pkt > > >> size), > > >>>>>>>> S3.5 (easier implementation). > > >>>>>>>>>>> > > >>>>>>>>>>> Something like... > > >>>>>>>>>>> The behaviour of the network and transport together needs > > >> to > > >>>>>>>>>>> alleviate congestion. We assume the network is bit- > > >> congestible > > >>>>>>>> (currently packet-congestible resources are rate). Therefore > > >>>>>>>> overall the response of the {network + transport} should be > > >> the > > >>>>>>>> same for the same congestion - whether the congestion is > > >> caused by > > >>>>>>>> a lot of small packets or a smaller number of larger packets. > > >> The > > >>>>>>>> implication is that the transport's behaviour should depend > > > on > > >>>>>>>> whether the network takes account (or not) of packet size > > > when > > >> it > > >>>>>>>> generates congestion indications:- Case 1: If the network > > >>>>>>>> implements packet-mode drop, ie its algorithm treats all > > >> packets > > >>>>>>>> equally regardless of their size, then the transport should > > >> take > > >>>>>>>> account of the size of the packet - in other words, the > > >> transport's > > >>>>>>>> congestion response should depend on the number of dropped > > >> bytes. > > >>>>>>>>>>> Case 2: If the network implements byte-mode drop, ie its > > >>>>>>>> algorithm treats packets differently depending on their size, > > >> then > > >>>>>>>> the transport should not take account of the size of the > > >> packet - > > >>>>>>>> in other words, the transport's congestion response should > > >> depend > > >>>>>>>> on the number of dropped packets. > > >>>>>>>>>>> > > >>>>>>>>>>> These cases are explained in more detail in sub-section > > >> below. > > >>>>>>>>>>> > > >>>>>>>>>>> In both cases the same discussion applies if packets are > > >>>>>>>> ECN-marked rather than dropped. > > >>>>>>>>>>> In the following sections we explain why Case 1 is > > >> preferable, > > >>>>>>>> and hence why we make the Recommendations of S2.2 and S3.3 > > >>>>>>>> (respectively, drop/mark pkts equally regardless of their > > >> size, and > > >>>>>>>> the strength of the transport's response should be > > >> proportionate to > > >>>>>>>> the size of the dropped/marked pkt). > > >>>>>>>>>>> Note that TCP responds to dropped or marked packets, > > > which > > >> differs > > >>>>>>>>>>> from our recommendation for transports. However, we are > > >> not > > >>>>>>>>>>> recommending that TCP should be changed; to date it > > >> hasn't been a > > >>>>>>>>>>> significant problem because most TCP implementations > > > have > > >> been > > >>>>>>>> used with similar packet sizes. But we do recommend that > > >> future > > >>>>>>>> transport protocols should respond to dropped or marked > > > bytes > > >> (as > > >>>>>>>> for example TFRC-SP [RFC4828]effectively does). > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> Sub-section > > >>>>>>>>>>> You could use much of S3.3, I suggest supplement with > > >> numerical > > >>>>>>>>>>> examples continuing S1.2 > > >>>>>>>>>>> -- > > >>>>>>>>>>> << This gives a get-out clause to any transport that > > > isn't > > >>>>>>>>>>> packet-size dependent (e.g. current TCP). Lacking packet- > > >> size > > >>>>>>>>>>> dependence just means they don't scale correctly with > > >> packet size - > > >>>>>>>>>>> but they are at liberty not to scale with packet size > > >> (particularly > > >>>>>>>>>>> given MTU growth isn't often being used to increase link > > >> rates at > > >>>>>>>>>>> this stage in history).>> > > >>>>>>>>>>> > > >>>>>>>>>>> This is introducing a different point. it's saying that > > >> your > > >>>>>>>> recommendation 2 [drop/mark pkts equally regardless of their > > >> size] > > >>>>>>>> is a really strong reco whilst recommendation 3 [strength of > > >>>>>>>> transport's response proportionate to the size of the > > >>>>>>>> dropped/marked pkt] is a much less important reco. I can see > > >> this > > >>>>>>>> might be true, but I don't think the i-d talks about this. > > >>>>>>>>>>> > > >>>>>>>>>>> -- > > >>>>>>>>>>> > > >>>>>>>>>>> From: Briscoe,RJ,Bob,DUB8 R > > >>>>>>>>>>> Sent: 05 September 2012 16:41 > > >>>>>>>>>>> To: Manner Jukka > > >>>>>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst; > > >> Eardley,PL,Philip,DUB8 R > > >>>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for > > >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest > > >>>>>>>>>>> > > >>>>>>>>>>> Jukka, > > >>>>>>>>>>> > > >>>>>>>>>>> I've repeated Phil's suggestions as quoted email then > > > made > > >> some > > >>>>>>>> alterations. > > >>>>>>>>>>> > > >>>>>>>>>>> Phil asked me to send this, then he will think about it. > > >>>>>>>>>>> > > >>>>>>>>>>> I'll respond about John Leslie's argument next... > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> 2.2. Recommendation on Encoding Congestion Notification > > >>>>>>>>>>> > > >>>>>>>>>>> [...] > > >>>>>>>>>>> > > >>>>>>>>>>> 1. AQM algorithms such as RED SHOULD use packet-mode > > >> drop, ie they > > >>>>>>>>>>> SHOULD NOT use byte-mode drop. The latter is more > > >> complex, > > >>>>>>>>>>> it creates the perverse incentive to fragment > > >> segments into > > >>>>>>>> tiny > > >>>>>>>>>>> pieces and it is vulnerable to floods of small > > >> packets. > > >>>>>>>>>>> > > >>>>>>>>>>> 2. If a vendor has implemented byte-mode drop, and an > > >> operator has > > >>>>>>>>>>> turned it on, it is RECOMMENDED to turn it off, > > > after > > >>>>>>>> establishing > > >>>>>>>>>>> if there are any implications on the relative > > >> performance of > > >>>>>>>>>>> applications using different packet sizes. > > >>>>>>>>>>> > > >>>>>>>>>>> RED as a whole SHOULD NOT be turned off. Without > > > RED, > > >> a drop > > >>>>>>>> tail > > >>>>>>>>>>> queue biases against large packets > > >>>>>>>>>>> > > >>>>>>>>>>> [BB adds]: and it is > > >> vulnerable to > > >>>>>>>> floods > > >>>>>>>>>>> of small-packets. > > >>>>>>>>>>> > > >>>>>>>>>>> (I suggest the last para just qualifies item 2. It > > > doesn't > > >> warrant > > >>>>>>>>>>> another item number.) > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> [PE:] S3.3 > > >>>>>>>>>>> The section could be slightly clearer. Starting with the > > >> second > > >>>>>>>> para, where you start talking about something you don't > > >> recommend > > >>>>>>>> (ie you have to remember that you're talking about the > > >> consequences > > >>>>>>>> of not following your recommendation). > > >>>>>>>>>>> > > >>>>>>>>>>> 3.3 Transport-Independent Network > > >>>>>>>>>>> > > >>>>>>>>>>> TCP congestion control ensures that flows competing for > > >> the same > > >>>>>>>>>>> resource each maintain the same number of segments in > > >> flight, > > >>>>>>>>>>> irrespective of segment size. So under similar > > >> conditions, flows > > >>>>>>>>>>> with different segment sizes will get different > > > bit-rates. > > >>>>>>>>>>> > > >>>>>>>>>>> [OLD:] > > >>>>>>>>>>> One motivation for the network biasing congestion > > >> notification by > > >>>>>>>>>>> packet size is to counter this effect and try to equalise > > >> the bit- > > >>>>>>>>>>> rates of flows with different packet sizes. > > >>>>>>>>>>> [SUGGESTED:] > > >>>>>>>>>>> To counter this effect it seems tempting not to follow > > >> our > > >>>>>>>>>>> recommendation, and instead for the network to bias > > >> congestion > > >>>>>>>>>>> notification by packet size in order to equalise the > > > bit- > > >> rates of > > >>>>>>>>>>> flows with different packet sizes. > > >>>>>>>>>>> [CONTINUE AS BEFORE:] > > >>>>>>>>>>> However, in order to do this, the queuing > > >> algorithm > > >>>>>>>>>>> has to make assumptions about the transport, which > > > become > > >> embedded > > >>>>>>>>>>> in the network. Specifically: > > >>>>>>>>>>> [...] > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> S3.3 > > >>>>>>>>>>> o The queuing algorithm has to assume how aggressively > > >> the > > >>>>>>>> transport > > >>>>>>>>>>> will respond to congestion (see Section 4.2.4). If > > >> the network > > >>>>>>>>>>> assumes the transport responds as aggressively as TCP > > >> NewReno, > > >>>>>>>> it > > >>>>>>>>>>> will be wrong for Compound TCP and differently wrong > > >> for Cubic > > >>>>>>>>>>> TCP, etc. To achieve equal bit-rates, each transport > > >> then has > > >>>>>>>> to > > >>>>>>>>>>> guess what assumption the network made, and work out > > >> how to > > >>>>>>>>>>> replace this assumed aggressiveness with its own > > >> aggressiveness. > > >>>>>>>>>>> o Also, if the network biases congestion notification > > > by > > >> packet > > >>>>>>>> size > > >>>>>>>>>>> it has to assume a baseline packet size--all proposed > > >> algorithms > > >>>>>>>>>>> use the local MTU. Then transports have to guess > > >> which link was > > >>>>>>>>>>> congested and what its local MTU was, in order to > > > know > > >> how to > > >>>>>>>>>>> tailor their congestion response to that link. > > >>>>>>>>>>> > > >>>>>>>>>>> So you're saying that for byte-mode drop, the network > > >> element > > >>>>>>>> has to compare the size of the current pkt with the MTU, and > > >> if > > >>>>>>>> it's 25* smaller then reduce the pkt loss probably by 25*? > > > And > > >> if > > >>>>>>>> the MTU was bigger, then the current pkt would be dropped > > > with > > >>>>>>>> greater probability? And both of these things are hard to do. > > >>>>>>>>>>> > > >>>>>>>>>>> [BB]: SUGGESTED REPLACEMENT to 2nd bullet: > > >>>>>>>>>>> > > >>>>>>>>>>> o Also, if the network biases congestion notification > > > by > > >> packet > > >>>>>>>> size > > >>>>>>>>>>> it has to assume a baseline packet size--all proposed > > >> algorithms > > >>>>>>>>>>> use the local MTU (for example see the byte-mode loss > > >>>>>>>> probability > > >>>>>>>>>>> formula in Table 1). Then if the non-Reno transports > > >> mentioned > > >>>>>>>> above > > >>>>>>>>>>> are trying to reverse engineer what the network > > >> assumed, they > > >>>>>>>> also > > >>>>>>>>>>> have to guess the MTU of the congested link. > > >>>>>>>>>>> > > >>>>>>>>>>> [Aside for Phil: The byte-mode algo uses MTU as its > > >> baseline because > > >>>>>>>>>>> a link cannot send a packet bigger than its MTU so the > > >> algo won't > > >>>>>>>>>>> ever give a drop probability >1).] > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> S3.4 (& knock-on effect on 3.3) > > >>>>>>>>>>> I think this could be better. > > >>>>>>>>>>> I agree with your arguments in S3.1 & 3.2 that dropping > > > or > > >>>>>>>> marking should be independent of pkt size. > > >>>>>>>>>>> You now go into a couple of pages, which I think could be > > >> boiled > > >>>>>>>>>>> down to a paragraph, saying something like:- > > >>>>>>>>>>> * the overall system (network + transport) has to be > > >> packet-size > > >>>>>>>>>>> dependent in order to drive out the right amount of > > >> traffic so the > > >>>>>>>>>>> resource becomes uncongested (since we assume all > > >> resources are in > > >>>>>>>>>>> practice byte rather than packet limited) > > >>>>>>>>>>> * from S3.1 and S3.2 the IETF is convinced that the > > >> network > > >>>>>>>> should notify independent of packet-size. > > >>>>>>>>>>> * therefore the transport must act dependent on packet- > > >> size. > > >>>>>>>>>>> > > >>>>>>>>>>> It seems to me this is a necessary consequence of your > > >> earlier > > >>>>>>>> assumptions /arguments. > > >>>>>>>>>>> > > >>>>>>>>>>> [BB:] This isn't at all obvious. Until I worked it > > >> through, it > > >>>>>>>> wasn't obvious to me. I think it needs to be spelled out. > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> [On the other hand, if someone disagrees with the > > >> arguments and > > >>>>>>>>>>> thinks that the network should notify dependent on > > > packet- > > >> size, then > > >>>>>>>>>>> it follows that the transport can act independent of > > >> packet-size.] > > >>>>>>>>>>> > > >>>>>>>>>>> I think in S3.3 you're trying to make another argument > > >> (?):- > > >>>>>>>>>>> * we can either do packet-size biasing in the network > > >> element or on > > >>>>>>>>>>> the end host transport (see argument above) > > >>>>>>>>>>> * packet-size biasing in the network is quite tricky, > > >> because > > >>>>>>>> then both the network element & the transport have to make > > >> some > > >>>>>>>> guesses about MTU - whereas with packet-size biasing in the > > >>>>>>>> transport, neither network element nor transport needs to > > > know > > >> what the > > >>>>>>>> MTU is. > > >>>>>>>>>>> * it is also easier to implement packet-size biasing in > > >> the > > >>>>>>>> transport than in the network. > > >>>>>>>>>>> > > >>>>>>>>>>> [BB] ...and all the other arguments about vulnerability > > > to > > >>>>>>>> flooding etc, transport-independence etc. > > >>>>>>>>>>> > > >>>>>>>>>>> Our argument is sort of like how Phil summarises it, but > > >> with > > >>>>>>>> an added nuance. It's also saying no-one has to do > > > packet-size > > >>>>>>>> biasing anyway. It's not saying "The transport should given > > >> the > > >>>>>>>> network shouldn't". It's saying "*If the transport wants to > > >> claim > > >>>>>>>> to be scalable wrt packet size* it should if the network > > >> shouldn't". > > >>>>>>>>>>> > > >>>>>>>>>>> This gives a get-out clause to any transport that isn't > > >>>>>>>> packet-size dependent (e.g. current TCP). Lacking packet-size > > >>>>>>>> dependence just means they don't scale correctly with packet > > >> size - > > >>>>>>>> but they are at liberty not to scale with packet size > > >> (particularly > > >>>>>>>> given MTU growth isn't often being used to increase link > > > rates > > >> at > > >>>>>>>> this stage in history). > > >>>>>>>>>>> > > >>>>>>>>>>> None of what Phil says convinces me we could say 3.4 (or > > >> 3.3) > > >>>>>>>> any more briefly or differently. It's easier to summarise > > > what > > >> you > > >>>>>>>> understand having read something. But that's not the same as > > >>>>>>>> writing the thing that helped you understand. There doesn't > > >> seem to > > >>>>>>>> be any argument for why anything needs to be changed, so I'm > > >> going > > >>>>>>>> to leave it as is, unless pushed. > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> On the last bullet, I didn't really follow your argument > > >> in > > >>>>>>>> S3.5. Might be easier to follow if S3.5 also talked about how > > >> a > > >>>>>>>> network element would take account of pkt size? > > >>>>>>>>>>> Also, does the following argument also apply?: > > >>>>>>>>>>> * if pkt-size biasing is done in the transport, then the > > >> work (to do > > >>>>>>>>>>> the biasing) is spread over many end hosts, > > >>>>>>>>>>> * whereas if pkt-size biasing is done in the network, > > > then > > >> the > > >>>>>>>> work is concentrated in just the congested network element, > > >> which > > >>>>>>>> has to operate on all the traffic at line speed. > > >>>>>>>>>>> > > >>>>>>>>>>> [BB]: 3.5. Implementation Efficiency > > >>>>>>>>>>> > > >>>>>>>>>>> [ADD:] > > >>>>>>>>>>> Biasing against large packets typically requires an > > > extra > > >> multiply > > >>>>>>>>>>> and divide in the network (see the example byte-mode > > > drop > > >>>>>>>> formula in table 1). > > >>>>>>>>>>> [CONTINUE AS BEFORE:] > > >>>>>>>>>>> Allowing for packet size at the transport rather than in > > >> the > > >>>>>>>>>>> network ensures that neither the network nor the > > >> transport needs to > > >>>>>>>>>>> do a multiply operation--multiplication by packet size > > > is > > >>>>>>>>>>> effectively achieved as a repeated add when the > > > transport > > >> adds to > > >>>>>>>>>>> its count of marked bytes as each congestion event is > > > fed > > >> to it. > > >>>>>>>>>>> [ADD:] > > >>>>>>>>>>> Also the work to do the biasing is spread over many > > >> hosts, rather > > >>>>>>>>>>> than concentrated in just the congested network element. > > >>>>>>>>>>> [CONTINUE AS BEFORE:] > > >>>>>>>>>>> > > > These > > >> aren't > > >>>>>>>>>>> principled reasons in themselves, but they are a happy > > >> consequence > > >>>>>>>>>>> of the other principled reasons. > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> Bob > > >>>>>>>>>>> > > >>>>>>>>>>> At 13:36 05/09/2012, Manner Jukka wrote: > > >>>>>>>>>>> > > >>>>>>>>>>> Hi Bob, > > >>>>>>>>>>> > > >>>>>>>>>>> Since Phil is your colleague at BT, even at Ipswich (?), > > >> can > > >>>>>>>> you check those and agree with Phil how to go forward? Some > > > of > > >>>>>>>> those are clear, others need discussion with Phil. > > >>>>>>>>>>> > > >>>>>>>>>>> Gorry, on point 2) below, I don't follow Leslie's > > >> arguments. I > > >>>>>>>> asked from him detailed comments and resolutions months ago, > > >> and nothing > > >>>>>>>> came. > > >>>>>>>>>>> > > >>>>>>>>>>> cheers, > > >>>>>>>>>>> Jukka > > >>>>>>>>>>> > > >>>>>>>>>>> On Sep 5, 2012, at 3:26 PM, Gorry Fairhurst wrote: > > >>>>>>>>>>> > > >>>>>>>>>>>> Bob and Jukka, > > >>>>>>>>>>>> > > >>>>>>>>>>>> I think I need your help to resolve this... Some of the > > >>>>>>>> comments raised by John Leslie appear to have substance, and > > >> I'm > > >>>>>>>> not sure what you plan to do to address these. > > >>>>>>>>>>>> > > >>>>>>>>>>>> It would be good to do something quick so that I can > > >> complete > > >>>>>>>> the submission to the IESG. > > >>>>>>>>>>>> > > >>>>>>>>>>>> The issues I particularly note are: > > >>>>>>>>>>>> > > >>>>>>>>>>>> 1) This contribution from Phil appears to be within > > > scope > > >> and > > >>>>>>>> it seems may have been overlooked (sorry): > > >>>>>>>>>>>> http://www.ietf.org/mail- > > >> archive/web/tsvwg/current/msg11234.html > > >>>>>>>>>>>> > > >>>>>>>>>>>> 2) Can you be clear here about what is actually been > > > said > > >> - > > >>>>>>>> because the point below seems to be a misunderstanding of > > >> language > > >>>>>>>> to me, and I hoped we did not claim this: > > >>>>>>>>>>>> > > >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find > > > that > > >> Bob is > > >>>>>>>>>>>>>> actually ] saying that transport-layer should _only_ > > >> consider > > >>>>>>>>>>>>>> "congested bytes", not ] "congested packets". > > >>>>>>>>>>>>>> ] > > >>>>>>>>>>>> > > >>>>>>>>>>>> 3) You'll need to post the updated draft and send a note > > >> to > > >>>>>>>> the group to confirm that the new version indeed concludes > > > the > > >>>>>>>> WGLC. I'll add a note to the writeup to indicate the draft > > >> content > > >>>>>>>> has been stable since Oct 2011. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Gorry (with my TSVWG Documnent Shepherd hat) > > >>>>>>>>>>>> cc: Co-Chairs for info. > > >>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>>> -----Original Message----- > > >>>>>>>>>>>>>> From: Gorry Fairhurst [ mailto:gorry@erg.abdn.ac.uk] > > >>>>>>>>>>>>>> Sent: Mittwoch, 15. August 2012 21:41 > > >>>>>>>>>>>>>> To: tsvwg chair > > >>>>>>>>>>>>>> Subject: Fwd: Re: [tsvwg] FYI: Document writeup for > > >>>>>>>>>>>>>> draft-ietf-tsvwg- byte-pkt-congest > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Hi guys, > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Apart form the usual rhetoric, there are some points > > >> here that we > > >>>>>>>>>>>>>> should note as chairs. What are you own thoughts? And > > >> was > > >>>>>>>>>>>>>> anything noted at the IETF in Vancouver concerning > > > this > > >> draft? > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Gorry > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> -------- Original Message -------- > > >>>>>>>>>>>>>> Subject: Re: [tsvwg] FYI: Document writeup for > > >>>>>>>>>>>>>> draft-ietf-tsvwg-byte- pkt-congest > > >>>>>>>>>>>>>> Date: Wed, 15 Aug 2012 15:07:28 -0400 > > >>>>>>>>>>>>>> From: John Leslie > > >>>>>>>>>>>>>> To: Gorry Fairhurst > > >>>>>>>>>>>>>> CC: tsvwg@ietf.org > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Gorry Fairhurst wrote: > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> The following document has been revised after > > >> receiving > > >>>>>>>> WGLC comments. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> The changes are mostly refreshing a document > > >> scheduled to > > >>>>>>>>>>>>>> expire this month. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> No issues were found: > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Is that with WGC-hat-on? > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Neither my issues nor Philip Eardley's comments were > > >> addressed. > > >>>>>>>>>>>>>> In fact, not even the changes Bob Briscoe mentioned > > > on- > > >> list have > > >>>>>>>>>>>>>> been included. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> As required by RFC 4858, this is the current template > > >> for the > > >>>>>>>>>>>>>> Document > > >>>>>>>>>>>>>>> Shepherd Write-Up. > > >>>>>>>>>>>>>>> ... > > >>>>>>>>>>>>>>> (1) What type of RFC is being requested (BCP, > > > Proposed > > >> Standard, > > >>>>>>>>>>>>>>> Internet Standard, Informational, Experimental, or > > >> Historic)? > > >>>>>>>>>>>>>>> Why is this the proper type of RFC? Is this type of > > >> RFC > > >>>>>>>>>>>>>>> indicated in the title page header? > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> This document is intended as BCP. (This was discussed > > >> at IETF-81 > > >>>>>>>>>>>>>>> and that the status changed from Informational to BCP > > >> since it > > >>>>>>>>>>>>>>> provides guidance to implementors and people > > >> configuring > > >>>>>>>> routers and hosts). > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Thank you for finally answering my question about > > > BCP > > >> status. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> ... > > >>>>>>>>>>>>>>> Working Group Summary > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> There was consensus to publish this as a WG document > > >> and > > >>>>>>>>>>>>>>> agreement at > > >>>>>>>>>>>>>>> IETF-82 that the document was now complete. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Was that reviewed on-list? > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> ... > > >>>>>>>>>>>>>>> (3) Briefly describe the review of this document that > > >> was > > >>>>>>>>>>>>>>> performed > > >>>>>>>>>>>>>> by > > >>>>>>>>>>>>>>> the Document Shepherd. If this version of the > > > document > > >> is not > > >>>>>>>>>>>>>>> ready for publication, please explain why the > > > document > > >> is being > > >>>>>>>>>>>>>>> forwarded to the IESG. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> The document was presented at IEWTF-82 (Taipei), with > > >> a request > > >>>>>>>>>>>>>>> for > > >>>>>>>>>>>>>> WGLC. > > >>>>>>>>>>>>>>> WGLC concluded with some discussion but no > > > substantive > > >> changes > > >>>>>>>>>>>>>>> on Friday 30th March 2012. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Yes, I guess that is true; but ignoring substantive > > >> comments > > >>>>>>>>>>>>>> isn't a good practice IMHO. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> (4) Does the document Shepherd have any concerns > > > about > > >> the depth > > >>>>>>>>>>>>>>> or breadth of the reviews that have been performed? > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> No - the original draft had a lot of background > > >> material, much > > >>>>>>>>>>>>>>> of > > >>>>>>>>>>>>>> this > > >>>>>>>>>>>>>>> has been condensed or removed, resulting in a smaller > > >> document. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> That is indeed what I basically asked for, but I > > >> don't see any > > >>>>>>>>>>>>>> evidence of it: > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> - diff(07,08) 48 lines changed or deleted; 53 lines > > >> changed or > > >>>>>>>> added > > >>>>>>>>>>>>>> - diff(06,07) 8 lines changed or deleted; 13 lines > > >> changed or > > >>>>>>>> added > > >>>>>>>>>>>>>> - diff(05,06) 64 lines changed or deleted; 69 lines > > >> changed or > > >>>>>>>>>>>>>> added > > >>>>>>>>>>>>>> - diff(04,05) 823 lines changed or deleted; 864 lines > > >> changed or > > >>>>>>>>>>>>>> added > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> (Need I go farther? That gets us back to March > > > 2011...) > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> (9) How solid is the WG consensus behind this > > >> document? Does it > > >>>>>>>>>>>>>>> represent the strong concurrence of a few > > > individuals, > > >> with > > >>>>>>>>>>>>>>> others being silent, or does the WG as a whole > > >> understand > > >>>>>>>> and agree with it? > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> The document has WG support and there is consensus to > > >> publish. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> This, IMHO, doesn't answer the question. :^( > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Does it represent the concurrence of a few > > >> individuals, or does > > >>>>>>>>>>>>>> the WG as a whole understand and agree with it? > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> For reference, my comments included: > > >>>>>>>>>>>>>> ] > > >>>>>>>>>>>>>> ] When I previously skimmed this document, I believed > > >> it > > >>>>>>>>>>>>>> contained only ] common ground: that AQM should > > >> drop/mark packets > > >>>>>>>>>>>>>> without favoring small ] packets, and that to whatever > > >> extent > > >>>>>>>>>>>>>> packet size _is_ considered, that ] should be a > > >>>>>>>> transport-layer responsibility. > > >>>>>>>>>>>>>> ] > > >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find > > > that > > >> Bob is > > >>>>>>>>>>>>>> actually ] saying that transport-layer should _only_ > > >> consider > > >>>>>>>>>>>>>> "congested bytes", not ] "congested packets". > > >>>>>>>>>>>>>> ] > > >>>>>>>>>>>>>> ] In fact, Bob openly endorses replacing TCP > > >> congestion-control > > >>>>>>>>>>>>>> with an ] algorithm which calculates "fair-share > > > bytes" > > >> and > > >>>>>>>>>>>>>> doesn't back off at all ] (even in the presence of 20% > > >> packet > > >>>>>>>>>>>>>> loss) unless you're already sending ] more than this > > >>>>>>>> "fair-share". > > >>>>>>>>>>>>>> ] > > >>>>>>>>>>>>>> ] I do not believe that is the consensus of this > > > WG; > > >> and I > > >>>>>>>> believe > > >>>>>>>>>>>>>> if > > >>>>>>>>>>>>>> ] that were the consensus it would exceed our charter. > > >>>>>>>>>>>>>> ] > > >>>>>>>>>>>>>> ] The draft contains a number of things I _do_ > > > support; > > >> and I'd > > >>>>>>>>>>>>>> be happy ] to support a considerably shorter draft > > >> which > > >>>>>>>>>>>>>> concentrates on the AQM ] recommendation, omitting any > > >>>>>>>>>>>>>> suggestions of modifying TCP congestion ] control. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> and Philip's comments included: > > >>>>>>>>>>>>>> ] > > >>>>>>>>>>>>>> ] S2.2 I thought the numbered bullets could be better > > >> phrased, > > >>>>>>>>>>>>>> something like ] +this:- ] > > >>>>>>>>>>>>>> ] 1. AQM algorithms such as RED SHOULD use packet- > > >> mode > > >>>>>>>> drop, ie they > > >>>>>>>>>>>>>> SHOULD NOT > > >>>>>>>>>>>>>> ] +use byte-mode drop. The latter ] is more complex, > > >>>>>>>>>>>>>> ] it creates the perverse incentive to fragment > > >> segments > > >>>>>>>> into > > >>>>>>>>>>>>>> tiny > > >>>>>>>>>>>>>> ] pieces and it is vulnerable to floods of > > >> small- > > >>>>>>>>>>>>>> ] packets. > > >>>>>>>>>>>>>> ] > > >>>>>>>>>>>>>> ] 2. If a vendor has implemented byte-mode drop, > > >> and an > > >>>>>>>> operator > > >>>>>>>>>>>>>> has > > >>>>>>>>>>>>>> ] turned it on, it is RECOMMENDED to turn it > > >> off, after > > >>>>>>>>>>>>>> establishing if > > >>>>>>>>>>>>>> ] +there are any implications on > > >>>>>>>>>>>>>> ] the relative performance of > > >>>>>>>>>>>>>> ] applications using different packet sizes. > > >>>>>>>>>>>>>> ] > > >>>>>>>>>>>>>> ] 3. RED SHOULD NOT be turned off. Without RED, a > > >> drop tail > > >>>>>>>>>>>>>> ] queue biases against large packets. > > >>>>>>>>>>>>>> ] > > >>>>>>>>>>>>>> ] Nit - the following paragraph shouldn't be indented > > >> (Note well > > >>>>>>>>>>>>>> that > > >>>>>>>>>>>>>> RED's...) > > >>>>>>>>>>>>>> ] > > >>>>>>>>>>>>>> ] S3.3 > > >>>>>>>>>>>>>> ] The section could be slightly clearer. Starting with > > >> the second > > >>>>>>>>>>>>>> para, where you ] +start talking about something you > > >> don't > > >>>>>>>>>>>>>> recommend (ie you have to remember that ] +you're > > >> talking about > > >>>>>>>>>>>>>> the consequences of not following your > > > recommendation). > > >>>>>>>>>>>>>> ] > > >>>>>>>>>>>>>> ] S3.3 > > >>>>>>>>>>>>>> ] o Also, if the network biases congestion > > >> notification by > > >>>>>>>> packet > > >>>>>>>>>>>>>> size > > >>>>>>>>>>>>>> ] it has to assume a baseline packet size--all > > >> proposed > > >>>>>>>>>>>>>> algorithms > > >>>>>>>>>>>>>> ] use the local MTU. Then transports have to > > >> guess which > > >>>>>>>> link > > >>>>>>>>>>>>>> was > > >>>>>>>>>>>>>> ] congested and what its local MTU was, in order > > >> to know > > >>>>>>>> how to > > >>>>>>>>>>>>>> ] tailor their congestion response to that link. > > >>>>>>>>>>>>>> ] So you're saying that for byte-mode drop, the > > > network > > >> element > > >>>>>>>>>>>>>> has to compare the ] +size of the current pkt with the > > >> MTU, and > > >>>>>>>>>>>>>> if it's 25* smaller then reduce the ] +pkt loss > > >> probably by 25*? > > >>>>>>>>>>>>>> And if the MTU was bigger, then the current pkt would > > > ] > > >> +be > > >>>>>>>>>>>>>> dropped with greater probability? And both of these > > >> things > > >>>>>>>> are hard to do. > > >>>>>>>>>>>>>> ] > > >>>>>>>>>>>>>> ] S3.4 (& knock-on effect on 3.3) ] I think this could > > >> be better. > > >>>>>>>>>>>>>> ] I agree with your arguments in S3.1 & 3.2 that > > >> dropping or > > >>>>>>>>>>>>>> marking should be ] +independent of pkt size. > > >>>>>>>>>>>>>> ] You now go into a couple of pages, which I think > > >> could be > > >>>>>>>>>>>>>> boiled down to a ] +paragraph, saying something like:- > > >> ] * the > > >>>>>>>>>>>>>> overall system (network + transport) has to be packet- > > >> size > > >>>>>>>>>>>>>> dependent in ] > > >>>>>>>>>>>>>> +order to drive out the right amount of traffic so the > > >> resource > > >>>>>>>>>>>>>> becomes ] > > >>>>>>>>>>>>>> +uncongested (since we assume all resources are in > > >> practice byte > > >>>>>>>>>>>>>> +rather > > >>>>>>>>>>>>>> than ] +packet limited) ] * from S3.1 and S3.2 the > > > IETF > > >> is > > >>>>>>>>>>>>>> convinced that the network should notify ] > > > +independent > > >> of > > >>>>>>>> packet-size. > > >>>>>>>>>>>>>> ] * therefore the transport must act dependent on > > >> packet-size. > > >>>>>>>>>>>>>> ] > > >>>>>>>>>>>>>> ] It seems to me this is a necessary consequence of > > >> your earlier > > >>>>>>>>>>>>>> assumptions ] +/arguments. > > >>>>>>>>>>>>>> ] > > >>>>>>>>>>>>>> ] [On the other hand, if someone disagrees with the > > >> arguments and > > >>>>>>>>>>>>>> thinks that the ] +network should notify dependent on > > >>>>>>>>>>>>>> packet-size, then it follows that the ] +transport can > > >> act > > >>>>>>>>>>>>>> independent of > > >>>>>>>>>>>>>> packet- size.] ] ] I think in S3.3 you're trying to > > >> make another > > >>>>>>>>>>>>>> argument (?):- ] * we can either do packet-size > > >> biasing in the > > >>>>>>>>>>>>>> network element or on the end host ] +transport (see > > >> argument > > >>>>>>>>>>>>>> above) ] * packet-size biasing in the network is quite > > >> tricky, > > >>>>>>>>>>>>>> because then both the ] +network element & the > > >> transport have to > > >>>>>>>>>>>>>> make some guesses about MTU - whereas ] > > >>>>>>>>>>>>>> +with packet-size biasing in the transport, neither > > >> network > > >>>>>>>>>>>>>> +element > > >>>>>>>>>>>>>> nor ] +transport needs to know what the MTU is. > > >>>>>>>>>>>>>> ] * it is also easier to implement packet-size biasing > > >> in the > > >>>>>>>>>>>>>> transport than in ] +the network. > > >>>>>>>>>>>>>> ] > > >>>>>>>>>>>>>> ] On the last bullet, I didn't really follow your > > >> argument in > > >>>>>>>> S3.5. > > >>>>>>>>>>>>>> Might be ] +easier to follow if S3.5 also talked about > > >> how a > > >>>>>>>>>>>>>> network element would take ] +account of pkt size? > > >> Also, does the > > >>>>>>>>>>>>>> following argument also apply?: > > >>>>>>>>>>>>>> ] * if pkt-size biasing is done in the transport, then > > >> the work > > >>>>>>>>>>>>>> (to do the ] +biasing) is spread over many end hosts, > > > ] > > >> * whereas > > >>>>>>>>>>>>>> if pkt-size biasing is done in the network, then the > > >> work is ] > > >>>>>>>>>>>>>> +concentrated in just the congested network element, > > >> which has to > > >>>>>>>>>>>>>> operate on all ] +the traffic at line speed. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> (Has there perhaps been some confusion about what > > >> went into the > > >>>>>>>>>>>>>> -08 > > >>>>>>>>>>>>>> version?) > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> -- > > >>>>>>>>>>>>>> John Leslie > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >> ________________________________________________________________ > > >>>>>>>>>>> Bob Briscoe, BT Innovate & > > >> Design > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>> > > >>>>>>> > > >> ________________________________________________________________ > > >>>>>>> Bob Briscoe, BT Innovate & > > >> Design > > >>>>>>> > > >>>>> > > >>>>> ________________________________________________________________ > > >>>>> Bob Briscoe, BT Innovate & Design > > >>> > > >>> ________________________________________________________________ > > >>> Bob Briscoe, BT Innovate & Design > > > ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Thu Oct 11 10:09:40 2012 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 4FB3E21F866C for ; Thu, 11 Oct 2012 10:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rdhcPIbJnWn for ; Thu, 11 Oct 2012 10:09:37 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 86B1621F8687 for ; Thu, 11 Oct 2012 10:09:36 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 11 Oct 2012 18:09:35 +0100 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 11 Oct 2012 18:09:34 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.309.2; Thu, 11 Oct 2012 18:09:22 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1349975301665; Thu, 11 Oct 2012 18:08:21 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.16.16]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q9BH8InG013834; Thu, 11 Oct 2012 18:08:18 +0100 Message-ID: <201210111708.q9BH8InG013834@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 11 Oct 2012 18:08:15 +0100 To: "Tschofenig, Hannes (NSN - FI/Espoo)" From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: gorry@erg.abdn.ac.uk, philip.eardley@bt.com, tsvwg IETF list , tsvwg-chairs@ietf.org Subject: [tsvwg] Fwd: RE: [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest 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, 11 Oct 2012 17:09:40 -0000 Hannes, Brainfart - sorry. for 'CoDel's 100ms target', read 5ms. Still crazy for hi-speed. Bob >Date: Thu, 11 Oct 2012 17:06:57 +0100 >To: "Tschofenig, Hannes (NSN - FI/Espoo)" >From: Bob Briscoe >Subject: RE: [tsvwg] [REVISED I-D]: Document writeup for >draft-ietf-tsvwg-byte-pkt-congest >Cc: ext Manner Jukka , >, , >, tsvwg IETF list > >Hannes, > >This doc is very general. The advice on AQM not biasing for small >packets applies equally to CoDel as to RED (it has already been >applied to PCN, which is another AQM). The doc gives specific advice >for RED as an exemplar, but it's not just about RED (it's worrying >that you think it is - which text gave this impression?). Everywhere >that RED is mentioned, the wording should carefully say it's an example. > >Similarly, it gives guidelines on end-to-end transports, and uses >TCP as an concrete example. > >[Changing the subject to "Who said CoDel is a panacea anyway?" CoDel >isn't really applicable on hi-speed links, certainly not if one >wants the main benefit of being insensitive to the chosen hard-coded >parameters. Even in the CoDel paper's simulations, CoDel gave higher >queuing delay than RED in all the cases shown except the lowest link >speed experiments. CoDel's 100ms target would be a crazy delay >target in a high speed network. To deploy CoDel in hi-speed >networks, you have to tune the parameters away from the hard-coded >ones, which loses the only benefit it has. >] > > >Bob > >At 13:57 11/10/2012, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>Hi Jukka, >> >>With QoS there is no such thing as "short term" (as we already had to >>learn painfully). >> >>That makes me wonder what is more useful: publish a document that >>describe how to configure RED correctly or to go for an AQM technique >>that (according to the authors) works almost zero configuration. >> >>My take-away from the Vancouver congestion control workshop was that it >>is better to ignore RED. (Maybe my impression was wrong -- someone else >>should confirm.) >> >>Ciao >>Hannes >> >> >> > -----Original Message----- >> > From: ext Manner Jukka [mailto:jukka.manner@aalto.fi] >> > Sent: Thursday, October 11, 2012 3:50 PM >> > To: Tschofenig, Hannes (NSN - FI/Espoo) >> > Cc: Bob Briscoe; ; ; >> > ; tsvwg IETF list >> > Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf- >> > tsvwg-byte-pkt-congest >> > >> > Hi, this document talks about the current and short term goals and >> > operations, while AFAIK CoDel is a more futuristic concept, >>interesting >> > concept, sure, but not deployed at large. >> > >> > cheers, >> > Jukka >> > >> > On Oct 11, 2012, at 3:44 PM, Tschofenig, Hannes (NSN - FI/Espoo) >>wrote: >> > >> > > Hi Jukka, Hi Bob, >> > > >> > > having listened to the presentations about CoDel I am wondering >> > whether >> > > this document may have taken over by events and is obsolete by now. >> > > What's your view on that? >> > > >> > > Ciao >> > > Hannes >> > > >> > > >> > >> -----Original Message----- >> > >> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On >> > Behalf >> > >> Of ext Manner Jukka >> > >> Sent: Thursday, October 11, 2012 3:34 PM >> > >> To: Bob Briscoe >> > >> Cc: ; ; > > >> chairs@ietf.org>; tsvwg IETF list >> > >> Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for >>draft-ietf- >> > >> tsvwg-byte-pkt-congest >> > >> >> > >> Hi, >> > >> >> > >> Yeah, please at the point about cheap devices, still, I wonder what >> > > the >> > >> cost of AQM is on those devices. Maybe 1 cnt in mass production? >> > Thus, >> > >> I still wonder if it is worth arguing something about the future >> > that >> > >> strongly. >> > >> >> > >> Sorry, but the same goes for AQM in general, and where it is, or >> > will >> > >> not be deployed. I understand technical reasons why not something >>is >> > >> feasible, but business or monetary reasons can change very quickly. >> > ;) >> > >> >> > >> Jukka >> > >> >> > >> On Oct 11, 2012, at 3:08 PM, Bob Briscoe wrote: >> > >> >> > >>> Jukka, >> > >>> >> > >>> What I had in mind is all low level buffers in cheap pure L2 >> > > devices, >> > >> in cheap NATs etc. I was going to list some of these, but instead >> > > chose >> > >> to say "no-one expects AQM to be universally deployed". This >>clearly >> > >> missed the mark. >> > >>> >> > >>> Should we include some of these concrete examples of where AQM >> > won't >> > >> be deployed instead? >> > >>> >> > >>> [I've cc'd the list, given we're starting to wordsmith >> > significantly >> > >> new text added since WG last call.] >> > >>> >> > >>> >> > >>> Bob >> > >>> >> > >>> At 20:04 10/10/2012, Manner Jukka wrote: >> > >>>> Hi, looked good to me. Just one comment, I wouldn't put that much >> > >> emphasis on what is a probably state of things, e.g. >> > >>>> >> > >>>> "no-one expects AQM to ever be .." > in the future it might, we >> > >> don't know, and since the paragraph says that it doesn't matter >> > > anyway, >> > >> I would formulate this paragraph a bit towards that we have partial >> > >> deployment now and even with a full deployment, ... >> > >>>> >> > >>>> and similarly with the unrealistic deployment of AQM in the >> > >> subsequent paragraph. >> > >>>> >> > >>>> cheers, >> > >>>> Jukka >> > >>>> >> > >>>> On Oct 10, 2012, at 6:25 PM, Bob Briscoe wrote: >> > >>>> >> > >>>>> Phil, >> > >>>>> >> > >>>>> Sorry for delay, my round-robin scheduler is taking so long to >> > > get >> > >> round all the tasks that I keep finding dead robins (that reminds >>me >> > > of >> > >> a bike ride my grandmother took. On her return, she said there were >> > a >> > >> worryingly large number of robins run over on the roads. It turned >> > out >> > >> that she had been going round the same small triangle of roads >> > > multiple >> > >> times). >> > >>>>> >> > >>>>> I've done a complete re-write of 3.4. I hope you will agree that >> > >> it really is a motivating argument now and it can stay where it is >>- >> > > it >> > >> is not just a preamble. >> > >>>>> >> > >>>>> I've gone back to the very first version of 3.4 I wrote and I >>now >> > >> realise that I had written the core of the argument so badly that >> > even >> > >> I forgot what it was meant to say when we started editing it. In >>the >> > >> draft-08 version, the original meaning is lost and in your re- >> > wording >> > >> it is entirely lost. The link with the draft-08 version is nearly >> > >> unrecognisable, but it's the argument I intended here. >> > >>>>> >> > >>>>> >> > >> >> > > >> > >>======================================================================= >> > >> =============== >> > >>>>> 3.4. Permanent Partial Deployment of AQM >> > >>>>> >> > >>>>> In overview, the argument in this section runs as follows: >> > >>>>> * Because the network will not and cannot always drop packets in >> > >> proportion to their size, it shouldn't be given the task of making >> > > drop >> > >> signals depend on packet size at all. >> > >>>>> * Transports on the other hand don't always want to make their >> > >> rate response proportional to the size of dropped packets, but if >> > they >> > >> want to, they always can. >> > >>>>> >> > >>>>> The argument is similar to the end-to-end argument that says >> > >> "Don't do X in the network if end-systems can do X by themselves, >> > and >> > >> they want to be able to choose whether to do X anyway." Actually >>the >> > >> following argument is stronger; in addition it says "Don't give the >> > >> network task X that could be done by the end-systems, if X won't >> > ever >> > >> be deployed on all network nodes, and end-systems won't be able to >> > > tell >> > >> whether their network is doing X, or whether they need to do X >> > >> themselves." In this case, the X in question is "making the >>response >> > > to >> > >> congestion depend on packet size". >> > >>>>> >> > >>>>> We will now re-run this argument taking each step in more depth. >> > >> The argument applies solely to drop, not ECN marking. >> > >>>>> >> > >>>>> A queue drops packets for either of two reasons: a) to signal to >> > >> host congestion controls that they should reduce the load and b) >> > >> because there is no buffer left to store the packets. Active queue >> > >> management tries to use drops as a signal for hosts to slow down >> > (case >> > >> a) so that drop due to buffer exhaustion (case b) should not be >> > >> necessary. >> > >>>>> >> > >>>>> No-one expects AQM to ever be universally deployed in every >>queue >> > >> in the Internet; and, even if AQM were universal, it has to be able >> > to >> > >> cope with buffer exhaustion (by switching to a behaviour like tail- >> > >> drop), in order to cope with unresponsive or excessive transports. >> > >> Therefore networks will often be dropping packets as a last resort >> > >> (case b) rather than under AQM control (case a). >> > >>>>> >> > >>>>> When buffers are exhausted (case b), they don't naturally drop >> > >> packets in proportion to their size. The network can only reduce >>the >> > >> probability of dropping smaller packets if it has enough space to >> > > store >> > >> them somewhere while it waits for a larger packet that it can drop. >> > If >> > >> the buffer is exhausted, it does not have this choice. Admittedly >> > > tail- >> > >> drop does naturally drop somewhat fewer small packets, but exactly >> > how >> > >> few depends more on the mix of sizes than the size of the packet in >> > >> question. Nonetheless, in general, if we wanted networks to do >>size- >> > >> dependent drop, we would need universal deployment of (packet-size >> > >> dependent) AQM code, which is unrealistic. >> > >>>>> >> > >>>>> A host transport cannot know whether any particular drop was a >> > >> deliberate signal from an AQM or a sign of a queue shedding packets >> > > due >> > >> to buffer exhaustion. Therefore, because the network cannot >> > > universally >> > >> do size-dependent drop, it should not do it all. >> > >>>>> >> > >>>>> Whereas universality is desirable in the network, diversity is >> > >> desirable between different transport layer protocols - some, like >> > >> NewReno TCP [RFC5681], may not choose to make their rate response >> > >> proportionate to the size of each dropped packet, while others will >> > >> (e.g. TFRC-SP [RFC4828]). >> > >>>>> >> > >> >> > > >> > >>======================================================================= >> > >> =============== >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> Bob >> > >>>>> >> > >>>>> At 13:13 04/10/2012, gorry@erg.abdn.ac.uk wrote: >> > >>>>>> That would be brilliant! >> > >>>>>> >> > >>>>>> Gorry >> > >>>>>> >> > >>>>>>> Will try to look at this later today. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> Bob >> > >>>>>>> >> > >>>>>>> At 10:42 02/10/2012, philip.eardley@bt.com wrote: >> > >>>>>>>> Think the token is with bob >> > >>>>>>>> >> > >>>>>>>> Re your comment - yes, I think you could move 3.4 to the end >> > > of >> > >> S3 - >> > >>>>>>>> or to the start - and do some re-phrasing, maybe something >> > > like >> > >> I tried. >> > >>>>>>>> >> > >>>>>>>> -----Original Message----- >> > >>>>>>>> From: Manner Jukka [mailto:jukka.manner@aalto.fi] >> > >>>>>>>> Sent: 01 October 2012 20:18 >> > >>>>>>>> To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,Bob,DUB8 R >> > >>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst >> > >>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for >> > >>>>>>>> draft-ietf-tsvwg-byte-pkt-congest >> > >>>>>>>> >> > >>>>>>>> Phil, Bob, can we close this finally? It's three weeks now >> > >> since >> > >>>>>>>> this previous message. >> > >>>>>>>> >> > >>>>>>>> Jukka >> > >>>>>>>> >> > >>>>>>>> On Sep 10, 2012, at 4:42 PM, Jukka Manner wrote: >> > >>>>>>>> >> > >>>>>>>>> Ack, I'm getting there...;) >> > >>>>>>>>> >> > >>>>>>>>> So, we could move 3.4 at the end of Section 3 and rephrase >> > >> it to >> > >>>>>>>> not talk about scaling per se, but rather about how Req 2.2 >> > >>>>>>>> eventually leads to Req 2.3? >> > >>>>>>>>> >> > >>>>>>>>> Jukka >> > >>>>>>>>> >> > >>>>>>>>> On Sep 7, 2012, at 4:07 PM, >> > >>>>>>>>> wrote: >> > >>>>>>>>> >> > >>>>>>>>>> 3.4 is, in my mind, completely different from 3.1, 3.2, >> > > 3.3 >> > >> and 3.5. >> > >>>>>>>>>> >> > >>>>>>>>>> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for >> > >> Recommendation >> > >>>>>>>>>> 2.2 & a lesser extent 2.3 >> > >>>>>>>>>> 3.4 makes doesn't make a motivating argument - it explains >> > >> that Rec >> > >>>>>>>>>> 2.2 & 2.3 come as a pair (if you recommend one, then >> > >> inevitably you >> > >>>>>>>>>> recommend the other) (delta some politeness about TCP) >> > >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> -----Original Message----- >> > >>>>>>>>>> From: Manner Jukka [mailto:jukka.manner@aalto.fi] >> > >>>>>>>>>> Sent: 07 September 2012 13:24 >> > >>>>>>>>>> To: Eardley,PL,Philip,DUB8 R >> > >>>>>>>>>> Cc: Briscoe,RJ,Bob,DUB8 R; ; >> > >>>>>>>>>> >> > >>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for >> > >>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest >> > >>>>>>>>>> >> > >>>>>>>>>> Hi, I'm trying to follow your reasoning, with little luck. >> > >> ;) >> > >>>>>>>>>> >> > >>>>>>>>>> After having read Section 3 again, I could think of a few >> > >>>>>>>> updates, but I'm not fully following what you want to see: >> > >>>>>>>>>> >> > >>>>>>>>>> - S3.5 is kind of small and lonely by itself. It could be >> > >> either >> > >>>>>>>> longer or merged somewhere. Not a major issue though and >> > > could >> > >> remain as >> > >>>>>>>> is. >> > >>>>>>>>>> >> > >>>>>>>>>> - S3.3: Yes, probably could be turned upside down, good >> > >> first, >> > >>>>>>>> bad later. Don't have a strong opinion. >> > >>>>>>>>>> >> > >>>>>>>>>> - S3.4: Here the scaling is used many times and in the >> > >> title, >> > >>>>>>>> although we talk about the end host side. This could be >> > >> rephrased >> > >>>>>>>> and slightly reworded to talk about hosts and their operation >> > >>>>>>>> altogether. Also the word scaling can turn the readers >> > >> expectation >> > >>>>>>>> into the wrong direction. >> > >>>>>>>>>> >> > >>>>>>>>>> - S3 altogether: It would help to have introductory text >> > >> about >> > >>>>>>>> networks vs. end host side, but I fail to see why (& how) to >> > >>>>>>>> restructure everything. >> > >>>>>>>>>> >> > >>>>>>>>>> cheers, >> > >>>>>>>>>> Jukka >> > >>>>>>>>>> >> > >>>>>>>>>> On Sep 6, 2012, at 6:18 PM, >> > >>>>>>>> wrote: >> > >>>>>>>>>> >> > >>>>>>>>>>> Ps otherwise Bob's comments are fine, though I suggest >> > > for >> > >> S3.5 you >> > >>>>>>>>>>> give more context (ie are you knocking down what you >> > >> recommend >> > >>>>>>>>>>> against, or building up what you recommend?) and in S3.3 >> > >> think >> > >>>>>>>>>>> would be better if you re-structured slightly [first talk >> > >> about what >> > >>>>>>>>>>> you like - penult para + 1st sentence of last para - then >> > >> talk about >> > >>>>>>>>>>> what you don't like - rest of text] >> > >>>>>>>>>>> >> > >>>>>>>>>>> From: Eardley,PL,Philip,DUB8 R >> > >>>>>>>>>>> Sent: 06 September 2012 16:12 >> > >>>>>>>>>>> To: Briscoe,RJ,Bob,DUB8 R; Manner Jukka >> > >>>>>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst >> > >>>>>>>>>>> Subject: RE: [REVISED I-D]: Document writeup for >> > >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest >> > >>>>>>>>>>> >> > >>>>>>>>>>> Thanks bob. Have now re-booted some state. >> > >>>>>>>>>>> I don't like S3.4. My basic problem with it is that it >> > >> isn't a >> > >>>>>>>> "motivating argument" (S3 title). It's an explanation about >> > >> the >> > >>>>>>>> consequences of assuming either [option 1] do pkt-size >> > > biasing >> > >> in >> > >>>>>>>> the transport; [option 2]; do pkt-size biasing in the nw. >> > >>>>>>>>>>> Perhaps your effort to buy peace with those who won't >> > >> change >> > >>>>>>>> TCP has obfuscated the basic point? >> > >>>>>>>>>>> The title of S3.4 (Scaling...) and the early text >> > > "scaling >> > >>>>>>>> argument" suggests that you're going to argue there is some >> > >> reason >> > >>>>>>>> why X scales as order N rather than N^2 or something like >> > > that >> > >> - >> > >>>>>>>> which isn't what S3.4 is about. >> > >>>>>>>>>>> >> > >>>>>>>>>>> I actually think it would be better to put S3.4 at the >> > >> start of >> > >>>>>>>> S3 - it's background where you say there are 2 options. After >> > >> that, >> > >>>>>>>> you can explain the reasons why option 1 [pkt biasing in the >> > >>>>>>>> transport] is better - the reasons being:- S3.1 (security >> > > etc >> > >>>>>>>> attacks if small pkts get preferential treatment), S3.2 >> > >> (really a >> > >>>>>>>> side note to S3.1; ie doesn't really present a "motivating >> > >>>>>>>> argument"), S3.3 (nw guessing MTU vs transport knowing pkt >> > >> size), >> > >>>>>>>> S3.5 (easier implementation). >> > >>>>>>>>>>> >> > >>>>>>>>>>> Something like... >> > >>>>>>>>>>> The behaviour of the network and transport together needs >> > >> to >> > >>>>>>>>>>> alleviate congestion. We assume the network is bit- >> > >> congestible >> > >>>>>>>> (currently packet-congestible resources are rate). Therefore >> > >>>>>>>> overall the response of the {network + transport} should be >> > >> the >> > >>>>>>>> same for the same congestion - whether the congestion is >> > >> caused by >> > >>>>>>>> a lot of small packets or a smaller number of larger packets. >> > >> The >> > >>>>>>>> implication is that the transport's behaviour should depend >> > > on >> > >>>>>>>> whether the network takes account (or not) of packet size >> > > when >> > >> it >> > >>>>>>>> generates congestion indications:- Case 1: If the network >> > >>>>>>>> implements packet-mode drop, ie its algorithm treats all >> > >> packets >> > >>>>>>>> equally regardless of their size, then the transport should >> > >> take >> > >>>>>>>> account of the size of the packet - in other words, the >> > >> transport's >> > >>>>>>>> congestion response should depend on the number of dropped >> > >> bytes. >> > >>>>>>>>>>> Case 2: If the network implements byte-mode drop, ie its >> > >>>>>>>> algorithm treats packets differently depending on their size, >> > >> then >> > >>>>>>>> the transport should not take account of the size of the >> > >> packet - >> > >>>>>>>> in other words, the transport's congestion response should >> > >> depend >> > >>>>>>>> on the number of dropped packets. >> > >>>>>>>>>>> >> > >>>>>>>>>>> These cases are explained in more detail in sub-section >> > >> below. >> > >>>>>>>>>>> >> > >>>>>>>>>>> In both cases the same discussion applies if packets are >> > >>>>>>>> ECN-marked rather than dropped. >> > >>>>>>>>>>> In the following sections we explain why Case 1 is >> > >> preferable, >> > >>>>>>>> and hence why we make the Recommendations of S2.2 and S3.3 >> > >>>>>>>> (respectively, drop/mark pkts equally regardless of their >> > >> size, and >> > >>>>>>>> the strength of the transport's response should be >> > >> proportionate to >> > >>>>>>>> the size of the dropped/marked pkt). >> > >>>>>>>>>>> Note that TCP responds to dropped or marked packets, >> > > which >> > >> differs >> > >>>>>>>>>>> from our recommendation for transports. However, we are >> > >> not >> > >>>>>>>>>>> recommending that TCP should be changed; to date it >> > >> hasn't been a >> > >>>>>>>>>>> significant problem because most TCP implementations >> > > have >> > >> been >> > >>>>>>>> used with similar packet sizes. But we do recommend that >> > >> future >> > >>>>>>>> transport protocols should respond to dropped or marked >> > > bytes >> > >> (as >> > >>>>>>>> for example TFRC-SP [RFC4828]effectively does). >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> Sub-section >> > >>>>>>>>>>> You could use much of S3.3, I suggest supplement with >> > >> numerical >> > >>>>>>>>>>> examples continuing S1.2 >> > >>>>>>>>>>> -- >> > >>>>>>>>>>> << This gives a get-out clause to any transport that >> > > isn't >> > >>>>>>>>>>> packet-size dependent (e.g. current TCP). Lacking packet- >> > >> size >> > >>>>>>>>>>> dependence just means they don't scale correctly with >> > >> packet size - >> > >>>>>>>>>>> but they are at liberty not to scale with packet size >> > >> (particularly >> > >>>>>>>>>>> given MTU growth isn't often being used to increase link >> > >> rates at >> > >>>>>>>>>>> this stage in history).>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> This is introducing a different point. it's saying that >> > >> your >> > >>>>>>>> recommendation 2 [drop/mark pkts equally regardless of their >> > >> size] >> > >>>>>>>> is a really strong reco whilst recommendation 3 [strength of >> > >>>>>>>> transport's response proportionate to the size of the >> > >>>>>>>> dropped/marked pkt] is a much less important reco. I can see >> > >> this >> > >>>>>>>> might be true, but I don't think the i-d talks about this. >> > >>>>>>>>>>> >> > >>>>>>>>>>> -- >> > >>>>>>>>>>> >> > >>>>>>>>>>> From: Briscoe,RJ,Bob,DUB8 R >> > >>>>>>>>>>> Sent: 05 September 2012 16:41 >> > >>>>>>>>>>> To: Manner Jukka >> > >>>>>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst; >> > >> Eardley,PL,Philip,DUB8 R >> > >>>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for >> > >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest >> > >>>>>>>>>>> >> > >>>>>>>>>>> Jukka, >> > >>>>>>>>>>> >> > >>>>>>>>>>> I've repeated Phil's suggestions as quoted email then >> > > made >> > >> some >> > >>>>>>>> alterations. >> > >>>>>>>>>>> >> > >>>>>>>>>>> Phil asked me to send this, then he will think about it. >> > >>>>>>>>>>> >> > >>>>>>>>>>> I'll respond about John Leslie's argument next... >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> 2.2. Recommendation on Encoding Congestion Notification >> > >>>>>>>>>>> >> > >>>>>>>>>>> [...] >> > >>>>>>>>>>> >> > >>>>>>>>>>> 1. AQM algorithms such as RED SHOULD use packet-mode >> > >> drop, ie they >> > >>>>>>>>>>> SHOULD NOT use byte-mode drop. The latter is more >> > >> complex, >> > >>>>>>>>>>> it creates the perverse incentive to fragment >> > >> segments into >> > >>>>>>>> tiny >> > >>>>>>>>>>> pieces and it is vulnerable to floods of small >> > >> packets. >> > >>>>>>>>>>> >> > >>>>>>>>>>> 2. If a vendor has implemented byte-mode drop, and an >> > >> operator has >> > >>>>>>>>>>> turned it on, it is RECOMMENDED to turn it off, >> > > after >> > >>>>>>>> establishing >> > >>>>>>>>>>> if there are any implications on the relative >> > >> performance of >> > >>>>>>>>>>> applications using different packet sizes. >> > >>>>>>>>>>> >> > >>>>>>>>>>> RED as a whole SHOULD NOT be turned off. Without >> > > RED, >> > >> a drop >> > >>>>>>>> tail >> > >>>>>>>>>>> queue biases against large packets >> > >>>>>>>>>>> >> > >>>>>>>>>>> [BB adds]: and it is >> > >> vulnerable to >> > >>>>>>>> floods >> > >>>>>>>>>>> of small-packets. >> > >>>>>>>>>>> >> > >>>>>>>>>>> (I suggest the last para just qualifies item 2. It >> > > doesn't >> > >> warrant >> > >>>>>>>>>>> another item number.) >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> [PE:] S3.3 >> > >>>>>>>>>>> The section could be slightly clearer. Starting with the >> > >> second >> > >>>>>>>> para, where you start talking about something you don't >> > >> recommend >> > >>>>>>>> (ie you have to remember that you're talking about the >> > >> consequences >> > >>>>>>>> of not following your recommendation). >> > >>>>>>>>>>> >> > >>>>>>>>>>> 3.3 Transport-Independent Network >> > >>>>>>>>>>> >> > >>>>>>>>>>> TCP congestion control ensures that flows competing for >> > >> the same >> > >>>>>>>>>>> resource each maintain the same number of segments in >> > >> flight, >> > >>>>>>>>>>> irrespective of segment size. So under similar >> > >> conditions, flows >> > >>>>>>>>>>> with different segment sizes will get different >> > > bit-rates. >> > >>>>>>>>>>> >> > >>>>>>>>>>> [OLD:] >> > >>>>>>>>>>> One motivation for the network biasing congestion >> > >> notification by >> > >>>>>>>>>>> packet size is to counter this effect and try to equalise >> > >> the bit- >> > >>>>>>>>>>> rates of flows with different packet sizes. >> > >>>>>>>>>>> [SUGGESTED:] >> > >>>>>>>>>>> To counter this effect it seems tempting not to follow >> > >> our >> > >>>>>>>>>>> recommendation, and instead for the network to bias >> > >> congestion >> > >>>>>>>>>>> notification by packet size in order to equalise the >> > > bit- >> > >> rates of >> > >>>>>>>>>>> flows with different packet sizes. >> > >>>>>>>>>>> [CONTINUE AS BEFORE:] >> > >>>>>>>>>>> However, in order to do this, the queuing >> > >> algorithm >> > >>>>>>>>>>> has to make assumptions about the transport, which >> > > become >> > >> embedded >> > >>>>>>>>>>> in the network. Specifically: >> > >>>>>>>>>>> [...] >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> S3.3 >> > >>>>>>>>>>> o The queuing algorithm has to assume how aggressively >> > >> the >> > >>>>>>>> transport >> > >>>>>>>>>>> will respond to congestion (see Section 4.2.4). If >> > >> the network >> > >>>>>>>>>>> assumes the transport responds as aggressively as TCP >> > >> NewReno, >> > >>>>>>>> it >> > >>>>>>>>>>> will be wrong for Compound TCP and differently wrong >> > >> for Cubic >> > >>>>>>>>>>> TCP, etc. To achieve equal bit-rates, each transport >> > >> then has >> > >>>>>>>> to >> > >>>>>>>>>>> guess what assumption the network made, and work out >> > >> how to >> > >>>>>>>>>>> replace this assumed aggressiveness with its own >> > >> aggressiveness. >> > >>>>>>>>>>> o Also, if the network biases congestion notification >> > > by >> > >> packet >> > >>>>>>>> size >> > >>>>>>>>>>> it has to assume a baseline packet size--all proposed >> > >> algorithms >> > >>>>>>>>>>> use the local MTU. Then transports have to guess >> > >> which link was >> > >>>>>>>>>>> congested and what its local MTU was, in order to >> > > know >> > >> how to >> > >>>>>>>>>>> tailor their congestion response to that link. >> > >>>>>>>>>>> >> > >>>>>>>>>>> So you're saying that for byte-mode drop, the network >> > >> element >> > >>>>>>>> has to compare the size of the current pkt with the MTU, and >> > >> if >> > >>>>>>>> it's 25* smaller then reduce the pkt loss probably by 25*? >> > > And >> > >> if >> > >>>>>>>> the MTU was bigger, then the current pkt would be dropped >> > > with >> > >>>>>>>> greater probability? And both of these things are hard to do. >> > >>>>>>>>>>> >> > >>>>>>>>>>> [BB]: SUGGESTED REPLACEMENT to 2nd bullet: >> > >>>>>>>>>>> >> > >>>>>>>>>>> o Also, if the network biases congestion notification >> > > by >> > >> packet >> > >>>>>>>> size >> > >>>>>>>>>>> it has to assume a baseline packet size--all proposed >> > >> algorithms >> > >>>>>>>>>>> use the local MTU (for example see the byte-mode loss >> > >>>>>>>> probability >> > >>>>>>>>>>> formula in Table 1). Then if the non-Reno transports >> > >> mentioned >> > >>>>>>>> above >> > >>>>>>>>>>> are trying to reverse engineer what the network >> > >> assumed, they >> > >>>>>>>> also >> > >>>>>>>>>>> have to guess the MTU of the congested link. >> > >>>>>>>>>>> >> > >>>>>>>>>>> [Aside for Phil: The byte-mode algo uses MTU as its >> > >> baseline because >> > >>>>>>>>>>> a link cannot send a packet bigger than its MTU so the >> > >> algo won't >> > >>>>>>>>>>> ever give a drop probability >1).] >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> S3.4 (& knock-on effect on 3.3) >> > >>>>>>>>>>> I think this could be better. >> > >>>>>>>>>>> I agree with your arguments in S3.1 & 3.2 that dropping >> > > or >> > >>>>>>>> marking should be independent of pkt size. >> > >>>>>>>>>>> You now go into a couple of pages, which I think could be >> > >> boiled >> > >>>>>>>>>>> down to a paragraph, saying something like:- >> > >>>>>>>>>>> * the overall system (network + transport) has to be >> > >> packet-size >> > >>>>>>>>>>> dependent in order to drive out the right amount of >> > >> traffic so the >> > >>>>>>>>>>> resource becomes uncongested (since we assume all >> > >> resources are in >> > >>>>>>>>>>> practice byte rather than packet limited) >> > >>>>>>>>>>> * from S3.1 and S3.2 the IETF is convinced that the >> > >> network >> > >>>>>>>> should notify independent of packet-size. >> > >>>>>>>>>>> * therefore the transport must act dependent on packet- >> > >> size. >> > >>>>>>>>>>> >> > >>>>>>>>>>> It seems to me this is a necessary consequence of your >> > >> earlier >> > >>>>>>>> assumptions /arguments. >> > >>>>>>>>>>> >> > >>>>>>>>>>> [BB:] This isn't at all obvious. Until I worked it >> > >> through, it >> > >>>>>>>> wasn't obvious to me. I think it needs to be spelled out. >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> [On the other hand, if someone disagrees with the >> > >> arguments and >> > >>>>>>>>>>> thinks that the network should notify dependent on >> > > packet- >> > >> size, then >> > >>>>>>>>>>> it follows that the transport can act independent of >> > >> packet-size.] >> > >>>>>>>>>>> >> > >>>>>>>>>>> I think in S3.3 you're trying to make another argument >> > >> (?):- >> > >>>>>>>>>>> * we can either do packet-size biasing in the network >> > >> element or on >> > >>>>>>>>>>> the end host transport (see argument above) >> > >>>>>>>>>>> * packet-size biasing in the network is quite tricky, >> > >> because >> > >>>>>>>> then both the network element & the transport have to make >> > >> some >> > >>>>>>>> guesses about MTU - whereas with packet-size biasing in the >> > >>>>>>>> transport, neither network element nor transport needs to >> > > know >> > >> what the >> > >>>>>>>> MTU is. >> > >>>>>>>>>>> * it is also easier to implement packet-size biasing in >> > >> the >> > >>>>>>>> transport than in the network. >> > >>>>>>>>>>> >> > >>>>>>>>>>> [BB] ...and all the other arguments about vulnerability >> > > to >> > >>>>>>>> flooding etc, transport-independence etc. >> > >>>>>>>>>>> >> > >>>>>>>>>>> Our argument is sort of like how Phil summarises it, but >> > >> with >> > >>>>>>>> an added nuance. It's also saying no-one has to do >> > > packet-size >> > >>>>>>>> biasing anyway. It's not saying "The transport should given >> > >> the >> > >>>>>>>> network shouldn't". It's saying "*If the transport wants to >> > >> claim >> > >>>>>>>> to be scalable wrt packet size* it should if the network >> > >> shouldn't". >> > >>>>>>>>>>> >> > >>>>>>>>>>> This gives a get-out clause to any transport that isn't >> > >>>>>>>> packet-size dependent (e.g. current TCP). Lacking packet-size >> > >>>>>>>> dependence just means they don't scale correctly with packet >> > >> size - >> > >>>>>>>> but they are at liberty not to scale with packet size >> > >> (particularly >> > >>>>>>>> given MTU growth isn't often being used to increase link >> > > rates >> > >> at >> > >>>>>>>> this stage in history). >> > >>>>>>>>>>> >> > >>>>>>>>>>> None of what Phil says convinces me we could say 3.4 (or >> > >> 3.3) >> > >>>>>>>> any more briefly or differently. It's easier to summarise >> > > what >> > >> you >> > >>>>>>>> understand having read something. But that's not the same as >> > >>>>>>>> writing the thing that helped you understand. There doesn't >> > >> seem to >> > >>>>>>>> be any argument for why anything needs to be changed, so I'm >> > >> going >> > >>>>>>>> to leave it as is, unless pushed. >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> On the last bullet, I didn't really follow your argument >> > >> in >> > >>>>>>>> S3.5. Might be easier to follow if S3.5 also talked about how >> > >> a >> > >>>>>>>> network element would take account of pkt size? >> > >>>>>>>>>>> Also, does the following argument also apply?: >> > >>>>>>>>>>> * if pkt-size biasing is done in the transport, then the >> > >> work (to do >> > >>>>>>>>>>> the biasing) is spread over many end hosts, >> > >>>>>>>>>>> * whereas if pkt-size biasing is done in the network, >> > > then >> > >> the >> > >>>>>>>> work is concentrated in just the congested network element, >> > >> which >> > >>>>>>>> has to operate on all the traffic at line speed. >> > >>>>>>>>>>> >> > >>>>>>>>>>> [BB]: 3.5. Implementation Efficiency >> > >>>>>>>>>>> >> > >>>>>>>>>>> [ADD:] >> > >>>>>>>>>>> Biasing against large packets typically requires an >> > > extra >> > >> multiply >> > >>>>>>>>>>> and divide in the network (see the example byte-mode >> > > drop >> > >>>>>>>> formula in table 1). >> > >>>>>>>>>>> [CONTINUE AS BEFORE:] >> > >>>>>>>>>>> Allowing for packet size at the transport rather than in >> > >> the >> > >>>>>>>>>>> network ensures that neither the network nor the >> > >> transport needs to >> > >>>>>>>>>>> do a multiply operation--multiplication by packet size >> > > is >> > >>>>>>>>>>> effectively achieved as a repeated add when the >> > > transport >> > >> adds to >> > >>>>>>>>>>> its count of marked bytes as each congestion event is >> > > fed >> > >> to it. >> > >>>>>>>>>>> [ADD:] >> > >>>>>>>>>>> Also the work to do the biasing is spread over many >> > >> hosts, rather >> > >>>>>>>>>>> than concentrated in just the congested network element. >> > >>>>>>>>>>> [CONTINUE AS BEFORE:] >> > >>>>>>>>>>> >> > > These >> > >> aren't >> > >>>>>>>>>>> principled reasons in themselves, but they are a happy >> > >> consequence >> > >>>>>>>>>>> of the other principled reasons. >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> Bob >> > >>>>>>>>>>> >> > >>>>>>>>>>> At 13:36 05/09/2012, Manner Jukka wrote: >> > >>>>>>>>>>> >> > >>>>>>>>>>> Hi Bob, >> > >>>>>>>>>>> >> > >>>>>>>>>>> Since Phil is your colleague at BT, even at Ipswich (?), >> > >> can >> > >>>>>>>> you check those and agree with Phil how to go forward? Some >> > > of >> > >>>>>>>> those are clear, others need discussion with Phil. >> > >>>>>>>>>>> >> > >>>>>>>>>>> Gorry, on point 2) below, I don't follow Leslie's >> > >> arguments. I >> > >>>>>>>> asked from him detailed comments and resolutions months ago, >> > >> and nothing >> > >>>>>>>> came. >> > >>>>>>>>>>> >> > >>>>>>>>>>> cheers, >> > >>>>>>>>>>> Jukka >> > >>>>>>>>>>> >> > >>>>>>>>>>> On Sep 5, 2012, at 3:26 PM, Gorry Fairhurst wrote: >> > >>>>>>>>>>> >> > >>>>>>>>>>>> Bob and Jukka, >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> I think I need your help to resolve this... Some of the >> > >>>>>>>> comments raised by John Leslie appear to have substance, and >> > >> I'm >> > >>>>>>>> not sure what you plan to do to address these. >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> It would be good to do something quick so that I can >> > >> complete >> > >>>>>>>> the submission to the IESG. >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> The issues I particularly note are: >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> 1) This contribution from Phil appears to be within >> > > scope >> > >> and >> > >>>>>>>> it seems may have been overlooked (sorry): >> > >>>>>>>>>>>> http://www.ietf.org/mail- >> > >> archive/web/tsvwg/current/msg11234.html >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> 2) Can you be clear here about what is actually been >> > > said >> > >> - >> > >>>>>>>> because the point below seems to be a misunderstanding of >> > >> language >> > >>>>>>>> to me, and I hoped we did not claim this: >> > >>>>>>>>>>>> >> > >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find >> > > that >> > >> Bob is >> > >>>>>>>>>>>>>> actually ] saying that transport-layer should _only_ >> > >> consider >> > >>>>>>>>>>>>>> "congested bytes", not ] "congested packets". >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> 3) You'll need to post the updated draft and send a note >> > >> to >> > >>>>>>>> the group to confirm that the new version indeed concludes >> > > the >> > >>>>>>>> WGLC. I'll add a note to the writeup to indicate the draft >> > >> content >> > >>>>>>>> has been stable since Oct 2011. >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> Gorry (with my TSVWG Documnent Shepherd hat) >> > >>>>>>>>>>>> cc: Co-Chairs for info. >> > >>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > >>>>>>>>>>>>>> -----Original Message----- >> > >>>>>>>>>>>>>> From: Gorry Fairhurst [ mailto:gorry@erg.abdn.ac.uk] >> > >>>>>>>>>>>>>> Sent: Mittwoch, 15. August 2012 21:41 >> > >>>>>>>>>>>>>> To: tsvwg chair >> > >>>>>>>>>>>>>> Subject: Fwd: Re: [tsvwg] FYI: Document writeup for >> > >>>>>>>>>>>>>> draft-ietf-tsvwg- byte-pkt-congest >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Hi guys, >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Apart form the usual rhetoric, there are some points >> > >> here that we >> > >>>>>>>>>>>>>> should note as chairs. What are you own thoughts? And >> > >> was >> > >>>>>>>>>>>>>> anything noted at the IETF in Vancouver concerning >> > > this >> > >> draft? >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Gorry >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> -------- Original Message -------- >> > >>>>>>>>>>>>>> Subject: Re: [tsvwg] FYI: Document writeup for >> > >>>>>>>>>>>>>> draft-ietf-tsvwg-byte- pkt-congest >> > >>>>>>>>>>>>>> Date: Wed, 15 Aug 2012 15:07:28 -0400 >> > >>>>>>>>>>>>>> From: John Leslie >> > >>>>>>>>>>>>>> To: Gorry Fairhurst >> > >>>>>>>>>>>>>> CC: tsvwg@ietf.org >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Gorry Fairhurst wrote: >> > >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> The following document has been revised after >> > >> receiving >> > >>>>>>>> WGLC comments. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> The changes are mostly refreshing a document >> > >> scheduled to >> > >>>>>>>>>>>>>> expire this month. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> No issues were found: >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Is that with WGC-hat-on? >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Neither my issues nor Philip Eardley's comments were >> > >> addressed. >> > >>>>>>>>>>>>>> In fact, not even the changes Bob Briscoe mentioned >> > > on- >> > >> list have >> > >>>>>>>>>>>>>> been included. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> As required by RFC 4858, this is the current template >> > >> for the >> > >>>>>>>>>>>>>> Document >> > >>>>>>>>>>>>>>> Shepherd Write-Up. >> > >>>>>>>>>>>>>>> ... >> > >>>>>>>>>>>>>>> (1) What type of RFC is being requested (BCP, >> > > Proposed >> > >> Standard, >> > >>>>>>>>>>>>>>> Internet Standard, Informational, Experimental, or >> > >> Historic)? >> > >>>>>>>>>>>>>>> Why is this the proper type of RFC? Is this type of >> > >> RFC >> > >>>>>>>>>>>>>>> indicated in the title page header? >> > >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> This document is intended as BCP. (This was discussed >> > >> at IETF-81 >> > >>>>>>>>>>>>>>> and that the status changed from Informational to BCP >> > >> since it >> > >>>>>>>>>>>>>>> provides guidance to implementors and people >> > >> configuring >> > >>>>>>>> routers and hosts). >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Thank you for finally answering my question about >> > > BCP >> > >> status. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> ... >> > >>>>>>>>>>>>>>> Working Group Summary >> > >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> There was consensus to publish this as a WG document >> > >> and >> > >>>>>>>>>>>>>>> agreement at >> > >>>>>>>>>>>>>>> IETF-82 that the document was now complete. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Was that reviewed on-list? >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> ... >> > >>>>>>>>>>>>>>> (3) Briefly describe the review of this document that >> > >> was >> > >>>>>>>>>>>>>>> performed >> > >>>>>>>>>>>>>> by >> > >>>>>>>>>>>>>>> the Document Shepherd. If this version of the >> > > document >> > >> is not >> > >>>>>>>>>>>>>>> ready for publication, please explain why the >> > > document >> > >> is being >> > >>>>>>>>>>>>>>> forwarded to the IESG. >> > >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> The document was presented at IEWTF-82 (Taipei), with >> > >> a request >> > >>>>>>>>>>>>>>> for >> > >>>>>>>>>>>>>> WGLC. >> > >>>>>>>>>>>>>>> WGLC concluded with some discussion but no >> > > substantive >> > >> changes >> > >>>>>>>>>>>>>>> on Friday 30th March 2012. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Yes, I guess that is true; but ignoring substantive >> > >> comments >> > >>>>>>>>>>>>>> isn't a good practice IMHO. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> (4) Does the document Shepherd have any concerns >> > > about >> > >> the depth >> > >>>>>>>>>>>>>>> or breadth of the reviews that have been performed? >> > >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> No - the original draft had a lot of background >> > >> material, much >> > >>>>>>>>>>>>>>> of >> > >>>>>>>>>>>>>> this >> > >>>>>>>>>>>>>>> has been condensed or removed, resulting in a smaller >> > >> document. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> That is indeed what I basically asked for, but I >> > >> don't see any >> > >>>>>>>>>>>>>> evidence of it: >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> - diff(07,08) 48 lines changed or deleted; 53 lines >> > >> changed or >> > >>>>>>>> added >> > >>>>>>>>>>>>>> - diff(06,07) 8 lines changed or deleted; 13 lines >> > >> changed or >> > >>>>>>>> added >> > >>>>>>>>>>>>>> - diff(05,06) 64 lines changed or deleted; 69 lines >> > >> changed or >> > >>>>>>>>>>>>>> added >> > >>>>>>>>>>>>>> - diff(04,05) 823 lines changed or deleted; 864 lines >> > >> changed or >> > >>>>>>>>>>>>>> added >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> (Need I go farther? That gets us back to March >> > > 2011...) >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> (9) How solid is the WG consensus behind this >> > >> document? Does it >> > >>>>>>>>>>>>>>> represent the strong concurrence of a few >> > > individuals, >> > >> with >> > >>>>>>>>>>>>>>> others being silent, or does the WG as a whole >> > >> understand >> > >>>>>>>> and agree with it? >> > >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> The document has WG support and there is consensus to >> > >> publish. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> This, IMHO, doesn't answer the question. :^( >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Does it represent the concurrence of a few >> > >> individuals, or does >> > >>>>>>>>>>>>>> the WG as a whole understand and agree with it? >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> For reference, my comments included: >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] When I previously skimmed this document, I believed >> > >> it >> > >>>>>>>>>>>>>> contained only ] common ground: that AQM should >> > >> drop/mark packets >> > >>>>>>>>>>>>>> without favoring small ] packets, and that to whatever >> > >> extent >> > >>>>>>>>>>>>>> packet size _is_ considered, that ] should be a >> > >>>>>>>> transport-layer responsibility. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find >> > > that >> > >> Bob is >> > >>>>>>>>>>>>>> actually ] saying that transport-layer should _only_ >> > >> consider >> > >>>>>>>>>>>>>> "congested bytes", not ] "congested packets". >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] In fact, Bob openly endorses replacing TCP >> > >> congestion-control >> > >>>>>>>>>>>>>> with an ] algorithm which calculates "fair-share >> > > bytes" >> > >> and >> > >>>>>>>>>>>>>> doesn't back off at all ] (even in the presence of 20% >> > >> packet >> > >>>>>>>>>>>>>> loss) unless you're already sending ] more than this >> > >>>>>>>> "fair-share". >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] I do not believe that is the consensus of this >> > > WG; >> > >> and I >> > >>>>>>>> believe >> > >>>>>>>>>>>>>> if >> > >>>>>>>>>>>>>> ] that were the consensus it would exceed our charter. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] The draft contains a number of things I _do_ >> > > support; >> > >> and I'd >> > >>>>>>>>>>>>>> be happy ] to support a considerably shorter draft >> > >> which >> > >>>>>>>>>>>>>> concentrates on the AQM ] recommendation, omitting any >> > >>>>>>>>>>>>>> suggestions of modifying TCP congestion ] control. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> and Philip's comments included: >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] S2.2 I thought the numbered bullets could be better >> > >> phrased, >> > >>>>>>>>>>>>>> something like ] +this:- ] >> > >>>>>>>>>>>>>> ] 1. AQM algorithms such as RED SHOULD use packet- >> > >> mode >> > >>>>>>>> drop, ie they >> > >>>>>>>>>>>>>> SHOULD NOT >> > >>>>>>>>>>>>>> ] +use byte-mode drop. The latter ] is more complex, >> > >>>>>>>>>>>>>> ] it creates the perverse incentive to fragment >> > >> segments >> > >>>>>>>> into >> > >>>>>>>>>>>>>> tiny >> > >>>>>>>>>>>>>> ] pieces and it is vulnerable to floods of >> > >> small- >> > >>>>>>>>>>>>>> ] packets. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] 2. If a vendor has implemented byte-mode drop, >> > >> and an >> > >>>>>>>> operator >> > >>>>>>>>>>>>>> has >> > >>>>>>>>>>>>>> ] turned it on, it is RECOMMENDED to turn it >> > >> off, after >> > >>>>>>>>>>>>>> establishing if >> > >>>>>>>>>>>>>> ] +there are any implications on >> > >>>>>>>>>>>>>> ] the relative performance of >> > >>>>>>>>>>>>>> ] applications using different packet sizes. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] 3. RED SHOULD NOT be turned off. Without RED, a >> > >> drop tail >> > >>>>>>>>>>>>>> ] queue biases against large packets. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] Nit - the following paragraph shouldn't be indented >> > >> (Note well >> > >>>>>>>>>>>>>> that >> > >>>>>>>>>>>>>> RED's...) >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] S3.3 >> > >>>>>>>>>>>>>> ] The section could be slightly clearer. Starting with >> > >> the second >> > >>>>>>>>>>>>>> para, where you ] +start talking about something you >> > >> don't >> > >>>>>>>>>>>>>> recommend (ie you have to remember that ] +you're >> > >> talking about >> > >>>>>>>>>>>>>> the consequences of not following your >> > > recommendation). >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] S3.3 >> > >>>>>>>>>>>>>> ] o Also, if the network biases congestion >> > >> notification by >> > >>>>>>>> packet >> > >>>>>>>>>>>>>> size >> > >>>>>>>>>>>>>> ] it has to assume a baseline packet size--all >> > >> proposed >> > >>>>>>>>>>>>>> algorithms >> > >>>>>>>>>>>>>> ] use the local MTU. Then transports have to >> > >> guess which >> > >>>>>>>> link >> > >>>>>>>>>>>>>> was >> > >>>>>>>>>>>>>> ] congested and what its local MTU was, in order >> > >> to know >> > >>>>>>>> how to >> > >>>>>>>>>>>>>> ] tailor their congestion response to that link. >> > >>>>>>>>>>>>>> ] So you're saying that for byte-mode drop, the >> > > network >> > >> element >> > >>>>>>>>>>>>>> has to compare the ] +size of the current pkt with the >> > >> MTU, and >> > >>>>>>>>>>>>>> if it's 25* smaller then reduce the ] +pkt loss >> > >> probably by 25*? >> > >>>>>>>>>>>>>> And if the MTU was bigger, then the current pkt would >> > > ] >> > >> +be >> > >>>>>>>>>>>>>> dropped with greater probability? And both of these >> > >> things >> > >>>>>>>> are hard to do. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] S3.4 (& knock-on effect on 3.3) ] I think this could >> > >> be better. >> > >>>>>>>>>>>>>> ] I agree with your arguments in S3.1 & 3.2 that >> > >> dropping or >> > >>>>>>>>>>>>>> marking should be ] +independent of pkt size. >> > >>>>>>>>>>>>>> ] You now go into a couple of pages, which I think >> > >> could be >> > >>>>>>>>>>>>>> boiled down to a ] +paragraph, saying something like:- >> > >> ] * the >> > >>>>>>>>>>>>>> overall system (network + transport) has to be packet- >> > >> size >> > >>>>>>>>>>>>>> dependent in ] >> > >>>>>>>>>>>>>> +order to drive out the right amount of traffic so the >> > >> resource >> > >>>>>>>>>>>>>> becomes ] >> > >>>>>>>>>>>>>> +uncongested (since we assume all resources are in >> > >> practice byte >> > >>>>>>>>>>>>>> +rather >> > >>>>>>>>>>>>>> than ] +packet limited) ] * from S3.1 and S3.2 the >> > > IETF >> > >> is >> > >>>>>>>>>>>>>> convinced that the network should notify ] >> > > +independent >> > >> of >> > >>>>>>>> packet-size. >> > >>>>>>>>>>>>>> ] * therefore the transport must act dependent on >> > >> packet-size. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] It seems to me this is a necessary consequence of >> > >> your earlier >> > >>>>>>>>>>>>>> assumptions ] +/arguments. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] [On the other hand, if someone disagrees with the >> > >> arguments and >> > >>>>>>>>>>>>>> thinks that the ] +network should notify dependent on >> > >>>>>>>>>>>>>> packet-size, then it follows that the ] +transport can >> > >> act >> > >>>>>>>>>>>>>> independent of >> > >>>>>>>>>>>>>> packet- size.] ] ] I think in S3.3 you're trying to >> > >> make another >> > >>>>>>>>>>>>>> argument (?):- ] * we can either do packet-size >> > >> biasing in the >> > >>>>>>>>>>>>>> network element or on the end host ] +transport (see >> > >> argument >> > >>>>>>>>>>>>>> above) ] * packet-size biasing in the network is quite >> > >> tricky, >> > >>>>>>>>>>>>>> because then both the ] +network element & the >> > >> transport have to >> > >>>>>>>>>>>>>> make some guesses about MTU - whereas ] >> > >>>>>>>>>>>>>> +with packet-size biasing in the transport, neither >> > >> network >> > >>>>>>>>>>>>>> +element >> > >>>>>>>>>>>>>> nor ] +transport needs to know what the MTU is. >> > >>>>>>>>>>>>>> ] * it is also easier to implement packet-size biasing >> > >> in the >> > >>>>>>>>>>>>>> transport than in ] +the network. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] On the last bullet, I didn't really follow your >> > >> argument in >> > >>>>>>>> S3.5. >> > >>>>>>>>>>>>>> Might be ] +easier to follow if S3.5 also talked about >> > >> how a >> > >>>>>>>>>>>>>> network element would take ] +account of pkt size? >> > >> Also, does the >> > >>>>>>>>>>>>>> following argument also apply?: >> > >>>>>>>>>>>>>> ] * if pkt-size biasing is done in the transport, then >> > >> the work >> > >>>>>>>>>>>>>> (to do the ] +biasing) is spread over many end hosts, >> > > ] >> > >> * whereas >> > >>>>>>>>>>>>>> if pkt-size biasing is done in the network, then the >> > >> work is ] >> > >>>>>>>>>>>>>> +concentrated in just the congested network element, >> > >> which has to >> > >>>>>>>>>>>>>> operate on all ] +the traffic at line speed. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> (Has there perhaps been some confusion about what >> > >> went into the >> > >>>>>>>>>>>>>> -08 >> > >>>>>>>>>>>>>> version?) >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> -- >> > >>>>>>>>>>>>>> John Leslie >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > >>>>>>>>>>>> >> > >>>>>>>>>>> >> > >> ________________________________________________________________ >> > >>>>>>>>>>> Bob Briscoe, BT Innovate & >> > >> Design >> > >>>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >> ________________________________________________________________ >> > >>>>>>> Bob Briscoe, BT Innovate & >> > >> Design >> > >>>>>>> >> > >>>>> >> > >>>>> ________________________________________________________________ >> > >>>>> Bob Briscoe, BT Innovate & Design >> > >>> >> > >>> ________________________________________________________________ >> > >>> Bob Briscoe, BT Innovate & Design >> > > > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design From internet-drafts@ietf.org Thu Oct 11 12:46:03 2012 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 68FC021F8551; Thu, 11 Oct 2012 12:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFcGPkz8qm2m; Thu, 11 Oct 2012 12:46:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD24C21F84D8; Thu, 11 Oct 2012 12:46:02 -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.34 Message-ID: <20121011194602.11308.44689.idtracker@ietfa.amsl.com> Date: Thu, 11 Oct 2012 12:46:02 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-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: Thu, 11 Oct 2012 19:46:03 -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 : Generic Aggregation of Resource ReSerVation Protocol (RS= VP) for IPv4 And IPv6 Reservations over PCN domains Author(s) : Georgios Karagiannis Anurag Bhargava Filename : draft-ietf-tsvwg-rsvp-pcn-03.txt Pages : 25 Date : 2012-10-11 Abstract: This document specifies the extensions to the Generic Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-pcn-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp-pcn-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From karagian@cs.utwente.nl Thu Oct 11 12:55:36 2012 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 879D71F0C3E; Thu, 11 Oct 2012 12:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPEw5RjJbsIL; Thu, 11 Oct 2012 12:55:35 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4D11F0429; Thu, 11 Oct 2012 12:55:34 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 11 Oct 2012 21:55:42 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.4]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Thu, 11 Oct 2012 21:55:33 +0200 From: To: , Thread-Topic: New Version Notification - draft-ietf-tsvwg-rsvp-pcn-03.txt Thread-Index: AQHNp+kXa8WbO4olbk+2c2aLWFA/mpe0gv86 Date: Thu, 11 Oct 2012 19:55:33 +0000 Message-ID: References: <20121011194603.11308.61516.idtracker@ietfa.amsl.com> In-Reply-To: <20121011194603.11308.61516.idtracker@ietfa.amsl.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.60.223.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tsvwg] FW: New Version Notification - draft-ietf-tsvwg-rsvp-pcn-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: Thu, 11 Oct 2012 19:55:36 -0000 Hi all, Please note that draft-ietf-tsvwg-rsvp-pcn-03.txt has just been submitted! All comments received during the tsvwg meeting in Vancouver and during the = tsvwg and pcn mailing lists have been worked out! If you have any other comments please send them to the tsvwg mailing list! Best regards, Georgios ________________________________________ Van: internet-drafts@ietf.org [internet-drafts@ietf.org] Verzonden: donderdag 11 oktober 2012 21:46 Aan: tsvwg-chairs@tools.ietf.org; draft-ietf-tsvwg-rsvp-pcn@tools.ietf.org;= martin.stiemerling@neclab.eu Onderwerp: New Version Notification - draft-ietf-tsvwg-rsvp-pcn-03.txt A new version (-03) has been submitted for draft-ietf-tsvwg-rsvp-pcn: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-pcn-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp-pcn-03 IETF Secretariat.= From andrewmcgr@gmail.com Thu Oct 11 15:24:48 2012 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 4506121F8551; Thu, 11 Oct 2012 15:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oc27BI2LDrq; Thu, 11 Oct 2012 15:24:45 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE3421F8532; Thu, 11 Oct 2012 15:24:45 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so2303323pbb.31 for ; Thu, 11 Oct 2012 15:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=+GzoWQBcK9+OsC1tXUgs7CJUUXtqgCBxNdbJfJ4D4Ps=; b=Fqe+HlnJBNe3wlSlUmQf8b6tZ0m3sb/uuUz+TOrhy8y+pMKPv2LNcmN+RlQ510YyiD CaJMZSqppeauC66M6pipcuR/7IRDhUK99v6XaBFmMuaFKQuOcYZIV6lSajAGZcPcIIQc sk8KVfgeS4OM7t0G+0Lq7gmjX5XafqJ8CknszluowoWaDpeQzPzBULCBEIF+IXQ//xnw zJUzwbPYoVp9cmVGVZZ46xrux7y/ZhzDlIWG0HybRFW6EtTVRZ60o/6rqwPfUXH8v5rw MbGulW8OogOV9YaeP0FNIEN7maFkdjzummhDoExjAc6xapWiq2iu9gscCM/409PrtnK6 Kq9g== Received: by 10.66.72.35 with SMTP id a3mr5848779pav.66.1349994284779; Thu, 11 Oct 2012 15:24:44 -0700 (PDT) Received: from ?IPv6:2406:e000:62e9:1:7171:d37a:589b:90b6? ([2406:e000:62e9:1:7171:d37a:589b:90b6]) by mx.google.com with ESMTPS id qp2sm2968971pbc.29.2012.10.11.15.24.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Oct 2012 15:24:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Andrew McGregor In-Reply-To: <201210111655.q9BGt47l013369@bagheera.jungle.bt.co.uk> Date: Fri, 12 Oct 2012 11:24:33 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120815190728.GQ15012@verdi> <502BFB47.7010803@erg.abdn.ac.uk> <791AD3077F94194BB2BDD13565B6295D45A6212A@PALLENE.office.hd> <15181_1346848013_5047450C_15181_645_1_50474507.3090706@erg.abdn.ac.uk> <3A5279D338C75C40B4B3DA15BA47D6330B616BD2@EXMDB04.org.aalto.fi> <201209051541.q85FfCs0019699@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F33D793B351@EMV65-UKRD.domain1.systemhost.net> <3A5279D338C75C40B4B3DA15BA47D6330B69261A@EXMDB04.org.aalto.fi> <9510D26531EF184D9017DF24659BB87F33D793B845@EMV65-UKRD.domain1.systemhost.net> <04AC95B5-A2B1-4DD2-B765-E20A4C1A69A3@aalto.fi> <3A5279D338C75C40B4B3DA15BA47D6330B6E81E4@EXMDB04.org.aalto.fi> <9510D26531EF184D9017DF24659BB87F33DCE34251@EMV65-UKRD.domain1.systemhost.net> <201210041126.q94BQ0hx002951@bagheera.jungle.bt.co.uk> <1904eec816d080f886f5bf8685358ddc.squirrel@www.erg.abdn.ac.uk> <201210101525.q9AFP4Mi008013@bagheera.jungle.bt.co.uk> <3A5279D338C75C40B4B3DA15BA47D6330B6FC2BB@EXMDB04.org.aalto.fi> <2012101112 08.q9BC8BAU012! ! 305@bag he era.jungl e.b t.co.uk> <3A5279D338C75C40B4B3DA15BA47D6330B6FD072@EXMDB04.org.aalto.fi> <999913AB42CC9341B05A99BBF358718D01F360CF@FIESEXC035.nsn-intra.net> <3A5279D338C75C40B4B3DA15BA47D6330B6FD197@EXMDB04.org.aalto.fi> <999913AB42CC9341B05A99BBF358718D01F360F7@FIESEXC035.nsn-intra.net> <201210111655.q9BGt47l013369@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1498) Cc: gorry@erg.abdn.ac.uk, philip.eardley@bt.com, tsvwg IETF list , tsvwg-chairs@ietf.org Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest 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, 11 Oct 2012 22:24:48 -0000 On 12/10/2012, at 5:06 AM, Bob Briscoe wrote: > Hannes, >=20 > This doc is very general. The advice on AQM not biasing for small = packets applies equally to CoDel as to RED (it has already been applied = to PCN, which is another AQM). The doc gives specific advice for RED as = an exemplar, but it's not just about RED (it's worrying that you think = it is - which text gave this impression?). Everywhere that RED is = mentioned, the wording should carefully say it's an example. >=20 > Similarly, it gives guidelines on end-to-end transports, and uses TCP = as an concrete example. >=20 > [Changing the subject to "Who said CoDel is a panacea anyway?" CoDel = isn't really applicable on hi-speed links, certainly not if one wants = the main benefit of being insensitive to the chosen hard-coded = parameters. Even in the CoDel paper's simulations, CoDel gave higher = queuing delay than RED in all the cases shown except the lowest link = speed experiments. CoDel's 100ms target would be a crazy delay target in = a high speed network. To deploy CoDel in hi-speed networks, you have to = tune the parameters away from the hard-coded ones, which loses the only = benefit it has. > ] >=20 >=20 > Bob In discussing CoDel, it is important to realise that the 100ms interval = is not a delay target, nor is the 5ms. They're both measurement = intervals, and pretty much form bounds on how long the algorithm will = allow the queueing delay to spike above whatever value CoDel is going to = converge to on that link. Interval at 100ms was chosen such that CoDel = would still be able to converge even on the longest delay links likely = in the internet (it degrades somewhat gracefully with RTT between 5x = interval and 8x interval, but performs horribly if RTT is greater than = that). Convergence queueing delay depends on the link characteristics = somewhat, especially if it is an aggregating link or one that is = transmission opportunity limited rather than bit rate limited, but is = generally around the transmission time of a few packets, between two and = perhaps 30. Which is on most realistic links, much less than 100ms of = delay, and on most fast links much less than 5ms. We've seen the actual = delay be under 250 microseconds on 10GbE. However, my view is that CoDel itself is just an ingredient in a = solution. CoDel will pick victim packets from flows that are not = congesting the queue, and does nothing for RTT fairness. The two = fq_codel variants that are around are much closer to a solution, but = even they are strong hints not a completely general answer. The 'fq' in = the name is somewhat of a misnomer too, since neither is strictly = classical fair queueing. In an actual deployed situation, fq_codel (Eric Dumazet version in the = Linux kernel) is magic. The interactive feel of a network where the = bottleneck link is managed by fq_codel in both directions is vastly = superior, RTT fairness is vastly superior, VoIP and video conferencing = just work in conjunction with throughput-maximising traffic, and in = actual practice the problems of poor queue management are in fact fixed. I've deployed fq_codel into four different networks now, three homes = (one DSL, two cable) and one 120-odd person office (gigabit fiber = ethernet), and in every case there was an immediate and noticeable = improvement in web latency, VoIP and video call quality, and in the = residential environments game transports benefited spectacularly as = well. The office required a transparent filtering web proxy, and the = web browsing behaviour there is now totally dominated by the proxy's = decision latency. Even then, the latency is so much better than without = fq_codel, it was a very noticeable benefit. I'll not that the residential deployments I'm referring to do use the = trick of rate-limiting both directions to a fraction less than the = available bandwidth so as to gain control of the bottleneck queue. This = loses about 10% of the bandwidth, but you gain so much from fq_codel = that it is a very worthwhile tradeoff. Actual observed downloads = usually complete faster due to fewer stalls anyway. In every case, the improvement was dramatic enough to be observed by = non-technical users. In the office case the mostly very technical user = base were not told of the deployment in advance, but most users noticed = that something had changed immediately, just from the improvement in = browsing and VoIP experience. So, proof by example: It is possible to do much, much better with AQM. = A good AQM can spectacularly improve coexistence of very different = transports sharing a bottleneck link, and in particular can allow = throughput maximising and real-time traffic to share a link with very = little impact on each other (yes, the real-time jitter does degrade = slightly in the presence of other traffic, but this is well within the = bounds of acceptable even on a fairly slow DSL link). Andrew >=20 > At 13:57 11/10/2012, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Hi Jukka, >>=20 >> With QoS there is no such thing as "short term" (as we already had to >> learn painfully). >>=20 >> That makes me wonder what is more useful: publish a document that >> describe how to configure RED correctly or to go for an AQM technique >> that (according to the authors) works almost zero configuration. >>=20 >> My take-away from the Vancouver congestion control workshop was that = it >> is better to ignore RED. (Maybe my impression was wrong -- someone = else >> should confirm.) >>=20 >> Ciao >> Hannes >>=20 >>=20 >> > -----Original Message----- >> > From: ext Manner Jukka [mailto:jukka.manner@aalto.fi] >> > Sent: Thursday, October 11, 2012 3:50 PM >> > To: Tschofenig, Hannes (NSN - FI/Espoo) >> > Cc: Bob Briscoe; ; ; >> > ; tsvwg IETF list >> > Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for = draft-ietf- >> > tsvwg-byte-pkt-congest >> > >> > Hi, this document talks about the current and short term goals and >> > operations, while AFAIK CoDel is a more futuristic concept, >> interesting >> > concept, sure, but not deployed at large. >> > >> > cheers, >> > Jukka >> > >> > On Oct 11, 2012, at 3:44 PM, Tschofenig, Hannes (NSN - FI/Espoo) >> wrote: >> > >> > > Hi Jukka, Hi Bob, >> > > >> > > having listened to the presentations about CoDel I am wondering >> > whether >> > > this document may have taken over by events and is obsolete by = now. >> > > What's your view on that? >> > > >> > > Ciao >> > > Hannes >> > > >> > > >> > >> -----Original Message----- >> > >> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On >> > Behalf >> > >> Of ext Manner Jukka >> > >> Sent: Thursday, October 11, 2012 3:34 PM >> > >> To: Bob Briscoe >> > >> Cc: ; ; > > >> chairs@ietf.org>; tsvwg IETF list >> > >> Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for >> draft-ietf- >> > >> tsvwg-byte-pkt-congest >> > >> >> > >> Hi, >> > >> >> > >> Yeah, please at the point about cheap devices, still, I wonder = what >> > > the >> > >> cost of AQM is on those devices. Maybe 1 cnt in mass production? >> > Thus, >> > >> I still wonder if it is worth arguing something about the future >> > that >> > >> strongly. >> > >> >> > >> Sorry, but the same goes for AQM in general, and where it is, or >> > will >> > >> not be deployed. I understand technical reasons why not = something >> is >> > >> feasible, but business or monetary reasons can change very = quickly. >> > ;) >> > >> >> > >> Jukka >> > >> >> > >> On Oct 11, 2012, at 3:08 PM, Bob Briscoe wrote: >> > >> >> > >>> Jukka, >> > >>> >> > >>> What I had in mind is all low level buffers in cheap pure L2 >> > > devices, >> > >> in cheap NATs etc. I was going to list some of these, but = instead >> > > chose >> > >> to say "no-one expects AQM to be universally deployed". This >> clearly >> > >> missed the mark. >> > >>> >> > >>> Should we include some of these concrete examples of where AQM >> > won't >> > >> be deployed instead? >> > >>> >> > >>> [I've cc'd the list, given we're starting to wordsmith >> > significantly >> > >> new text added since WG last call.] >> > >>> >> > >>> >> > >>> Bob >> > >>> >> > >>> At 20:04 10/10/2012, Manner Jukka wrote: >> > >>>> Hi, looked good to me. Just one comment, I wouldn't put that = much >> > >> emphasis on what is a probably state of things, e.g. >> > >>>> >> > >>>> "no-one expects AQM to ever be .." > in the future it might, = we >> > >> don't know, and since the paragraph says that it doesn't matter >> > > anyway, >> > >> I would formulate this paragraph a bit towards that we have = partial >> > >> deployment now and even with a full deployment, ... >> > >>>> >> > >>>> and similarly with the unrealistic deployment of AQM in the >> > >> subsequent paragraph. >> > >>>> >> > >>>> cheers, >> > >>>> Jukka >> > >>>> >> > >>>> On Oct 10, 2012, at 6:25 PM, Bob Briscoe wrote: >> > >>>> >> > >>>>> Phil, >> > >>>>> >> > >>>>> Sorry for delay, my round-robin scheduler is taking so long = to >> > > get >> > >> round all the tasks that I keep finding dead robins (that = reminds >> me >> > > of >> > >> a bike ride my grandmother took. On her return, she said there = were >> > a >> > >> worryingly large number of robins run over on the roads. It = turned >> > out >> > >> that she had been going round the same small triangle of roads >> > > multiple >> > >> times). >> > >>>>> >> > >>>>> I've done a complete re-write of 3.4. I hope you will agree = that >> > >> it really is a motivating argument now and it can stay where it = is >> - >> > > it >> > >> is not just a preamble. >> > >>>>> >> > >>>>> I've gone back to the very first version of 3.4 I wrote and I >> now >> > >> realise that I had written the core of the argument so badly = that >> > even >> > >> I forgot what it was meant to say when we started editing it. In >> the >> > >> draft-08 version, the original meaning is lost and in your re- >> > wording >> > >> it is entirely lost. The link with the draft-08 version is = nearly >> > >> unrecognisable, but it's the argument I intended here. >> > >>>>> >> > >>>>> >> > >> >> > > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >>>>> 3.4. Permanent Partial Deployment of AQM >> > >>>>> >> > >>>>> In overview, the argument in this section runs as follows: >> > >>>>> * Because the network will not and cannot always drop packets = in >> > >> proportion to their size, it shouldn't be given the task of = making >> > > drop >> > >> signals depend on packet size at all. >> > >>>>> * Transports on the other hand don't always want to make = their >> > >> rate response proportional to the size of dropped packets, but = if >> > they >> > >> want to, they always can. >> > >>>>> >> > >>>>> The argument is similar to the end-to-end argument that says >> > >> "Don't do X in the network if end-systems can do X by = themselves, >> > and >> > >> they want to be able to choose whether to do X anyway." Actually >> the >> > >> following argument is stronger; in addition it says "Don't give = the >> > >> network task X that could be done by the end-systems, if X won't >> > ever >> > >> be deployed on all network nodes, and end-systems won't be able = to >> > > tell >> > >> whether their network is doing X, or whether they need to do X >> > >> themselves." In this case, the X in question is "making the >> response >> > > to >> > >> congestion depend on packet size". >> > >>>>> >> > >>>>> We will now re-run this argument taking each step in more = depth. >> > >> The argument applies solely to drop, not ECN marking. >> > >>>>> >> > >>>>> A queue drops packets for either of two reasons: a) to signal = to >> > >> host congestion controls that they should reduce the load and b) >> > >> because there is no buffer left to store the packets. Active = queue >> > >> management tries to use drops as a signal for hosts to slow down >> > (case >> > >> a) so that drop due to buffer exhaustion (case b) should not be >> > >> necessary. >> > >>>>> >> > >>>>> No-one expects AQM to ever be universally deployed in every >> queue >> > >> in the Internet; and, even if AQM were universal, it has to be = able >> > to >> > >> cope with buffer exhaustion (by switching to a behaviour like = tail- >> > >> drop), in order to cope with unresponsive or excessive = transports. >> > >> Therefore networks will often be dropping packets as a last = resort >> > >> (case b) rather than under AQM control (case a). >> > >>>>> >> > >>>>> When buffers are exhausted (case b), they don't naturally = drop >> > >> packets in proportion to their size. The network can only reduce >> the >> > >> probability of dropping smaller packets if it has enough space = to >> > > store >> > >> them somewhere while it waits for a larger packet that it can = drop. >> > If >> > >> the buffer is exhausted, it does not have this choice. = Admittedly >> > > tail- >> > >> drop does naturally drop somewhat fewer small packets, but = exactly >> > how >> > >> few depends more on the mix of sizes than the size of the packet = in >> > >> question. Nonetheless, in general, if we wanted networks to do >> size- >> > >> dependent drop, we would need universal deployment of = (packet-size >> > >> dependent) AQM code, which is unrealistic. >> > >>>>> >> > >>>>> A host transport cannot know whether any particular drop was = a >> > >> deliberate signal from an AQM or a sign of a queue shedding = packets >> > > due >> > >> to buffer exhaustion. Therefore, because the network cannot >> > > universally >> > >> do size-dependent drop, it should not do it all. >> > >>>>> >> > >>>>> Whereas universality is desirable in the network, diversity = is >> > >> desirable between different transport layer protocols - some, = like >> > >> NewReno TCP [RFC5681], may not choose to make their rate = response >> > >> proportionate to the size of each dropped packet, while others = will >> > >> (e.g. TFRC-SP [RFC4828]). >> > >>>>> >> > >> >> > > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> Bob >> > >>>>> >> > >>>>> At 13:13 04/10/2012, gorry@erg.abdn.ac.uk wrote: >> > >>>>>> That would be brilliant! >> > >>>>>> >> > >>>>>> Gorry >> > >>>>>> >> > >>>>>>> Will try to look at this later today. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> Bob >> > >>>>>>> >> > >>>>>>> At 10:42 02/10/2012, philip.eardley@bt.com wrote: >> > >>>>>>>> Think the token is with bob >> > >>>>>>>> >> > >>>>>>>> Re your comment - yes, I think you could move 3.4 to the = end >> > > of >> > >> S3 - >> > >>>>>>>> or to the start - and do some re-phrasing, maybe something >> > > like >> > >> I tried. >> > >>>>>>>> >> > >>>>>>>> -----Original Message----- >> > >>>>>>>> From: Manner Jukka [mailto:jukka.manner@aalto.fi] >> > >>>>>>>> Sent: 01 October 2012 20:18 >> > >>>>>>>> To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,Bob,DUB8 R >> > >>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst >> > >>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for >> > >>>>>>>> draft-ietf-tsvwg-byte-pkt-congest >> > >>>>>>>> >> > >>>>>>>> Phil, Bob, can we close this finally? It's three weeks now >> > >> since >> > >>>>>>>> this previous message. >> > >>>>>>>> >> > >>>>>>>> Jukka >> > >>>>>>>> >> > >>>>>>>> On Sep 10, 2012, at 4:42 PM, Jukka Manner wrote: >> > >>>>>>>> >> > >>>>>>>>> Ack, I'm getting there...;) >> > >>>>>>>>> >> > >>>>>>>>> So, we could move 3.4 at the end of Section 3 and = rephrase >> > >> it to >> > >>>>>>>> not talk about scaling per se, but rather about how Req = 2.2 >> > >>>>>>>> eventually leads to Req 2.3? >> > >>>>>>>>> >> > >>>>>>>>> Jukka >> > >>>>>>>>> >> > >>>>>>>>> On Sep 7, 2012, at 4:07 PM, >> > >>>>>>>>> wrote: >> > >>>>>>>>> >> > >>>>>>>>>> 3.4 is, in my mind, completely different from 3.1, 3.2, >> > > 3.3 >> > >> and 3.5. >> > >>>>>>>>>> >> > >>>>>>>>>> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for >> > >> Recommendation >> > >>>>>>>>>> 2.2 & a lesser extent 2.3 >> > >>>>>>>>>> 3.4 makes doesn't make a motivating argument - it = explains >> > >> that Rec >> > >>>>>>>>>> 2.2 & 2.3 come as a pair (if you recommend one, then >> > >> inevitably you >> > >>>>>>>>>> recommend the other) (delta some politeness about TCP) >> > >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> -----Original Message----- >> > >>>>>>>>>> From: Manner Jukka [mailto:jukka.manner@aalto.fi] >> > >>>>>>>>>> Sent: 07 September 2012 13:24 >> > >>>>>>>>>> To: Eardley,PL,Philip,DUB8 R >> > >>>>>>>>>> Cc: Briscoe,RJ,Bob,DUB8 R; ; >> > >>>>>>>>>> >> > >>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for >> > >>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest >> > >>>>>>>>>> >> > >>>>>>>>>> Hi, I'm trying to follow your reasoning, with little = luck. >> > >> ;) >> > >>>>>>>>>> >> > >>>>>>>>>> After having read Section 3 again, I could think of a = few >> > >>>>>>>> updates, but I'm not fully following what you want to see: >> > >>>>>>>>>> >> > >>>>>>>>>> - S3.5 is kind of small and lonely by itself. It could = be >> > >> either >> > >>>>>>>> longer or merged somewhere. Not a major issue though and >> > > could >> > >> remain as >> > >>>>>>>> is. >> > >>>>>>>>>> >> > >>>>>>>>>> - S3.3: Yes, probably could be turned upside down, good >> > >> first, >> > >>>>>>>> bad later. Don't have a strong opinion. >> > >>>>>>>>>> >> > >>>>>>>>>> - S3.4: Here the scaling is used many times and in the >> > >> title, >> > >>>>>>>> although we talk about the end host side. This could be >> > >> rephrased >> > >>>>>>>> and slightly reworded to talk about hosts and their = operation >> > >>>>>>>> altogether. Also the word scaling can turn the readers >> > >> expectation >> > >>>>>>>> into the wrong direction. >> > >>>>>>>>>> >> > >>>>>>>>>> - S3 altogether: It would help to have introductory text >> > >> about >> > >>>>>>>> networks vs. end host side, but I fail to see why (& how) = to >> > >>>>>>>> restructure everything. >> > >>>>>>>>>> >> > >>>>>>>>>> cheers, >> > >>>>>>>>>> Jukka >> > >>>>>>>>>> >> > >>>>>>>>>> On Sep 6, 2012, at 6:18 PM, >> > >>>>>>>> wrote: >> > >>>>>>>>>> >> > >>>>>>>>>>> Ps otherwise Bob's comments are fine, though I suggest >> > > for >> > >> S3.5 you >> > >>>>>>>>>>> give more context (ie are you knocking down what you >> > >> recommend >> > >>>>>>>>>>> against, or building up what you recommend?) and in = S3.3 >> > >> think >> > >>>>>>>>>>> would be better if you re-structured slightly [first = talk >> > >> about what >> > >>>>>>>>>>> you like - penult para + 1st sentence of last para - = then >> > >> talk about >> > >>>>>>>>>>> what you don't like - rest of text] >> > >>>>>>>>>>> >> > >>>>>>>>>>> From: Eardley,PL,Philip,DUB8 R >> > >>>>>>>>>>> Sent: 06 September 2012 16:12 >> > >>>>>>>>>>> To: Briscoe,RJ,Bob,DUB8 R; Manner Jukka >> > >>>>>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst >> > >>>>>>>>>>> Subject: RE: [REVISED I-D]: Document writeup for >> > >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest >> > >>>>>>>>>>> >> > >>>>>>>>>>> Thanks bob. Have now re-booted some state. >> > >>>>>>>>>>> I don't like S3.4. My basic problem with it is that it >> > >> isn't a >> > >>>>>>>> "motivating argument" (S3 title). It's an explanation = about >> > >> the >> > >>>>>>>> consequences of assuming either [option 1] do pkt-size >> > > biasing >> > >> in >> > >>>>>>>> the transport; [option 2]; do pkt-size biasing in the nw. >> > >>>>>>>>>>> Perhaps your effort to buy peace with those who won't >> > >> change >> > >>>>>>>> TCP has obfuscated the basic point? >> > >>>>>>>>>>> The title of S3.4 (Scaling...) and the early text >> > > "scaling >> > >>>>>>>> argument" suggests that you're going to argue there is = some >> > >> reason >> > >>>>>>>> why X scales as order N rather than N^2 or something like >> > > that >> > >> - >> > >>>>>>>> which isn't what S3.4 is about. >> > >>>>>>>>>>> >> > >>>>>>>>>>> I actually think it would be better to put S3.4 at the >> > >> start of >> > >>>>>>>> S3 - it's background where you say there are 2 options. = After >> > >> that, >> > >>>>>>>> you can explain the reasons why option 1 [pkt biasing in = the >> > >>>>>>>> transport] is better - the reasons being:- S3.1 (security >> > > etc >> > >>>>>>>> attacks if small pkts get preferential treatment), S3.2 >> > >> (really a >> > >>>>>>>> side note to S3.1; ie doesn't really present a "motivating >> > >>>>>>>> argument"), S3.3 (nw guessing MTU vs transport knowing pkt >> > >> size), >> > >>>>>>>> S3.5 (easier implementation). >> > >>>>>>>>>>> >> > >>>>>>>>>>> Something like... >> > >>>>>>>>>>> The behaviour of the network and transport together = needs >> > >> to >> > >>>>>>>>>>> alleviate congestion. We assume the network is bit- >> > >> congestible >> > >>>>>>>> (currently packet-congestible resources are rate). = Therefore >> > >>>>>>>> overall the response of the {network + transport} should = be >> > >> the >> > >>>>>>>> same for the same congestion - whether the congestion is >> > >> caused by >> > >>>>>>>> a lot of small packets or a smaller number of larger = packets. >> > >> The >> > >>>>>>>> implication is that the transport's behaviour should = depend >> > > on >> > >>>>>>>> whether the network takes account (or not) of packet size >> > > when >> > >> it >> > >>>>>>>> generates congestion indications:- Case 1: If the network >> > >>>>>>>> implements packet-mode drop, ie its algorithm treats all >> > >> packets >> > >>>>>>>> equally regardless of their size, then the transport = should >> > >> take >> > >>>>>>>> account of the size of the packet - in other words, the >> > >> transport's >> > >>>>>>>> congestion response should depend on the number of dropped >> > >> bytes. >> > >>>>>>>>>>> Case 2: If the network implements byte-mode drop, ie = its >> > >>>>>>>> algorithm treats packets differently depending on their = size, >> > >> then >> > >>>>>>>> the transport should not take account of the size of the >> > >> packet - >> > >>>>>>>> in other words, the transport's congestion response should >> > >> depend >> > >>>>>>>> on the number of dropped packets. >> > >>>>>>>>>>> >> > >>>>>>>>>>> These cases are explained in more detail in sub-section >> > >> below. >> > >>>>>>>>>>> >> > >>>>>>>>>>> In both cases the same discussion applies if packets = are >> > >>>>>>>> ECN-marked rather than dropped. >> > >>>>>>>>>>> In the following sections we explain why Case 1 is >> > >> preferable, >> > >>>>>>>> and hence why we make the Recommendations of S2.2 and S3.3 >> > >>>>>>>> (respectively, drop/mark pkts equally regardless of their >> > >> size, and >> > >>>>>>>> the strength of the transport's response should be >> > >> proportionate to >> > >>>>>>>> the size of the dropped/marked pkt). >> > >>>>>>>>>>> Note that TCP responds to dropped or marked packets, >> > > which >> > >> differs >> > >>>>>>>>>>> from our recommendation for transports. However, we are >> > >> not >> > >>>>>>>>>>> recommending that TCP should be changed; to date it >> > >> hasn't been a >> > >>>>>>>>>>> significant problem because most TCP implementations >> > > have >> > >> been >> > >>>>>>>> used with similar packet sizes. But we do recommend that >> > >> future >> > >>>>>>>> transport protocols should respond to dropped or marked >> > > bytes >> > >> (as >> > >>>>>>>> for example TFRC-SP [RFC4828]effectively does). >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> Sub-section >> > >>>>>>>>>>> You could use much of S3.3, I suggest supplement with >> > >> numerical >> > >>>>>>>>>>> examples continuing S1.2 >> > >>>>>>>>>>> -- >> > >>>>>>>>>>> << This gives a get-out clause to any transport that >> > > isn't >> > >>>>>>>>>>> packet-size dependent (e.g. current TCP). Lacking = packet- >> > >> size >> > >>>>>>>>>>> dependence just means they don't scale correctly with >> > >> packet size - >> > >>>>>>>>>>> but they are at liberty not to scale with packet size >> > >> (particularly >> > >>>>>>>>>>> given MTU growth isn't often being used to increase = link >> > >> rates at >> > >>>>>>>>>>> this stage in history).>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> This is introducing a different point. it's saying that >> > >> your >> > >>>>>>>> recommendation 2 [drop/mark pkts equally regardless of = their >> > >> size] >> > >>>>>>>> is a really strong reco whilst recommendation 3 [strength = of >> > >>>>>>>> transport's response proportionate to the size of the >> > >>>>>>>> dropped/marked pkt] is a much less important reco. I can = see >> > >> this >> > >>>>>>>> might be true, but I don't think the i-d talks about this. >> > >>>>>>>>>>> >> > >>>>>>>>>>> -- >> > >>>>>>>>>>> >> > >>>>>>>>>>> From: Briscoe,RJ,Bob,DUB8 R >> > >>>>>>>>>>> Sent: 05 September 2012 16:41 >> > >>>>>>>>>>> To: Manner Jukka >> > >>>>>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst; >> > >> Eardley,PL,Philip,DUB8 R >> > >>>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for >> > >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest >> > >>>>>>>>>>> >> > >>>>>>>>>>> Jukka, >> > >>>>>>>>>>> >> > >>>>>>>>>>> I've repeated Phil's suggestions as quoted email then >> > > made >> > >> some >> > >>>>>>>> alterations. >> > >>>>>>>>>>> >> > >>>>>>>>>>> Phil asked me to send this, then he will think about = it. >> > >>>>>>>>>>> >> > >>>>>>>>>>> I'll respond about John Leslie's argument next... >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> 2.2. Recommendation on Encoding Congestion Notification >> > >>>>>>>>>>> >> > >>>>>>>>>>> [...] >> > >>>>>>>>>>> >> > >>>>>>>>>>> 1. AQM algorithms such as RED SHOULD use packet-mode >> > >> drop, ie they >> > >>>>>>>>>>> SHOULD NOT use byte-mode drop. The latter is more >> > >> complex, >> > >>>>>>>>>>> it creates the perverse incentive to fragment >> > >> segments into >> > >>>>>>>> tiny >> > >>>>>>>>>>> pieces and it is vulnerable to floods of small >> > >> packets. >> > >>>>>>>>>>> >> > >>>>>>>>>>> 2. If a vendor has implemented byte-mode drop, and an >> > >> operator has >> > >>>>>>>>>>> turned it on, it is RECOMMENDED to turn it off, >> > > after >> > >>>>>>>> establishing >> > >>>>>>>>>>> if there are any implications on the relative >> > >> performance of >> > >>>>>>>>>>> applications using different packet sizes. >> > >>>>>>>>>>> >> > >>>>>>>>>>> RED as a whole SHOULD NOT be turned off. Without >> > > RED, >> > >> a drop >> > >>>>>>>> tail >> > >>>>>>>>>>> queue biases against large packets >> > >>>>>>>>>>> >> > >>>>>>>>>>> [BB adds]: and it is >> > >> vulnerable to >> > >>>>>>>> floods >> > >>>>>>>>>>> of small-packets. >> > >>>>>>>>>>> >> > >>>>>>>>>>> (I suggest the last para just qualifies item 2. It >> > > doesn't >> > >> warrant >> > >>>>>>>>>>> another item number.) >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> [PE:] S3.3 >> > >>>>>>>>>>> The section could be slightly clearer. Starting with = the >> > >> second >> > >>>>>>>> para, where you start talking about something you don't >> > >> recommend >> > >>>>>>>> (ie you have to remember that you're talking about the >> > >> consequences >> > >>>>>>>> of not following your recommendation). >> > >>>>>>>>>>> >> > >>>>>>>>>>> 3.3 Transport-Independent Network >> > >>>>>>>>>>> >> > >>>>>>>>>>> TCP congestion control ensures that flows competing for >> > >> the same >> > >>>>>>>>>>> resource each maintain the same number of segments in >> > >> flight, >> > >>>>>>>>>>> irrespective of segment size. So under similar >> > >> conditions, flows >> > >>>>>>>>>>> with different segment sizes will get different >> > > bit-rates. >> > >>>>>>>>>>> >> > >>>>>>>>>>> [OLD:] >> > >>>>>>>>>>> One motivation for the network biasing congestion >> > >> notification by >> > >>>>>>>>>>> packet size is to counter this effect and try to = equalise >> > >> the bit- >> > >>>>>>>>>>> rates of flows with different packet sizes. >> > >>>>>>>>>>> [SUGGESTED:] >> > >>>>>>>>>>> To counter this effect it seems tempting not to follow >> > >> our >> > >>>>>>>>>>> recommendation, and instead for the network to bias >> > >> congestion >> > >>>>>>>>>>> notification by packet size in order to equalise the >> > > bit- >> > >> rates of >> > >>>>>>>>>>> flows with different packet sizes. >> > >>>>>>>>>>> [CONTINUE AS BEFORE:] >> > >>>>>>>>>>> However, in order to do this, the = queuing >> > >> algorithm >> > >>>>>>>>>>> has to make assumptions about the transport, which >> > > become >> > >> embedded >> > >>>>>>>>>>> in the network. Specifically: >> > >>>>>>>>>>> [...] >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> S3.3 >> > >>>>>>>>>>> o The queuing algorithm has to assume how aggressively >> > >> the >> > >>>>>>>> transport >> > >>>>>>>>>>> will respond to congestion (see Section 4.2.4). If >> > >> the network >> > >>>>>>>>>>> assumes the transport responds as aggressively as = TCP >> > >> NewReno, >> > >>>>>>>> it >> > >>>>>>>>>>> will be wrong for Compound TCP and differently wrong >> > >> for Cubic >> > >>>>>>>>>>> TCP, etc. To achieve equal bit-rates, each = transport >> > >> then has >> > >>>>>>>> to >> > >>>>>>>>>>> guess what assumption the network made, and work out >> > >> how to >> > >>>>>>>>>>> replace this assumed aggressiveness with its own >> > >> aggressiveness. >> > >>>>>>>>>>> o Also, if the network biases congestion notification >> > > by >> > >> packet >> > >>>>>>>> size >> > >>>>>>>>>>> it has to assume a baseline packet size--all = proposed >> > >> algorithms >> > >>>>>>>>>>> use the local MTU. Then transports have to guess >> > >> which link was >> > >>>>>>>>>>> congested and what its local MTU was, in order to >> > > know >> > >> how to >> > >>>>>>>>>>> tailor their congestion response to that link. >> > >>>>>>>>>>> >> > >>>>>>>>>>> So you're saying that for byte-mode drop, the network >> > >> element >> > >>>>>>>> has to compare the size of the current pkt with the MTU, = and >> > >> if >> > >>>>>>>> it's 25* smaller then reduce the pkt loss probably by 25*? >> > > And >> > >> if >> > >>>>>>>> the MTU was bigger, then the current pkt would be dropped >> > > with >> > >>>>>>>> greater probability? And both of these things are hard to = do. >> > >>>>>>>>>>> >> > >>>>>>>>>>> [BB]: SUGGESTED REPLACEMENT to 2nd bullet: >> > >>>>>>>>>>> >> > >>>>>>>>>>> o Also, if the network biases congestion notification >> > > by >> > >> packet >> > >>>>>>>> size >> > >>>>>>>>>>> it has to assume a baseline packet size--all = proposed >> > >> algorithms >> > >>>>>>>>>>> use the local MTU (for example see the byte-mode = loss >> > >>>>>>>> probability >> > >>>>>>>>>>> formula in Table 1). Then if the non-Reno = transports >> > >> mentioned >> > >>>>>>>> above >> > >>>>>>>>>>> are trying to reverse engineer what the network >> > >> assumed, they >> > >>>>>>>> also >> > >>>>>>>>>>> have to guess the MTU of the congested link. >> > >>>>>>>>>>> >> > >>>>>>>>>>> [Aside for Phil: The byte-mode algo uses MTU as its >> > >> baseline because >> > >>>>>>>>>>> a link cannot send a packet bigger than its MTU so the >> > >> algo won't >> > >>>>>>>>>>> ever give a drop probability >1).] >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> S3.4 (& knock-on effect on 3.3) >> > >>>>>>>>>>> I think this could be better. >> > >>>>>>>>>>> I agree with your arguments in S3.1 & 3.2 that dropping >> > > or >> > >>>>>>>> marking should be independent of pkt size. >> > >>>>>>>>>>> You now go into a couple of pages, which I think could = be >> > >> boiled >> > >>>>>>>>>>> down to a paragraph, saying something like:- >> > >>>>>>>>>>> * the overall system (network + transport) has to be >> > >> packet-size >> > >>>>>>>>>>> dependent in order to drive out the right amount of >> > >> traffic so the >> > >>>>>>>>>>> resource becomes uncongested (since we assume all >> > >> resources are in >> > >>>>>>>>>>> practice byte rather than packet limited) >> > >>>>>>>>>>> * from S3.1 and S3.2 the IETF is convinced that the >> > >> network >> > >>>>>>>> should notify independent of packet-size. >> > >>>>>>>>>>> * therefore the transport must act dependent on packet- >> > >> size. >> > >>>>>>>>>>> >> > >>>>>>>>>>> It seems to me this is a necessary consequence of your >> > >> earlier >> > >>>>>>>> assumptions /arguments. >> > >>>>>>>>>>> >> > >>>>>>>>>>> [BB:] This isn't at all obvious. Until I worked it >> > >> through, it >> > >>>>>>>> wasn't obvious to me. I think it needs to be spelled out. >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> [On the other hand, if someone disagrees with the >> > >> arguments and >> > >>>>>>>>>>> thinks that the network should notify dependent on >> > > packet- >> > >> size, then >> > >>>>>>>>>>> it follows that the transport can act independent of >> > >> packet-size.] >> > >>>>>>>>>>> >> > >>>>>>>>>>> I think in S3.3 you're trying to make another argument >> > >> (?):- >> > >>>>>>>>>>> * we can either do packet-size biasing in the network >> > >> element or on >> > >>>>>>>>>>> the end host transport (see argument above) >> > >>>>>>>>>>> * packet-size biasing in the network is quite tricky, >> > >> because >> > >>>>>>>> then both the network element & the transport have to make >> > >> some >> > >>>>>>>> guesses about MTU - whereas with packet-size biasing in = the >> > >>>>>>>> transport, neither network element nor transport needs to >> > > know >> > >> what the >> > >>>>>>>> MTU is. >> > >>>>>>>>>>> * it is also easier to implement packet-size biasing in >> > >> the >> > >>>>>>>> transport than in the network. >> > >>>>>>>>>>> >> > >>>>>>>>>>> [BB] ...and all the other arguments about vulnerability >> > > to >> > >>>>>>>> flooding etc, transport-independence etc. >> > >>>>>>>>>>> >> > >>>>>>>>>>> Our argument is sort of like how Phil summarises it, = but >> > >> with >> > >>>>>>>> an added nuance. It's also saying no-one has to do >> > > packet-size >> > >>>>>>>> biasing anyway. It's not saying "The transport should = given >> > >> the >> > >>>>>>>> network shouldn't". It's saying "*If the transport wants = to >> > >> claim >> > >>>>>>>> to be scalable wrt packet size* it should if the network >> > >> shouldn't". >> > >>>>>>>>>>> >> > >>>>>>>>>>> This gives a get-out clause to any transport that isn't >> > >>>>>>>> packet-size dependent (e.g. current TCP). Lacking = packet-size >> > >>>>>>>> dependence just means they don't scale correctly with = packet >> > >> size - >> > >>>>>>>> but they are at liberty not to scale with packet size >> > >> (particularly >> > >>>>>>>> given MTU growth isn't often being used to increase link >> > > rates >> > >> at >> > >>>>>>>> this stage in history). >> > >>>>>>>>>>> >> > >>>>>>>>>>> None of what Phil says convinces me we could say 3.4 = (or >> > >> 3.3) >> > >>>>>>>> any more briefly or differently. It's easier to summarise >> > > what >> > >> you >> > >>>>>>>> understand having read something. But that's not the same = as >> > >>>>>>>> writing the thing that helped you understand. There = doesn't >> > >> seem to >> > >>>>>>>> be any argument for why anything needs to be changed, so = I'm >> > >> going >> > >>>>>>>> to leave it as is, unless pushed. >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> On the last bullet, I didn't really follow your = argument >> > >> in >> > >>>>>>>> S3.5. Might be easier to follow if S3.5 also talked about = how >> > >> a >> > >>>>>>>> network element would take account of pkt size? >> > >>>>>>>>>>> Also, does the following argument also apply?: >> > >>>>>>>>>>> * if pkt-size biasing is done in the transport, then = the >> > >> work (to do >> > >>>>>>>>>>> the biasing) is spread over many end hosts, >> > >>>>>>>>>>> * whereas if pkt-size biasing is done in the network, >> > > then >> > >> the >> > >>>>>>>> work is concentrated in just the congested network = element, >> > >> which >> > >>>>>>>> has to operate on all the traffic at line speed. >> > >>>>>>>>>>> >> > >>>>>>>>>>> [BB]: 3.5. Implementation Efficiency >> > >>>>>>>>>>> >> > >>>>>>>>>>> [ADD:] >> > >>>>>>>>>>> Biasing against large packets typically requires an >> > > extra >> > >> multiply >> > >>>>>>>>>>> and divide in the network (see the example byte-mode >> > > drop >> > >>>>>>>> formula in table 1). >> > >>>>>>>>>>> [CONTINUE AS BEFORE:] >> > >>>>>>>>>>> Allowing for packet size at the transport rather than = in >> > >> the >> > >>>>>>>>>>> network ensures that neither the network nor the >> > >> transport needs to >> > >>>>>>>>>>> do a multiply operation--multiplication by packet size >> > > is >> > >>>>>>>>>>> effectively achieved as a repeated add when the >> > > transport >> > >> adds to >> > >>>>>>>>>>> its count of marked bytes as each congestion event is >> > > fed >> > >> to it. >> > >>>>>>>>>>> [ADD:] >> > >>>>>>>>>>> Also the work to do the biasing is spread over many >> > >> hosts, rather >> > >>>>>>>>>>> than concentrated in just the congested network = element. >> > >>>>>>>>>>> [CONTINUE AS BEFORE:] >> > >>>>>>>>>>> >> > > These >> > >> aren't >> > >>>>>>>>>>> principled reasons in themselves, but they are a happy >> > >> consequence >> > >>>>>>>>>>> of the other principled reasons. >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> Bob >> > >>>>>>>>>>> >> > >>>>>>>>>>> At 13:36 05/09/2012, Manner Jukka wrote: >> > >>>>>>>>>>> >> > >>>>>>>>>>> Hi Bob, >> > >>>>>>>>>>> >> > >>>>>>>>>>> Since Phil is your colleague at BT, even at Ipswich = (?), >> > >> can >> > >>>>>>>> you check those and agree with Phil how to go forward? = Some >> > > of >> > >>>>>>>> those are clear, others need discussion with Phil. >> > >>>>>>>>>>> >> > >>>>>>>>>>> Gorry, on point 2) below, I don't follow Leslie's >> > >> arguments. I >> > >>>>>>>> asked from him detailed comments and resolutions months = ago, >> > >> and nothing >> > >>>>>>>> came. >> > >>>>>>>>>>> >> > >>>>>>>>>>> cheers, >> > >>>>>>>>>>> Jukka >> > >>>>>>>>>>> >> > >>>>>>>>>>> On Sep 5, 2012, at 3:26 PM, Gorry Fairhurst wrote: >> > >>>>>>>>>>> >> > >>>>>>>>>>>> Bob and Jukka, >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> I think I need your help to resolve this... Some of = the >> > >>>>>>>> comments raised by John Leslie appear to have substance, = and >> > >> I'm >> > >>>>>>>> not sure what you plan to do to address these. >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> It would be good to do something quick so that I can >> > >> complete >> > >>>>>>>> the submission to the IESG. >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> The issues I particularly note are: >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> 1) This contribution from Phil appears to be within >> > > scope >> > >> and >> > >>>>>>>> it seems may have been overlooked (sorry): >> > >>>>>>>>>>>> http://www.ietf.org/mail- >> > >> archive/web/tsvwg/current/msg11234.html >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> 2) Can you be clear here about what is actually been >> > > said >> > >> - >> > >>>>>>>> because the point below seems to be a misunderstanding of >> > >> language >> > >>>>>>>> to me, and I hoped we did not claim this: >> > >>>>>>>>>>>> >> > >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find >> > > that >> > >> Bob is >> > >>>>>>>>>>>>>> actually ] saying that transport-layer should _only_ >> > >> consider >> > >>>>>>>>>>>>>> "congested bytes", not ] "congested packets". >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> 3) You'll need to post the updated draft and send a = note >> > >> to >> > >>>>>>>> the group to confirm that the new version indeed concludes >> > > the >> > >>>>>>>> WGLC. I'll add a note to the writeup to indicate the draft >> > >> content >> > >>>>>>>> has been stable since Oct 2011. >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> Gorry (with my TSVWG Documnent Shepherd hat) >> > >>>>>>>>>>>> cc: Co-Chairs for info. >> > >>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > >>>>>>>>>>>>>> -----Original Message----- >> > >>>>>>>>>>>>>> From: Gorry Fairhurst [ mailto:gorry@erg.abdn.ac.uk] >> > >>>>>>>>>>>>>> Sent: Mittwoch, 15. August 2012 21:41 >> > >>>>>>>>>>>>>> To: tsvwg chair >> > >>>>>>>>>>>>>> Subject: Fwd: Re: [tsvwg] FYI: Document writeup for >> > >>>>>>>>>>>>>> draft-ietf-tsvwg- byte-pkt-congest >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Hi guys, >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Apart form the usual rhetoric, there are some points >> > >> here that we >> > >>>>>>>>>>>>>> should note as chairs. What are you own thoughts? = And >> > >> was >> > >>>>>>>>>>>>>> anything noted at the IETF in Vancouver concerning >> > > this >> > >> draft? >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Gorry >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> -------- Original Message -------- >> > >>>>>>>>>>>>>> Subject: Re: [tsvwg] FYI: Document writeup for >> > >>>>>>>>>>>>>> draft-ietf-tsvwg-byte- pkt-congest >> > >>>>>>>>>>>>>> Date: Wed, 15 Aug 2012 15:07:28 -0400 >> > >>>>>>>>>>>>>> From: John Leslie >> > >>>>>>>>>>>>>> To: Gorry Fairhurst >> > >>>>>>>>>>>>>> CC: tsvwg@ietf.org >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Gorry Fairhurst wrote: >> > >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> The following document has been revised after >> > >> receiving >> > >>>>>>>> WGLC comments. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> The changes are mostly refreshing a document >> > >> scheduled to >> > >>>>>>>>>>>>>> expire this month. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> No issues were found: >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Is that with WGC-hat-on? >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Neither my issues nor Philip Eardley's comments = were >> > >> addressed. >> > >>>>>>>>>>>>>> In fact, not even the changes Bob Briscoe mentioned >> > > on- >> > >> list have >> > >>>>>>>>>>>>>> been included. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> As required by RFC 4858, this is the current = template >> > >> for the >> > >>>>>>>>>>>>>> Document >> > >>>>>>>>>>>>>>> Shepherd Write-Up. >> > >>>>>>>>>>>>>>> ... >> > >>>>>>>>>>>>>>> (1) What type of RFC is being requested (BCP, >> > > Proposed >> > >> Standard, >> > >>>>>>>>>>>>>>> Internet Standard, Informational, Experimental, or >> > >> Historic)? >> > >>>>>>>>>>>>>>> Why is this the proper type of RFC? Is this type of >> > >> RFC >> > >>>>>>>>>>>>>>> indicated in the title page header? >> > >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> This document is intended as BCP. (This was = discussed >> > >> at IETF-81 >> > >>>>>>>>>>>>>>> and that the status changed from Informational to = BCP >> > >> since it >> > >>>>>>>>>>>>>>> provides guidance to implementors and people >> > >> configuring >> > >>>>>>>> routers and hosts). >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Thank you for finally answering my question about >> > > BCP >> > >> status. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> ... >> > >>>>>>>>>>>>>>> Working Group Summary >> > >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> There was consensus to publish this as a WG = document >> > >> and >> > >>>>>>>>>>>>>>> agreement at >> > >>>>>>>>>>>>>>> IETF-82 that the document was now complete. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Was that reviewed on-list? >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> ... >> > >>>>>>>>>>>>>>> (3) Briefly describe the review of this document = that >> > >> was >> > >>>>>>>>>>>>>>> performed >> > >>>>>>>>>>>>>> by >> > >>>>>>>>>>>>>>> the Document Shepherd. If this version of the >> > > document >> > >> is not >> > >>>>>>>>>>>>>>> ready for publication, please explain why the >> > > document >> > >> is being >> > >>>>>>>>>>>>>>> forwarded to the IESG. >> > >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> The document was presented at IEWTF-82 (Taipei), = with >> > >> a request >> > >>>>>>>>>>>>>>> for >> > >>>>>>>>>>>>>> WGLC. >> > >>>>>>>>>>>>>>> WGLC concluded with some discussion but no >> > > substantive >> > >> changes >> > >>>>>>>>>>>>>>> on Friday 30th March 2012. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Yes, I guess that is true; but ignoring substantive >> > >> comments >> > >>>>>>>>>>>>>> isn't a good practice IMHO. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> (4) Does the document Shepherd have any concerns >> > > about >> > >> the depth >> > >>>>>>>>>>>>>>> or breadth of the reviews that have been performed? >> > >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> No - the original draft had a lot of background >> > >> material, much >> > >>>>>>>>>>>>>>> of >> > >>>>>>>>>>>>>> this >> > >>>>>>>>>>>>>>> has been condensed or removed, resulting in a = smaller >> > >> document. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> That is indeed what I basically asked for, but I >> > >> don't see any >> > >>>>>>>>>>>>>> evidence of it: >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> - diff(07,08) 48 lines changed or deleted; 53 = lines >> > >> changed or >> > >>>>>>>> added >> > >>>>>>>>>>>>>> - diff(06,07) 8 lines changed or deleted; 13 = lines >> > >> changed or >> > >>>>>>>> added >> > >>>>>>>>>>>>>> - diff(05,06) 64 lines changed or deleted; 69 = lines >> > >> changed or >> > >>>>>>>>>>>>>> added >> > >>>>>>>>>>>>>> - diff(04,05) 823 lines changed or deleted; 864 = lines >> > >> changed or >> > >>>>>>>>>>>>>> added >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> (Need I go farther? That gets us back to March >> > > 2011...) >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> (9) How solid is the WG consensus behind this >> > >> document? Does it >> > >>>>>>>>>>>>>>> represent the strong concurrence of a few >> > > individuals, >> > >> with >> > >>>>>>>>>>>>>>> others being silent, or does the WG as a whole >> > >> understand >> > >>>>>>>> and agree with it? >> > >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> The document has WG support and there is consensus = to >> > >> publish. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> This, IMHO, doesn't answer the question. :^( >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Does it represent the concurrence of a few >> > >> individuals, or does >> > >>>>>>>>>>>>>> the WG as a whole understand and agree with it? >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> For reference, my comments included: >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] When I previously skimmed this document, I = believed >> > >> it >> > >>>>>>>>>>>>>> contained only ] common ground: that AQM should >> > >> drop/mark packets >> > >>>>>>>>>>>>>> without favoring small ] packets, and that to = whatever >> > >> extent >> > >>>>>>>>>>>>>> packet size _is_ considered, that ] should be a >> > >>>>>>>> transport-layer responsibility. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find >> > > that >> > >> Bob is >> > >>>>>>>>>>>>>> actually ] saying that transport-layer should _only_ >> > >> consider >> > >>>>>>>>>>>>>> "congested bytes", not ] "congested packets". >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] In fact, Bob openly endorses replacing TCP >> > >> congestion-control >> > >>>>>>>>>>>>>> with an ] algorithm which calculates "fair-share >> > > bytes" >> > >> and >> > >>>>>>>>>>>>>> doesn't back off at all ] (even in the presence of = 20% >> > >> packet >> > >>>>>>>>>>>>>> loss) unless you're already sending ] more than this >> > >>>>>>>> "fair-share". >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] I do not believe that is the consensus of this >> > > WG; >> > >> and I >> > >>>>>>>> believe >> > >>>>>>>>>>>>>> if >> > >>>>>>>>>>>>>> ] that were the consensus it would exceed our = charter. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] The draft contains a number of things I _do_ >> > > support; >> > >> and I'd >> > >>>>>>>>>>>>>> be happy ] to support a considerably shorter draft >> > >> which >> > >>>>>>>>>>>>>> concentrates on the AQM ] recommendation, omitting = any >> > >>>>>>>>>>>>>> suggestions of modifying TCP congestion ] control. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> and Philip's comments included: >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] S2.2 I thought the numbered bullets could be = better >> > >> phrased, >> > >>>>>>>>>>>>>> something like ] +this:- ] >> > >>>>>>>>>>>>>> ] 1. AQM algorithms such as RED SHOULD use = packet- >> > >> mode >> > >>>>>>>> drop, ie they >> > >>>>>>>>>>>>>> SHOULD NOT >> > >>>>>>>>>>>>>> ] +use byte-mode drop. The latter ] is more complex, >> > >>>>>>>>>>>>>> ] it creates the perverse incentive to = fragment >> > >> segments >> > >>>>>>>> into >> > >>>>>>>>>>>>>> tiny >> > >>>>>>>>>>>>>> ] pieces and it is vulnerable to floods of >> > >> small- >> > >>>>>>>>>>>>>> ] packets. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] 2. If a vendor has implemented byte-mode drop, >> > >> and an >> > >>>>>>>> operator >> > >>>>>>>>>>>>>> has >> > >>>>>>>>>>>>>> ] turned it on, it is RECOMMENDED to turn it >> > >> off, after >> > >>>>>>>>>>>>>> establishing if >> > >>>>>>>>>>>>>> ] +there are any implications on >> > >>>>>>>>>>>>>> ] the relative performance of >> > >>>>>>>>>>>>>> ] applications using different packet sizes. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] 3. RED SHOULD NOT be turned off. Without RED, a >> > >> drop tail >> > >>>>>>>>>>>>>> ] queue biases against large packets. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] Nit - the following paragraph shouldn't be = indented >> > >> (Note well >> > >>>>>>>>>>>>>> that >> > >>>>>>>>>>>>>> RED's...) >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] S3.3 >> > >>>>>>>>>>>>>> ] The section could be slightly clearer. Starting = with >> > >> the second >> > >>>>>>>>>>>>>> para, where you ] +start talking about something you >> > >> don't >> > >>>>>>>>>>>>>> recommend (ie you have to remember that ] +you're >> > >> talking about >> > >>>>>>>>>>>>>> the consequences of not following your >> > > recommendation). >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] S3.3 >> > >>>>>>>>>>>>>> ] o Also, if the network biases congestion >> > >> notification by >> > >>>>>>>> packet >> > >>>>>>>>>>>>>> size >> > >>>>>>>>>>>>>> ] it has to assume a baseline packet size--all >> > >> proposed >> > >>>>>>>>>>>>>> algorithms >> > >>>>>>>>>>>>>> ] use the local MTU. Then transports have to >> > >> guess which >> > >>>>>>>> link >> > >>>>>>>>>>>>>> was >> > >>>>>>>>>>>>>> ] congested and what its local MTU was, in = order >> > >> to know >> > >>>>>>>> how to >> > >>>>>>>>>>>>>> ] tailor their congestion response to that = link. >> > >>>>>>>>>>>>>> ] So you're saying that for byte-mode drop, the >> > > network >> > >> element >> > >>>>>>>>>>>>>> has to compare the ] +size of the current pkt with = the >> > >> MTU, and >> > >>>>>>>>>>>>>> if it's 25* smaller then reduce the ] +pkt loss >> > >> probably by 25*? >> > >>>>>>>>>>>>>> And if the MTU was bigger, then the current pkt = would >> > > ] >> > >> +be >> > >>>>>>>>>>>>>> dropped with greater probability? And both of these >> > >> things >> > >>>>>>>> are hard to do. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] S3.4 (& knock-on effect on 3.3) ] I think this = could >> > >> be better. >> > >>>>>>>>>>>>>> ] I agree with your arguments in S3.1 & 3.2 that >> > >> dropping or >> > >>>>>>>>>>>>>> marking should be ] +independent of pkt size. >> > >>>>>>>>>>>>>> ] You now go into a couple of pages, which I think >> > >> could be >> > >>>>>>>>>>>>>> boiled down to a ] +paragraph, saying something = like:- >> > >> ] * the >> > >>>>>>>>>>>>>> overall system (network + transport) has to be = packet- >> > >> size >> > >>>>>>>>>>>>>> dependent in ] >> > >>>>>>>>>>>>>> +order to drive out the right amount of traffic so = the >> > >> resource >> > >>>>>>>>>>>>>> becomes ] >> > >>>>>>>>>>>>>> +uncongested (since we assume all resources are in >> > >> practice byte >> > >>>>>>>>>>>>>> +rather >> > >>>>>>>>>>>>>> than ] +packet limited) ] * from S3.1 and S3.2 the >> > > IETF >> > >> is >> > >>>>>>>>>>>>>> convinced that the network should notify ] >> > > +independent >> > >> of >> > >>>>>>>> packet-size. >> > >>>>>>>>>>>>>> ] * therefore the transport must act dependent on >> > >> packet-size. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] It seems to me this is a necessary consequence of >> > >> your earlier >> > >>>>>>>>>>>>>> assumptions ] +/arguments. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] [On the other hand, if someone disagrees with the >> > >> arguments and >> > >>>>>>>>>>>>>> thinks that the ] +network should notify dependent = on >> > >>>>>>>>>>>>>> packet-size, then it follows that the ] +transport = can >> > >> act >> > >>>>>>>>>>>>>> independent of >> > >>>>>>>>>>>>>> packet- size.] ] ] I think in S3.3 you're trying to >> > >> make another >> > >>>>>>>>>>>>>> argument (?):- ] * we can either do packet-size >> > >> biasing in the >> > >>>>>>>>>>>>>> network element or on the end host ] +transport (see >> > >> argument >> > >>>>>>>>>>>>>> above) ] * packet-size biasing in the network is = quite >> > >> tricky, >> > >>>>>>>>>>>>>> because then both the ] +network element & the >> > >> transport have to >> > >>>>>>>>>>>>>> make some guesses about MTU - whereas ] >> > >>>>>>>>>>>>>> +with packet-size biasing in the transport, neither >> > >> network >> > >>>>>>>>>>>>>> +element >> > >>>>>>>>>>>>>> nor ] +transport needs to know what the MTU is. >> > >>>>>>>>>>>>>> ] * it is also easier to implement packet-size = biasing >> > >> in the >> > >>>>>>>>>>>>>> transport than in ] +the network. >> > >>>>>>>>>>>>>> ] >> > >>>>>>>>>>>>>> ] On the last bullet, I didn't really follow your >> > >> argument in >> > >>>>>>>> S3.5. >> > >>>>>>>>>>>>>> Might be ] +easier to follow if S3.5 also talked = about >> > >> how a >> > >>>>>>>>>>>>>> network element would take ] +account of pkt size? >> > >> Also, does the >> > >>>>>>>>>>>>>> following argument also apply?: >> > >>>>>>>>>>>>>> ] * if pkt-size biasing is done in the transport, = then >> > >> the work >> > >>>>>>>>>>>>>> (to do the ] +biasing) is spread over many end = hosts, >> > > ] >> > >> * whereas >> > >>>>>>>>>>>>>> if pkt-size biasing is done in the network, then the >> > >> work is ] >> > >>>>>>>>>>>>>> +concentrated in just the congested network element, >> > >> which has to >> > >>>>>>>>>>>>>> operate on all ] +the traffic at line speed. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> (Has there perhaps been some confusion about what >> > >> went into the >> > >>>>>>>>>>>>>> -08 >> > >>>>>>>>>>>>>> version?) >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> -- >> > >>>>>>>>>>>>>> John Leslie >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > >>>>>>>>>>>> >> > >>>>>>>>>>> >> > >> ________________________________________________________________ >> > >>>>>>>>>>> Bob Briscoe, BT Innovate = & >> > >> Design >> > >>>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >> ________________________________________________________________ >> > >>>>>>> Bob Briscoe, BT Innovate & >> > >> Design >> > >>>>>>> >> > >>>>> >> > >>>>> = ________________________________________________________________ >> > >>>>> Bob Briscoe, BT Innovate & = Design >> > >>> >> > >>> = ________________________________________________________________ >> > >>> Bob Briscoe, BT Innovate & = Design >> > > >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 From andrewmcgr@gmail.com Thu Oct 11 16:04:19 2012 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 3212621F8588; Thu, 11 Oct 2012 16:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcnDrbP3natp; Thu, 11 Oct 2012 16:04:16 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 958F521F8587; Thu, 11 Oct 2012 16:04:14 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so2232903pad.31 for ; Thu, 11 Oct 2012 16:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=U4SrKIK+x3BaOUgrBnjmCIfhnwuKUbYemYG2cA+s+l0=; b=k6pVgWYePv54tkjvJkapzmfSjrX45160DoKoWytcVc8fYublJHqgf9dYE8f8ziXTYu x0pmguaPk0Q+qvXhfPU/g2PVWIPJvZDN5mH3D8dh+cZK2X3NIYwLxJKryjmGU+cCOjXr 7E5fAJOl6UoNKhK/5uG/asTB33MrasxW1BDpFR3F6uZQBneKLQmpiGgtKm80XQdZCv/n l36je+PHCxc0rBmhi0nhkooCPuAKCLmHcWQ7XZzTTkbvkTmPm6X8X6jLiHaECjUP6kkl wSvzZ06sIue2Y4xzPuT0LhL/f1SU8Kkb3EzLz2tgFATCfl7pYThfBFR/UuY/5QeAzzR6 4QuQ== Received: by 10.68.143.162 with SMTP id sf2mr7883799pbb.137.1349996653881; Thu, 11 Oct 2012 16:04:13 -0700 (PDT) Received: from ?IPv6:2406:e000:62e9:1:7171:d37a:589b:90b6? ([2406:e000:62e9:1:7171:d37a:589b:90b6]) by mx.google.com with ESMTPS id c1sm3265045pay.19.2012.10.11.16.04.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Oct 2012 16:04:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Andrew McGregor In-Reply-To: <201210111708.q9BH8InG013834@bagheera.jungle.bt.co.uk> Date: Fri, 12 Oct 2012 12:04:02 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <740561B2-4C9C-40BA-BDA3-7AF70222BE01@gmail.com> References: <201210111708.q9BH8InG013834@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1498) Cc: gorry@erg.abdn.ac.uk, philip.eardley@bt.com, tsvwg IETF list , tsvwg-chairs@ietf.org Subject: Re: [tsvwg] Fwd: RE: [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest 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, 11 Oct 2012 23:04:19 -0000 Bob, The CoDel constant called 'target' is not a target delay, it's really a = measurement interval. The actual achieved delay is much, much smaller = than 'target' on nearly any link. Target and Interval actually set = bounds on how long the latency can spike for, in a fairly convoluted = way. I have no idea why that constant is called Target, but then I can't = think of a better name for it either. 'ShortInterval' might be as good = as you can do for a name. Andrew On 12/10/2012, at 6:08 AM, Bob Briscoe wrote: > Hannes, >=20 > Brainfart - sorry. for 'CoDel's 100ms target', read 5ms. >=20 > Still crazy for hi-speed. >=20 >=20 > Bob >=20 >> Date: Thu, 11 Oct 2012 17:06:57 +0100 >> To: "Tschofenig, Hannes (NSN - FI/Espoo)" >> From: Bob Briscoe >> Subject: RE: [tsvwg] [REVISED I-D]: Document writeup for = draft-ietf-tsvwg-byte-pkt-congest >> Cc: ext Manner Jukka , , = , , tsvwg IETF list = >>=20 >> Hannes, >>=20 >> This doc is very general. The advice on AQM not biasing for small = packets applies equally to CoDel as to RED (it has already been applied = to PCN, which is another AQM). The doc gives specific advice for RED as = an exemplar, but it's not just about RED (it's worrying that you think = it is - which text gave this impression?). Everywhere that RED is = mentioned, the wording should carefully say it's an example. >>=20 >> Similarly, it gives guidelines on end-to-end transports, and uses TCP = as an concrete example. >>=20 >> [Changing the subject to "Who said CoDel is a panacea anyway?" CoDel = isn't really applicable on hi-speed links, certainly not if one wants = the main benefit of being insensitive to the chosen hard-coded = parameters. Even in the CoDel paper's simulations, CoDel gave higher = queuing delay than RED in all the cases shown except the lowest link = speed experiments. CoDel's 100ms target would be a crazy delay target in = a high speed network. To deploy CoDel in hi-speed networks, you have to = tune the parameters away from the hard-coded ones, which loses the only = benefit it has. >> ] >>=20 >>=20 >> Bob >>=20 >> At 13:57 11/10/2012, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>> Hi Jukka, >>>=20 >>> With QoS there is no such thing as "short term" (as we already had = to >>> learn painfully). >>>=20 >>> That makes me wonder what is more useful: publish a document that >>> describe how to configure RED correctly or to go for an AQM = technique >>> that (according to the authors) works almost zero configuration. >>>=20 >>> My take-away from the Vancouver congestion control workshop was that = it >>> is better to ignore RED. (Maybe my impression was wrong -- someone = else >>> should confirm.) >>>=20 >>> Ciao >>> Hannes >>>=20 >>>=20 >>> > -----Original Message----- >>> > From: ext Manner Jukka [mailto:jukka.manner@aalto.fi] >>> > Sent: Thursday, October 11, 2012 3:50 PM >>> > To: Tschofenig, Hannes (NSN - FI/Espoo) >>> > Cc: Bob Briscoe; ; ; >>> > ; tsvwg IETF list >>> > Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for = draft-ietf- >>> > tsvwg-byte-pkt-congest >>> > >>> > Hi, this document talks about the current and short term goals and >>> > operations, while AFAIK CoDel is a more futuristic concept, >>> interesting >>> > concept, sure, but not deployed at large. >>> > >>> > cheers, >>> > Jukka >>> > >>> > On Oct 11, 2012, at 3:44 PM, Tschofenig, Hannes (NSN - FI/Espoo) >>> wrote: >>> > >>> > > Hi Jukka, Hi Bob, >>> > > >>> > > having listened to the presentations about CoDel I am wondering >>> > whether >>> > > this document may have taken over by events and is obsolete by = now. >>> > > What's your view on that? >>> > > >>> > > Ciao >>> > > Hannes >>> > > >>> > > >>> > >> -----Original Message----- >>> > >> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On >>> > Behalf >>> > >> Of ext Manner Jukka >>> > >> Sent: Thursday, October 11, 2012 3:34 PM >>> > >> To: Bob Briscoe >>> > >> Cc: ; ; >> > >> chairs@ietf.org>; tsvwg IETF list >>> > >> Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for >>> draft-ietf- >>> > >> tsvwg-byte-pkt-congest >>> > >> >>> > >> Hi, >>> > >> >>> > >> Yeah, please at the point about cheap devices, still, I wonder = what >>> > > the >>> > >> cost of AQM is on those devices. Maybe 1 cnt in mass = production? >>> > Thus, >>> > >> I still wonder if it is worth arguing something about the = future >>> > that >>> > >> strongly. >>> > >> >>> > >> Sorry, but the same goes for AQM in general, and where it is, = or >>> > will >>> > >> not be deployed. I understand technical reasons why not = something >>> is >>> > >> feasible, but business or monetary reasons can change very = quickly. >>> > ;) >>> > >> >>> > >> Jukka >>> > >> >>> > >> On Oct 11, 2012, at 3:08 PM, Bob Briscoe wrote: >>> > >> >>> > >>> Jukka, >>> > >>> >>> > >>> What I had in mind is all low level buffers in cheap pure L2 >>> > > devices, >>> > >> in cheap NATs etc. I was going to list some of these, but = instead >>> > > chose >>> > >> to say "no-one expects AQM to be universally deployed". This >>> clearly >>> > >> missed the mark. >>> > >>> >>> > >>> Should we include some of these concrete examples of where AQM >>> > won't >>> > >> be deployed instead? >>> > >>> >>> > >>> [I've cc'd the list, given we're starting to wordsmith >>> > significantly >>> > >> new text added since WG last call.] >>> > >>> >>> > >>> >>> > >>> Bob >>> > >>> >>> > >>> At 20:04 10/10/2012, Manner Jukka wrote: >>> > >>>> Hi, looked good to me. Just one comment, I wouldn't put that = much >>> > >> emphasis on what is a probably state of things, e.g. >>> > >>>> >>> > >>>> "no-one expects AQM to ever be .." > in the future it might, = we >>> > >> don't know, and since the paragraph says that it doesn't matter >>> > > anyway, >>> > >> I would formulate this paragraph a bit towards that we have = partial >>> > >> deployment now and even with a full deployment, ... >>> > >>>> >>> > >>>> and similarly with the unrealistic deployment of AQM in the >>> > >> subsequent paragraph. >>> > >>>> >>> > >>>> cheers, >>> > >>>> Jukka >>> > >>>> >>> > >>>> On Oct 10, 2012, at 6:25 PM, Bob Briscoe wrote: >>> > >>>> >>> > >>>>> Phil, >>> > >>>>> >>> > >>>>> Sorry for delay, my round-robin scheduler is taking so long = to >>> > > get >>> > >> round all the tasks that I keep finding dead robins (that = reminds >>> me >>> > > of >>> > >> a bike ride my grandmother took. On her return, she said there = were >>> > a >>> > >> worryingly large number of robins run over on the roads. It = turned >>> > out >>> > >> that she had been going round the same small triangle of roads >>> > > multiple >>> > >> times). >>> > >>>>> >>> > >>>>> I've done a complete re-write of 3.4. I hope you will agree = that >>> > >> it really is a motivating argument now and it can stay where it = is >>> - >>> > > it >>> > >> is not just a preamble. >>> > >>>>> >>> > >>>>> I've gone back to the very first version of 3.4 I wrote and = I >>> now >>> > >> realise that I had written the core of the argument so badly = that >>> > even >>> > >> I forgot what it was meant to say when we started editing it. = In >>> the >>> > >> draft-08 version, the original meaning is lost and in your re- >>> > wording >>> > >> it is entirely lost. The link with the draft-08 version is = nearly >>> > >> unrecognisable, but it's the argument I intended here. >>> > >>>>> >>> > >>>>> >>> > >> >>> > > >>> > >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> > >>>>> 3.4. Permanent Partial Deployment of AQM >>> > >>>>> >>> > >>>>> In overview, the argument in this section runs as follows: >>> > >>>>> * Because the network will not and cannot always drop = packets in >>> > >> proportion to their size, it shouldn't be given the task of = making >>> > > drop >>> > >> signals depend on packet size at all. >>> > >>>>> * Transports on the other hand don't always want to make = their >>> > >> rate response proportional to the size of dropped packets, but = if >>> > they >>> > >> want to, they always can. >>> > >>>>> >>> > >>>>> The argument is similar to the end-to-end argument that says >>> > >> "Don't do X in the network if end-systems can do X by = themselves, >>> > and >>> > >> they want to be able to choose whether to do X anyway." = Actually >>> the >>> > >> following argument is stronger; in addition it says "Don't give = the >>> > >> network task X that could be done by the end-systems, if X = won't >>> > ever >>> > >> be deployed on all network nodes, and end-systems won't be able = to >>> > > tell >>> > >> whether their network is doing X, or whether they need to do X >>> > >> themselves." In this case, the X in question is "making the >>> response >>> > > to >>> > >> congestion depend on packet size". >>> > >>>>> >>> > >>>>> We will now re-run this argument taking each step in more = depth. >>> > >> The argument applies solely to drop, not ECN marking. >>> > >>>>> >>> > >>>>> A queue drops packets for either of two reasons: a) to = signal to >>> > >> host congestion controls that they should reduce the load and = b) >>> > >> because there is no buffer left to store the packets. Active = queue >>> > >> management tries to use drops as a signal for hosts to slow = down >>> > (case >>> > >> a) so that drop due to buffer exhaustion (case b) should not be >>> > >> necessary. >>> > >>>>> >>> > >>>>> No-one expects AQM to ever be universally deployed in every >>> queue >>> > >> in the Internet; and, even if AQM were universal, it has to be = able >>> > to >>> > >> cope with buffer exhaustion (by switching to a behaviour like = tail- >>> > >> drop), in order to cope with unresponsive or excessive = transports. >>> > >> Therefore networks will often be dropping packets as a last = resort >>> > >> (case b) rather than under AQM control (case a). >>> > >>>>> >>> > >>>>> When buffers are exhausted (case b), they don't naturally = drop >>> > >> packets in proportion to their size. The network can only = reduce >>> the >>> > >> probability of dropping smaller packets if it has enough space = to >>> > > store >>> > >> them somewhere while it waits for a larger packet that it can = drop. >>> > If >>> > >> the buffer is exhausted, it does not have this choice. = Admittedly >>> > > tail- >>> > >> drop does naturally drop somewhat fewer small packets, but = exactly >>> > how >>> > >> few depends more on the mix of sizes than the size of the = packet in >>> > >> question. Nonetheless, in general, if we wanted networks to do >>> size- >>> > >> dependent drop, we would need universal deployment of = (packet-size >>> > >> dependent) AQM code, which is unrealistic. >>> > >>>>> >>> > >>>>> A host transport cannot know whether any particular drop was = a >>> > >> deliberate signal from an AQM or a sign of a queue shedding = packets >>> > > due >>> > >> to buffer exhaustion. Therefore, because the network cannot >>> > > universally >>> > >> do size-dependent drop, it should not do it all. >>> > >>>>> >>> > >>>>> Whereas universality is desirable in the network, diversity = is >>> > >> desirable between different transport layer protocols - some, = like >>> > >> NewReno TCP [RFC5681], may not choose to make their rate = response >>> > >> proportionate to the size of each dropped packet, while others = will >>> > >> (e.g. TFRC-SP [RFC4828]). >>> > >>>>> >>> > >> >>> > > >>> > >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> > >>>>> >>> > >>>>> >>> > >>>>> >>> > >>>>> >>> > >>>>> Bob >>> > >>>>> >>> > >>>>> At 13:13 04/10/2012, gorry@erg.abdn.ac.uk wrote: >>> > >>>>>> That would be brilliant! >>> > >>>>>> >>> > >>>>>> Gorry >>> > >>>>>> >>> > >>>>>>> Will try to look at this later today. >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> Bob >>> > >>>>>>> >>> > >>>>>>> At 10:42 02/10/2012, philip.eardley@bt.com wrote: >>> > >>>>>>>> Think the token is with bob >>> > >>>>>>>> >>> > >>>>>>>> Re your comment - yes, I think you could move 3.4 to the = end >>> > > of >>> > >> S3 - >>> > >>>>>>>> or to the start - and do some re-phrasing, maybe = something >>> > > like >>> > >> I tried. >>> > >>>>>>>> >>> > >>>>>>>> -----Original Message----- >>> > >>>>>>>> From: Manner Jukka [mailto:jukka.manner@aalto.fi] >>> > >>>>>>>> Sent: 01 October 2012 20:18 >>> > >>>>>>>> To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,Bob,DUB8 R >>> > >>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst >>> > >>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for >>> > >>>>>>>> draft-ietf-tsvwg-byte-pkt-congest >>> > >>>>>>>> >>> > >>>>>>>> Phil, Bob, can we close this finally? It's three weeks = now >>> > >> since >>> > >>>>>>>> this previous message. >>> > >>>>>>>> >>> > >>>>>>>> Jukka >>> > >>>>>>>> >>> > >>>>>>>> On Sep 10, 2012, at 4:42 PM, Jukka Manner wrote: >>> > >>>>>>>> >>> > >>>>>>>>> Ack, I'm getting there...;) >>> > >>>>>>>>> >>> > >>>>>>>>> So, we could move 3.4 at the end of Section 3 and = rephrase >>> > >> it to >>> > >>>>>>>> not talk about scaling per se, but rather about how Req = 2.2 >>> > >>>>>>>> eventually leads to Req 2.3? >>> > >>>>>>>>> >>> > >>>>>>>>> Jukka >>> > >>>>>>>>> >>> > >>>>>>>>> On Sep 7, 2012, at 4:07 PM, >>> > >>>>>>>>> wrote: >>> > >>>>>>>>> >>> > >>>>>>>>>> 3.4 is, in my mind, completely different from 3.1, 3.2, >>> > > 3.3 >>> > >> and 3.5. >>> > >>>>>>>>>> >>> > >>>>>>>>>> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for >>> > >> Recommendation >>> > >>>>>>>>>> 2.2 & a lesser extent 2.3 >>> > >>>>>>>>>> 3.4 makes doesn't make a motivating argument - it = explains >>> > >> that Rec >>> > >>>>>>>>>> 2.2 & 2.3 come as a pair (if you recommend one, then >>> > >> inevitably you >>> > >>>>>>>>>> recommend the other) (delta some politeness about TCP) >>> > >>>>>>>>>> >>> > >>>>>>>>>> >>> > >>>>>>>>>> >>> > >>>>>>>>>> -----Original Message----- >>> > >>>>>>>>>> From: Manner Jukka [mailto:jukka.manner@aalto.fi] >>> > >>>>>>>>>> Sent: 07 September 2012 13:24 >>> > >>>>>>>>>> To: Eardley,PL,Philip,DUB8 R >>> > >>>>>>>>>> Cc: Briscoe,RJ,Bob,DUB8 R; ; >>> > >>>>>>>>>> >>> > >>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for >>> > >>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest >>> > >>>>>>>>>> >>> > >>>>>>>>>> Hi, I'm trying to follow your reasoning, with little = luck. >>> > >> ;) >>> > >>>>>>>>>> >>> > >>>>>>>>>> After having read Section 3 again, I could think of a = few >>> > >>>>>>>> updates, but I'm not fully following what you want to = see: >>> > >>>>>>>>>> >>> > >>>>>>>>>> - S3.5 is kind of small and lonely by itself. It could = be >>> > >> either >>> > >>>>>>>> longer or merged somewhere. Not a major issue though and >>> > > could >>> > >> remain as >>> > >>>>>>>> is. >>> > >>>>>>>>>> >>> > >>>>>>>>>> - S3.3: Yes, probably could be turned upside down, good >>> > >> first, >>> > >>>>>>>> bad later. Don't have a strong opinion. >>> > >>>>>>>>>> >>> > >>>>>>>>>> - S3.4: Here the scaling is used many times and in the >>> > >> title, >>> > >>>>>>>> although we talk about the end host side. This could be >>> > >> rephrased >>> > >>>>>>>> and slightly reworded to talk about hosts and their = operation >>> > >>>>>>>> altogether. Also the word scaling can turn the readers >>> > >> expectation >>> > >>>>>>>> into the wrong direction. >>> > >>>>>>>>>> >>> > >>>>>>>>>> - S3 altogether: It would help to have introductory = text >>> > >> about >>> > >>>>>>>> networks vs. end host side, but I fail to see why (& = how) to >>> > >>>>>>>> restructure everything. >>> > >>>>>>>>>> >>> > >>>>>>>>>> cheers, >>> > >>>>>>>>>> Jukka >>> > >>>>>>>>>> >>> > >>>>>>>>>> On Sep 6, 2012, at 6:18 PM, >>> > >>>>>>>> wrote: >>> > >>>>>>>>>> >>> > >>>>>>>>>>> Ps otherwise Bob's comments are fine, though I suggest >>> > > for >>> > >> S3.5 you >>> > >>>>>>>>>>> give more context (ie are you knocking down what you >>> > >> recommend >>> > >>>>>>>>>>> against, or building up what you recommend?) and in = S3.3 >>> > >> think >>> > >>>>>>>>>>> would be better if you re-structured slightly [first = talk >>> > >> about what >>> > >>>>>>>>>>> you like - penult para + 1st sentence of last para - = then >>> > >> talk about >>> > >>>>>>>>>>> what you don't like - rest of text] >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> From: Eardley,PL,Philip,DUB8 R >>> > >>>>>>>>>>> Sent: 06 September 2012 16:12 >>> > >>>>>>>>>>> To: Briscoe,RJ,Bob,DUB8 R; Manner Jukka >>> > >>>>>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst >>> > >>>>>>>>>>> Subject: RE: [REVISED I-D]: Document writeup for >>> > >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> Thanks bob. Have now re-booted some state. >>> > >>>>>>>>>>> I don't like S3.4. My basic problem with it is that it >>> > >> isn't a >>> > >>>>>>>> "motivating argument" (S3 title). It's an explanation = about >>> > >> the >>> > >>>>>>>> consequences of assuming either [option 1] do pkt-size >>> > > biasing >>> > >> in >>> > >>>>>>>> the transport; [option 2]; do pkt-size biasing in the nw. >>> > >>>>>>>>>>> Perhaps your effort to buy peace with those who won't >>> > >> change >>> > >>>>>>>> TCP has obfuscated the basic point? >>> > >>>>>>>>>>> The title of S3.4 (Scaling...) and the early text >>> > > "scaling >>> > >>>>>>>> argument" suggests that you're going to argue there is = some >>> > >> reason >>> > >>>>>>>> why X scales as order N rather than N^2 or something like >>> > > that >>> > >> - >>> > >>>>>>>> which isn't what S3.4 is about. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> I actually think it would be better to put S3.4 at the >>> > >> start of >>> > >>>>>>>> S3 - it's background where you say there are 2 options. = After >>> > >> that, >>> > >>>>>>>> you can explain the reasons why option 1 [pkt biasing in = the >>> > >>>>>>>> transport] is better - the reasons being:- S3.1 = (security >>> > > etc >>> > >>>>>>>> attacks if small pkts get preferential treatment), S3.2 >>> > >> (really a >>> > >>>>>>>> side note to S3.1; ie doesn't really present a = "motivating >>> > >>>>>>>> argument"), S3.3 (nw guessing MTU vs transport knowing = pkt >>> > >> size), >>> > >>>>>>>> S3.5 (easier implementation). >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> Something like... >>> > >>>>>>>>>>> The behaviour of the network and transport together = needs >>> > >> to >>> > >>>>>>>>>>> alleviate congestion. We assume the network is bit- >>> > >> congestible >>> > >>>>>>>> (currently packet-congestible resources are rate). = Therefore >>> > >>>>>>>> overall the response of the {network + transport} should = be >>> > >> the >>> > >>>>>>>> same for the same congestion - whether the congestion is >>> > >> caused by >>> > >>>>>>>> a lot of small packets or a smaller number of larger = packets. >>> > >> The >>> > >>>>>>>> implication is that the transport's behaviour should = depend >>> > > on >>> > >>>>>>>> whether the network takes account (or not) of packet size >>> > > when >>> > >> it >>> > >>>>>>>> generates congestion indications:- Case 1: If the network >>> > >>>>>>>> implements packet-mode drop, ie its algorithm treats all >>> > >> packets >>> > >>>>>>>> equally regardless of their size, then the transport = should >>> > >> take >>> > >>>>>>>> account of the size of the packet - in other words, the >>> > >> transport's >>> > >>>>>>>> congestion response should depend on the number of = dropped >>> > >> bytes. >>> > >>>>>>>>>>> Case 2: If the network implements byte-mode drop, ie = its >>> > >>>>>>>> algorithm treats packets differently depending on their = size, >>> > >> then >>> > >>>>>>>> the transport should not take account of the size of the >>> > >> packet - >>> > >>>>>>>> in other words, the transport's congestion response = should >>> > >> depend >>> > >>>>>>>> on the number of dropped packets. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> These cases are explained in more detail in = sub-section >>> > >> below. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> In both cases the same discussion applies if packets = are >>> > >>>>>>>> ECN-marked rather than dropped. >>> > >>>>>>>>>>> In the following sections we explain why Case 1 is >>> > >> preferable, >>> > >>>>>>>> and hence why we make the Recommendations of S2.2 and = S3.3 >>> > >>>>>>>> (respectively, drop/mark pkts equally regardless of their >>> > >> size, and >>> > >>>>>>>> the strength of the transport's response should be >>> > >> proportionate to >>> > >>>>>>>> the size of the dropped/marked pkt). >>> > >>>>>>>>>>> Note that TCP responds to dropped or marked packets, >>> > > which >>> > >> differs >>> > >>>>>>>>>>> from our recommendation for transports. However, we = are >>> > >> not >>> > >>>>>>>>>>> recommending that TCP should be changed; to date it >>> > >> hasn't been a >>> > >>>>>>>>>>> significant problem because most TCP implementations >>> > > have >>> > >> been >>> > >>>>>>>> used with similar packet sizes. But we do recommend that >>> > >> future >>> > >>>>>>>> transport protocols should respond to dropped or marked >>> > > bytes >>> > >> (as >>> > >>>>>>>> for example TFRC-SP [RFC4828]effectively does). >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> Sub-section >>> > >>>>>>>>>>> You could use much of S3.3, I suggest supplement with >>> > >> numerical >>> > >>>>>>>>>>> examples continuing S1.2 >>> > >>>>>>>>>>> -- >>> > >>>>>>>>>>> << This gives a get-out clause to any transport that >>> > > isn't >>> > >>>>>>>>>>> packet-size dependent (e.g. current TCP). Lacking = packet- >>> > >> size >>> > >>>>>>>>>>> dependence just means they don't scale correctly with >>> > >> packet size - >>> > >>>>>>>>>>> but they are at liberty not to scale with packet size >>> > >> (particularly >>> > >>>>>>>>>>> given MTU growth isn't often being used to increase = link >>> > >> rates at >>> > >>>>>>>>>>> this stage in history).>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> This is introducing a different point. it's saying = that >>> > >> your >>> > >>>>>>>> recommendation 2 [drop/mark pkts equally regardless of = their >>> > >> size] >>> > >>>>>>>> is a really strong reco whilst recommendation 3 [strength = of >>> > >>>>>>>> transport's response proportionate to the size of the >>> > >>>>>>>> dropped/marked pkt] is a much less important reco. I can = see >>> > >> this >>> > >>>>>>>> might be true, but I don't think the i-d talks about = this. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> -- >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> From: Briscoe,RJ,Bob,DUB8 R >>> > >>>>>>>>>>> Sent: 05 September 2012 16:41 >>> > >>>>>>>>>>> To: Manner Jukka >>> > >>>>>>>>>>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst; >>> > >> Eardley,PL,Philip,DUB8 R >>> > >>>>>>>>>>> Subject: Re: [REVISED I-D]: Document writeup for >>> > >>>>>>>>>>> draft-ietf-tsvwg-byte-pkt-congest >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> Jukka, >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> I've repeated Phil's suggestions as quoted email then >>> > > made >>> > >> some >>> > >>>>>>>> alterations. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> Phil asked me to send this, then he will think about = it. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> I'll respond about John Leslie's argument next... >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> 2.2. Recommendation on Encoding Congestion = Notification >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> [...] >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> 1. AQM algorithms such as RED SHOULD use packet-mode >>> > >> drop, ie they >>> > >>>>>>>>>>> SHOULD NOT use byte-mode drop. The latter is more >>> > >> complex, >>> > >>>>>>>>>>> it creates the perverse incentive to fragment >>> > >> segments into >>> > >>>>>>>> tiny >>> > >>>>>>>>>>> pieces and it is vulnerable to floods of small >>> > >> packets. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> 2. If a vendor has implemented byte-mode drop, and an >>> > >> operator has >>> > >>>>>>>>>>> turned it on, it is RECOMMENDED to turn it off, >>> > > after >>> > >>>>>>>> establishing >>> > >>>>>>>>>>> if there are any implications on the relative >>> > >> performance of >>> > >>>>>>>>>>> applications using different packet sizes. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> RED as a whole SHOULD NOT be turned off. Without >>> > > RED, >>> > >> a drop >>> > >>>>>>>> tail >>> > >>>>>>>>>>> queue biases against large packets >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> [BB adds]: and it is >>> > >> vulnerable to >>> > >>>>>>>> floods >>> > >>>>>>>>>>> of small-packets. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> (I suggest the last para just qualifies item 2. It >>> > > doesn't >>> > >> warrant >>> > >>>>>>>>>>> another item number.) >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> [PE:] S3.3 >>> > >>>>>>>>>>> The section could be slightly clearer. Starting with = the >>> > >> second >>> > >>>>>>>> para, where you start talking about something you don't >>> > >> recommend >>> > >>>>>>>> (ie you have to remember that you're talking about the >>> > >> consequences >>> > >>>>>>>> of not following your recommendation). >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> 3.3 Transport-Independent Network >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> TCP congestion control ensures that flows competing = for >>> > >> the same >>> > >>>>>>>>>>> resource each maintain the same number of segments in >>> > >> flight, >>> > >>>>>>>>>>> irrespective of segment size. So under similar >>> > >> conditions, flows >>> > >>>>>>>>>>> with different segment sizes will get different >>> > > bit-rates. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> [OLD:] >>> > >>>>>>>>>>> One motivation for the network biasing congestion >>> > >> notification by >>> > >>>>>>>>>>> packet size is to counter this effect and try to = equalise >>> > >> the bit- >>> > >>>>>>>>>>> rates of flows with different packet sizes. >>> > >>>>>>>>>>> [SUGGESTED:] >>> > >>>>>>>>>>> To counter this effect it seems tempting not to follow >>> > >> our >>> > >>>>>>>>>>> recommendation, and instead for the network to bias >>> > >> congestion >>> > >>>>>>>>>>> notification by packet size in order to equalise the >>> > > bit- >>> > >> rates of >>> > >>>>>>>>>>> flows with different packet sizes. >>> > >>>>>>>>>>> [CONTINUE AS BEFORE:] >>> > >>>>>>>>>>> However, in order to do this, the = queuing >>> > >> algorithm >>> > >>>>>>>>>>> has to make assumptions about the transport, which >>> > > become >>> > >> embedded >>> > >>>>>>>>>>> in the network. Specifically: >>> > >>>>>>>>>>> [...] >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> S3.3 >>> > >>>>>>>>>>> o The queuing algorithm has to assume how = aggressively >>> > >> the >>> > >>>>>>>> transport >>> > >>>>>>>>>>> will respond to congestion (see Section 4.2.4). If >>> > >> the network >>> > >>>>>>>>>>> assumes the transport responds as aggressively as = TCP >>> > >> NewReno, >>> > >>>>>>>> it >>> > >>>>>>>>>>> will be wrong for Compound TCP and differently = wrong >>> > >> for Cubic >>> > >>>>>>>>>>> TCP, etc. To achieve equal bit-rates, each = transport >>> > >> then has >>> > >>>>>>>> to >>> > >>>>>>>>>>> guess what assumption the network made, and work = out >>> > >> how to >>> > >>>>>>>>>>> replace this assumed aggressiveness with its own >>> > >> aggressiveness. >>> > >>>>>>>>>>> o Also, if the network biases congestion notification >>> > > by >>> > >> packet >>> > >>>>>>>> size >>> > >>>>>>>>>>> it has to assume a baseline packet size--all = proposed >>> > >> algorithms >>> > >>>>>>>>>>> use the local MTU. Then transports have to guess >>> > >> which link was >>> > >>>>>>>>>>> congested and what its local MTU was, in order to >>> > > know >>> > >> how to >>> > >>>>>>>>>>> tailor their congestion response to that link. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> So you're saying that for byte-mode drop, the network >>> > >> element >>> > >>>>>>>> has to compare the size of the current pkt with the MTU, = and >>> > >> if >>> > >>>>>>>> it's 25* smaller then reduce the pkt loss probably by = 25*? >>> > > And >>> > >> if >>> > >>>>>>>> the MTU was bigger, then the current pkt would be dropped >>> > > with >>> > >>>>>>>> greater probability? And both of these things are hard to = do. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> [BB]: SUGGESTED REPLACEMENT to 2nd bullet: >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> o Also, if the network biases congestion notification >>> > > by >>> > >> packet >>> > >>>>>>>> size >>> > >>>>>>>>>>> it has to assume a baseline packet size--all = proposed >>> > >> algorithms >>> > >>>>>>>>>>> use the local MTU (for example see the byte-mode = loss >>> > >>>>>>>> probability >>> > >>>>>>>>>>> formula in Table 1). Then if the non-Reno = transports >>> > >> mentioned >>> > >>>>>>>> above >>> > >>>>>>>>>>> are trying to reverse engineer what the network >>> > >> assumed, they >>> > >>>>>>>> also >>> > >>>>>>>>>>> have to guess the MTU of the congested link. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> [Aside for Phil: The byte-mode algo uses MTU as its >>> > >> baseline because >>> > >>>>>>>>>>> a link cannot send a packet bigger than its MTU so the >>> > >> algo won't >>> > >>>>>>>>>>> ever give a drop probability >1).] >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> S3.4 (& knock-on effect on 3.3) >>> > >>>>>>>>>>> I think this could be better. >>> > >>>>>>>>>>> I agree with your arguments in S3.1 & 3.2 that = dropping >>> > > or >>> > >>>>>>>> marking should be independent of pkt size. >>> > >>>>>>>>>>> You now go into a couple of pages, which I think could = be >>> > >> boiled >>> > >>>>>>>>>>> down to a paragraph, saying something like:- >>> > >>>>>>>>>>> * the overall system (network + transport) has to be >>> > >> packet-size >>> > >>>>>>>>>>> dependent in order to drive out the right amount of >>> > >> traffic so the >>> > >>>>>>>>>>> resource becomes uncongested (since we assume all >>> > >> resources are in >>> > >>>>>>>>>>> practice byte rather than packet limited) >>> > >>>>>>>>>>> * from S3.1 and S3.2 the IETF is convinced that the >>> > >> network >>> > >>>>>>>> should notify independent of packet-size. >>> > >>>>>>>>>>> * therefore the transport must act dependent on = packet- >>> > >> size. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> It seems to me this is a necessary consequence of your >>> > >> earlier >>> > >>>>>>>> assumptions /arguments. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> [BB:] This isn't at all obvious. Until I worked it >>> > >> through, it >>> > >>>>>>>> wasn't obvious to me. I think it needs to be spelled out. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> [On the other hand, if someone disagrees with the >>> > >> arguments and >>> > >>>>>>>>>>> thinks that the network should notify dependent on >>> > > packet- >>> > >> size, then >>> > >>>>>>>>>>> it follows that the transport can act independent of >>> > >> packet-size.] >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> I think in S3.3 you're trying to make another argument >>> > >> (?):- >>> > >>>>>>>>>>> * we can either do packet-size biasing in the network >>> > >> element or on >>> > >>>>>>>>>>> the end host transport (see argument above) >>> > >>>>>>>>>>> * packet-size biasing in the network is quite tricky, >>> > >> because >>> > >>>>>>>> then both the network element & the transport have to = make >>> > >> some >>> > >>>>>>>> guesses about MTU - whereas with packet-size biasing in = the >>> > >>>>>>>> transport, neither network element nor transport needs to >>> > > know >>> > >> what the >>> > >>>>>>>> MTU is. >>> > >>>>>>>>>>> * it is also easier to implement packet-size biasing = in >>> > >> the >>> > >>>>>>>> transport than in the network. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> [BB] ...and all the other arguments about = vulnerability >>> > > to >>> > >>>>>>>> flooding etc, transport-independence etc. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> Our argument is sort of like how Phil summarises it, = but >>> > >> with >>> > >>>>>>>> an added nuance. It's also saying no-one has to do >>> > > packet-size >>> > >>>>>>>> biasing anyway. It's not saying "The transport should = given >>> > >> the >>> > >>>>>>>> network shouldn't". It's saying "*If the transport wants = to >>> > >> claim >>> > >>>>>>>> to be scalable wrt packet size* it should if the network >>> > >> shouldn't". >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> This gives a get-out clause to any transport that = isn't >>> > >>>>>>>> packet-size dependent (e.g. current TCP). Lacking = packet-size >>> > >>>>>>>> dependence just means they don't scale correctly with = packet >>> > >> size - >>> > >>>>>>>> but they are at liberty not to scale with packet size >>> > >> (particularly >>> > >>>>>>>> given MTU growth isn't often being used to increase link >>> > > rates >>> > >> at >>> > >>>>>>>> this stage in history). >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> None of what Phil says convinces me we could say 3.4 = (or >>> > >> 3.3) >>> > >>>>>>>> any more briefly or differently. It's easier to summarise >>> > > what >>> > >> you >>> > >>>>>>>> understand having read something. But that's not the same = as >>> > >>>>>>>> writing the thing that helped you understand. There = doesn't >>> > >> seem to >>> > >>>>>>>> be any argument for why anything needs to be changed, so = I'm >>> > >> going >>> > >>>>>>>> to leave it as is, unless pushed. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> On the last bullet, I didn't really follow your = argument >>> > >> in >>> > >>>>>>>> S3.5. Might be easier to follow if S3.5 also talked about = how >>> > >> a >>> > >>>>>>>> network element would take account of pkt size? >>> > >>>>>>>>>>> Also, does the following argument also apply?: >>> > >>>>>>>>>>> * if pkt-size biasing is done in the transport, then = the >>> > >> work (to do >>> > >>>>>>>>>>> the biasing) is spread over many end hosts, >>> > >>>>>>>>>>> * whereas if pkt-size biasing is done in the network, >>> > > then >>> > >> the >>> > >>>>>>>> work is concentrated in just the congested network = element, >>> > >> which >>> > >>>>>>>> has to operate on all the traffic at line speed. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> [BB]: 3.5. Implementation Efficiency >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> [ADD:] >>> > >>>>>>>>>>> Biasing against large packets typically requires an >>> > > extra >>> > >> multiply >>> > >>>>>>>>>>> and divide in the network (see the example byte-mode >>> > > drop >>> > >>>>>>>> formula in table 1). >>> > >>>>>>>>>>> [CONTINUE AS BEFORE:] >>> > >>>>>>>>>>> Allowing for packet size at the transport rather than = in >>> > >> the >>> > >>>>>>>>>>> network ensures that neither the network nor the >>> > >> transport needs to >>> > >>>>>>>>>>> do a multiply operation--multiplication by packet = size >>> > > is >>> > >>>>>>>>>>> effectively achieved as a repeated add when the >>> > > transport >>> > >> adds to >>> > >>>>>>>>>>> its count of marked bytes as each congestion event is >>> > > fed >>> > >> to it. >>> > >>>>>>>>>>> [ADD:] >>> > >>>>>>>>>>> Also the work to do the biasing is spread over many >>> > >> hosts, rather >>> > >>>>>>>>>>> than concentrated in just the congested network = element. >>> > >>>>>>>>>>> [CONTINUE AS BEFORE:] >>> > >>>>>>>>>>> >>> > > These >>> > >> aren't >>> > >>>>>>>>>>> principled reasons in themselves, but they are a happy >>> > >> consequence >>> > >>>>>>>>>>> of the other principled reasons. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> Bob >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> At 13:36 05/09/2012, Manner Jukka wrote: >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> Hi Bob, >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> Since Phil is your colleague at BT, even at Ipswich = (?), >>> > >> can >>> > >>>>>>>> you check those and agree with Phil how to go forward? = Some >>> > > of >>> > >>>>>>>> those are clear, others need discussion with Phil. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> Gorry, on point 2) below, I don't follow Leslie's >>> > >> arguments. I >>> > >>>>>>>> asked from him detailed comments and resolutions months = ago, >>> > >> and nothing >>> > >>>>>>>> came. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> cheers, >>> > >>>>>>>>>>> Jukka >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> On Sep 5, 2012, at 3:26 PM, Gorry Fairhurst wrote: >>> > >>>>>>>>>>> >>> > >>>>>>>>>>>> Bob and Jukka, >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> I think I need your help to resolve this... Some of = the >>> > >>>>>>>> comments raised by John Leslie appear to have substance, = and >>> > >> I'm >>> > >>>>>>>> not sure what you plan to do to address these. >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> It would be good to do something quick so that I can >>> > >> complete >>> > >>>>>>>> the submission to the IESG. >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> The issues I particularly note are: >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> 1) This contribution from Phil appears to be within >>> > > scope >>> > >> and >>> > >>>>>>>> it seems may have been overlooked (sorry): >>> > >>>>>>>>>>>> http://www.ietf.org/mail- >>> > >> archive/web/tsvwg/current/msg11234.html >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> 2) Can you be clear here about what is actually been >>> > > said >>> > >> - >>> > >>>>>>>> because the point below seems to be a misunderstanding of >>> > >> language >>> > >>>>>>>> to me, and I hoped we did not claim this: >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find >>> > > that >>> > >> Bob is >>> > >>>>>>>>>>>>>> actually ] saying that transport-layer should = _only_ >>> > >> consider >>> > >>>>>>>>>>>>>> "congested bytes", not ] "congested packets". >>> > >>>>>>>>>>>>>> ] >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> 3) You'll need to post the updated draft and send a = note >>> > >> to >>> > >>>>>>>> the group to confirm that the new version indeed = concludes >>> > > the >>> > >>>>>>>> WGLC. I'll add a note to the writeup to indicate the = draft >>> > >> content >>> > >>>>>>>> has been stable since Oct 2011. >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> Gorry (with my TSVWG Documnent Shepherd hat) >>> > >>>>>>>>>>>> cc: Co-Chairs for info. >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> -----Original Message----- >>> > >>>>>>>>>>>>>> From: Gorry Fairhurst [ = mailto:gorry@erg.abdn.ac.uk] >>> > >>>>>>>>>>>>>> Sent: Mittwoch, 15. August 2012 21:41 >>> > >>>>>>>>>>>>>> To: tsvwg chair >>> > >>>>>>>>>>>>>> Subject: Fwd: Re: [tsvwg] FYI: Document writeup for >>> > >>>>>>>>>>>>>> draft-ietf-tsvwg- byte-pkt-congest >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Hi guys, >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Apart form the usual rhetoric, there are some = points >>> > >> here that we >>> > >>>>>>>>>>>>>> should note as chairs. What are you own thoughts? = And >>> > >> was >>> > >>>>>>>>>>>>>> anything noted at the IETF in Vancouver concerning >>> > > this >>> > >> draft? >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Gorry >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> -------- Original Message -------- >>> > >>>>>>>>>>>>>> Subject: Re: [tsvwg] FYI: Document writeup for >>> > >>>>>>>>>>>>>> draft-ietf-tsvwg-byte- pkt-congest >>> > >>>>>>>>>>>>>> Date: Wed, 15 Aug 2012 15:07:28 -0400 >>> > >>>>>>>>>>>>>> From: John Leslie >>> > >>>>>>>>>>>>>> To: Gorry Fairhurst >>> > >>>>>>>>>>>>>> CC: tsvwg@ietf.org >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Gorry Fairhurst wrote: >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> The following document has been revised after >>> > >> receiving >>> > >>>>>>>> WGLC comments. >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> The changes are mostly refreshing a document >>> > >> scheduled to >>> > >>>>>>>>>>>>>> expire this month. >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> No issues were found: >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Is that with WGC-hat-on? >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Neither my issues nor Philip Eardley's comments = were >>> > >> addressed. >>> > >>>>>>>>>>>>>> In fact, not even the changes Bob Briscoe mentioned >>> > > on- >>> > >> list have >>> > >>>>>>>>>>>>>> been included. >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> As required by RFC 4858, this is the current = template >>> > >> for the >>> > >>>>>>>>>>>>>> Document >>> > >>>>>>>>>>>>>>> Shepherd Write-Up. >>> > >>>>>>>>>>>>>>> ... >>> > >>>>>>>>>>>>>>> (1) What type of RFC is being requested (BCP, >>> > > Proposed >>> > >> Standard, >>> > >>>>>>>>>>>>>>> Internet Standard, Informational, Experimental, or >>> > >> Historic)? >>> > >>>>>>>>>>>>>>> Why is this the proper type of RFC? Is this type = of >>> > >> RFC >>> > >>>>>>>>>>>>>>> indicated in the title page header? >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> This document is intended as BCP. (This was = discussed >>> > >> at IETF-81 >>> > >>>>>>>>>>>>>>> and that the status changed from Informational to = BCP >>> > >> since it >>> > >>>>>>>>>>>>>>> provides guidance to implementors and people >>> > >> configuring >>> > >>>>>>>> routers and hosts). >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Thank you for finally answering my question about >>> > > BCP >>> > >> status. >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> ... >>> > >>>>>>>>>>>>>>> Working Group Summary >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> There was consensus to publish this as a WG = document >>> > >> and >>> > >>>>>>>>>>>>>>> agreement at >>> > >>>>>>>>>>>>>>> IETF-82 that the document was now complete. >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Was that reviewed on-list? >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> ... >>> > >>>>>>>>>>>>>>> (3) Briefly describe the review of this document = that >>> > >> was >>> > >>>>>>>>>>>>>>> performed >>> > >>>>>>>>>>>>>> by >>> > >>>>>>>>>>>>>>> the Document Shepherd. If this version of the >>> > > document >>> > >> is not >>> > >>>>>>>>>>>>>>> ready for publication, please explain why the >>> > > document >>> > >> is being >>> > >>>>>>>>>>>>>>> forwarded to the IESG. >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> The document was presented at IEWTF-82 (Taipei), = with >>> > >> a request >>> > >>>>>>>>>>>>>>> for >>> > >>>>>>>>>>>>>> WGLC. >>> > >>>>>>>>>>>>>>> WGLC concluded with some discussion but no >>> > > substantive >>> > >> changes >>> > >>>>>>>>>>>>>>> on Friday 30th March 2012. >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Yes, I guess that is true; but ignoring = substantive >>> > >> comments >>> > >>>>>>>>>>>>>> isn't a good practice IMHO. >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> (4) Does the document Shepherd have any concerns >>> > > about >>> > >> the depth >>> > >>>>>>>>>>>>>>> or breadth of the reviews that have been = performed? >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> No - the original draft had a lot of background >>> > >> material, much >>> > >>>>>>>>>>>>>>> of >>> > >>>>>>>>>>>>>> this >>> > >>>>>>>>>>>>>>> has been condensed or removed, resulting in a = smaller >>> > >> document. >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> That is indeed what I basically asked for, but I >>> > >> don't see any >>> > >>>>>>>>>>>>>> evidence of it: >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> - diff(07,08) 48 lines changed or deleted; 53 = lines >>> > >> changed or >>> > >>>>>>>> added >>> > >>>>>>>>>>>>>> - diff(06,07) 8 lines changed or deleted; 13 = lines >>> > >> changed or >>> > >>>>>>>> added >>> > >>>>>>>>>>>>>> - diff(05,06) 64 lines changed or deleted; 69 = lines >>> > >> changed or >>> > >>>>>>>>>>>>>> added >>> > >>>>>>>>>>>>>> - diff(04,05) 823 lines changed or deleted; 864 = lines >>> > >> changed or >>> > >>>>>>>>>>>>>> added >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> (Need I go farther? That gets us back to March >>> > > 2011...) >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> (9) How solid is the WG consensus behind this >>> > >> document? Does it >>> > >>>>>>>>>>>>>>> represent the strong concurrence of a few >>> > > individuals, >>> > >> with >>> > >>>>>>>>>>>>>>> others being silent, or does the WG as a whole >>> > >> understand >>> > >>>>>>>> and agree with it? >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> The document has WG support and there is consensus = to >>> > >> publish. >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> This, IMHO, doesn't answer the question. :^( >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Does it represent the concurrence of a few >>> > >> individuals, or does >>> > >>>>>>>>>>>>>> the WG as a whole understand and agree with it? >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> For reference, my comments included: >>> > >>>>>>>>>>>>>> ] >>> > >>>>>>>>>>>>>> ] When I previously skimmed this document, I = believed >>> > >> it >>> > >>>>>>>>>>>>>> contained only ] common ground: that AQM should >>> > >> drop/mark packets >>> > >>>>>>>>>>>>>> without favoring small ] packets, and that to = whatever >>> > >> extent >>> > >>>>>>>>>>>>>> packet size _is_ considered, that ] should be a >>> > >>>>>>>> transport-layer responsibility. >>> > >>>>>>>>>>>>>> ] >>> > >>>>>>>>>>>>>> ] Alas, when I read it carefully this week, I find >>> > > that >>> > >> Bob is >>> > >>>>>>>>>>>>>> actually ] saying that transport-layer should = _only_ >>> > >> consider >>> > >>>>>>>>>>>>>> "congested bytes", not ] "congested packets". >>> > >>>>>>>>>>>>>> ] >>> > >>>>>>>>>>>>>> ] In fact, Bob openly endorses replacing TCP >>> > >> congestion-control >>> > >>>>>>>>>>>>>> with an ] algorithm which calculates "fair-share >>> > > bytes" >>> > >> and >>> > >>>>>>>>>>>>>> doesn't back off at all ] (even in the presence of = 20% >>> > >> packet >>> > >>>>>>>>>>>>>> loss) unless you're already sending ] more than = this >>> > >>>>>>>> "fair-share". >>> > >>>>>>>>>>>>>> ] >>> > >>>>>>>>>>>>>> ] I do not believe that is the consensus of this >>> > > WG; >>> > >> and I >>> > >>>>>>>> believe >>> > >>>>>>>>>>>>>> if >>> > >>>>>>>>>>>>>> ] that were the consensus it would exceed our = charter. >>> > >>>>>>>>>>>>>> ] >>> > >>>>>>>>>>>>>> ] The draft contains a number of things I _do_ >>> > > support; >>> > >> and I'd >>> > >>>>>>>>>>>>>> be happy ] to support a considerably shorter draft >>> > >> which >>> > >>>>>>>>>>>>>> concentrates on the AQM ] recommendation, omitting = any >>> > >>>>>>>>>>>>>> suggestions of modifying TCP congestion ] control. >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> and Philip's comments included: >>> > >>>>>>>>>>>>>> ] >>> > >>>>>>>>>>>>>> ] S2.2 I thought the numbered bullets could be = better >>> > >> phrased, >>> > >>>>>>>>>>>>>> something like ] +this:- ] >>> > >>>>>>>>>>>>>> ] 1. AQM algorithms such as RED SHOULD use = packet- >>> > >> mode >>> > >>>>>>>> drop, ie they >>> > >>>>>>>>>>>>>> SHOULD NOT >>> > >>>>>>>>>>>>>> ] +use byte-mode drop. The latter ] is more = complex, >>> > >>>>>>>>>>>>>> ] it creates the perverse incentive to = fragment >>> > >> segments >>> > >>>>>>>> into >>> > >>>>>>>>>>>>>> tiny >>> > >>>>>>>>>>>>>> ] pieces and it is vulnerable to floods of >>> > >> small- >>> > >>>>>>>>>>>>>> ] packets. >>> > >>>>>>>>>>>>>> ] >>> > >>>>>>>>>>>>>> ] 2. If a vendor has implemented byte-mode = drop, >>> > >> and an >>> > >>>>>>>> operator >>> > >>>>>>>>>>>>>> has >>> > >>>>>>>>>>>>>> ] turned it on, it is RECOMMENDED to turn it >>> > >> off, after >>> > >>>>>>>>>>>>>> establishing if >>> > >>>>>>>>>>>>>> ] +there are any implications on >>> > >>>>>>>>>>>>>> ] the relative performance of >>> > >>>>>>>>>>>>>> ] applications using different packet sizes. >>> > >>>>>>>>>>>>>> ] >>> > >>>>>>>>>>>>>> ] 3. RED SHOULD NOT be turned off. Without RED, = a >>> > >> drop tail >>> > >>>>>>>>>>>>>> ] queue biases against large packets. >>> > >>>>>>>>>>>>>> ] >>> > >>>>>>>>>>>>>> ] Nit - the following paragraph shouldn't be = indented >>> > >> (Note well >>> > >>>>>>>>>>>>>> that >>> > >>>>>>>>>>>>>> RED's...) >>> > >>>>>>>>>>>>>> ] >>> > >>>>>>>>>>>>>> ] S3.3 >>> > >>>>>>>>>>>>>> ] The section could be slightly clearer. Starting = with >>> > >> the second >>> > >>>>>>>>>>>>>> para, where you ] +start talking about something = you >>> > >> don't >>> > >>>>>>>>>>>>>> recommend (ie you have to remember that ] +you're >>> > >> talking about >>> > >>>>>>>>>>>>>> the consequences of not following your >>> > > recommendation). >>> > >>>>>>>>>>>>>> ] >>> > >>>>>>>>>>>>>> ] S3.3 >>> > >>>>>>>>>>>>>> ] o Also, if the network biases congestion >>> > >> notification by >>> > >>>>>>>> packet >>> > >>>>>>>>>>>>>> size >>> > >>>>>>>>>>>>>> ] it has to assume a baseline packet = size--all >>> > >> proposed >>> > >>>>>>>>>>>>>> algorithms >>> > >>>>>>>>>>>>>> ] use the local MTU. Then transports have to >>> > >> guess which >>> > >>>>>>>> link >>> > >>>>>>>>>>>>>> was >>> > >>>>>>>>>>>>>> ] congested and what its local MTU was, in = order >>> > >> to know >>> > >>>>>>>> how to >>> > >>>>>>>>>>>>>> ] tailor their congestion response to that = link. >>> > >>>>>>>>>>>>>> ] So you're saying that for byte-mode drop, the >>> > > network >>> > >> element >>> > >>>>>>>>>>>>>> has to compare the ] +size of the current pkt with = the >>> > >> MTU, and >>> > >>>>>>>>>>>>>> if it's 25* smaller then reduce the ] +pkt loss >>> > >> probably by 25*? >>> > >>>>>>>>>>>>>> And if the MTU was bigger, then the current pkt = would >>> > > ] >>> > >> +be >>> > >>>>>>>>>>>>>> dropped with greater probability? And both of these >>> > >> things >>> > >>>>>>>> are hard to do. >>> > >>>>>>>>>>>>>> ] >>> > >>>>>>>>>>>>>> ] S3.4 (& knock-on effect on 3.3) ] I think this = could >>> > >> be better. >>> > >>>>>>>>>>>>>> ] I agree with your arguments in S3.1 & 3.2 that >>> > >> dropping or >>> > >>>>>>>>>>>>>> marking should be ] +independent of pkt size. >>> > >>>>>>>>>>>>>> ] You now go into a couple of pages, which I think >>> > >> could be >>> > >>>>>>>>>>>>>> boiled down to a ] +paragraph, saying something = like:- >>> > >> ] * the >>> > >>>>>>>>>>>>>> overall system (network + transport) has to be = packet- >>> > >> size >>> > >>>>>>>>>>>>>> dependent in ] >>> > >>>>>>>>>>>>>> +order to drive out the right amount of traffic so = the >>> > >> resource >>> > >>>>>>>>>>>>>> becomes ] >>> > >>>>>>>>>>>>>> +uncongested (since we assume all resources are in >>> > >> practice byte >>> > >>>>>>>>>>>>>> +rather >>> > >>>>>>>>>>>>>> than ] +packet limited) ] * from S3.1 and S3.2 the >>> > > IETF >>> > >> is >>> > >>>>>>>>>>>>>> convinced that the network should notify ] >>> > > +independent >>> > >> of >>> > >>>>>>>> packet-size. >>> > >>>>>>>>>>>>>> ] * therefore the transport must act dependent on >>> > >> packet-size. >>> > >>>>>>>>>>>>>> ] >>> > >>>>>>>>>>>>>> ] It seems to me this is a necessary consequence of >>> > >> your earlier >>> > >>>>>>>>>>>>>> assumptions ] +/arguments. >>> > >>>>>>>>>>>>>> ] >>> > >>>>>>>>>>>>>> ] [On the other hand, if someone disagrees with the >>> > >> arguments and >>> > >>>>>>>>>>>>>> thinks that the ] +network should notify dependent = on >>> > >>>>>>>>>>>>>> packet-size, then it follows that the ] +transport = can >>> > >> act >>> > >>>>>>>>>>>>>> independent of >>> > >>>>>>>>>>>>>> packet- size.] ] ] I think in S3.3 you're trying to >>> > >> make another >>> > >>>>>>>>>>>>>> argument (?):- ] * we can either do packet-size >>> > >> biasing in the >>> > >>>>>>>>>>>>>> network element or on the end host ] +transport = (see >>> > >> argument >>> > >>>>>>>>>>>>>> above) ] * packet-size biasing in the network is = quite >>> > >> tricky, >>> > >>>>>>>>>>>>>> because then both the ] +network element & the >>> > >> transport have to >>> > >>>>>>>>>>>>>> make some guesses about MTU - whereas ] >>> > >>>>>>>>>>>>>> +with packet-size biasing in the transport, neither >>> > >> network >>> > >>>>>>>>>>>>>> +element >>> > >>>>>>>>>>>>>> nor ] +transport needs to know what the MTU is. >>> > >>>>>>>>>>>>>> ] * it is also easier to implement packet-size = biasing >>> > >> in the >>> > >>>>>>>>>>>>>> transport than in ] +the network. >>> > >>>>>>>>>>>>>> ] >>> > >>>>>>>>>>>>>> ] On the last bullet, I didn't really follow your >>> > >> argument in >>> > >>>>>>>> S3.5. >>> > >>>>>>>>>>>>>> Might be ] +easier to follow if S3.5 also talked = about >>> > >> how a >>> > >>>>>>>>>>>>>> network element would take ] +account of pkt size? >>> > >> Also, does the >>> > >>>>>>>>>>>>>> following argument also apply?: >>> > >>>>>>>>>>>>>> ] * if pkt-size biasing is done in the transport, = then >>> > >> the work >>> > >>>>>>>>>>>>>> (to do the ] +biasing) is spread over many end = hosts, >>> > > ] >>> > >> * whereas >>> > >>>>>>>>>>>>>> if pkt-size biasing is done in the network, then = the >>> > >> work is ] >>> > >>>>>>>>>>>>>> +concentrated in just the congested network = element, >>> > >> which has to >>> > >>>>>>>>>>>>>> operate on all ] +the traffic at line speed. >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> (Has there perhaps been some confusion about what >>> > >> went into the >>> > >>>>>>>>>>>>>> -08 >>> > >>>>>>>>>>>>>> version?) >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> -- >>> > >>>>>>>>>>>>>> John Leslie >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >> = ________________________________________________________________ >>> > >>>>>>>>>>> Bob Briscoe, BT = Innovate & >>> > >> Design >>> > >>>>>>>>>>> >>> > >>>>>>>>>> >>> > >>>>>>>>> >>> > >>>>>>> >>> > >>>>>>> >>> > >> = ________________________________________________________________ >>> > >>>>>>> Bob Briscoe, BT Innovate & >>> > >> Design >>> > >>>>>>> >>> > >>>>> >>> > >>>>> = ________________________________________________________________ >>> > >>>>> Bob Briscoe, BT Innovate & = Design >>> > >>> >>> > >>> = ________________________________________________________________ >>> > >>> Bob Briscoe, BT Innovate & = Design >>> > > >>=20 >> ________________________________________________________________ >> Bob Briscoe, BT Innovate & Design >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 From gorry@erg.abdn.ac.uk Sat Oct 13 04:20:38 2012 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 2266C21F85A0 for ; Sat, 13 Oct 2012 04:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUeZEvbMoccw for ; Sat, 13 Oct 2012 04:20:37 -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 1AFB221F859E for ; Sat, 13 Oct 2012 04:20:37 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 4D9712B45EE; Sat, 13 Oct 2012 12:20:35 +0100 (BST) Received: from Gorry.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id C92372B44BF; Sat, 13 Oct 2012 12:20:32 +0100 (BST) Message-ID: <50794E7B.6020903@erg.abdn.ac.uk> Date: Sat, 13 Oct 2012 12:20:27 +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:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gorry Fairhurst Subject: [tsvwg] Post WGLC, comments on revised draft for draft-ietf-tsvwg-sctp-udp-encaps 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: Sat, 13 Oct 2012 11:20:38 -0000 The questions and comments below are intended to help conclude the edits after the close of the WGLC in April. Comments are welcome. Gorry Fairhurst (as TSVWG-Co Chair) ----- 1) Which RFCs does this document formally update? 2) I assume we will intended to publish as PS (rather than BCP). 3) Please can each author confirm that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed? ----- Review comments on this revision of the draft: Section 4.3 - IPv6 UDP checksum change for tunnel APIs. The text says: / The UDP checksum SHOULD be computed and the SCTP checksum MUST be computed./ - This needs to cite draft-ietf-6man-udpzero and ietf-6man-udpchecksum - If the intent is to allow IPv6 UDP zero checksum it must explain how it meets the requirements for detecting paths that do not support this - and caution that NAPT/NAT/Firewall,etc traversal may be impacted. - The issues in firewall traversal may also be noted in the security considerations section. - This draft also needs to say that enabling IPv6 UDP zero checksum supports requires that SCTP registers the used port(s) as supporting the zero checksum option with the UDP module. - I do not see a way defined for probing whether a path will actually support a UDP zero checksum. This is needed for a transport - otherwise a change of path could result in a broken connection (no IPv6 zero checksum support). - Thoughts welcome on this, since it is a new addition to the draft, and incorporating this adds new things to check. Section 4.3 - Editorial /port number stored for the destination address the packet is sent to (see Section 4.1)./ may be could be better: /port number stored for the destination address to which the packet is sent (see Section 4.1)./ Section 4.3 - Editorial /Then a lookup is performed to find the association the received SCTP packet belongs to./ may be could be better: /Then a lookup is performed to find the association for the received SCTP packet./ and /The UDP source port is stored as the encapsulation port for the destination address the SCTP packet is received from (see Section 4.1)./ may be could be better: /The UDP source port is stored as the encapsulation port for the destination address in the received SCTP packet (see Section 4.1)./ Section 4.5 - RFC 2119 language? /There MAY be implementation constraints not allowing to process received ICMP or ICMPv6 messages at all./ - may be better written as below, and I am not sure this is a requirement, this seems to be captured in the previous 'MUST'. Section 4.5 - Need to clarify corner cases: /Implementation constraints could prevent processing received ICMP or ICMPv6 messages./ Consider adding something like: [RFC5927] describes precautions that are desirable before TCP acts on the receipt of an ICMP message. Similar precautions are desirable prior to forwarding a UDP Datagram to the SCTP module. The minimal length ICMP error message generated in response to processing a UDP Datagram only identifies the Source UDP Port and Destination UDP Port. This ICMP message does not carry sufficient information to discover the encapsulated SCTP association. Section 4.6 - editorial Should this Path MTU - with a capital 'P'? Section 4.6 - editorial / If the implementation does not allow to control the dont't fragment (DF)-bit contained in the IPv4 header, path MTU discovery can't be used. / may be better as: / If an implementation does not allow control of the dont't fragment (DF)-bit contained in the IPv4 header, then Path MTU Discovery can not be used. / Section 4.7 - Info REF to behave RFC? Is the intention to suggest using dns names instead of IP addresses, this would seem reasonable, and must surely be recommended in an RFC? Section 4.8 - Query / the ECN bits MUST NOT be changed during encapsulation and decapsulation./ - I assume this refers to the ECN field in the IP header? (please explain) - I assume that on reception this field SHOULD be passed to SCTP? (please say) - Is there any procedure that needs to be specified here... or does SCTP detect that ECB marks are not being sent to the receiver and elect not to mark as ECN-capable, please explain. From jmpolk@cisco.com Sat Oct 13 13:25:02 2012 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 A697521F847B for ; Sat, 13 Oct 2012 13:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uThuuLz2E5Rt for ; Sat, 13 Oct 2012 13:25:02 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id DE91A21F847A for ; Sat, 13 Oct 2012 13:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1259; q=dns/txt; s=iport; t=1350159902; x=1351369502; h=message-id:date:to:from:subject:cc:mime-version; bh=EHmgo4ja8oN+1ZGNRz/5G15tuBdnO4xWlT97/qBnH2o=; b=Og9uDz+NzEYRRvS70KupE0JCW0spGq/fcEICon2nA0i5tvOOWZmiPogl gkhTbGGw40UgsaYVDLoImZzCY0jSuOiKvCkSHyX9JdGyVN06cnlKCG5Br PRiN6wpdp/L/sIQS41Ih6xV7HTG26jdjwNKTyoccBlwQFurU2YUpn8d9i E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJ3NeVCtJV2c/2dsb2JhbABEv2+BCII5AQobAj8XOil5h2KcTJ85jnWDIQOIWJtZgWuDC4FF X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208";a="131346441" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 13 Oct 2012 20:25:01 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) (authenticated bits=0) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9DKP1uQ020238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Oct 2012 20:25:01 GMT Message-Id: <201210132025.q9DKP1uQ020238@rcdn-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 13 Oct 2012 15:25:00 -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 Cc: Gorry Fairhurst Subject: [tsvwg] TSVWG - Call for presentations for IETF85 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: Sat, 13 Oct 2012 20:25:02 -0000 TSVWG This note is a TSVWG call for those wanting to present during our meeting. We are currently meeting TWICE, with available agenda time during our 2hour second session on Friday morning. THIS SESSION TIME IS SUBJECT TO CHANGE STILL, so DON'T MAKE TRAVEL ARRANGEMENTS BASED ON THIS INFORMATION. Please respond to *me* with the following: - name of draft - URL to draft in repository - name of expected presenter - time presenter will want to present - this amount will be adjusted up or down based on the number of presentations to be given within the time we have scheduled. The general starting point is 10 minutes though. ALL presentations will be due in my email in-box by 1200 (noon) local time on Wednesday, November 7th. Presentation preference will be given to - WG items first; - then to non-WG items that have been discussed in the past on our list (i.e., from previous meetings); - then to new items destined for this WG that have had discussion on our list; Therefore, it behoves authors to initiate discussion on this list as well as to create interest within TSVWG for any ID they want presented during the meeting. James, Gorry and Rolf TSVWG chairs From bob.briscoe@bt.com Mon Oct 15 02:18:16 2012 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 8480321F8691 for ; Mon, 15 Oct 2012 02:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPu+f5Qsa6Un for ; Mon, 15 Oct 2012 02:18:11 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 35A1321F8692 for ; Mon, 15 Oct 2012 02:18:10 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 15 Oct 2012 10:18:06 +0100 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 15 Oct 2012 10:18:07 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.309.2; Mon, 15 Oct 2012 10:18:03 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1350292679435; Mon, 15 Oct 2012 10:17:59 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q9F9HwIG006958; Mon, 15 Oct 2012 10:17:58 +0100 Message-ID: <201210150917.q9F9HwIG006958@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Oct 2012 10:17:59 +0100 To: Manner Jukka From: Bob Briscoe In-Reply-To: <3A5279D338C75C40B4B3DA15BA47D6330B6FD072@EXMDB04.org.aalto .fi> References: <20120815190728.GQ15012@verdi> <502BFB47.7010803@erg.abdn.ac.uk> <791AD3077F94194BB2BDD13565B6295D45A6212A@PALLENE.office.hd> <15181_1346848013_5047450C_15181_645_1_50474507.3090706@erg.abdn.ac.uk> <3A5279D338C75C40B4B3DA15BA47D6330B616BD2@EXMDB04.org.aalto.fi> <201209051541.q85FfCs0019699@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F33D793B351@EMV65-UKRD.domain1.systemhost.net> <3A5279D338C75C40B4B3DA15BA47D6330B69261A@EXMDB04.org.aalto.fi> <9510D26531EF184D9017DF24659BB87F33D793B845@EMV65-UKRD.domain1.systemhost.net> <04AC95B5-A2B1-4DD2-B765-E20A4C1A69A3@aalto.fi> <3A5279D338C75C40B4B3DA15BA47D6330B6E81E4@EXMDB04.org.aalto.fi> <9510D26531EF184D9017DF24659BB87F33DCE34251@EMV65-UKRD.domain1.systemhost.net> <201210041126.q94BQ0hx002951@bagheera.jungle.bt.co.uk> <1904eec816d080f886f5bf8685358ddc.squirrel@www.erg.abdn.ac.uk> <201210101525.q9AFP4Mi008013@bagheera.jungle.bt.co.uk> <3A5279D338C75C40B4B3DA15BA47D6330B6FC2BB@EXMDB04.org.aalto.fi> <201210111208.q9BC8BAU012305@bagheera.jungle.bt.co.uk> <3A5279D338C75C40B4B3DA15BA47D6330B6FD072@EXMDB04.org.aalto.fi> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1024161496==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: "" , "" , "" , tsvwg IETF list Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest 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, 15 Oct 2012 09:18:16 -0000 --=====================_1024161496==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Jukka, OK, 2nd attempt below, annotated with HTML formatting. Rather than predicting the future, I have confined the text to the lack of universal deployment in the present. If you're happy with this, pls go ahead and re-issue the draft. ====================================================================================== 3.4. Permanent Partial Deployment of AQM In overview, the argument in this section runs as follows: * Because the network does will not and cannot always drop packets in proportion to their size, it shouldn't be given the task of making drop signals depend on packet size at all. * Transports on the other hand don't always want to make their rate response proportional to the size of dropped packets, but if they want to, they always can. The argument is similar to the end-to-end argument that says "Don't do X in the network if end-systems can do X by themselves, and they want to be able to choose whether to do X anyway." Actually the following argument is stronger; in addition it says "Don't give the network task X that could be done by the end-systems, if X is not won't ever be deployed on all network nodes, and end-systems won't be able to tell whether their network is doing X, or whether they need to do X themselves." In this case, the X in question is "making the response to congestion depend on packet size". We will now re-run this argument taking each step in more depth. The argument applies solely to drop, not to ECN marking. A queue drops packets for either of two reasons: a) to signal to host congestion controls that they should reduce the load and b) because there is no buffer left to store the packets. Active queue management tries to use drops as a signal for hosts to slow down (case a) so that drop due to buffer exhaustion (case b) should not be necessary. No-one expects AQM is not to ever be universally deployed in every queue in the Internet; many cheap ethernet bridges, software firewalls, NATs on consumer devices, etc implement simple tail-drop buffers. and, eEven if AQM were universal, it has to be able to cope with buffer exhaustion (by switching to a behaviour like tail-drop), in order to cope with unresponsive or excessive transports. Therefore For both these reasons networks will often be dropping packets as a last resort (case b) rather than under AQM control (case a). When buffers are exhausted (case b), they don't naturally drop packets in proportion to their size. The network can only reduce the probability of dropping smaller packets if it has enough space to store them somewhere while it waits for a larger packet that it can drop. If the buffer is exhausted, it does not have this choice. Admittedly tail-drop does naturally drop somewhat fewer small packets, but exactly how few depends more on the mix of sizes than the size of the packet in question. Nonetheless, in general, if we wanted networks to do size-dependent drop, we would need universal deployment of (packet-size dependent) AQM code, which is currently unrealistic. A host transport cannot know whether any particular drop was a deliberate signal from an AQM or a sign of a queue shedding packets due to buffer exhaustion. Therefore, because the network cannot universally do size-dependent drop, it should not do it all. Whereas universality is desirable in the network, diversity is desirable between different transport layer protocols - some, like NewReno TCP [RFC5681], may not choose to make their rate response proportionate to the size of each dropped packet, while others will (e.g. TFRC-SP [RFC4828]). ====================================================================================== Bob At 13:34 11/10/2012, Manner Jukka wrote: >Hi, > >Yeah, please at the point about cheap devices, still, I wonder what >the cost of AQM is on those devices. Maybe 1 cnt in mass production? >Thus, I still wonder if it is worth arguing something about the >future that strongly. > >Sorry, but the same goes for AQM in general, and where it is, or >will not be deployed. I understand technical reasons why not >something is feasible, but business or monetary reasons can change >very quickly. ;) > >Jukka > >On Oct 11, 2012, at 3:08 PM, Bob Briscoe wrote: > > > Jukka, > > > > What I had in mind is all low level buffers in cheap pure L2 > devices, in cheap NATs etc. I was going to list some of these, but > instead chose to say "no-one expects AQM to be universally > deployed". This clearly missed the mark. > > > > Should we include some of these concrete examples of where AQM > won't be deployed instead? > > > > [I've cc'd the list, given we're starting to wordsmith > significantly new text added since WG last call.] > > > > > > Bob > > > > At 20:04 10/10/2012, Manner Jukka wrote: > >> Hi, looked good to me. Just one comment, I wouldn't put that > much emphasis on what is a probably state of things, e.g. > >> > >> "no-one expects AQM to ever be .." > in the future it might, we > don't know, and since the paragraph says that it doesn't matter > anyway, I would formulate this paragraph a bit towards that we have > partial deployment now and even with a full deployment, ... > >> > >> and similarly with the unrealistic deployment of AQM in the > subsequent paragraph. > >> > >> cheers, > >> Jukka > >> > >> On Oct 10, 2012, at 6:25 PM, Bob Briscoe wrote: > >> > >> > Phil, > >> > > >> > Sorry for delay, my round-robin scheduler is taking so long to > get round all the tasks that I keep finding dead robins (that > reminds me of a bike ride my grandmother took. On her return, she > said there were a worryingly large number of robins run over on the > roads. It turned out that she had been going round the same small > triangle of roads multiple times). > >> > > >> > I've done a complete re-write of 3.4. I hope you will agree > that it really is a motivating argument now and it can stay where > it is - it is not just a preamble. > >> > > >> > I've gone back to the very first version of 3.4 I wrote and I > now realise that I had written the core of the argument so badly > that even I forgot what it was meant to say when we started editing > it. In the draft-08 version, the original meaning is lost and in > your re-wording it is entirely lost. The link with the draft-08 > version is nearly unrecognisable, but it's the argument I intended here. > >> > > >> > > ====================================================================================== > >> > 3.4. Permanent Partial Deployment of AQM > >> > > >> > In overview, the argument in this section runs as follows: > >> > * Because the network will not and cannot always drop packets > in proportion to their size, it shouldn't be given the task of > making drop signals depend on packet size at all. > >> > * Transports on the other hand don't always want to make their > rate response proportional to the size of dropped packets, but if > they want to, they always can. > >> > > >> > The argument is similar to the end-to-end argument that says > "Don't do X in the network if end-systems can do X by themselves, > and they want to be able to choose whether to do X anyway." > Actually the following argument is stronger; in addition it says > "Don't give the network task X that could be done by the > end-systems, if X won't ever be deployed on all network nodes, and > end-systems won't be able to tell whether their network is doing X, > or whether they need to do X themselves." In this case, the X in > question is "making the response to congestion depend on packet size". > >> > > >> > We will now re-run this argument taking each step in more > depth. The argument applies solely to drop, not ECN marking. > >> > > >> > A queue drops packets for either of two reasons: a) to signal > to host congestion controls that they should reduce the load and b) > because there is no buffer left to store the packets. Active queue > management tries to use drops as a signal for hosts to slow down > (case a) so that drop due to buffer exhaustion (case b) should not > be necessary. > >> > > >> > No-one expects AQM to ever be universally deployed in every > queue in the Internet; and, even if AQM were universal, it has to > be able to cope with buffer exhaustion (by switching to a behaviour > like tail-drop), in order to cope with unresponsive or excessive > transports. Therefore networks will often be dropping packets as a > last resort (case b) rather than under AQM control (case a). > >> > > >> > When buffers are exhausted (case b), they don't naturally drop > packets in proportion to their size. The network can only reduce > the probability of dropping smaller packets if it has enough space > to store them somewhere while it waits for a larger packet that it > can drop. If the buffer is exhausted, it does not have this choice. > Admittedly tail-drop does naturally drop somewhat fewer small > packets, but exactly how few depends more on the mix of sizes than > the size of the packet in question. Nonetheless, in general, if we > wanted networks to do size-dependent drop, we would need universal > deployment of (packet-size dependent) AQM code, which is unrealistic. > >> > > >> > A host transport cannot know whether any particular drop was a > deliberate signal from an AQM or a sign of a queue shedding packets > due to buffer exhaustion. Therefore, because the network cannot > universally do size-dependent drop, it should not do it all. > >> > > >> > Whereas universality is desirable in the network, diversity is > desirable between different transport layer protocols - some, like > NewReno TCP [RFC5681], may not choose to make their rate response > proportionate to the size of each dropped packet, while others will > (e.g. TFRC-SP [RFC4828]). > >> > > ====================================================================================== > >> > > >> > > >> > > >> > > >> > Bob > >> > > >> > At 13:13 04/10/2012, gorry@erg.abdn.ac.uk wrote: > >> >> That would be brilliant! > >> >> > >> >> Gorry > >> >> > >> >> > Will try to look at this later today. > >> >> > > >> >> > > >> >> > Bob > >> >> > > >> >> > At 10:42 02/10/2012, philip.eardley@bt.com wrote: > >> >> >>Think the token is with bob > >> >> >> > >> >> >>Re your comment - yes, I think you could move 3.4 to the end of S3 - > >> >> >>or to the start - and do some re-phrasing, maybe something > like I tried. > >> >> >> > >> >> >>-----Original Message----- > >> >> >>From: Manner Jukka [mailto:jukka.manner@aalto.fi] > >> >> >>Sent: 01 October 2012 20:18 > >> >> >>To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,Bob,DUB8 R > >> >> >>Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst > >> >> >>Subject: Re: [REVISED I-D]: Document writeup for > >> >> >>draft-ietf-tsvwg-byte-pkt-congest > >> >> >> > >> >> >>Phil, Bob, can we close this finally? It's three weeks now since > >> >> >>this previous message. > >> >> >> > >> >> >>Jukka > >> >> >> > >> >> >>On Sep 10, 2012, at 4:42 PM, Jukka Manner wrote: > >> >> >> > >> >> >> > Ack, I'm getting there...;) > >> >> >> > > >> >> >> > So, we could move 3.4 at the end of Section 3 and rephrase it to > >> >> >> not talk about scaling per se, but rather about how Req 2.2 > >> >> >> eventually leads to Req 2.3? > >> >> >> > > >> >> >> > Jukka > >> >> >> > > >> >> >> > On Sep 7, 2012, at 4:07 PM, > >> >> >> > wrote: > >> >> >> > > >> >> >> >> 3.4 is, in my mind, completely different from 3.1, 3.2, > 3.3 and 3.5. > >> >> >> >> > >> >> >> >> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for > Recommendation > >> >> >> >> 2.2 & a lesser extent 2.3 > >> >> >> >> 3.4 makes doesn't make a motivating argument - it > explains that Rec > >> >> >> >> 2.2 & 2.3 come as a pair (if you recommend one, then > inevitably you > >> >> >> >> recommend the other) (delta some politeness about TCP) > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> -----Original Message----- > >> >> >> >> From: Manner Jukka [mailto:jukka.manner@aalto.fi] > >> >> >> >> Sent: 07 September 2012 13:24 > >> >> >> >> To: Eardley,PL,Philip,DUB8 R > >> >> >> >> Cc: Briscoe,RJ,Bob,DUB8 R; ; > >> >> >> >> > >> >> >> >> Subject: Re: [REVISED I-D]: Document writeup for > >> >> >> >> draft-ietf-tsvwg-byte-pkt-congest > >> >> >> >> > >> >> >> >> Hi, I'm trying to follow your reasoning, with little luck. ;) > >> >> >> >> > >> >> >> >> After having read Section 3 again, I could think of a few > >> >> >> updates, but I'm not fully following what you want to see: > >> >> >> >> > >> >> >> >> - S3.5 is kind of small and lonely by itself. It could be either > >> >> >> longer or merged somewhere. Not a major issue though and > could remain as > >> >> >> is. > >> >> >> >> > >> >> >> >> - S3.3: Yes, probably could be turned upside down, good first, > >> >> >> bad later. Don't have a strong opinion. > >> >> >> >> > >> >> >> >> - S3.4: Here the scaling is used many times and in the title, > >> >> >> although we talk about the end host side. This could be rephrased > >> >> >> and slightly reworded to talk about hosts and their operation > >> >> >> altogether. Also the word scaling can turn the readers expectation > >> >> >> into the wrong direction. > >> >> >> >> > >> >> >> >> - S3 altogether: It would help to have introductory text about > >> >> >> networks vs. end host side, but I fail to see why (& how) to > >> >> >> restructure everything. > >> >> >> >> > >> >> >> >> cheers, > >> >> >> >> Jukka > >> >> >> >> > >> >> >> >> On Sep 6, 2012, at 6:18 PM, > >> >> >> wrote: > >> >> >> >> > >> >> >> >>> Ps otherwise Bob's comments are fine, though I suggest > for S3.5 you > >> >> >> >>> give more context (ie are you knocking down what you recommend > >> >> >> >>> against, or building up what you recommend?) and in S3.3 think > >> >> >> >>> would be better if you re-structured slightly [first > talk about what > >> >> >> >>> you like - penult para + 1st sentence of last para - > then talk about > >> >> >> >>> what you don't like - rest of text] > >> >> >> >>> > >> >> >> >>> From: Eardley,PL,Philip,DUB8 R > >> >> >> >>> Sent: 06 September 2012 16:12 > >> >> >> >>> To: Briscoe,RJ,Bob,DUB8 R; Manner Jukka > >> >> >> >>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst > >> >> >> >>> Subject: RE: [REVISED I-D]: Document writeup for > >> >> >> >>> draft-ietf-tsvwg-byte-pkt-congest > >> >> >> >>> > >> >> >> >>> Thanks bob. Have now re-booted some state. > >> >> >> >>> I don't like S3.4. My basic problem with it is that it isn't a > >> >> >> "motivating argument" (S3 title). It's an explanation about the > >> >> >> consequences of assuming either [option 1] do pkt-size biasing in > >> >> >> the transport; [option 2]; do pkt-size biasing in the nw. > >> >> >> >>> Perhaps your effort to buy peace with those who won't change > >> >> >> TCP has obfuscated the basic point? > >> >> >> >>> The title of S3.4 (Scaling...) and the early text "scaling > >> >> >> argument" suggests that you're going to argue there is some reason > >> >> >> why X scales as order N rather than N^2 or something like that - > >> >> >> which isn't what S3.4 is about. > >> >> >> >>> > >> >> >> >>> I actually think it would be better to put S3.4 at the start of > >> >> >> S3 - it's background where you say there are 2 options. After that, > >> >> >> you can explain the reasons why option 1 [pkt biasing in the > >> >> >> transport] is better - the reasons being:- S3.1 (security etc > >> >> >> attacks if small pkts get preferential treatment), S3.2 (really a > >> >> >> side note to S3.1; ie doesn't really present a "motivating > >> >> >> argument"), S3.3 (nw guessing MTU vs transport knowing pkt size), > >> >> >> S3.5 (easier implementation). > >> >> >> >>> > >> >> >> >>> Something like... > >> >> >> >>> The behaviour of the network and transport together needs to > >> >> >> >>> alleviate congestion. We assume the network is bit-congestible > >> >> >> (currently packet-congestible resources are rate). Therefore > >> >> >> overall the response of the {network + transport} should be the > >> >> >> same for the same congestion - whether the congestion is caused by > >> >> >> a lot of small packets or a smaller number of larger packets. The > >> >> >> implication is that the transport's behaviour should depend on > >> >> >> whether the network takes account (or not) of packet size when it > >> >> >> generates congestion indications:- Case 1: If the network > >> >> >> implements packet-mode drop, ie its algorithm treats all packets > >> >> >> equally regardless of their size, then the transport should take > >> >> >> account of the size of the packet - in other words, the transport's > >> >> >> congestion response should depend on the number of dropped bytes. > >> >> >> >>> Case 2: If the network implements byte-mode drop, ie its > >> >> >> algorithm treats packets differently depending on their size, then > >> >> >> the transport should not take account of the size of the packet - > >> >> >> in other words, the transport's congestion response should depend > >> >> >> on the number of dropped packets. > >> >> >> >>> > >> >> >> >>> These cases are explained in more detail in sub-section below. > >> >> >> >>> > >> >> >> >>> In both cases the same discussion applies if packets are > >> >> >> ECN-marked rather than dropped. > >> >> >> >>> In the following sections we explain why Case 1 is preferable, > >> >> >> and hence why we make the Recommendations of S2.2 and S3.3 > >> >> >> (respectively, drop/mark pkts equally regardless of their size, and > >> >> >> the strength of the transport's response should be proportionate to > >> >> >> the size of the dropped/marked pkt). > >> >> >> >>> Note that TCP responds to dropped or marked packets, > which differs > >> >> >> >>> from our recommendation for transports. However, we are not > >> >> >> >>> recommending that TCP should be changed; to date it > hasn't been a > >> >> >> >>> significant problem because most TCP implementations have been > >> >> >> used with similar packet sizes. But we do recommend that future > >> >> >> transport protocols should respond to dropped or marked bytes (as > >> >> >> for example TFRC-SP [RFC4828]effectively does). > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> Sub-section > >> >> >> >>> You could use much of S3.3, I suggest supplement with numerical > >> >> >> >>> examples continuing S1.2 > >> >> >> >>> -- > >> >> >> >>> << This gives a get-out clause to any transport that isn't > >> >> >> >>> packet-size dependent (e.g. current TCP). Lacking packet-size > >> >> >> >>> dependence just means they don't scale correctly with > packet size - > >> >> >> >>> but they are at liberty not to scale with packet size > (particularly > >> >> >> >>> given MTU growth isn't often being used to increase > link rates at > >> >> >> >>> this stage in history).>> > >> >> >> >>> > >> >> >> >>> This is introducing a different point. it's saying that your > >> >> >> recommendation 2 [drop/mark pkts equally regardless of their size] > >> >> >> is a really strong reco whilst recommendation 3 [strength of > >> >> >> transport's response proportionate to the size of the > >> >> >> dropped/marked pkt] is a much less important reco. I can see this > >> >> >> might be true, but I don't think the i-d talks about this. > >> >> >> >>> > >> >> >> >>> -- > >> >> >> >>> > >> >> >> >>> From: Briscoe,RJ,Bob,DUB8 R > >> >> >> >>> Sent: 05 September 2012 16:41 > >> >> >> >>> To: Manner Jukka > >> >> >> >>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst; > Eardley,PL,Philip,DUB8 R > >> >> >> >>> Subject: Re: [REVISED I-D]: Document writeup for > >> >> >> >>> draft-ietf-tsvwg-byte-pkt-congest > >> >> >> >>> > >> >> >> >>> Jukka, > >> >> >> >>> > >> >> >> >>> I've repeated Phil's suggestions as quoted email then made some > >> >> >> alterations. > >> >> >> >>> > >> >> >> >>> Phil asked me to send this, then he will think about it. > >> >> >> >>> > >> >> >> >>> I'll respond about John Leslie's argument next... > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> 2.2. Recommendation on Encoding Congestion Notification > >> >> >> >>> > >> >> >> >>> [...] > >> >> >> >>> > >> >> >> >>> 1. AQM algorithms such as RED SHOULD use packet-mode > drop, ie they > >> >> >> >>> SHOULD NOT use byte-mode drop. The latter is more complex, > >> >> >> >>> it creates the perverse incentive to fragment segments into > >> >> >> tiny > >> >> >> >>> pieces and it is vulnerable to floods of small packets. > >> >> >> >>> > >> >> >> >>> 2. If a vendor has implemented byte-mode drop, and > an operator has > >> >> >> >>> turned it on, it is RECOMMENDED to turn it off, after > >> >> >> establishing > >> >> >> >>> if there are any implications on the relative > performance of > >> >> >> >>> applications using different packet sizes. > >> >> >> >>> > >> >> >> >>> RED as a whole SHOULD NOT be turned off. Without > RED, a drop > >> >> >> tail > >> >> >> >>> queue biases against large packets > >> >> >> >>> > >> >> >> >>> [BB adds]: and it is > vulnerable to > >> >> >> floods > >> >> >> >>> of small-packets. > >> >> >> >>> > >> >> >> >>> (I suggest the last para just qualifies item 2. It > doesn't warrant > >> >> >> >>> another item number.) > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> [PE:] S3.3 > >> >> >> >>> The section could be slightly clearer. Starting with the second > >> >> >> para, where you start talking about something you don't recommend > >> >> >> (ie you have to remember that you're talking about the consequences > >> >> >> of not following your recommendation). > >> >> >> >>> > >> >> >> >>> 3.3 Transport-Independent Network > >> >> >> >>> > >> >> >> >>> TCP congestion control ensures that flows competing > for the same > >> >> >> >>> resource each maintain the same number of segments in flight, > >> >> >> >>> irrespective of segment size. So under similar > conditions, flows > >> >> >> >>> with different segment sizes will get different bit-rates. > >> >> >> >>> > >> >> >> >>> [OLD:] > >> >> >> >>> One motivation for the network biasing congestion > notification by > >> >> >> >>> packet size is to counter this effect and try to > equalise the bit- > >> >> >> >>> rates of flows with different packet sizes. > >> >> >> >>> [SUGGESTED:] > >> >> >> >>> To counter this effect it seems tempting not to follow our > >> >> >> >>> recommendation, and instead for the network to bias congestion > >> >> >> >>> notification by packet size in order to equalise the > bit-rates of > >> >> >> >>> flows with different packet sizes. > >> >> >> >>> [CONTINUE AS BEFORE:] > >> >> >> >>> However, in order to do this, the > queuing algorithm > >> >> >> >>> has to make assumptions about the transport, which > become embedded > >> >> >> >>> in the network. Specifically: > >> >> >> >>> [...] > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> S3.3 > >> >> >> >>> o The queuing algorithm has to assume how aggressively the > >> >> >> transport > >> >> >> >>> will respond to congestion (see Section > 4.2.4). If the network > >> >> >> >>> assumes the transport responds as aggressively as > TCP NewReno, > >> >> >> it > >> >> >> >>> will be wrong for Compound TCP and differently > wrong for Cubic > >> >> >> >>> TCP, etc. To achieve equal bit-rates, each > transport then has > >> >> >> to > >> >> >> >>> guess what assumption the network made, and work out how to > >> >> >> >>> replace this assumed aggressiveness with its own > aggressiveness. > >> >> >> >>> o Also, if the network biases congestion > notification by packet > >> >> >> size > >> >> >> >>> it has to assume a baseline packet size--all > proposed algorithms > >> >> >> >>> use the local MTU. Then transports have to guess > which link was > >> >> >> >>> congested and what its local MTU was, in order to > know how to > >> >> >> >>> tailor their congestion response to that link. > >> >> >> >>> > >> >> >> >>> So you're saying that for byte-mode drop, the network element > >> >> >> has to compare the size of the current pkt with the MTU, and if > >> >> >> it's 25* smaller then reduce the pkt loss probably by 25*? And if > >> >> >> the MTU was bigger, then the current pkt would be dropped with > >> >> >> greater probability? And both of these things are hard to do. > >> >> >> >>> > >> >> >> >>> [BB]: SUGGESTED REPLACEMENT to 2nd bullet: > >> >> >> >>> > >> >> >> >>> o Also, if the network biases congestion > notification by packet > >> >> >> size > >> >> >> >>> it has to assume a baseline packet size--all > proposed algorithms > >> >> >> >>> use the local MTU (for example see the byte-mode loss > >> >> >> probability > >> >> >> >>> formula in Table 1). Then if the non-Reno > transports mentioned > >> >> >> above > >> >> >> >>> are trying to reverse engineer what the network > assumed, they > >> >> >> also > >> >> >> >>> have to guess the MTU of the congested link. > >> >> >> >>> > >> >> >> >>> [Aside for Phil: The byte-mode algo uses MTU as its > baseline because > >> >> >> >>> a link cannot send a packet bigger than its MTU so the > algo won't > >> >> >> >>> ever give a drop probability >1).] > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> S3.4 (& knock-on effect on 3.3) > >> >> >> >>> I think this could be better. > >> >> >> >>> I agree with your arguments in S3.1 & 3.2 that dropping or > >> >> >> marking should be independent of pkt size. > >> >> >> >>> You now go into a couple of pages, which I think could be boiled > >> >> >> >>> down to a paragraph, saying something like:- > >> >> >> >>> * the overall system (network + transport) has to be packet-size > >> >> >> >>> dependent in order to drive out the right amount of > traffic so the > >> >> >> >>> resource becomes uncongested (since we assume all > resources are in > >> >> >> >>> practice byte rather than packet limited) > >> >> >> >>> * from S3.1 and S3.2 the IETF is convinced that the network > >> >> >> should notify independent of packet-size. > >> >> >> >>> * therefore the transport must act dependent on packet-size. > >> >> >> >>> > >> >> >> >>> It seems to me this is a necessary consequence of your earlier > >> >> >> assumptions /arguments. > >> >> >> >>> > >> >> >> >>> [BB:] This isn't at all obvious. Until I worked it through, it > >> >> >> wasn't obvious to me. I think it needs to be spelled out. > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> [On the other hand, if someone disagrees with the arguments and > >> >> >> >>> thinks that the network should notify dependent on > packet-size, then > >> >> >> >>> it follows that the transport can act independent of > packet-size.] > >> >> >> >>> > >> >> >> >>> I think in S3.3 you're trying to make another argument (?):- > >> >> >> >>> * we can either do packet-size biasing in the network > element or on > >> >> >> >>> the end host transport (see argument above) > >> >> >> >>> * packet-size biasing in the network is quite tricky, because > >> >> >> then both the network element & the transport have to make some > >> >> >> guesses about MTU - whereas with packet-size biasing in the > >> >> >> transport, neither network element nor transport needs to > know what the > >> >> >> MTU is. > >> >> >> >>> * it is also easier to implement packet-size biasing in the > >> >> >> transport than in the network. > >> >> >> >>> > >> >> >> >>> [BB] ...and all the other arguments about vulnerability to > >> >> >> flooding etc, transport-independence etc. > >> >> >> >>> > >> >> >> >>> Our argument is sort of like how Phil summarises it, but with > >> >> >> an added nuance. It's also saying no-one has to do packet-size > >> >> >> biasing anyway. It's not saying "The transport should given the > >> >> >> network shouldn't". It's saying "*If the transport wants to claim > >> >> >> to be scalable wrt packet size* it should if the network shouldn't". > >> >> >> >>> > >> >> >> >>> This gives a get-out clause to any transport that isn't > >> >> >> packet-size dependent (e.g. current TCP). Lacking packet-size > >> >> >> dependence just means they don't scale correctly with packet size - > >> >> >> but they are at liberty not to scale with packet size (particularly > >> >> >> given MTU growth isn't often being used to increase link rates at > >> >> >> this stage in history). > >> >> >> >>> > >> >> >> >>> None of what Phil says convinces me we could say 3.4 (or 3.3) > >> >> >> any more briefly or differently. It's easier to summarise what you > >> >> >> understand having read something. But that's not the same as > >> >> >> writing the thing that helped you understand. There doesn't seem to > >> >> >> be any argument for why anything needs to be changed, so I'm going > >> >> >> to leave it as is, unless pushed. > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> On the last bullet, I didn't really follow your argument in > >> >> >> S3.5. Might be easier to follow if S3.5 also talked about how a > >> >> >> network element would take account of pkt size? > >> >> >> >>> Also, does the following argument also apply?: > >> >> >> >>> * if pkt-size biasing is done in the transport, then > the work (to do > >> >> >> >>> the biasing) is spread over many end hosts, > >> >> >> >>> * whereas if pkt-size biasing is done in the network, then the > >> >> >> work is concentrated in just the congested network element, which > >> >> >> has to operate on all the traffic at line speed. > >> >> >> >>> > >> >> >> >>> [BB]: 3.5. Implementation Efficiency > >> >> >> >>> > >> >> >> >>> [ADD:] > >> >> >> >>> Biasing against large packets typically requires an > extra multiply > >> >> >> >>> and divide in the network (see the example byte-mode drop > >> >> >> formula in table 1). > >> >> >> >>> [CONTINUE AS BEFORE:] > >> >> >> >>> Allowing for packet size at the transport rather than in the > >> >> >> >>> network ensures that neither the network nor the > transport needs to > >> >> >> >>> do a multiply operation--multiplication by packet size is > >> >> >> >>> effectively achieved as a repeated add when the > transport adds to > >> >> >> >>> its count of marked bytes as each congestion event is > fed to it. > >> >> >> >>> [ADD:] > >> >> >> >>> Also the work to do the biasing is spread over many > hosts, rather > >> >> >> >>> than concentrated in just the congested network element. > >> >> >> >>> [CONTINUE AS BEFORE:] > >> >> >> >>> > These aren't > >> >> >> >>> principled reasons in themselves, but they are a happy > consequence > >> >> >> >>> of the other principled reasons. > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> Bob > >> >> >> >>> > >> >> >> >>> At 13:36 05/09/2012, Manner Jukka wrote: > >> >> >> >>> > >> >> >> >>> Hi Bob, > >> >> >> >>> > >> >> >> >>> Since Phil is your colleague at BT, even at Ipswich (?), can > >> >> >> you check those and agree with Phil how to go forward? Some of > >> >> >> those are clear, others need discussion with Phil. > >> >> >> >>> > >> >> >> >>> Gorry, on point 2) below, I don't follow Leslie's arguments. I > >> >> >> asked from him detailed comments and resolutions months > ago, and nothing > >> >> >> came. > >> >> >> >>> > >> >> >> >>> cheers, > >> >> >> >>> Jukka > >> >> >> >>> > >> >> >> >>> On Sep 5, 2012, at 3:26 PM, Gorry Fairhurst wrote: > >> >> >> >>> > >> >> >> >>>> Bob and Jukka, > >> >> >> >>>> > >> >> >> >>>> I think I need your help to resolve this... Some of the > >> >> >> comments raised by John Leslie appear to have substance, and I'm > >> >> >> not sure what you plan to do to address these. > >> >> >> >>>> > >> >> >> >>>> It would be good to do something quick so that I can complete > >> >> >> the submission to the IESG. > >> >> >> >>>> > >> >> >> >>>> The issues I particularly note are: > >> >> >> >>>> > >> >> >> >>>> 1) This contribution from Phil appears to be within scope and > >> >> >> it seems may have been overlooked (sorry): > >> >> >> >>>> > http://www.ietf.org/mail-archive/web/tsvwg/current/msg11234.html > >> >> >> >>>> > >> >> >> >>>> 2) Can you be clear here about what is actually been said - > >> >> >> because the point below seems to be a misunderstanding of language > >> >> >> to me, and I hoped we did not claim this: > >> >> >> >>>> > >> >> >> >>>>>> ] Alas, when I read it carefully this week, I find > that Bob is > >> >> >> >>>>>> actually ] saying that transport-layer should _only_ consider > >> >> >> >>>>>> "congested bytes", not ] "congested packets". > >> >> >> >>>>>> ] > >> >> >> >>>> > >> >> >> >>>> 3) You'll need to post the updated draft and send a note to > >> >> >> the group to confirm that the new version indeed concludes the > >> >> >> WGLC. I'll add a note to the writeup to indicate the draft content > >> >> >> has been stable since Oct 2011. > >> >> >> >>>> > >> >> >> >>>> Gorry (with my TSVWG Documnent Shepherd hat) > >> >> >> >>>> cc: Co-Chairs for info. > >> >> >> >>>> > >> >> >> >>>>> > >> >> >> >>>>>> -----Original Message----- > >> >> >> >>>>>> From: Gorry Fairhurst [ mailto:gorry@erg.abdn.ac.uk] > >> >> >> >>>>>> Sent: Mittwoch, 15. August 2012 21:41 > >> >> >> >>>>>> To: tsvwg chair > >> >> >> >>>>>> Subject: Fwd: Re: [tsvwg] FYI: Document writeup for > >> >> >> >>>>>> draft-ietf-tsvwg- byte-pkt-congest > >> >> >> >>>>>> > >> >> >> >>>>>> > >> >> >> >>>>>> > >> >> >> >>>>>> Hi guys, > >> >> >> >>>>>> > >> >> >> >>>>>> > >> >> >> >>>>>> Apart form the usual rhetoric, there are some > points here that we > >> >> >> >>>>>> should note as chairs. What are you own thoughts? And was > >> >> >> >>>>>> anything noted at the IETF in Vancouver concerning > this draft? > >> >> >> >>>>>> > >> >> >> >>>>>> Gorry > >> >> >> >>>>>> > >> >> >> >>>>>> > >> >> >> >>>>>> > >> >> >> >>>>>> -------- Original Message -------- > >> >> >> >>>>>> Subject: Re: [tsvwg] FYI: Document writeup for > >> >> >> >>>>>> draft-ietf-tsvwg-byte- pkt-congest > >> >> >> >>>>>> Date: Wed, 15 Aug 2012 15:07:28 -0400 > >> >> >> >>>>>> From: John Leslie > >> >> >> >>>>>> To: Gorry Fairhurst > >> >> >> >>>>>> CC: tsvwg@ietf.org > >> >> >> >>>>>> > >> >> >> >>>>>> Gorry Fairhurst wrote: > >> >> >> >>>>>>> > >> >> >> >>>>>>> The following document has been revised after receiving > >> >> >> WGLC comments. > >> >> >> >>>>>> > >> >> >> >>>>>> The changes are mostly refreshing a document scheduled to > >> >> >> >>>>>> expire this month. > >> >> >> >>>>>> > >> >> >> >>>>>>> No issues were found: > >> >> >> >>>>>> > >> >> >> >>>>>> Is that with WGC-hat-on? > >> >> >> >>>>>> > >> >> >> >>>>>> Neither my issues nor Philip Eardley's comments > were addressed. > >> >> >> >>>>>> In fact, not even the changes Bob Briscoe mentioned > on-list have > >> >> >> >>>>>> been included. > >> >> >> >>>>>> > >> >> >> >>>>>>> As required by RFC 4858, this is the current > template for the > >> >> >> >>>>>> Document > >> >> >> >>>>>>> Shepherd Write-Up. > >> >> >> >>>>>>> ... > >> >> >> >>>>>>> (1) What type of RFC is being requested (BCP, > Proposed Standard, > >> >> >> >>>>>>> Internet Standard, Informational, Experimental, or > Historic)? > >> >> >> >>>>>>> Why is this the proper type of RFC? Is this type of RFC > >> >> >> >>>>>>> indicated in the title page header? > >> >> >> >>>>>>> > >> >> >> >>>>>>> This document is intended as BCP. (This was > discussed at IETF-81 > >> >> >> >>>>>>> and that the status changed from Informational to > BCP since it > >> >> >> >>>>>>> provides guidance to implementors and people configuring > >> >> >> routers and hosts). > >> >> >> >>>>>> > >> >> >> >>>>>> Thank you for finally answering my question about > BCP status. > >> >> >> >>>>>> > >> >> >> >>>>>>> ... > >> >> >> >>>>>>> Working Group Summary > >> >> >> >>>>>>> > >> >> >> >>>>>>> There was consensus to publish this as a WG document and > >> >> >> >>>>>>> agreement at > >> >> >> >>>>>>> IETF-82 that the document was now complete. > >> >> >> >>>>>> > >> >> >> >>>>>> Was that reviewed on-list? > >> >> >> >>>>>> > >> >> >> >>>>>>> ... > >> >> >> >>>>>>> (3) Briefly describe the review of this document that was > >> >> >> >>>>>>> performed > >> >> >> >>>>>> by > >> >> >> >>>>>>> the Document Shepherd. If this version of the > document is not > >> >> >> >>>>>>> ready for publication, please explain why the > document is being > >> >> >> >>>>>>> forwarded to the IESG. > >> >> >> >>>>>>> > >> >> >> >>>>>>> The document was presented at IEWTF-82 (Taipei), > with a request > >> >> >> >>>>>>> for > >> >> >> >>>>>> WGLC. > >> >> >> >>>>>>> WGLC concluded with some discussion but no > substantive changes > >> >> >> >>>>>>> on Friday 30th March 2012. > >> >> >> >>>>>> > >> >> >> >>>>>> Yes, I guess that is true; but ignoring > substantive comments > >> >> >> >>>>>> isn't a good practice IMHO. > >> >> >> >>>>>> > >> >> >> >>>>>>> (4) Does the document Shepherd have any concerns > about the depth > >> >> >> >>>>>>> or breadth of the reviews that have been performed? > >> >> >> >>>>>>> > >> >> >> >>>>>>> No - the original draft had a lot of background > material, much > >> >> >> >>>>>>> of > >> >> >> >>>>>> this > >> >> >> >>>>>>> has been condensed or removed, resulting in a > smaller document. > >> >> >> >>>>>> > >> >> >> >>>>>> That is indeed what I basically asked for, but I > don't see any > >> >> >> >>>>>> evidence of it: > >> >> >> >>>>>> > >> >> >> >>>>>> - diff(07,08) 48 lines changed or deleted; 53 > lines changed or > >> >> >> added > >> >> >> >>>>>> - diff(06,07) 8 lines changed or deleted; 13 > lines changed or > >> >> >> added > >> >> >> >>>>>> - diff(05,06) 64 lines changed or deleted; 69 > lines changed or > >> >> >> >>>>>> added > >> >> >> >>>>>> - diff(04,05) 823 lines changed or deleted; 864 > lines changed or > >> >> >> >>>>>> added > >> >> >> >>>>>> > >> >> >> >>>>>> (Need I go farther? That gets us back to March 2011...) > >> >> >> >>>>>> > >> >> >> >>>>>>> (9) How solid is the WG consensus behind this > document? Does it > >> >> >> >>>>>>> represent the strong concurrence of a few individuals, with > >> >> >> >>>>>>> others being silent, or does the WG as a whole understand > >> >> >> and agree with it? > >> >> >> >>>>>>> > >> >> >> >>>>>>> The document has WG support and there is consensus > to publish. > >> >> >> >>>>>> > >> >> >> >>>>>> This, IMHO, doesn't answer the question. :^( > >> >> >> >>>>>> > >> >> >> >>>>>> Does it represent the concurrence of a few > individuals, or does > >> >> >> >>>>>> the WG as a whole understand and agree with it? > >> >> >> >>>>>> > >> >> >> >>>>>> For reference, my comments included: > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] When I previously skimmed this document, I believed it > >> >> >> >>>>>> contained only ] common ground: that AQM should > drop/mark packets > >> >> >> >>>>>> without favoring small ] packets, and that to whatever extent > >> >> >> >>>>>> packet size _is_ considered, that ] should be a > >> >> >> transport-layer responsibility. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] Alas, when I read it carefully this week, I find > that Bob is > >> >> >> >>>>>> actually ] saying that transport-layer should _only_ consider > >> >> >> >>>>>> "congested bytes", not ] "congested packets". > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] In fact, Bob openly endorses replacing TCP > congestion-control > >> >> >> >>>>>> with an ] algorithm which calculates "fair-share bytes" and > >> >> >> >>>>>> doesn't back off at all ] (even in the presence of 20% packet > >> >> >> >>>>>> loss) unless you're already sending ] more than this > >> >> >> "fair-share". > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] I do not believe that is the consensus of this WG; and I > >> >> >> believe > >> >> >> >>>>>> if > >> >> >> >>>>>> ] that were the consensus it would exceed our charter. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] The draft contains a number of things I _do_ > support; and I'd > >> >> >> >>>>>> be happy ] to support a considerably shorter draft which > >> >> >> >>>>>> concentrates on the AQM ] recommendation, omitting any > >> >> >> >>>>>> suggestions of modifying TCP congestion ] control. > >> >> >> >>>>>> > >> >> >> >>>>>> and Philip's comments included: > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] S2.2 I thought the numbered bullets could be > better phrased, > >> >> >> >>>>>> something like ] +this:- ] > >> >> >> >>>>>> ] 1. AQM algorithms such as RED SHOULD use packet-mode > >> >> >> drop, ie they > >> >> >> >>>>>> SHOULD NOT > >> >> >> >>>>>> ] +use byte-mode drop. The latter ] is more complex, > >> >> >> >>>>>> ] it creates the perverse incentive to > fragment segments > >> >> >> into > >> >> >> >>>>>> tiny > >> >> >> >>>>>> ] pieces and it is vulnerable to floods of small- > >> >> >> >>>>>> ] packets. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] 2. If a vendor has implemented byte-mode drop, and an > >> >> >> operator > >> >> >> >>>>>> has > >> >> >> >>>>>> ] turned it on, it is RECOMMENDED to turn it > off, after > >> >> >> >>>>>> establishing if > >> >> >> >>>>>> ] +there are any implications on > >> >> >> >>>>>> ] the relative performance of > >> >> >> >>>>>> ] applications using different packet sizes. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] 3. RED SHOULD NOT be turned off. Without RED, > a drop tail > >> >> >> >>>>>> ] queue biases against large packets. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] Nit - the following paragraph shouldn't be > indented (Note well > >> >> >> >>>>>> that > >> >> >> >>>>>> RED's...) > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] S3.3 > >> >> >> >>>>>> ] The section could be slightly clearer. Starting > with the second > >> >> >> >>>>>> para, where you ] +start talking about something you don't > >> >> >> >>>>>> recommend (ie you have to remember that ] +you're > talking about > >> >> >> >>>>>> the consequences of not following your recommendation). > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] S3.3 > >> >> >> >>>>>> ] o Also, if the network biases congestion > notification by > >> >> >> packet > >> >> >> >>>>>> size > >> >> >> >>>>>> ] it has to assume a baseline packet size--all proposed > >> >> >> >>>>>> algorithms > >> >> >> >>>>>> ] use the local MTU. Then transports have to > guess which > >> >> >> link > >> >> >> >>>>>> was > >> >> >> >>>>>> ] congested and what its local MTU was, in > order to know > >> >> >> how to > >> >> >> >>>>>> ] tailor their congestion response to that link. > >> >> >> >>>>>> ] So you're saying that for byte-mode drop, the > network element > >> >> >> >>>>>> has to compare the ] +size of the current pkt with > the MTU, and > >> >> >> >>>>>> if it's 25* smaller then reduce the ] +pkt loss > probably by 25*? > >> >> >> >>>>>> And if the MTU was bigger, then the current pkt would ] +be > >> >> >> >>>>>> dropped with greater probability? And both of these things > >> >> >> are hard to do. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] S3.4 (& knock-on effect on 3.3) ] I think this > could be better. > >> >> >> >>>>>> ] I agree with your arguments in S3.1 & 3.2 that dropping or > >> >> >> >>>>>> marking should be ] +independent of pkt size. > >> >> >> >>>>>> ] You now go into a couple of pages, which I think could be > >> >> >> >>>>>> boiled down to a ] +paragraph, saying something > like:- ] * the > >> >> >> >>>>>> overall system (network + transport) has to be packet-size > >> >> >> >>>>>> dependent in ] > >> >> >> >>>>>> +order to drive out the right amount of traffic so > the resource > >> >> >> >>>>>> becomes ] > >> >> >> >>>>>> +uncongested (since we assume all resources are in > practice byte > >> >> >> >>>>>> +rather > >> >> >> >>>>>> than ] +packet limited) ] * from S3.1 and S3.2 the IETF is > >> >> >> >>>>>> convinced that the network should notify ] +independent of > >> >> >> packet-size. > >> >> >> >>>>>> ] * therefore the transport must act dependent on > packet-size. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] It seems to me this is a necessary consequence of > your earlier > >> >> >> >>>>>> assumptions ] +/arguments. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] [On the other hand, if someone disagrees with the > arguments and > >> >> >> >>>>>> thinks that the ] +network should notify dependent on > >> >> >> >>>>>> packet-size, then it follows that the ] +transport can act > >> >> >> >>>>>> independent of > >> >> >> >>>>>> packet- size.] ] ] I think in S3.3 you're trying to > make another > >> >> >> >>>>>> argument (?):- ] * we can either do packet-size > biasing in the > >> >> >> >>>>>> network element or on the end host ] +transport (see argument > >> >> >> >>>>>> above) ] * packet-size biasing in the network is > quite tricky, > >> >> >> >>>>>> because then both the ] +network element & the > transport have to > >> >> >> >>>>>> make some guesses about MTU - whereas ] > >> >> >> >>>>>> +with packet-size biasing in the transport, neither network > >> >> >> >>>>>> +element > >> >> >> >>>>>> nor ] +transport needs to know what the MTU is. > >> >> >> >>>>>> ] * it is also easier to implement packet-size biasing in the > >> >> >> >>>>>> transport than in ] +the network. > >> >> >> >>>>>> ] > >> >> >> >>>>>> ] On the last bullet, I didn't really follow your argument in > >> >> >> S3.5. > >> >> >> >>>>>> Might be ] +easier to follow if S3.5 also talked about how a > >> >> >> >>>>>> network element would take ] +account of pkt size? > Also, does the > >> >> >> >>>>>> following argument also apply?: > >> >> >> >>>>>> ] * if pkt-size biasing is done in the transport, > then the work > >> >> >> >>>>>> (to do the ] +biasing) is spread over many end > hosts, ] * whereas > >> >> >> >>>>>> if pkt-size biasing is done in the network, then > the work is ] > >> >> >> >>>>>> +concentrated in just the congested network > element, which has to > >> >> >> >>>>>> operate on all ] +the traffic at line speed. > >> >> >> >>>>>> > >> >> >> >>>>>> (Has there perhaps been some confusion about what > went into the > >> >> >> >>>>>> -08 > >> >> >> >>>>>> version?) > >> >> >> >>>>>> > >> >> >> >>>>>> -- > >> >> >> >>>>>> John Leslie > >> >> >> >>>>>> > >> >> >> >>>>>> > >> >> >> >>>>> > >> >> >> >>>> > >> >> >> >>> ________________________________________________________________ > >> >> >> >>> Bob Briscoe, BT Innovate & Design > >> >> >> >>> > >> >> >> >> > >> >> >> > > >> >> > > >> >> > ________________________________________________________________ > >> >> > Bob Briscoe, BT Innovate & Design > >> >> > > >> > > >> > ________________________________________________________________ > >> > Bob Briscoe, BT Innovate & Design > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_1024161496==.ALT Content-Type: text/html; charset="us-ascii" Jukka,

OK, 2nd attempt below, annotated with HTML formatting. Rather than predicting the future, I have confined the text to the lack of universal deployment in the present. If you're happy with this, pls go ahead and re-issue the draft.


======================================================================================
3.4.  Permanent Partial Deployment of AQM

In overview, the argument in this section runs as follows:
* Because the network does will not and cannot always drop packets in proportion to their size, it shouldn't be given the task of making drop signals depend on packet size at all.
* Transports on the other hand don't always want to make their rate response proportional to the size of dropped packets, but if they want to, they always can.

The argument is similar to the end-to-end argument that says "Don't do X in the network if end-systems can do X by themselves, and they want to be able to choose whether to do X anyway." Actually the following argument is stronger; in addition it says "Don't give the network task X that could be done by the end-systems, if X is not won't ever be deployed on all network nodes, and end-systems won't be able to tell whether their network is doing X, or whether they need to do X themselves." In this case, the X in question is "making the response to congestion depend on packet size".

We will now re-run this argument taking each step in more depth. The argument applies solely to drop, not to ECN marking.

A queue drops packets for either of two reasons: a) to signal to host congestion controls that they should reduce the load and b) because there is no buffer left to store the packets. Active queue management tries to use drops as a signal for hosts to slow down (case a) so that drop due to buffer exhaustion (case b) should not be necessary.

No-one expects AQM is not to ever be universally deployed in every queue in the Internet; many cheap ethernet bridges, software firewalls, NATs on consumer devices, etc implement simple tail-drop buffers. and, eEven if AQM were universal, it has to be able to cope with buffer exhaustion (by switching to a behaviour like tail-drop), in order to cope with unresponsive or excessive transports. Therefore For both these reasons networks will often be dropping packets as a last resort (case b) rather than under AQM control (case a).

When buffers are exhausted (case b), they don't naturally drop packets in proportion to their size. The network can only reduce the probability of dropping smaller packets if it has enough space to store them somewhere while it waits for a larger packet that it can drop. If the buffer is exhausted, it does not have this choice. Admittedly tail-drop does naturally drop somewhat fewer small packets, but exactly how few depends more on the mix of sizes than the size of the packet in question. Nonetheless, in general, if we wanted networks to do size-dependent drop, we would need universal deployment of (packet-size dependent) AQM code, which is currently unrealistic.

A host transport cannot know whether any particular drop was a deliberate signal from an AQM or a sign of a queue shedding packets due to buffer exhaustion. Therefore, because the network cannot universally do size-dependent drop, it should not do it all.

Whereas universality is desirable in the network, diversity is desirable between different transport layer protocols - some, like NewReno TCP [RFC5681], may not choose to make their rate response proportionate to the size of each dropped packet, while others will (e.g. TFRC-SP [RFC4828]).
======================================================================================



Bob

At 13:34 11/10/2012, Manner Jukka wrote:
Hi,

Yeah, please at the point about cheap devices, still, I wonder what the cost of AQM is on those devices. Maybe 1 cnt in mass production? Thus, I still wonder if it is worth arguing something about the future that strongly.

Sorry, but the same goes for AQM in general, and where it is, or will not be deployed. I understand technical reasons why not something is feasible, but business or monetary reasons can change very quickly. ;)

Jukka

On Oct 11, 2012, at 3:08 PM, Bob Briscoe wrote:

> Jukka,
>
> What I had in mind is all low level buffers in cheap pure L2 devices, in cheap NATs etc. I was going to list some of these, but instead chose to say "no-one expects AQM to be universally deployed". This clearly missed the mark.
>
> Should we include some of these concrete examples of where AQM won't be deployed instead?
>
> [I've cc'd the list, given we're starting to wordsmith significantly new text added since WG last call.]
>
>
> Bob
>
> At 20:04 10/10/2012, Manner Jukka wrote:
>> Hi, looked good to me. Just one comment, I wouldn't put that much emphasis on what is a probably state of things, e.g.
>>
>> "no-one expects AQM to ever be .."  > in the future it might, we don't know, and since the paragraph says that it doesn't matter anyway, I would formulate this paragraph a bit towards that we have partial deployment now and  even with a full deployment, ...
>>
>> and similarly with the unrealistic deployment of AQM in the subsequent paragraph.
>>
>> cheers,
>> Jukka
>>
>> On Oct 10, 2012, at 6:25 PM, Bob Briscoe wrote:
>>
>> > Phil,
>> >
>> > Sorry for delay, my round-robin scheduler is taking so long to get round all the tasks that I keep finding dead robins (that reminds me of a bike ride my grandmother took. On her return, she said there were a worryingly large number of robins run over on the roads. It turned out that she had been going round the same small triangle of roads multiple times).
>> >
>> > I've done a complete re-write of 3.4. I hope you will agree that it really is a motivating argument now and it can stay where it is - it is not just a preamble.
>> >
>> > I've gone back to the very first version of 3.4 I wrote and I now realise that I had written the core of the argument so badly that even I forgot what it was meant to say when we started editing it. In the draft-08 version, the original meaning is lost and in your re-wording it is entirely lost. The link with the draft-08 version is nearly unrecognisable, but it's the argument I intended here.
>> >
>> > ======================================================================================
>> > 3.4.  Permanent Partial Deployment of AQM
>> >
>> > In overview, the argument in this section runs as follows:
>> > * Because the network will not and cannot always drop packets in proportion to their size, it shouldn't be given the task of making drop signals depend on packet size at all.
>> > * Transports on the other hand don't always want to make their rate response proportional to the size of dropped packets, but if they want to, they always can.
>> >
>> > The argument is similar to the end-to-end argument that says "Don't do X in the network if end-systems can do X by themselves, and they want to be able to choose whether to do X anyway." Actually the following argument is stronger; in addition it says "Don't give the network task X that could be done by the end-systems, if X won't ever be deployed on all network nodes, and end-systems won't be able to tell whether their network is doing X, or whether they need to do X themselves." In this case, the X in question is "making the response to congestion depend on packet size".
>> >
>> > We will now re-run this argument taking each step in more depth. The argument applies solely to drop, not ECN marking.
>> >
>> > A queue drops packets for either of two reasons: a) to signal to host congestion controls that they should reduce the load and b) because there is no buffer left to store the packets. Active queue management tries to use drops as a signal for hosts to slow down (case a) so that drop due to buffer exhaustion (case b) should not be necessary.
>> >
>> > No-one expects AQM to ever be universally deployed in every queue in the Internet; and, even if AQM were universal, it has to be able to cope with buffer exhaustion (by switching to a behaviour like tail-drop), in order to cope with unresponsive or excessive transports. Therefore networks will often be dropping packets as a last resort (case b) rather than under AQM control (case a).
>> >
>> > When buffers are exhausted (case b), they don't naturally drop packets in proportion to their size. The network can only reduce the probability of dropping smaller packets if it has enough space to store them somewhere while it waits for a larger packet that it can drop. If the buffer is exhausted, it does not have this choice. Admittedly tail-drop does naturally drop somewhat fewer small packets, but exactly how few depends more on the mix of sizes than the size of the packet in question. Nonetheless, in general, if we wanted networks to do size-dependent drop, we would need universal deployment of (packet-size dependent) AQM code, which is unrealistic.
>> >
>> > A host transport cannot know whether any particular drop was a deliberate signal from an AQM or a sign of a queue shedding packets due to buffer exhaustion. Therefore, because the network cannot universally do size-dependent drop, it should not do it all.
>> >
>> > Whereas universality is desirable in the network, diversity is desirable between different transport layer protocols - some, like NewReno TCP [RFC5681], may not choose to make their rate response proportionate to the size of each dropped packet, while others will (e.g. TFRC-SP [RFC4828]).
>> > ======================================================================================
>> >
>> >
>> >
>> >
>> > Bob
>> >
>> > At 13:13 04/10/2012, gorry@erg.abdn.ac.uk wrote:
>> >> That would be brilliant!
>> >>
>> >> Gorry
>> >>
>> >> > Will try to look at this later today.
>> >> >
>> >> >
>> >> > Bob
>> >> >
>> >> > At 10:42 02/10/2012, philip.eardley@bt.com wrote:
>> >> >>Think the token is with bob
>> >> >>
>> >> >>Re your comment - yes, I think you could move 3.4 to the end of S3 -
>> >> >>or to the start - and do some re-phrasing, maybe something like I tried.
>> >> >>
>> >> >>-----Original Message-----
>> >> >>From: Manner Jukka [ mailto:jukka.manner@aalto.fi]
>> >> >>Sent: 01 October 2012 20:18
>> >> >>To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,Bob,DUB8 R
>> >> >>Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst
>> >> >>Subject: Re: [REVISED I-D]: Document writeup for
>> >> >>draft-ietf-tsvwg-byte-pkt-congest
>> >> >>
>> >> >>Phil, Bob, can we close this finally? It's three weeks now since
>> >> >>this previous message.
>> >> >>
>> >> >>Jukka
>> >> >>
>> >> >>On Sep 10, 2012, at 4:42 PM, Jukka Manner wrote:
>> >> >>
>> >> >> > Ack, I'm getting there...;)
>> >> >> >
>> >> >> > So, we could move 3.4 at the end of Section 3 and rephrase it to
>> >> >> not talk about scaling per se, but rather about how Req 2.2
>> >> >> eventually leads to Req 2.3?
>> >> >> >
>> >> >> > Jukka
>> >> >> >
>> >> >> > On Sep 7, 2012, at 4:07 PM, <philip.eardley@bt.com>
>> >> >> > <philip.eardley@bt.com> wrote:
>> >> >> >
>> >> >> >> 3.4 is, in my mind, completely different from 3.1, 3.2, 3.3 and 3.5.
>> >> >> >>
>> >> >> >> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for Recommendation
>> >> >> >> 2.2 & a lesser extent 2.3
>> >> >> >> 3.4 makes doesn't make a motivating argument - it explains that  Rec
>> >> >> >> 2.2 & 2.3 come as a pair (if you recommend one, then inevitably you
>> >> >> >> recommend the other) (delta some politeness about TCP)
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> -----Original Message-----
>> >> >> >> From: Manner Jukka [ mailto:jukka.manner@aalto.fi]
>> >> >> >> Sent: 07 September 2012 13:24
>> >> >> >> To: Eardley,PL,Philip,DUB8 R
>> >> >> >> Cc: Briscoe,RJ,Bob,DUB8 R; <tsvwg-chairs@ietf.org>;
>> >> >> >> <gorry@erg.abdn.ac.uk>
>> >> >> >> Subject: Re: [REVISED I-D]: Document writeup for
>> >> >> >> draft-ietf-tsvwg-byte-pkt-congest
>> >> >> >>
>> >> >> >> Hi, I'm trying to follow your reasoning, with little luck. ;)
>> >> >> >>
>> >> >> >> After having read Section 3 again, I could think of a few
>> >> >> updates, but I'm not fully following what you want to see:
>> >> >> >>
>> >> >> >> - S3.5 is kind of small and lonely by itself. It could be either
>> >> >> longer or merged somewhere. Not a major issue though and could remain as
>> >> >> is.
>> >> >> >>
>> >> >> >> - S3.3: Yes, probably could be turned upside down, good first,
>> >> >> bad later. Don't have a strong opinion.
>> >> >> >>
>> >> >> >> - S3.4: Here the scaling is used many times and in the title,
>> >> >> although we talk about the end host side. This could be rephrased
>> >> >> and slightly reworded to talk about hosts and their operation
>> >> >> altogether. Also the word scaling can turn the readers expectation
>> >> >> into the wrong direction.
>> >> >> >>
>> >> >> >> - S3 altogether: It would help to have introductory text about
>> >> >> networks vs. end host side, but I fail to see why  (& how) to
>> >> >> restructure everything.
>> >> >> >>
>> >> >> >> cheers,
>> >> >> >> Jukka
>> >> >> >>
>> >> >> >> On Sep 6, 2012, at 6:18 PM,
>> >> >> <philip.eardley@bt.com>  <philip.eardley@bt.com> wrote:
>> >> >> >>
>> >> >> >>> Ps otherwise Bob's comments are fine, though I suggest for S3.5 you
>> >> >> >>> give more context (ie are you knocking down what you recommend
>> >> >> >>> against, or building up what you recommend?)  and in S3.3 think
>> >> >> >>> would be better if you re-structured slightly [first talk about what
>> >> >> >>> you like - penult para + 1st sentence of last para - then talk about
>> >> >> >>> what you don't like - rest of text]
>> >> >> >>>
>> >> >> >>> From: Eardley,PL,Philip,DUB8 R
>> >> >> >>> Sent: 06 September 2012 16:12
>> >> >> >>> To: Briscoe,RJ,Bob,DUB8 R; Manner Jukka
>> >> >> >>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst
>> >> >> >>> Subject: RE: [REVISED I-D]: Document writeup for
>> >> >> >>> draft-ietf-tsvwg-byte-pkt-congest
>> >> >> >>>
>> >> >> >>> Thanks bob. Have now re-booted some state.
>> >> >> >>> I don't like S3.4. My basic problem with it is that it isn't a
>> >> >> "motivating argument" (S3 title). It's an explanation about the
>> >> >> consequences of assuming either [option 1] do pkt-size biasing in
>> >> >> the transport; [option 2]; do pkt-size biasing in the nw.
>> >> >> >>> Perhaps your effort to buy peace with those who won't change
>> >> >> TCP has obfuscated the basic point?
>> >> >> >>> The title of S3.4 (Scaling...) and the early text "scaling
>> >> >> argument" suggests that you're going to argue there is some reason
>> >> >> why X scales as order N rather than N^2 or something like that -
>> >> >> which isn't what S3.4 is about.
>> >> >> >>>
>> >> >> >>> I actually think it would be better to put S3.4 at the start of
>> >> >> S3 - it's background where you say there are 2 options. After that,
>> >> >> you can explain the reasons why option 1 [pkt biasing in the
>> >> >> transport] is better - the reasons being:-  S3.1 (security etc
>> >> >> attacks if small pkts get preferential treatment), S3.2 (really a
>> >> >> side note to S3.1; ie doesn't really present a "motivating
>> >> >> argument"), S3.3 (nw guessing MTU vs transport knowing pkt size),
>> >> >> S3.5 (easier implementation).
>> >> >> >>>
>> >> >> >>> Something like...
>> >> >> >>> The behaviour of the network and transport together needs to
>> >> >> >>> alleviate congestion. We assume the network is bit-congestible
>> >> >> (currently packet-congestible resources are rate). Therefore
>> >> >> overall the response of the {network + transport} should be the
>> >> >> same for the same congestion - whether the congestion is caused by
>> >> >> a lot of small packets or a smaller number of larger packets. The
>> >> >> implication is that the transport's behaviour should depend on
>> >> >> whether the network takes account (or not) of packet size when it
>> >> >> generates congestion indications:- Case 1: If the network
>> >> >> implements packet-mode drop, ie its algorithm treats all packets
>> >> >> equally regardless of their size, then the transport should take
>> >> >> account of the size of the packet - in other words, the transport's
>> >> >> congestion response should depend on the number of dropped bytes.
>> >> >> >>> Case 2: If the network implements byte-mode drop, ie its
>> >> >> algorithm treats packets differently depending on their size, then
>> >> >> the transport should not take account of the size of the packet -
>> >> >> in other words, the transport's congestion response should depend
>> >> >> on the number of dropped packets.
>> >> >> >>>
>> >> >> >>> These cases are explained in more detail in sub-section below.
>> >> >> >>>
>> >> >> >>> In both cases the same discussion applies if packets are
>> >> >> ECN-marked rather than dropped.
>> >> >> >>> In the following sections we explain why Case 1 is preferable,
>> >> >> and hence why we make the Recommendations of S2.2 and S3.3
>> >> >> (respectively, drop/mark pkts equally regardless of their size, and
>> >> >> the strength of the transport's response should be proportionate to
>> >> >> the size of the dropped/marked pkt).
>> >> >> >>> Note that TCP responds to dropped or marked packets, which differs
>> >> >> >>> from our recommendation for transports. However, we are not
>> >> >> >>> recommending that TCP  should be changed; to date it hasn't been a
>> >> >> >>> significant problem because most TCP implementations  have been
>> >> >> used with similar packet sizes. But we do recommend that future
>> >> >> transport protocols should  respond to dropped or marked bytes (as
>> >> >> for example TFRC-SP [RFC4828]effectively does).
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> Sub-section
>> >> >> >>> You could use much of S3.3, I suggest supplement with numerical
>> >> >> >>> examples continuing S1.2
>> >> >> >>> --
>> >> >> >>> << This gives a get-out clause to any transport that isn't
>> >> >> >>> packet-size dependent (e.g. current TCP). Lacking packet-size
>> >> >> >>> dependence just means they don't scale correctly with packet size -
>> >> >> >>> but they are at liberty not to scale with packet size (particularly
>> >> >> >>> given MTU growth isn't often being used to increase link rates at
>> >> >> >>> this stage in history).>>
>> >> >> >>>
>> >> >> >>> This is introducing a different point. it's saying that your
>> >> >> recommendation 2 [drop/mark pkts equally regardless of their size]
>> >> >> is a really strong reco whilst recommendation 3 [strength of
>> >> >> transport's response proportionate to the size of the
>> >> >> dropped/marked pkt] is a much less important reco.  I can see this
>> >> >> might be true, but I don't think the i-d talks about this.
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>>
>> >> >> >>> From: Briscoe,RJ,Bob,DUB8 R
>> >> >> >>> Sent: 05 September 2012 16:41
>> >> >> >>> To: Manner Jukka
>> >> >> >>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst; Eardley,PL,Philip,DUB8 R
>> >> >> >>> Subject: Re: [REVISED I-D]: Document writeup for
>> >> >> >>> draft-ietf-tsvwg-byte-pkt-congest
>> >> >> >>>
>> >> >> >>> Jukka,
>> >> >> >>>
>> >> >> >>> I've repeated Phil's suggestions as quoted email then made some
>> >> >> alterations.
>> >> >> >>>
>> >> >> >>> Phil asked me to send this, then he will think about it.
>> >> >> >>>
>> >> >> >>> I'll respond about John Leslie's argument next...
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> 2.2. Recommendation on Encoding Congestion Notification
>> >> >> >>>
>> >> >> >>> [...]
>> >> >> >>>
>> >> >> >>>  1.  AQM algorithms such as RED SHOULD use packet-mode drop, ie they
>> >> >> >>>      SHOULD NOT use byte-mode drop. The latter is more complex,
>> >> >> >>>      it creates the perverse incentive to fragment segments into
>> >> >> tiny
>> >> >> >>>      pieces and it is vulnerable to floods of small packets.
>> >> >> >>>
>> >> >> >>>  2.  If a vendor has implemented byte-mode drop, and an operator has
>> >> >> >>>      turned it on, it is RECOMMENDED to turn it off, after
>> >> >> establishing
>> >> >> >>>      if there are any implications on the relative performance of
>> >> >> >>>      applications using different packet sizes.
>> >> >> >>>
>> >> >> >>>      RED as a whole SHOULD NOT be turned off. Without RED, a drop
>> >> >> tail
>> >> >> >>>      queue biases against large packets
>> >> >> >>>
>> >> >> >>> [BB adds]:                                 and it is vulnerable to
>> >> >> floods
>> >> >> >>>       of small-packets.
>> >> >> >>>
>> >> >> >>> (I suggest the last para just qualifies item 2. It doesn't warrant
>> >> >> >>> another item number.)
>> >> >> >>>
>> >> >> >>> <Agree with Phil; Don't indent "Note well...">
>> >> >> >>>
>> >> >> >>> [PE:] S3.3
>> >> >> >>> The section could be slightly clearer. Starting with the second
>> >> >> para, where you start talking about something you don't recommend
>> >> >> (ie you have to remember that you're talking about the consequences
>> >> >> of not following your recommendation).
>> >> >> >>>
>> >> >> >>> 3.3 Transport-Independent Network
>> >> >> >>>
>> >> >> >>>  TCP congestion control ensures that flows competing for the same
>> >> >> >>> resource each maintain the same number of segments in flight,
>> >> >> >>> irrespective of segment size.  So under similar conditions, flows
>> >> >> >>> with different segment sizes will get different bit-rates.
>> >> >> >>>
>> >> >> >>> [OLD:]
>> >> >> >>>  One motivation for the network biasing congestion notification by
>> >> >> >>> packet size is to counter this effect and try to equalise the bit-
>> >> >> >>> rates of flows with different packet sizes.
>> >> >> >>> [SUGGESTED:]
>> >> >> >>>  To counter this effect it seems tempting not to follow our
>> >> >> >>> recommendation,  and instead for the network to bias congestion
>> >> >> >>> notification by  packet size in order to equalise the bit-rates of
>> >> >> >>> flows with different  packet sizes.
>> >> >> >>> [CONTINUE AS BEFORE:]
>> >> >> >>>                However, in order to do  this, the queuing algorithm
>> >> >> >>> has to make assumptions about the  transport, which become embedded
>> >> >> >>> in the network.  Specifically:
>> >> >> >>> [...]
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> S3.3
>> >> >> >>>  o  The queuing algorithm has to assume how aggressively the
>> >> >> transport
>> >> >> >>>     will respond to congestion (see Section 4.2.4).  If the network
>> >> >> >>>     assumes the transport responds as aggressively as TCP NewReno,
>> >> >> it
>> >> >> >>>     will be wrong for Compound TCP and differently wrong for Cubic
>> >> >> >>>     TCP, etc.  To achieve equal bit-rates, each transport then has
>> >> >> to
>> >> >> >>>     guess what assumption the network made, and work out how to
>> >> >> >>>     replace this assumed aggressiveness with its own aggressiveness.
>> >> >> >>>  o  Also, if the network biases congestion notification by packet
>> >> >> size
>> >> >> >>>     it has to assume a baseline packet size--all proposed algorithms
>> >> >> >>>     use the local MTU.  Then transports have to guess which link was
>> >> >> >>>     congested and what its local MTU was, in order to know how to
>> >> >> >>>     tailor their congestion response to that link.
>> >> >> >>>
>> >> >> >>> So you're saying that for byte-mode drop, the network element
>> >> >> has to compare the size of the current pkt with the MTU, and if
>> >> >> it's 25* smaller then reduce the pkt loss probably by 25*? And if
>> >> >> the MTU was bigger, then the current pkt would be dropped with
>> >> >> greater probability? And both of these things are hard to do.
>> >> >> >>>
>> >> >> >>> [BB]: SUGGESTED REPLACEMENT to 2nd bullet:
>> >> >> >>>
>> >> >> >>>  o  Also, if the network biases congestion notification by packet
>> >> >> size
>> >> >> >>>     it has to assume a baseline packet size--all proposed algorithms
>> >> >> >>>     use the local MTU (for example see the byte-mode loss
>> >> >> probability
>> >> >> >>>     formula in Table 1).  Then if the non-Reno transports mentioned
>> >> >> above
>> >> >> >>>     are trying to reverse engineer what the network assumed, they
>> >> >> also
>> >> >> >>>     have to guess the MTU of the congested link.
>> >> >> >>>
>> >> >> >>> [Aside for Phil: The byte-mode algo uses MTU as its baseline because
>> >> >> >>> a link cannot send a packet bigger than its MTU so the algo won't
>> >> >> >>> ever give a drop probability >1).]
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> S3.4 (& knock-on effect on 3.3)
>> >> >> >>> I think this could be better.
>> >> >> >>> I agree with your arguments in S3.1 & 3.2 that dropping or
>> >> >> marking should be independent of pkt size.
>> >> >> >>> You now go into a couple of pages, which I think could be boiled
>> >> >> >>> down to a paragraph, saying something like:-
>> >> >> >>> * the overall system (network + transport) has to be packet-size
>> >> >> >>> dependent in order to drive out the right amount of traffic so the
>> >> >> >>> resource becomes uncongested (since we assume all resources are in
>> >> >> >>> practice byte rather than packet limited)
>> >> >> >>> * from S3.1 and S3.2 the IETF is convinced that the network
>> >> >> should notify independent of packet-size.
>> >> >> >>> * therefore the transport must act dependent on packet-size.
>> >> >> >>>
>> >> >> >>> It seems to me this is a necessary consequence of your earlier
>> >> >> assumptions /arguments.
>> >> >> >>>
>> >> >> >>> [BB:] This isn't at all obvious. Until I worked it through, it
>> >> >> wasn't obvious to me. I think it needs to be spelled out.
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> [On the other hand, if someone disagrees with the arguments and
>> >> >> >>> thinks that the network should notify dependent on packet-size, then
>> >> >> >>> it follows that the transport can act independent of packet-size.]
>> >> >> >>>
>> >> >> >>> I think in S3.3 you're trying to make another argument (?):-
>> >> >> >>> * we can either do packet-size biasing in the network element or on
>> >> >> >>> the end host transport (see argument above)
>> >> >> >>> * packet-size biasing in the network is quite tricky, because
>> >> >> then both the network element & the transport have to make some
>> >> >> guesses about MTU - whereas with packet-size biasing in the
>> >> >> transport, neither network element nor transport needs to know what the
>> >> >> MTU is.
>> >> >> >>> * it is also easier to implement packet-size biasing in the
>> >> >> transport than in the network.
>> >> >> >>>
>> >> >> >>> [BB] ...and all the other arguments about vulnerability to
>> >> >> flooding etc, transport-independence etc.
>> >> >> >>>
>> >> >> >>> Our argument is sort of like how Phil summarises it, but with
>> >> >> an added nuance. It's also saying no-one has to do packet-size
>> >> >> biasing anyway. It's not saying "The transport should given the
>> >> >> network shouldn't". It's saying "*If the transport wants to claim
>> >> >> to be scalable wrt packet size* it should if the network shouldn't".
>> >> >> >>>
>> >> >> >>> This gives a get-out clause to any transport that isn't
>> >> >> packet-size dependent (e.g. current TCP). Lacking packet-size
>> >> >> dependence just means they don't scale correctly with packet size -
>> >> >> but they are at liberty not to scale with packet size (particularly
>> >> >> given MTU growth isn't often being used to increase link rates at
>> >> >> this stage in history).
>> >> >> >>>
>> >> >> >>> None of what Phil says convinces me we could say 3.4 (or 3.3)
>> >> >> any more briefly or differently. It's easier to summarise what you
>> >> >> understand having read something. But that's not the same as
>> >> >> writing the thing that helped you understand. There doesn't seem to
>> >> >> be any argument for why anything needs to be changed, so I'm going
>> >> >> to leave it as is, unless pushed.
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> On the last bullet, I didn't really follow your argument in
>> >> >> S3.5. Might be easier to follow if S3.5 also talked about how a
>> >> >> network element would take account of pkt size?
>> >> >> >>> Also, does the following argument also apply?:
>> >> >> >>> * if pkt-size biasing is done in the transport, then the work (to do
>> >> >> >>> the biasing) is spread over many end hosts,
>> >> >> >>> * whereas if pkt-size biasing is done in the network, then the
>> >> >> work is concentrated in just the congested network element, which
>> >> >> has to operate on all the traffic at line speed.
>> >> >> >>>
>> >> >> >>> [BB]: 3.5. Implementation Efficiency
>> >> >> >>>
>> >> >> >>> [ADD:]
>> >> >> >>>  Biasing against large packets typically requires an extra multiply
>> >> >> >>> and  divide in the network (see the example byte-mode drop
>> >> >> formula in table 1).
>> >> >> >>> [CONTINUE AS BEFORE:]
>> >> >> >>>  Allowing for packet size at the transport rather than in the
>> >> >> >>> network  ensures that neither the network nor the transport needs to
>> >> >> >>> do a  multiply operation--multiplication by packet size is
>> >> >> >>> effectively  achieved as a repeated add when the transport adds to
>> >> >> >>> its count of  marked bytes as each congestion event is fed to it.
>> >> >> >>> [ADD:]
>> >> >> >>>  Also the work to do the biasing is spread over many hosts, rather
>> >> >> >>> than  concentrated in just the congested network element.
>> >> >> >>> [CONTINUE AS BEFORE:]
>> >> >> >>>                                                      These aren't
>> >> >> >>> principled reasons in themselves, but they are a happy consequence
>> >> >> >>> of the  other principled reasons.
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> Bob
>> >> >> >>>
>> >> >> >>> At 13:36 05/09/2012, Manner Jukka wrote:
>> >> >> >>>
>> >> >> >>> Hi Bob,
>> >> >> >>>
>> >> >> >>> Since Phil is your colleague at BT, even at Ipswich (?), can
>> >> >> you check those and agree with Phil how to go forward? Some of
>> >> >> those are clear, others need discussion with Phil.
>> >> >> >>>
>> >> >> >>> Gorry, on point 2) below, I don't follow Leslie's arguments. I
>> >> >> asked from him detailed comments and resolutions months ago, and nothing
>> >> >> came.
>> >> >> >>>
>> >> >> >>> cheers,
>> >> >> >>> Jukka
>> >> >> >>>
>> >> >> >>> On Sep 5, 2012, at 3:26 PM, Gorry Fairhurst wrote:
>> >> >> >>>
>> >> >> >>>> Bob and Jukka,
>> >> >> >>>>
>> >> >> >>>> I think I need your help to resolve this... Some of the
>> >> >> comments raised by John Leslie appear to have substance, and I'm
>> >> >> not sure what you plan to do to address these.
>> >> >> >>>>
>> >> >> >>>> It would be good to do something quick so that I can complete
>> >> >> the submission to the IESG.
>> >> >> >>>>
>> >> >> >>>> The issues I particularly note are:
>> >> >> >>>>
>> >> >> >>>> 1) This contribution from Phil appears to be within scope and
>> >> >> it seems may have been overlooked (sorry):
>> >> >> >>>> http://www.ietf.org/mail-archive/web/tsvwg/current/msg11234.html
>> >> >> >>>>
>> >> >> >>>> 2) Can you be clear here about what is actually been said -
>> >> >> because the point below seems to be a misunderstanding of language
>> >> >> to me, and I hoped we did not claim this:
>> >> >> >>>>
>> >> >> >>>>>> ] Alas, when I read it carefully this week, I find that Bob is
>> >> >> >>>>>> actually ] saying that transport-layer should _only_ consider
>> >> >> >>>>>> "congested bytes", not ] "congested packets".
>> >> >> >>>>>> ]
>> >> >> >>>>
>> >> >> >>>> 3) You'll need to post the updated draft and send a note to
>> >> >> the group to confirm that the new version indeed concludes the
>> >> >> WGLC. I'll add a note to the writeup to indicate the draft content
>> >> >> has been stable since Oct 2011.
>> >> >> >>>>
>> >> >> >>>> Gorry (with my TSVWG Documnent Shepherd hat)
>> >> >> >>>> cc: Co-Chairs for info.
>> >> >> >>>>
>> >> >> >>>>>
>> >> >> >>>>>> -----Original Message-----
>> >> >> >>>>>> From: Gorry Fairhurst [ mailto:gorry@erg.abdn.ac.uk]
>> >> >> >>>>>> Sent: Mittwoch, 15. August 2012 21:41
>> >> >> >>>>>> To: tsvwg chair
>> >> >> >>>>>> Subject: Fwd: Re: [tsvwg] FYI: Document writeup for
>> >> >> >>>>>> draft-ietf-tsvwg- byte-pkt-congest
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>> Hi guys,
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>> Apart form the usual rhetoric, there are some points here that we
>> >> >> >>>>>> should note as chairs. What are you own thoughts? And was
>> >> >> >>>>>> anything noted at the IETF in Vancouver concerning this draft?
>> >> >> >>>>>>
>> >> >> >>>>>> Gorry
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>> -------- Original Message --------
>> >> >> >>>>>> Subject: Re: [tsvwg] FYI: Document writeup for
>> >> >> >>>>>> draft-ietf-tsvwg-byte- pkt-congest
>> >> >> >>>>>> Date: Wed, 15 Aug 2012 15:07:28 -0400
>> >> >> >>>>>> From: John Leslie <john@jlc.net>
>> >> >> >>>>>> To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
>> >> >> >>>>>> CC: tsvwg@ietf.org
>> >> >> >>>>>>
>> >> >> >>>>>> Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>> >> >> >>>>>>>
>> >> >> >>>>>>> The following document has been revised after receiving
>> >> >> WGLC comments.
>> >> >> >>>>>>
>> >> >> >>>>>>   The changes are mostly refreshing a document scheduled to
>> >> >> >>>>>> expire this month.
>> >> >> >>>>>>
>> >> >> >>>>>>> No issues were found:
>> >> >> >>>>>>
>> >> >> >>>>>>   Is that with WGC-hat-on?
>> >> >> >>>>>>
>> >> >> >>>>>>   Neither my issues nor Philip Eardley's comments were addressed.
>> >> >> >>>>>> In fact, not even the changes Bob Briscoe mentioned on-list have
>> >> >> >>>>>> been included.
>> >> >> >>>>>>
>> >> >> >>>>>>> As required by RFC 4858, this is the current template for the
>> >> >> >>>>>> Document
>> >> >> >>>>>>> Shepherd Write-Up.
>> >> >> >>>>>>> ...
>> >> >> >>>>>>> (1) What type of RFC is being requested (BCP, Proposed Standard,
>> >> >> >>>>>>> Internet Standard, Informational, Experimental, or Historic)?
>> >> >> >>>>>>> Why is this the proper type of RFC? Is this type of RFC
>> >> >> >>>>>>> indicated in the title page header?
>> >> >> >>>>>>>
>> >> >> >>>>>>> This document is intended as BCP. (This was discussed at IETF-81
>> >> >> >>>>>>> and that the status changed from Informational to BCP since it
>> >> >> >>>>>>> provides guidance to implementors and people configuring
>> >> >> routers and hosts).
>> >> >> >>>>>>
>> >> >> >>>>>>   Thank you for finally answering my question about BCP status.
>> >> >> >>>>>>
>> >> >> >>>>>>> ...
>> >> >> >>>>>>> Working Group Summary
>> >> >> >>>>>>>
>> >> >> >>>>>>> There was consensus to publish this as a WG document and
>> >> >> >>>>>>> agreement at
>> >> >> >>>>>>> IETF-82 that the document was now complete.
>> >> >> >>>>>>
>> >> >> >>>>>>   Was that reviewed on-list?
>> >> >> >>>>>>
>> >> >> >>>>>>> ...
>> >> >> >>>>>>> (3) Briefly describe the review of this document that was
>> >> >> >>>>>>> performed
>> >> >> >>>>>> by
>> >> >> >>>>>>> the Document Shepherd. If this version of the document is not
>> >> >> >>>>>>> ready for publication, please explain why the document is being
>> >> >> >>>>>>> forwarded to the IESG.
>> >> >> >>>>>>>
>> >> >> >>>>>>> The document was presented at IEWTF-82 (Taipei), with a request
>> >> >> >>>>>>> for
>> >> >> >>>>>> WGLC.
>> >> >> >>>>>>> WGLC concluded with some discussion but no substantive changes
>> >> >> >>>>>>> on Friday 30th March 2012.
>> >> >> >>>>>>
>> >> >> >>>>>>   Yes, I guess that is true; but ignoring substantive comments
>> >> >> >>>>>> isn't a good practice IMHO.
>> >> >> >>>>>>
>> >> >> >>>>>>> (4) Does the document Shepherd have any concerns about the depth
>> >> >> >>>>>>> or breadth of the reviews that have been performed?
>> >> >> >>>>>>>
>> >> >> >>>>>>> No - the original draft had a lot of background material, much
>> >> >> >>>>>>> of
>> >> >> >>>>>> this
>> >> >> >>>>>>> has been condensed or removed, resulting in a smaller document.
>> >> >> >>>>>>
>> >> >> >>>>>>   That is indeed what I basically asked for, but I don't see any
>> >> >> >>>>>> evidence of it:
>> >> >> >>>>>>
>> >> >> >>>>>> - diff(07,08)  48 lines changed or deleted;  53 lines changed or
>> >> >> added
>> >> >> >>>>>> - diff(06,07)   8 lines changed or deleted;  13 lines changed or
>> >> >> added
>> >> >> >>>>>> - diff(05,06)  64 lines changed or deleted;  69 lines changed or
>> >> >> >>>>>> added
>> >> >> >>>>>> - diff(04,05) 823 lines changed or deleted; 864 lines changed or
>> >> >> >>>>>> added
>> >> >> >>>>>>
>> >> >> >>>>>> (Need I go farther? That gets us back to March 2011...)
>> >> >> >>>>>>
>> >> >> >>>>>>> (9) How solid is the WG consensus behind this document? Does it
>> >> >> >>>>>>> represent the strong concurrence of a few individuals, with
>> >> >> >>>>>>> others being silent, or does the WG as a whole understand
>> >> >> and agree with it?
>> >> >> >>>>>>>
>> >> >> >>>>>>> The document has WG support and there is consensus to publish.
>> >> >> >>>>>>
>> >> >> >>>>>>   This, IMHO, doesn't answer the question. :^(
>> >> >> >>>>>>
>> >> >> >>>>>>   Does it represent the concurrence of a few individuals, or does
>> >> >> >>>>>> the WG as a whole understand and agree with it?
>> >> >> >>>>>>
>> >> >> >>>>>> For reference, my comments included:
>> >> >> >>>>>> ]
>> >> >> >>>>>> ] When I previously skimmed this document, I believed it
>> >> >> >>>>>> contained only ] common ground: that AQM should drop/mark packets
>> >> >> >>>>>> without favoring small ] packets, and that to whatever extent
>> >> >> >>>>>> packet size _is_ considered, that ] should be a
>> >> >> transport-layer responsibility.
>> >> >> >>>>>> ]
>> >> >> >>>>>> ] Alas, when I read it carefully this week, I find that Bob is
>> >> >> >>>>>> actually ] saying that transport-layer should _only_ consider
>> >> >> >>>>>> "congested bytes", not ] "congested packets".
>> >> >> >>>>>> ]
>> >> >> >>>>>> ] In fact, Bob openly endorses replacing TCP congestion-control
>> >> >> >>>>>> with an ] algorithm which calculates "fair-share bytes" and
>> >> >> >>>>>> doesn't back off at all ] (even in the presence of 20% packet
>> >> >> >>>>>> loss) unless you're already sending ] more than this
>> >> >> "fair-share".
>> >> >> >>>>>> ]
>> >> >> >>>>>> ]    I do not believe that is the consensus of this WG; and I
>> >> >> believe
>> >> >> >>>>>> if
>> >> >> >>>>>> ] that were the consensus it would exceed our charter.
>> >> >> >>>>>> ]
>> >> >> >>>>>> ] The draft contains a number of things I _do_ support; and I'd
>> >> >> >>>>>> be happy ] to support a considerably shorter draft which
>> >> >> >>>>>> concentrates on the AQM ] recommendation, omitting any
>> >> >> >>>>>> suggestions of modifying TCP congestion ] control.
>> >> >> >>>>>>
>> >> >> >>>>>> and Philip's comments included:
>> >> >> >>>>>> ]
>> >> >> >>>>>> ] S2.2 I thought the numbered bullets could be better phrased,
>> >> >> >>>>>> something like ] +this:- ]
>> >> >> >>>>>> ]   1.  AQM algorithms such as RED SHOULD use packet-mode
>> >> >> drop, ie they
>> >> >> >>>>>> SHOULD NOT
>> >> >> >>>>>> ] +use byte-mode drop. The latter ] is more complex,
>> >> >> >>>>>> ]        it creates the perverse incentive to fragment segments
>> >> >> into
>> >> >> >>>>>> tiny
>> >> >> >>>>>> ]        pieces and it is vulnerable to floods of small-
>> >> >> >>>>>> ]        packets.
>> >> >> >>>>>> ]
>> >> >> >>>>>> ]    2.  If a vendor has implemented byte-mode drop, and an
>> >> >> operator
>> >> >> >>>>>> has
>> >> >> >>>>>> ]        turned it on, it is RECOMMENDED to turn it off, after
>> >> >> >>>>>> establishing if
>> >> >> >>>>>> ] +there are any implications on
>> >> >> >>>>>> ] the relative performance of
>> >> >> >>>>>> ]        applications using different packet sizes.
>> >> >> >>>>>> ]
>> >> >> >>>>>> ]   3.  RED SHOULD NOT be turned off. Without RED, a drop tail
>> >> >> >>>>>> ]        queue biases against large packets.
>> >> >> >>>>>> ]
>> >> >> >>>>>> ] Nit - the following paragraph shouldn't be indented (Note well
>> >> >> >>>>>> that
>> >> >> >>>>>> RED's...)
>> >> >> >>>>>> ]
>> >> >> >>>>>> ] S3.3
>> >> >> >>>>>> ] The section could be slightly clearer. Starting with the second
>> >> >> >>>>>> para, where you ] +start talking about something you don't
>> >> >> >>>>>> recommend (ie you have to remember that ] +you're talking about
>> >> >> >>>>>> the consequences of not following your recommendation).
>> >> >> >>>>>> ]
>> >> >> >>>>>> ] S3.3
>> >> >> >>>>>> ]    o  Also, if the network biases congestion notification by
>> >> >> packet
>> >> >> >>>>>> size
>> >> >> >>>>>> ]       it has to assume a baseline packet size--all proposed
>> >> >> >>>>>> algorithms
>> >> >> >>>>>> ]       use the local MTU.  Then transports have to guess which
>> >> >> link
>> >> >> >>>>>> was
>> >> >> >>>>>> ]       congested and what its local MTU was, in order to know
>> >> >> how to
>> >> >> >>>>>> ]       tailor their congestion response to that link.
>> >> >> >>>>>> ] So you're saying that for byte-mode drop, the network element
>> >> >> >>>>>> has to compare the ] +size of the current pkt with the MTU, and
>> >> >> >>>>>> if it's 25* smaller then reduce the ] +pkt loss probably by 25*?
>> >> >> >>>>>> And if the MTU was bigger, then the current pkt would ] +be
>> >> >> >>>>>> dropped with greater probability? And both of these things
>> >> >> are hard to do.
>> >> >> >>>>>> ]
>> >> >> >>>>>> ] S3.4 (& knock-on effect on 3.3) ] I think this could be better.
>> >> >> >>>>>> ] I agree with your arguments in S3.1 & 3.2 that dropping or
>> >> >> >>>>>> marking should be ] +independent of pkt size.
>> >> >> >>>>>> ] You now go into a couple of pages, which I think could be
>> >> >> >>>>>> boiled down to a ] +paragraph, saying something like:- ] * the
>> >> >> >>>>>> overall system (network + transport) has to be packet-size
>> >> >> >>>>>> dependent in ]
>> >> >> >>>>>> +order to drive out the right amount of traffic so the resource
>> >> >> >>>>>> becomes ]
>> >> >> >>>>>> +uncongested (since we assume all resources are in practice byte
>> >> >> >>>>>> +rather
>> >> >> >>>>>> than ] +packet limited) ] * from S3.1 and S3.2 the IETF is
>> >> >> >>>>>> convinced that the network should notify ] +independent of
>> >> >> packet-size.
>> >> >> >>>>>> ] * therefore the transport must act dependent on packet-size.
>> >> >> >>>>>> ]
>> >> >> >>>>>> ] It seems to me this is a necessary consequence of your earlier
>> >> >> >>>>>> assumptions ] +/arguments.
>> >> >> >>>>>> ]
>> >> >> >>>>>> ] [On the other hand, if someone disagrees with the arguments and
>> >> >> >>>>>> thinks that the ] +network should notify dependent on
>> >> >> >>>>>> packet-size, then it follows that the ] +transport can act
>> >> >> >>>>>> independent of
>> >> >> >>>>>> packet- size.] ] ] I think in S3.3 you're trying to make another
>> >> >> >>>>>> argument (?):-  ] * we can either do packet-size biasing in the
>> >> >> >>>>>> network element or on the end host ] +transport (see argument
>> >> >> >>>>>> above) ] * packet-size biasing in the network is quite tricky,
>> >> >> >>>>>> because then both the ] +network element & the transport have to
>> >> >> >>>>>> make some guesses about MTU - whereas ]
>> >> >> >>>>>> +with packet-size biasing in the transport, neither network
>> >> >> >>>>>> +element
>> >> >> >>>>>> nor ] +transport needs to know what the MTU is.
>> >> >> >>>>>> ] * it is also easier to implement packet-size biasing in the
>> >> >> >>>>>> transport than in ] +the network.
>> >> >> >>>>>> ]
>> >> >> >>>>>> ] On the last bullet, I didn't really follow your argument in
>> >> >> S3.5.
>> >> >> >>>>>> Might be ] +easier to follow if S3.5 also talked about how a
>> >> >> >>>>>> network element would take ] +account of pkt size? Also, does the
>> >> >> >>>>>> following argument also apply?:
>> >> >> >>>>>> ] * if pkt-size biasing is done in the transport, then the work
>> >> >> >>>>>> (to do the ] +biasing) is spread over many end hosts, ] * whereas
>> >> >> >>>>>> if pkt-size biasing is done in the network, then the work is ]
>> >> >> >>>>>> +concentrated in just the congested network element, which has to
>> >> >> >>>>>> operate on all ] +the traffic at line speed.
>> >> >> >>>>>>
>> >> >> >>>>>>   (Has there perhaps been some confusion about what went into the
>> >> >> >>>>>> -08
>> >> >> >>>>>> version?)
>> >> >> >>>>>>
>> >> >> >>>>>> --
>> >> >> >>>>>> John Leslie <john@jlc.net>
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>
>> >> >> >>>>
>> >> >> >>> ________________________________________________________________
>> >> >> >>> Bob Briscoe,                                BT Innovate & Design
>> >> >> >>>
>> >> >> >>
>> >> >> >
>> >> >
>> >> > ________________________________________________________________
>> >> > Bob Briscoe,                                BT Innovate & Design
>> >> >
>> >
>> > ________________________________________________________________
>> > Bob Briscoe,                                BT Innovate & Design
>
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_1024161496==.ALT-- From philip.eardley@bt.com Mon Oct 15 03:41:50 2012 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 F0B5921F86DB; Mon, 15 Oct 2012 03:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.818 X-Spam-Level: X-Spam-Status: No, score=-102.818 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S45isOfLIC+P; Mon, 15 Oct 2012 03:41:41 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id D691221F86D1; Mon, 15 Oct 2012 03:41:39 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 15 Oct 2012 11:41:38 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.17]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Mon, 15 Oct 2012 11:41:38 +0100 From: To: , Date: Mon, 15 Oct 2012 11:41:37 +0100 Thread-Topic: [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest Thread-Index: Ac2qtf28owj+qrGFRV6gNxHPMc0MYQACV7WQ Message-ID: <9510D26531EF184D9017DF24659BB87F33DD2D3573@EMV65-UKRD.domain1.systemhost.net> References: <20120815190728.GQ15012@verdi> <502BFB47.7010803@erg.abdn.ac.uk> <791AD3077F94194BB2BDD13565B6295D45A6212A@PALLENE.office.hd> <15181_1346848013_5047450C_15181_645_1_50474507.3090706@erg.abdn.ac.uk> <3A5279D338C75C40B4B3DA15BA47D6330B616BD2@EXMDB04.org.aalto.fi> <201209051541.q85FfCs0019699@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F33D793B351@EMV65-UKRD.domain1.systemhost.net> <3A5279D338C75C40B4B3DA15BA47D6330B69261A@EXMDB04.org.aalto.fi> <9510D26531EF184D9017DF24659BB87F33D793B845@EMV65-UKRD.domain1.systemhost.net> <04AC95B5-A2B1-4DD2-B765-E20A4C1A69A3@aalto.fi> <3A5279D338C75C40B4B3DA15BA47D6330B6E81E4@EXMDB04.org.aalto.fi> <9510D26531EF184D9017DF24659BB87F33DCE34251@EMV65-UKRD.domain1.systemhost.net> <201210041126.q94BQ0hx002951@bagheera.jungle.bt.co.uk> <1904eec816d080f886f5bf8685358ddc.squirrel@www.erg.abdn.ac.uk> <201210101525.q9AFP4Mi008013@bagheera.jungle.bt.co.uk> <3A5279D338C75C40B4B3DA15BA47D6330B6FC2BB@EXMDB04.org.aalto.fi> <201210111208.q9BC8BAU012305@bagheera.jungle.bt.co.uk> <3A5279D338C75C40B4B3DA15BA47D6330B6FD072@EXMDB04.org.aalto.fi> <201210150917.q9F9HwIG006958@bagheera.jungle.bt.co.uk> In-Reply-To: <201210150917.q9F9HwIG006958@bagheera.jungle.bt.co.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F33DD2D3573EMV65UKRDdoma_" MIME-Version: 1.0 Cc: gorry@erg.abdn.ac.uk, tsvwg-chairs@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest 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, 15 Oct 2012 10:41:50 -0000 --_000_9510D26531EF184D9017DF24659BB87F33DD2D3573EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bob, Your argument seems ok to me. << Transports on the other hand don't always want to make their rate respon= se proportional to the size of dropped packets, but if they want to, they a= lways can>> "always can"? do they always know? << rate response proportionate to the size of each dropped packet, while ot= hers will (e.g. TFRC-SP [RFC4828]).>> Does 4828 make a packet-by-packet decision or does it know that the small p= kt source has a particular pkt size for a long run? "each dropped pkt" soun= ds like the former, thought 4828 was the latter? << The argument applies solely to drop, not to ECN marking.>> Should you make more comment here? Given that much of the draft is about ec= n marking. << For both these reasons networks will often be dropping packets as a last= resort (case b) rather than under AQM control (case a).>> "often" seems wrong. "sometimes"? Also, pendantically "both reasons" seems wrong, since the two reasons are m= utually exclusive they cannot both be true. Thanks phil From: Briscoe,RJ,Bob,DUB8 R Sent: 15 October 2012 10:18 To: Manner Jukka Cc: Eardley,PL,Philip,DUB8 R; ; ; tsvwg IETF list Subject: Re: [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-= congest Jukka, OK, 2nd attempt below, annotated with HTML formatting. Rather than predicti= ng the future, I have confined the text to the lack of universal deployment= in the present. If you're happy with this, pls go ahead and re-issue the d= raft. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3.4. Permanent Partial Deployment of AQM In overview, the argument in this section runs as follows: * Because the network does will not and cannot always drop packets in propo= rtion to their size, it shouldn't be given the task of making drop signals = depend on packet size at all. * Transports on the other hand don't always want to make their rate respons= e proportional to the size of dropped packets, but if they want to, they al= ways can. The argument is similar to the end-to-end argument that says "Don't do X in= the network if end-systems can do X by themselves, and they want to be abl= e to choose whether to do X anyway." Actually the following argument is str= onger; in addition it says "Don't give the network task X that could be don= e by the end-systems, if X is not won't ever be deployed on all network nod= es, and end-systems won't be able to tell whether their network is doing X,= or whether they need to do X themselves." In this case, the X in question = is "making the response to congestion depend on packet size". We will now re-run this argument taking each step in more depth. The argume= nt applies solely to drop, not to ECN marking. A queue drops packets for either of two reasons: a) to signal to host conge= stion controls that they should reduce the load and b) because there is no = buffer left to store the packets. Active queue management tries to use drop= s as a signal for hosts to slow down (case a) so that drop due to buffer ex= haustion (case b) should not be necessary. No-one expects AQM is not to ever be universally deployed in every queue in= the Internet; many cheap ethernet bridges, software firewalls, NATs on con= sumer devices, etc implement simple tail-drop buffers. and, eEven if AQM we= re universal, it has to be able to cope with buffer exhaustion (by switchin= g to a behaviour like tail-drop), in order to cope with unresponsive or exc= essive transports. Therefore For both these reasons networks will often be = dropping packets as a last resort (case b) rather than under AQM control (c= ase a). When buffers are exhausted (case b), they don't naturally drop packets in p= roportion to their size. The network can only reduce the probability of dro= pping smaller packets if it has enough space to store them somewhere while = it waits for a larger packet that it can drop. If the buffer is exhausted, = it does not have this choice. Admittedly tail-drop does naturally drop some= what fewer small packets, but exactly how few depends more on the mix of si= zes than the size of the packet in question. Nonetheless, in general, if we= wanted networks to do size-dependent drop, we would need universal deploym= ent of (packet-size dependent) AQM code, which is currently unrealistic. A host transport cannot know whether any particular drop was a deliberate s= ignal from an AQM or a sign of a queue shedding packets due to buffer exhau= stion. Therefore, because the network cannot universally do size-dependent = drop, it should not do it all. Whereas universality is desirable in the network, diversity is desirable be= tween different transport layer protocols - some, like NewReno TCP [RFC5681= ], may not choose to make their rate response proportionate to the size of = each dropped packet, while others will (e.g. TFRC-SP [RFC4828]). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bob At 13:34 11/10/2012, Manner Jukka wrote: Hi, Yeah, please at the point about cheap devices, still, I wonder what the cos= t of AQM is on those devices. Maybe 1 cnt in mass production? Thus, I still= wonder if it is worth arguing something about the future that strongly. Sorry, but the same goes for AQM in general, and where it is, or will not b= e deployed. I understand technical reasons why not something is feasible, b= ut business or monetary reasons can change very quickly. ;) Jukka On Oct 11, 2012, at 3:08 PM, Bob Briscoe wrote: > Jukka, > > What I had in mind is all low level buffers in cheap pure L2 devices, in = cheap NATs etc. I was going to list some of these, but instead chose to say= "no-one expects AQM to be universally deployed". This clearly missed the m= ark. > > Should we include some of these concrete examples of where AQM won't be d= eployed instead? > > [I've cc'd the list, given we're starting to wordsmith significantly new = text added since WG last call.] > > > Bob > > At 20:04 10/10/2012, Manner Jukka wrote: >> Hi, looked good to me. Just one comment, I wouldn't put that much emphas= is on what is a probably state of things, e.g. >> >> "no-one expects AQM to ever be .." > in the future it might, we don't k= now, and since the paragraph says that it doesn't matter anyway, I would fo= rmulate this paragraph a bit towards that we have partial deployment now an= d even with a full deployment, ... >> >> and similarly with the unrealistic deployment of AQM in the subsequent p= aragraph. >> >> cheers, >> Jukka >> >> On Oct 10, 2012, at 6:25 PM, Bob Briscoe wrote: >> >> > Phil, >> > >> > Sorry for delay, my round-robin scheduler is taking so long to get rou= nd all the tasks that I keep finding dead robins (that reminds me of a bike= ride my grandmother took. On her return, she said there were a worryingly = large number of robins run over on the roads. It turned out that she had be= en going round the same small triangle of roads multiple times). >> > >> > I've done a complete re-write of 3.4. I hope you will agree that it re= ally is a motivating argument now and it can stay where it is - it is not j= ust a preamble. >> > >> > I've gone back to the very first version of 3.4 I wrote and I now real= ise that I had written the core of the argument so badly that even I forgot= what it was meant to say when we started editing it. In the draft-08 versi= on, the original meaning is lost and in your re-wording it is entirely lost= . The link with the draft-08 version is nearly unrecognisable, but it's the= argument I intended here. >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > 3.4. Permanent Partial Deployment of AQM >> > >> > In overview, the argument in this section runs as follows: >> > * Because the network will not and cannot always drop packets in propo= rtion to their size, it shouldn't be given the task of making drop signals = depend on packet size at all. >> > * Transports on the other hand don't always want to make their rate re= sponse proportional to the size of dropped packets, but if they want to, th= ey always can. >> > >> > The argument is similar to the end-to-end argument that says "Don't do= X in the network if end-systems can do X by themselves, and they want to b= e able to choose whether to do X anyway." Actually the following argument i= s stronger; in addition it says "Don't give the network task X that could b= e done by the end-systems, if X won't ever be deployed on all network nodes= , and end-systems won't be able to tell whether their network is doing X, o= r whether they need to do X themselves." In this case, the X in question is= "making the response to congestion depend on packet size". >> > >> > We will now re-run this argument taking each step in more depth. The a= rgument applies solely to drop, not ECN marking. >> > >> > A queue drops packets for either of two reasons: a) to signal to host = congestion controls that they should reduce the load and b) because there i= s no buffer left to store the packets. Active queue management tries to use= drops as a signal for hosts to slow down (case a) so that drop due to buff= er exhaustion (case b) should not be necessary. >> > >> > No-one expects AQM to ever be universally deployed in every queue in t= he Internet; and, even if AQM were universal, it has to be able to cope wit= h buffer exhaustion (by switching to a behaviour like tail-drop), in order = to cope with unresponsive or excessive transports. Therefore networks will = often be dropping packets as a last resort (case b) rather than under AQM c= ontrol (case a). >> > >> > When buffers are exhausted (case b), they don't naturally drop packets= in proportion to their size. The network can only reduce the probability o= f dropping smaller packets if it has enough space to store them somewhere w= hile it waits for a larger packet that it can drop. If the buffer is exhaus= ted, it does not have this choice. Admittedly tail-drop does naturally drop= somewhat fewer small packets, but exactly how few depends more on the mix = of sizes than the size of the packet in question. Nonetheless, in general, = if we wanted networks to do size-dependent drop, we would need universal de= ployment of (packet-size dependent) AQM code, which is unrealistic. >> > >> > A host transport cannot know whether any particular drop was a deliber= ate signal from an AQM or a sign of a queue shedding packets due to buffer = exhaustion. Therefore, because the network cannot universally do size-depen= dent drop, it should not do it all. >> > >> > Whereas universality is desirable in the network, diversity is desirab= le between different transport layer protocols - some, like NewReno TCP [RF= C5681], may not choose to make their rate response proportionate to the siz= e of each dropped packet, while others will (e.g. TFRC-SP [RFC4828]). >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> > >> > >> > >> > Bob >> > >> > At 13:13 04/10/2012, gorry@erg.abdn.ac.uk= wrote: >> >> That would be brilliant! >> >> >> >> Gorry >> >> >> >> > Will try to look at this later today. >> >> > >> >> > >> >> > Bob >> >> > >> >> > At 10:42 02/10/2012, philip.eardley@bt.com wrote: >> >> >>Think the token is with bob >> >> >> >> >> >>Re your comment - yes, I think you could move 3.4 to the end of S3 = - >> >> >>or to the start - and do some re-phrasing, maybe something like I t= ried. >> >> >> >> >> >>-----Original Message----- >> >> >>From: Manner Jukka [ mailto:jukka.manner@aalto.fi] >> >> >>Sent: 01 October 2012 20:18 >> >> >>To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,Bob,DUB8 R >> >> >>Cc: tsvwg-chairs@ietf.org; Gorry Fair= hurst >> >> >>Subject: Re: [REVISED I-D]: Document writeup for >> >> >>draft-ietf-tsvwg-byte-pkt-congest >> >> >> >> >> >>Phil, Bob, can we close this finally? It's three weeks now since >> >> >>this previous message. >> >> >> >> >> >>Jukka >> >> >> >> >> >>On Sep 10, 2012, at 4:42 PM, Jukka Manner wrote: >> >> >> >> >> >> > Ack, I'm getting there...;) >> >> >> > >> >> >> > So, we could move 3.4 at the end of Section 3 and rephrase it to >> >> >> not talk about scaling per se, but rather about how Req 2.2 >> >> >> eventually leads to Req 2.3? >> >> >> > >> >> >> > Jukka >> >> >> > >> >> >> > On Sep 7, 2012, at 4:07 PM, > >> >> >> > > wrote: >> >> >> > >> >> >> >> 3.4 is, in my mind, completely different from 3.1, 3.2, 3.3 and= 3.5. >> >> >> >> >> >> >> >> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for Recommen= dation >> >> >> >> 2.2 & a lesser extent 2.3 >> >> >> >> 3.4 makes doesn't make a motivating argument - it explains that= Rec >> >> >> >> 2.2 & 2.3 come as a pair (if you recommend one, then inevitably= you >> >> >> >> recommend the other) (delta some politeness about TCP) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> >> From: Manner Jukka [ mailto:jukka.manner@aalto.fi] >> >> >> >> Sent: 07 September 2012 13:24 >> >> >> >> To: Eardley,PL,Philip,DUB8 R >> >> >> >> Cc: Briscoe,RJ,Bob,DUB8 R; >; >> >> >> >> > >> >> >> >> Subject: Re: [REVISED I-D]: Document writeup for >> >> >> >> draft-ietf-tsvwg-byte-pkt-congest >> >> >> >> >> >> >> >> Hi, I'm trying to follow your reasoning, with little luck. ;) >> >> >> >> >> >> >> >> After having read Section 3 again, I could think of a few >> >> >> updates, but I'm not fully following what you want to see: >> >> >> >> >> >> >> >> - S3.5 is kind of small and lonely by itself. It could be eithe= r >> >> >> longer or merged somewhere. Not a major issue though and could rem= ain as >> >> >> is. >> >> >> >> >> >> >> >> - S3.3: Yes, probably could be turned upside down, good first, >> >> >> bad later. Don't have a strong opinion. >> >> >> >> >> >> >> >> - S3.4: Here the scaling is used many times and in the title, >> >> >> although we talk about the end host side. This could be rephrased >> >> >> and slightly reworded to talk about hosts and their operation >> >> >> altogether. Also the word scaling can turn the readers expectation >> >> >> into the wrong direction. >> >> >> >> >> >> >> >> - S3 altogether: It would help to have introductory text about >> >> >> networks vs. end host side, but I fail to see why (& how) to >> >> >> restructure everything. >> >> >> >> >> >> >> >> cheers, >> >> >> >> Jukka >> >> >> >> >> >> >> >> On Sep 6, 2012, at 6:18 PM, >> >> >> > > wrote: >> >> >> >> >> >> >> >>> Ps otherwise Bob's comments are fine, though I suggest for S3.= 5 you >> >> >> >>> give more context (ie are you knocking down what you recommend >> >> >> >>> against, or building up what you recommend?) and in S3.3 thin= k >> >> >> >>> would be better if you re-structured slightly [first talk abou= t what >> >> >> >>> you like - penult para + 1st sentence of last para - then talk= about >> >> >> >>> what you don't like - rest of text] >> >> >> >>> >> >> >> >>> From: Eardley,PL,Philip,DUB8 R >> >> >> >>> Sent: 06 September 2012 16:12 >> >> >> >>> To: Briscoe,RJ,Bob,DUB8 R; Manner Jukka >> >> >> >>> Cc: tsvwg-chairs@ietf.org; Gorry= Fairhurst >> >> >> >>> Subject: RE: [REVISED I-D]: Document writeup for >> >> >> >>> draft-ietf-tsvwg-byte-pkt-congest >> >> >> >>> >> >> >> >>> Thanks bob. Have now re-booted some state. >> >> >> >>> I don't like S3.4. My basic problem with it is that it isn't a >> >> >> "motivating argument" (S3 title). It's an explanation about the >> >> >> consequences of assuming either [option 1] do pkt-size biasing in >> >> >> the transport; [option 2]; do pkt-size biasing in the nw. >> >> >> >>> Perhaps your effort to buy peace with those who won't change >> >> >> TCP has obfuscated the basic point? >> >> >> >>> The title of S3.4 (Scaling...) and the early text "scaling >> >> >> argument" suggests that you're going to argue there is some reason >> >> >> why X scales as order N rather than N^2 or something like that - >> >> >> which isn't what S3.4 is about. >> >> >> >>> >> >> >> >>> I actually think it would be better to put S3.4 at the start o= f >> >> >> S3 - it's background where you say there are 2 options. After that= , >> >> >> you can explain the reasons why option 1 [pkt biasing in the >> >> >> transport] is better - the reasons being:- S3.1 (security etc >> >> >> attacks if small pkts get preferential treatment), S3.2 (really a >> >> >> side note to S3.1; ie doesn't really present a "motivating >> >> >> argument"), S3.3 (nw guessing MTU vs transport knowing pkt size), >> >> >> S3.5 (easier implementation). >> >> >> >>> >> >> >> >>> Something like... >> >> >> >>> The behaviour of the network and transport together needs to >> >> >> >>> alleviate congestion. We assume the network is bit-congestible >> >> >> (currently packet-congestible resources are rate). Therefore >> >> >> overall the response of the {network + transport} should be the >> >> >> same for the same congestion - whether the congestion is caused by >> >> >> a lot of small packets or a smaller number of larger packets. The >> >> >> implication is that the transport's behaviour should depend on >> >> >> whether the network takes account (or not) of packet size when it >> >> >> generates congestion indications:- Case 1: If the network >> >> >> implements packet-mode drop, ie its algorithm treats all packets >> >> >> equally regardless of their size, then the transport should take >> >> >> account of the size of the packet - in other words, the transport'= s >> >> >> congestion response should depend on the number of dropped bytes. >> >> >> >>> Case 2: If the network implements byte-mode drop, ie its >> >> >> algorithm treats packets differently depending on their size, then >> >> >> the transport should not take account of the size of the packet - >> >> >> in other words, the transport's congestion response should depend >> >> >> on the number of dropped packets. >> >> >> >>> >> >> >> >>> These cases are explained in more detail in sub-section below. >> >> >> >>> >> >> >> >>> In both cases the same discussion applies if packets are >> >> >> ECN-marked rather than dropped. >> >> >> >>> In the following sections we explain why Case 1 is preferable, >> >> >> and hence why we make the Recommendations of S2.2 and S3.3 >> >> >> (respectively, drop/mark pkts equally regardless of their size, an= d >> >> >> the strength of the transport's response should be proportionate t= o >> >> >> the size of the dropped/marked pkt). >> >> >> >>> Note that TCP responds to dropped or marked packets, which dif= fers >> >> >> >>> from our recommendation for transports. However, we are not >> >> >> >>> recommending that TCP should be changed; to date it hasn't be= en a >> >> >> >>> significant problem because most TCP implementations have bee= n >> >> >> used with similar packet sizes. But we do recommend that future >> >> >> transport protocols should respond to dropped or marked bytes (as >> >> >> for example TFRC-SP [RFC4828]effectively does). >> >> >> >>> >> >> >> >>> >> >> >> >>> Sub-section >> >> >> >>> You could use much of S3.3, I suggest supplement with numerica= l >> >> >> >>> examples continuing S1.2 >> >> >> >>> -- >> >> >> >>> << This gives a get-out clause to any transport that isn't >> >> >> >>> packet-size dependent (e.g. current TCP). Lacking packet-size >> >> >> >>> dependence just means they don't scale correctly with packet s= ize - >> >> >> >>> but they are at liberty not to scale with packet size (particu= larly >> >> >> >>> given MTU growth isn't often being used to increase link rates= at >> >> >> >>> this stage in history).>> >> >> >> >>> >> >> >> >>> This is introducing a different point. it's saying that your >> >> >> recommendation 2 [drop/mark pkts equally regardless of their size] >> >> >> is a really strong reco whilst recommendation 3 [strength of >> >> >> transport's response proportionate to the size of the >> >> >> dropped/marked pkt] is a much less important reco. I can see this >> >> >> might be true, but I don't think the i-d talks about this. >> >> >> >>> >> >> >> >>> -- >> >> >> >>> >> >> >> >>> From: Briscoe,RJ,Bob,DUB8 R >> >> >> >>> Sent: 05 September 2012 16:41 >> >> >> >>> To: Manner Jukka >> >> >> >>> Cc: tsvwg-chairs@ietf.org; Gorry= Fairhurst; Eardley,PL,Philip,DUB8 R >> >> >> >>> Subject: Re: [REVISED I-D]: Document writeup for >> >> >> >>> draft-ietf-tsvwg-byte-pkt-congest >> >> >> >>> >> >> >> >>> Jukka, >> >> >> >>> >> >> >> >>> I've repeated Phil's suggestions as quoted email then made som= e >> >> >> alterations. >> >> >> >>> >> >> >> >>> Phil asked me to send this, then he will think about it. >> >> >> >>> >> >> >> >>> I'll respond about John Leslie's argument next... >> >> >> >>> >> >> >> >>> >> >> >> >>> 2.2. Recommendation on Encoding Congestion Notification >> >> >> >>> >> >> >> >>> [...] >> >> >> >>> >> >> >> >>> 1. AQM algorithms such as RED SHOULD use packet-mode drop, i= e they >> >> >> >>> SHOULD NOT use byte-mode drop. The latter is more complex= , >> >> >> >>> it creates the perverse incentive to fragment segments in= to >> >> >> tiny >> >> >> >>> pieces and it is vulnerable to floods of small packets. >> >> >> >>> >> >> >> >>> 2. If a vendor has implemented byte-mode drop, and an operat= or has >> >> >> >>> turned it on, it is RECOMMENDED to turn it off, after >> >> >> establishing >> >> >> >>> if there are any implications on the relative performance= of >> >> >> >>> applications using different packet sizes. >> >> >> >>> >> >> >> >>> RED as a whole SHOULD NOT be turned off. Without RED, a d= rop >> >> >> tail >> >> >> >>> queue biases against large packets >> >> >> >>> >> >> >> >>> [BB adds]: and it is vulnerabl= e to >> >> >> floods >> >> >> >>> of small-packets. >> >> >> >>> >> >> >> >>> (I suggest the last para just qualifies item 2. It doesn't war= rant >> >> >> >>> another item number.) >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> [PE:] S3.3 >> >> >> >>> The section could be slightly clearer. Starting with the secon= d >> >> >> para, where you start talking about something you don't recommend >> >> >> (ie you have to remember that you're talking about the consequence= s >> >> >> of not following your recommendation). >> >> >> >>> >> >> >> >>> 3.3 Transport-Independent Network >> >> >> >>> >> >> >> >>> TCP congestion control ensures that flows competing for the s= ame >> >> >> >>> resource each maintain the same number of segments in flight, >> >> >> >>> irrespective of segment size. So under similar conditions, fl= ows >> >> >> >>> with different segment sizes will get different bit-rates. >> >> >> >>> >> >> >> >>> [OLD:] >> >> >> >>> One motivation for the network biasing congestion notificatio= n by >> >> >> >>> packet size is to counter this effect and try to equalise the = bit- >> >> >> >>> rates of flows with different packet sizes. >> >> >> >>> [SUGGESTED:] >> >> >> >>> To counter this effect it seems tempting not to follow our >> >> >> >>> recommendation, and instead for the network to bias congestio= n >> >> >> >>> notification by packet size in order to equalise the bit-rate= s of >> >> >> >>> flows with different packet sizes. >> >> >> >>> [CONTINUE AS BEFORE:] >> >> >> >>> However, in order to do this, the queuing algo= rithm >> >> >> >>> has to make assumptions about the transport, which become emb= edded >> >> >> >>> in the network. Specifically: >> >> >> >>> [...] >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> S3.3 >> >> >> >>> o The queuing algorithm has to assume how aggressively the >> >> >> transport >> >> >> >>> will respond to congestion (see Section 4.2.4). If the ne= twork >> >> >> >>> assumes the transport responds as aggressively as TCP NewR= eno, >> >> >> it >> >> >> >>> will be wrong for Compound TCP and differently wrong for C= ubic >> >> >> >>> TCP, etc. To achieve equal bit-rates, each transport then= has >> >> >> to >> >> >> >>> guess what assumption the network made, and work out how t= o >> >> >> >>> replace this assumed aggressiveness with its own aggressiv= eness. >> >> >> >>> o Also, if the network biases congestion notification by pac= ket >> >> >> size >> >> >> >>> it has to assume a baseline packet size--all proposed algo= rithms >> >> >> >>> use the local MTU. Then transports have to guess which li= nk was >> >> >> >>> congested and what its local MTU was, in order to know how= to >> >> >> >>> tailor their congestion response to that link. >> >> >> >>> >> >> >> >>> So you're saying that for byte-mode drop, the network element >> >> >> has to compare the size of the current pkt with the MTU, and if >> >> >> it's 25* smaller then reduce the pkt loss probably by 25*? And if >> >> >> the MTU was bigger, then the current pkt would be dropped with >> >> >> greater probability? And both of these things are hard to do. >> >> >> >>> >> >> >> >>> [BB]: SUGGESTED REPLACEMENT to 2nd bullet: >> >> >> >>> >> >> >> >>> o Also, if the network biases congestion notification by pac= ket >> >> >> size >> >> >> >>> it has to assume a baseline packet size--all proposed algo= rithms >> >> >> >>> use the local MTU (for example see the byte-mode loss >> >> >> probability >> >> >> >>> formula in Table 1). Then if the non-Reno transports ment= ioned >> >> >> above >> >> >> >>> are trying to reverse engineer what the network assumed, t= hey >> >> >> also >> >> >> >>> have to guess the MTU of the congested link. >> >> >> >>> >> >> >> >>> [Aside for Phil: The byte-mode algo uses MTU as its baseline b= ecause >> >> >> >>> a link cannot send a packet bigger than its MTU so the algo wo= n't >> >> >> >>> ever give a drop probability >1).] >> >> >> >>> >> >> >> >>> >> >> >> >>> S3.4 (& knock-on effect on 3.3) >> >> >> >>> I think this could be better. >> >> >> >>> I agree with your arguments in S3.1 & 3.2 that dropping or >> >> >> marking should be independent of pkt size. >> >> >> >>> You now go into a couple of pages, which I think could be boil= ed >> >> >> >>> down to a paragraph, saying something like:- >> >> >> >>> * the overall system (network + transport) has to be packet-si= ze >> >> >> >>> dependent in order to drive out the right amount of traffic so= the >> >> >> >>> resource becomes uncongested (since we assume all resources ar= e in >> >> >> >>> practice byte rather than packet limited) >> >> >> >>> * from S3.1 and S3.2 the IETF is convinced that the network >> >> >> should notify independent of packet-size. >> >> >> >>> * therefore the transport must act dependent on packet-size. >> >> >> >>> >> >> >> >>> It seems to me this is a necessary consequence of your earlier >> >> >> assumptions /arguments. >> >> >> >>> >> >> >> >>> [BB:] This isn't at all obvious. Until I worked it through, it >> >> >> wasn't obvious to me. I think it needs to be spelled out. >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> [On the other hand, if someone disagrees with the arguments an= d >> >> >> >>> thinks that the network should notify dependent on packet-size= , then >> >> >> >>> it follows that the transport can act independent of packet-si= ze.] >> >> >> >>> >> >> >> >>> I think in S3.3 you're trying to make another argument (?):- >> >> >> >>> * we can either do packet-size biasing in the network element = or on >> >> >> >>> the end host transport (see argument above) >> >> >> >>> * packet-size biasing in the network is quite tricky, because >> >> >> then both the network element & the transport have to make some >> >> >> guesses about MTU - whereas with packet-size biasing in the >> >> >> transport, neither network element nor transport needs to know wha= t the >> >> >> MTU is. >> >> >> >>> * it is also easier to implement packet-size biasing in the >> >> >> transport than in the network. >> >> >> >>> >> >> >> >>> [BB] ...and all the other arguments about vulnerability to >> >> >> flooding etc, transport-independence etc. >> >> >> >>> >> >> >> >>> Our argument is sort of like how Phil summarises it, but with >> >> >> an added nuance. It's also saying no-one has to do packet-size >> >> >> biasing anyway. It's not saying "The transport should given the >> >> >> network shouldn't". It's saying "*If the transport wants to claim >> >> >> to be scalable wrt packet size* it should if the network shouldn't= ". >> >> >> >>> >> >> >> >>> This gives a get-out clause to any transport that isn't >> >> >> packet-size dependent (e.g. current TCP). Lacking packet-size >> >> >> dependence just means they don't scale correctly with packet size = - >> >> >> but they are at liberty not to scale with packet size (particularl= y >> >> >> given MTU growth isn't often being used to increase link rates at >> >> >> this stage in history). >> >> >> >>> >> >> >> >>> None of what Phil says convinces me we could say 3.4 (or 3.3) >> >> >> any more briefly or differently. It's easier to summarise what you >> >> >> understand having read something. But that's not the same as >> >> >> writing the thing that helped you understand. There doesn't seem t= o >> >> >> be any argument for why anything needs to be changed, so I'm going >> >> >> to leave it as is, unless pushed. >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> On the last bullet, I didn't really follow your argument in >> >> >> S3.5. Might be easier to follow if S3.5 also talked about how a >> >> >> network element would take account of pkt size? >> >> >> >>> Also, does the following argument also apply?: >> >> >> >>> * if pkt-size biasing is done in the transport, then the work = (to do >> >> >> >>> the biasing) is spread over many end hosts, >> >> >> >>> * whereas if pkt-size biasing is done in the network, then the >> >> >> work is concentrated in just the congested network element, which >> >> >> has to operate on all the traffic at line speed. >> >> >> >>> >> >> >> >>> [BB]: 3.5. Implementation Efficiency >> >> >> >>> >> >> >> >>> [ADD:] >> >> >> >>> Biasing against large packets typically requires an extra mul= tiply >> >> >> >>> and divide in the network (see the example byte-mode drop >> >> >> formula in table 1). >> >> >> >>> [CONTINUE AS BEFORE:] >> >> >> >>> Allowing for packet size at the transport rather than in the >> >> >> >>> network ensures that neither the network nor the transport ne= eds to >> >> >> >>> do a multiply operation--multiplication by packet size is >> >> >> >>> effectively achieved as a repeated add when the transport add= s to >> >> >> >>> its count of marked bytes as each congestion event is fed to = it. >> >> >> >>> [ADD:] >> >> >> >>> Also the work to do the biasing is spread over many hosts, ra= ther >> >> >> >>> than concentrated in just the congested network element. >> >> >> >>> [CONTINUE AS BEFORE:] >> >> >> >>> These are= n't >> >> >> >>> principled reasons in themselves, but they are a happy consequ= ence >> >> >> >>> of the other principled reasons. >> >> >> >>> >> >> >> >>> >> >> >> >>> Bob >> >> >> >>> >> >> >> >>> At 13:36 05/09/2012, Manner Jukka wrote: >> >> >> >>> >> >> >> >>> Hi Bob, >> >> >> >>> >> >> >> >>> Since Phil is your colleague at BT, even at Ipswich (?), can >> >> >> you check those and agree with Phil how to go forward? Some of >> >> >> those are clear, others need discussion with Phil. >> >> >> >>> >> >> >> >>> Gorry, on point 2) below, I don't follow Leslie's arguments. I >> >> >> asked from him detailed comments and resolutions months ago, and n= othing >> >> >> came. >> >> >> >>> >> >> >> >>> cheers, >> >> >> >>> Jukka >> >> >> >>> >> >> >> >>> On Sep 5, 2012, at 3:26 PM, Gorry Fairhurst wrote: >> >> >> >>> >> >> >> >>>> Bob and Jukka, >> >> >> >>>> >> >> >> >>>> I think I need your help to resolve this... Some of the >> >> >> comments raised by John Leslie appear to have substance, and I'm >> >> >> not sure what you plan to do to address these. >> >> >> >>>> >> >> >> >>>> It would be good to do something quick so that I can complete >> >> >> the submission to the IESG. >> >> >> >>>> >> >> >> >>>> The issues I particularly note are: >> >> >> >>>> >> >> >> >>>> 1) This contribution from Phil appears to be within scope and >> >> >> it seems may have been overlooked (sorry): >> >> >> >>>> http://www.ietf.org/mail-archive/web/tsvwg/current/msg11234.h= tml >> >> >> >>>> >> >> >> >>>> 2) Can you be clear here about what is actually been said - >> >> >> because the point below seems to be a misunderstanding of language >> >> >> to me, and I hoped we did not claim this: >> >> >> >>>> >> >> >> >>>>>> ] Alas, when I read it carefully this week, I find that Bob= is >> >> >> >>>>>> actually ] saying that transport-layer should _only_ consid= er >> >> >> >>>>>> "congested bytes", not ] "congested packets". >> >> >> >>>>>> ] >> >> >> >>>> >> >> >> >>>> 3) You'll need to post the updated draft and send a note to >> >> >> the group to confirm that the new version indeed concludes the >> >> >> WGLC. I'll add a note to the writeup to indicate the draft content >> >> >> has been stable since Oct 2011. >> >> >> >>>> >> >> >> >>>> Gorry (with my TSVWG Documnent Shepherd hat) >> >> >> >>>> cc: Co-Chairs for info. >> >> >> >>>> >> >> >> >>>>> >> >> >> >>>>>> -----Original Message----- >> >> >> >>>>>> From: Gorry Fairhurst [ mailto:gorry@erg.abdn.ac.uk] >> >> >> >>>>>> Sent: Mittwoch, 15. August 2012 21:41 >> >> >> >>>>>> To: tsvwg chair >> >> >> >>>>>> Subject: Fwd: Re: [tsvwg] FYI: Document writeup for >> >> >> >>>>>> draft-ietf-tsvwg- byte-pkt-congest >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> Hi guys, >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> Apart form the usual rhetoric, there are some points here t= hat we >> >> >> >>>>>> should note as chairs. What are you own thoughts? And was >> >> >> >>>>>> anything noted at the IETF in Vancouver concerning this dra= ft? >> >> >> >>>>>> >> >> >> >>>>>> Gorry >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> -------- Original Message -------- >> >> >> >>>>>> Subject: Re: [tsvwg] FYI: Document writeup for >> >> >> >>>>>> draft-ietf-tsvwg-byte- pkt-congest >> >> >> >>>>>> Date: Wed, 15 Aug 2012 15:07:28 -0400 >> >> >> >>>>>> From: John Leslie > >> >> >> >>>>>> To: Gorry Fairhurst > >> >> >> >>>>>> CC: tsvwg@ietf.org >> >> >> >>>>>> >> >> >> >>>>>> Gorry Fairhurst > wrote: >> >> >> >>>>>>> >> >> >> >>>>>>> The following document has been revised after receiving >> >> >> WGLC comments. >> >> >> >>>>>> >> >> >> >>>>>> The changes are mostly refreshing a document scheduled to >> >> >> >>>>>> expire this month. >> >> >> >>>>>> >> >> >> >>>>>>> No issues were found: >> >> >> >>>>>> >> >> >> >>>>>> Is that with WGC-hat-on? >> >> >> >>>>>> >> >> >> >>>>>> Neither my issues nor Philip Eardley's comments were addr= essed. >> >> >> >>>>>> In fact, not even the changes Bob Briscoe mentioned on-list= have >> >> >> >>>>>> been included. >> >> >> >>>>>> >> >> >> >>>>>>> As required by RFC 4858, this is the current template for = the >> >> >> >>>>>> Document >> >> >> >>>>>>> Shepherd Write-Up. >> >> >> >>>>>>> ... >> >> >> >>>>>>> (1) What type of RFC is being requested (BCP, Proposed Sta= ndard, >> >> >> >>>>>>> Internet Standard, Informational, Experimental, or Histori= c)? >> >> >> >>>>>>> Why is this the proper type of RFC? Is this type of RFC >> >> >> >>>>>>> indicated in the title page header? >> >> >> >>>>>>> >> >> >> >>>>>>> This document is intended as BCP. (This was discussed at I= ETF-81 >> >> >> >>>>>>> and that the status changed from Informational to BCP sinc= e it >> >> >> >>>>>>> provides guidance to implementors and people configuring >> >> >> routers and hosts). >> >> >> >>>>>> >> >> >> >>>>>> Thank you for finally answering my question about BCP sta= tus. >> >> >> >>>>>> >> >> >> >>>>>>> ... >> >> >> >>>>>>> Working Group Summary >> >> >> >>>>>>> >> >> >> >>>>>>> There was consensus to publish this as a WG document and >> >> >> >>>>>>> agreement at >> >> >> >>>>>>> IETF-82 that the document was now complete. >> >> >> >>>>>> >> >> >> >>>>>> Was that reviewed on-list? >> >> >> >>>>>> >> >> >> >>>>>>> ... >> >> >> >>>>>>> (3) Briefly describe the review of this document that was >> >> >> >>>>>>> performed >> >> >> >>>>>> by >> >> >> >>>>>>> the Document Shepherd. If this version of the document is = not >> >> >> >>>>>>> ready for publication, please explain why the document is = being >> >> >> >>>>>>> forwarded to the IESG. >> >> >> >>>>>>> >> >> >> >>>>>>> The document was presented at IEWTF-82 (Taipei), with a re= quest >> >> >> >>>>>>> for >> >> >> >>>>>> WGLC. >> >> >> >>>>>>> WGLC concluded with some discussion but no substantive cha= nges >> >> >> >>>>>>> on Friday 30th March 2012. >> >> >> >>>>>> >> >> >> >>>>>> Yes, I guess that is true; but ignoring substantive comme= nts >> >> >> >>>>>> isn't a good practice IMHO. >> >> >> >>>>>> >> >> >> >>>>>>> (4) Does the document Shepherd have any concerns about the= depth >> >> >> >>>>>>> or breadth of the reviews that have been performed? >> >> >> >>>>>>> >> >> >> >>>>>>> No - the original draft had a lot of background material, = much >> >> >> >>>>>>> of >> >> >> >>>>>> this >> >> >> >>>>>>> has been condensed or removed, resulting in a smaller docu= ment. >> >> >> >>>>>> >> >> >> >>>>>> That is indeed what I basically asked for, but I don't se= e any >> >> >> >>>>>> evidence of it: >> >> >> >>>>>> >> >> >> >>>>>> - diff(07,08) 48 lines changed or deleted; 53 lines chang= ed or >> >> >> added >> >> >> >>>>>> - diff(06,07) 8 lines changed or deleted; 13 lines chang= ed or >> >> >> added >> >> >> >>>>>> - diff(05,06) 64 lines changed or deleted; 69 lines chang= ed or >> >> >> >>>>>> added >> >> >> >>>>>> - diff(04,05) 823 lines changed or deleted; 864 lines chang= ed or >> >> >> >>>>>> added >> >> >> >>>>>> >> >> >> >>>>>> (Need I go farther? That gets us back to March 2011...) >> >> >> >>>>>> >> >> >> >>>>>>> (9) How solid is the WG consensus behind this document? Do= es it >> >> >> >>>>>>> represent the strong concurrence of a few individuals, wit= h >> >> >> >>>>>>> others being silent, or does the WG as a whole understand >> >> >> and agree with it? >> >> >> >>>>>>> >> >> >> >>>>>>> The document has WG support and there is consensus to publ= ish. >> >> >> >>>>>> >> >> >> >>>>>> This, IMHO, doesn't answer the question. :^( >> >> >> >>>>>> >> >> >> >>>>>> Does it represent the concurrence of a few individuals, o= r does >> >> >> >>>>>> the WG as a whole understand and agree with it? >> >> >> >>>>>> >> >> >> >>>>>> For reference, my comments included: >> >> >> >>>>>> ] >> >> >> >>>>>> ] When I previously skimmed this document, I believed it >> >> >> >>>>>> contained only ] common ground: that AQM should drop/mark p= ackets >> >> >> >>>>>> without favoring small ] packets, and that to whatever exte= nt >> >> >> >>>>>> packet size _is_ considered, that ] should be a >> >> >> transport-layer responsibility. >> >> >> >>>>>> ] >> >> >> >>>>>> ] Alas, when I read it carefully this week, I find that Bob= is >> >> >> >>>>>> actually ] saying that transport-layer should _only_ consid= er >> >> >> >>>>>> "congested bytes", not ] "congested packets". >> >> >> >>>>>> ] >> >> >> >>>>>> ] In fact, Bob openly endorses replacing TCP congestion-con= trol >> >> >> >>>>>> with an ] algorithm which calculates "fair-share bytes" and >> >> >> >>>>>> doesn't back off at all ] (even in the presence of 20% pack= et >> >> >> >>>>>> loss) unless you're already sending ] more than this >> >> >> "fair-share". >> >> >> >>>>>> ] >> >> >> >>>>>> ] I do not believe that is the consensus of this WG; and= I >> >> >> believe >> >> >> >>>>>> if >> >> >> >>>>>> ] that were the consensus it would exceed our charter. >> >> >> >>>>>> ] >> >> >> >>>>>> ] The draft contains a number of things I _do_ support; and= I'd >> >> >> >>>>>> be happy ] to support a considerably shorter draft which >> >> >> >>>>>> concentrates on the AQM ] recommendation, omitting any >> >> >> >>>>>> suggestions of modifying TCP congestion ] control. >> >> >> >>>>>> >> >> >> >>>>>> and Philip's comments included: >> >> >> >>>>>> ] >> >> >> >>>>>> ] S2.2 I thought the numbered bullets could be better phras= ed, >> >> >> >>>>>> something like ] +this:- ] >> >> >> >>>>>> ] 1. AQM algorithms such as RED SHOULD use packet-mode >> >> >> drop, ie they >> >> >> >>>>>> SHOULD NOT >> >> >> >>>>>> ] +use byte-mode drop. The latter ] is more complex, >> >> >> >>>>>> ] it creates the perverse incentive to fragment segm= ents >> >> >> into >> >> >> >>>>>> tiny >> >> >> >>>>>> ] pieces and it is vulnerable to floods of small- >> >> >> >>>>>> ] packets. >> >> >> >>>>>> ] >> >> >> >>>>>> ] 2. If a vendor has implemented byte-mode drop, and an >> >> >> operator >> >> >> >>>>>> has >> >> >> >>>>>> ] turned it on, it is RECOMMENDED to turn it off, af= ter >> >> >> >>>>>> establishing if >> >> >> >>>>>> ] +there are any implications on >> >> >> >>>>>> ] the relative performance of >> >> >> >>>>>> ] applications using different packet sizes. >> >> >> >>>>>> ] >> >> >> >>>>>> ] 3. RED SHOULD NOT be turned off. Without RED, a drop t= ail >> >> >> >>>>>> ] queue biases against large packets. >> >> >> >>>>>> ] >> >> >> >>>>>> ] Nit - the following paragraph shouldn't be indented (Note= well >> >> >> >>>>>> that >> >> >> >>>>>> RED's...) >> >> >> >>>>>> ] >> >> >> >>>>>> ] S3.3 >> >> >> >>>>>> ] The section could be slightly clearer. Starting with the = second >> >> >> >>>>>> para, where you ] +start talking about something you don't >> >> >> >>>>>> recommend (ie you have to remember that ] +you're talking a= bout >> >> >> >>>>>> the consequences of not following your recommendation). >> >> >> >>>>>> ] >> >> >> >>>>>> ] S3.3 >> >> >> >>>>>> ] o Also, if the network biases congestion notification= by >> >> >> packet >> >> >> >>>>>> size >> >> >> >>>>>> ] it has to assume a baseline packet size--all propos= ed >> >> >> >>>>>> algorithms >> >> >> >>>>>> ] use the local MTU. Then transports have to guess w= hich >> >> >> link >> >> >> >>>>>> was >> >> >> >>>>>> ] congested and what its local MTU was, in order to k= now >> >> >> how to >> >> >> >>>>>> ] tailor their congestion response to that link. >> >> >> >>>>>> ] So you're saying that for byte-mode drop, the network ele= ment >> >> >> >>>>>> has to compare the ] +size of the current pkt with the MTU,= and >> >> >> >>>>>> if it's 25* smaller then reduce the ] +pkt loss probably by= 25*? >> >> >> >>>>>> And if the MTU was bigger, then the current pkt would ] +be >> >> >> >>>>>> dropped with greater probability? And both of these things >> >> >> are hard to do. >> >> >> >>>>>> ] >> >> >> >>>>>> ] S3.4 (& knock-on effect on 3.3) ] I think this could be b= etter. >> >> >> >>>>>> ] I agree with your arguments in S3.1 & 3.2 that dropping o= r >> >> >> >>>>>> marking should be ] +independent of pkt size. >> >> >> >>>>>> ] You now go into a couple of pages, which I think could be >> >> >> >>>>>> boiled down to a ] +paragraph, saying something like:- ] * = the >> >> >> >>>>>> overall system (network + transport) has to be packet-size >> >> >> >>>>>> dependent in ] >> >> >> >>>>>> +order to drive out the right amount of traffic so the reso= urce >> >> >> >>>>>> becomes ] >> >> >> >>>>>> +uncongested (since we assume all resources are in practice= byte >> >> >> >>>>>> +rather >> >> >> >>>>>> than ] +packet limited) ] * from S3.1 and S3.2 the IETF is >> >> >> >>>>>> convinced that the network should notify ] +independent of >> >> >> packet-size. >> >> >> >>>>>> ] * therefore the transport must act dependent on packet-si= ze. >> >> >> >>>>>> ] >> >> >> >>>>>> ] It seems to me this is a necessary consequence of your ea= rlier >> >> >> >>>>>> assumptions ] +/arguments. >> >> >> >>>>>> ] >> >> >> >>>>>> ] [On the other hand, if someone disagrees with the argumen= ts and >> >> >> >>>>>> thinks that the ] +network should notify dependent on >> >> >> >>>>>> packet-size, then it follows that the ] +transport can act >> >> >> >>>>>> independent of >> >> >> >>>>>> packet- size.] ] ] I think in S3.3 you're trying to make an= other >> >> >> >>>>>> argument (?):- ] * we can either do packet-size biasing in= the >> >> >> >>>>>> network element or on the end host ] +transport (see argume= nt >> >> >> >>>>>> above) ] * packet-size biasing in the network is quite tric= ky, >> >> >> >>>>>> because then both the ] +network element & the transport ha= ve to >> >> >> >>>>>> make some guesses about MTU - whereas ] >> >> >> >>>>>> +with packet-size biasing in the transport, neither network >> >> >> >>>>>> +element >> >> >> >>>>>> nor ] +transport needs to know what the MTU is. >> >> >> >>>>>> ] * it is also easier to implement packet-size biasing in t= he >> >> >> >>>>>> transport than in ] +the network. >> >> >> >>>>>> ] >> >> >> >>>>>> ] On the last bullet, I didn't really follow your argument = in >> >> >> S3.5. >> >> >> >>>>>> Might be ] +easier to follow if S3.5 also talked about how = a >> >> >> >>>>>> network element would take ] +account of pkt size? Also, do= es the >> >> >> >>>>>> following argument also apply?: >> >> >> >>>>>> ] * if pkt-size biasing is done in the transport, then the = work >> >> >> >>>>>> (to do the ] +biasing) is spread over many end hosts, ] * w= hereas >> >> >> >>>>>> if pkt-size biasing is done in the network, then the work i= s ] >> >> >> >>>>>> +concentrated in just the congested network element, which = has to >> >> >> >>>>>> operate on all ] +the traffic at line speed. >> >> >> >>>>>> >> >> >> >>>>>> (Has there perhaps been some confusion about what went in= to the >> >> >> >>>>>> -08 >> >> >> >>>>>> version?) >> >> >> >>>>>> >> >> >> >>>>>> -- >> >> >> >>>>>> John Leslie > >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>> >> >> >> >>>> >> >> >> >>> ______________________________________________________________= __ >> >> >> >>> Bob Briscoe, BT Innovate & Desi= gn >> >> >> >>> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________________________________________ >> >> > Bob Briscoe, BT Innovate & Design >> >> > >> > >> > ________________________________________________________________ >> > Bob Briscoe, BT Innovate & Design > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design --_000_9510D26531EF184D9017DF24659BB87F33DD2D3573EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bob,

Your argument seems ok to me.

<< Transports on the other hand don't always want = to make their rate response proportional to the size of dropped packets, bu= t if they want to, they always can>>

“alwa= ys can”? do they always know?

<< rate resp= onse proportionate to the size of each dropped packet, while others will (e= .g. TFRC-SP [RFC4828]).>>

Does 4828 make a packe= t-by-packet decision or does it know that the small pkt source has a partic= ular pkt size for a long run? “each dropped pkt” sounds like th= e former, thought 4828 was the latter?

<< The ar= gument applies solely to drop, not to ECN marking.>>

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>Should you make more comment here? Given that much of the draft is ab= out ecn marking.

<<= For both these reasons networks will often be dropping packets = as a last resort (case b) rather than under AQM control (case a).>>

“often” seems wrong. “sometimes”= ;?

Also, pendantically “both reasons” see= ms wrong, since the two reasons are mutually exclusive they cannot both be = true.

Thanks

phil=

 

From: B= riscoe,RJ,Bob,DUB8 R
Sent: 15 October 2012 10:18
To: M= anner Jukka
Cc: Eardley,PL,Philip,DUB8 R; <tsvwg-chairs@ietf.o= rg>; <gorry@erg.abdn.ac.uk>; tsvwg IETF list
Subject: Re= : [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest

 

Jukka,

OK, 2nd attempt below, annotated with HTML = formatting. Rather than predicting the future, I have confined the text to = the lack of universal deployment in the present. If you're happy with this,= pls go ahead and re-issue the draft.


=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
3.4.  Permanent Partial Deployment of AQM

I= n overview, the argument in this section runs as follows:
* Because the= network does will not and c= annot always drop packets in proportion to their size, it shouldn't be give= n the task of making drop signals depend on packet size at all.
* Trans= ports on the other hand don't always want to make their rate response propo= rtional to the size of dropped packets, but if they want to, they always ca= n.

The argument is similar to the end-to-end argument that says &quo= t;Don't do X in the network if end-systems can do X by themselves, and they= want to be able to choose whether to do X anyway." Actually the follo= wing argument is stronger; in addition it says "Don't give the network= task X that could be done by the end-systems, if X is not won't ever be deployed on all network nodes,= and end-systems won't be able to tell whether their network is doing X, or= whether they need to do X themselves." In this case, the X in questio= n is "making the response to congestion depend on packet size". <= br>
We will now re-run this argument taking each step in more depth. The= argument applies solely to drop, not to ECN marking.

A queue drops= packets for either of two reasons: a) to signal to host congestion control= s that they should reduce the load and b) because there is no buffer left t= o store the packets. Active queue management tries to use drops as a signal= for hosts to slow down (case a) so that drop due to buffer exhaustion (cas= e b) should not be necessary.

No-one expects AQM is not to ever be universally deployed = in every queue in the Internet; many cheap eth= ernet bridges, software firewalls, NATs on consumer devices, etc implement = simple tail-drop buffers. and, eEven if AQM were universal, it has to be able to cope with b= uffer exhaustion (by switching to a behaviour like tail-drop), in order to = cope with unresponsive or excessive transports. Therefore For both these reasons networks will often be= dropping packets as a last resort (case b) rather than under AQM control (= case a).

When buffers are exhausted (case b), they don't naturally d= rop packets in proportion to their size. The network can only reduce the pr= obability of dropping smaller packets if it has enough space to store them = somewhere while it waits for a larger packet that it can drop. If the buffe= r is exhausted, it does not have this choice. Admittedly tail-drop does nat= urally drop somewhat fewer small packets, but exactly how few depends more = on the mix of sizes than the size of the packet in question. Nonetheless, i= n general, if we wanted networks to do size-dependent drop, we would need u= niversal deployment of (packet-size dependent) AQM code, which is currently unrealistic.

A host transpo= rt cannot know whether any particular drop was a deliberate signal from an = AQM or a sign of a queue shedding packets due to buffer exhaustion. Therefo= re, because the network cannot universally do size-dependent drop, it shoul= d not do it all.

Whereas universality is desirable in the network, = diversity is desirable between different transport layer protocols - some, = like NewReno TCP [RFC5681], may not choose to make their rate response prop= ortionate to the size of each dropped packet, while others will (e.g. TFRC-= SP [RFC4828]).
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



Bob
<= br>At 13:34 11/10/2012, Manner Jukka wrote:

Hi,

Yeah, please at the point about cheap devices, stil= l, I wonder what the cost of AQM is on those devices. Maybe 1 cnt in mass p= roduction? Thus, I still wonder if it is worth arguing something about the = future that strongly.

Sorry, but the same goes for AQM in general, a= nd where it is, or will not be deployed. I understand technical reasons why= not something is feasible, but business or monetary reasons can change ver= y quickly. ;)

Jukka

On Oct 11, 2012, at 3:08 PM, Bob Briscoe = wrote:

> Jukka,
>
> What I had in mind is all low le= vel buffers in cheap pure L2 devices, in cheap NATs etc. I was going to lis= t some of these, but instead chose to say "no-one expects AQM to be un= iversally deployed". This clearly missed the mark.
>
> Sh= ould we include some of these concrete examples of where AQM won't be deplo= yed instead?
>
> [I've cc'd the list, given we're starting to = wordsmith significantly new text added since WG last call.]
>
>= ;
> Bob
>
> At 20:04 10/10/2012, Manner Jukka wrote:>> Hi, looked good to me. Just one comment, I wouldn't put that much= emphasis on what is a probably state of things, e.g.
>>
>&= gt; "no-one expects AQM to ever be .."  > in the future i= t might, we don't know, and since the paragraph says that it doesn't matter= anyway, I would formulate this paragraph a bit towards that we have partia= l deployment now and  even with a full deployment, ...
>> >> and similarly with the unrealistic deployment of AQM in the subse= quent paragraph.
>>
>> cheers,
>> Jukka
>= >
>> On Oct 10, 2012, at 6:25 PM, Bob Briscoe wrote:
>&g= t;
>> > Phil,
>> >
>> > Sorry for dela= y, my round-robin scheduler is taking so long to get round all the tasks th= at I keep finding dead robins (that reminds me of a bike ride my grandmothe= r took. On her return, she said there were a worryingly large number of rob= ins run over on the roads. It turned out that she had been going round the = same small triangle of roads multiple times).
>> >
>> = > I've done a complete re-write of 3.4. I hope you will agree that it re= ally is a motivating argument now and it can stay where it is - it is not j= ust a preamble.
>> >
>> > I've gone back to the ver= y first version of 3.4 I wrote and I now realise that I had written the cor= e of the argument so badly that even I forgot what it was meant to say when= we started editing it. In the draft-08 version, the original meaning is lo= st and in your re-wording it is entirely lost. The link with the draft-08 v= ersion is nearly unrecognisable, but it's the argument I intended here.
= >> >
>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>&= gt; > 3.4.  Permanent Partial Deployment of AQM
>> >>> > In overview, the argument in this section runs as follows:>> > * Because the network will not and cannot always drop packe= ts in proportion to their size, it shouldn't be given the task of making dr= op signals depend on packet size at all.
>> > * Transports on t= he other hand don't always want to make their rate response proportional to= the size of dropped packets, but if they want to, they always can.
>= > >
>> > The argument is similar to the end-to-end argume= nt that says "Don't do X in the network if end-systems can do X by the= mselves, and they want to be able to choose whether to do X anyway." A= ctually the following argument is stronger; in addition it says "Don't= give the network task X that could be done by the end-systems, if X won't = ever be deployed on all network nodes, and end-systems won't be able to tel= l whether their network is doing X, or whether they need to do X themselves= ." In this case, the X in question is "making the response to con= gestion depend on packet size".
>> >
>> > We w= ill now re-run this argument taking each step in more depth. The argument a= pplies solely to drop, not ECN marking.
>> >
>> > A= queue drops packets for either of two reasons: a) to signal to host conges= tion controls that they should reduce the load and b) because there is no b= uffer left to store the packets. Active queue management tries to use drops= as a signal for hosts to slow down (case a) so that drop due to buffer exh= austion (case b) should not be necessary.
>> >
>> >= No-one expects AQM to ever be universally deployed in every queue in the I= nternet; and, even if AQM were universal, it has to be able to cope with bu= ffer exhaustion (by switching to a behaviour like tail-drop), in order to c= ope with unresponsive or excessive transports. Therefore networks will ofte= n be dropping packets as a last resort (case b) rather than under AQM contr= ol (case a).
>> >
>> > When buffers are exhausted (= case b), they don't naturally drop packets in proportion to their size. The= network can only reduce the probability of dropping smaller packets if it = has enough space to store them somewhere while it waits for a larger packet= that it can drop. If the buffer is exhausted, it does not have this choice= . Admittedly tail-drop does naturally drop somewhat fewer small packets, bu= t exactly how few depends more on the mix of sizes than the size of the pac= ket in question. Nonetheless, in general, if we wanted networks to do size-= dependent drop, we would need universal deployment of (packet-size dependen= t) AQM code, which is unrealistic.
>> >
>> > A host= transport cannot know whether any particular drop was a deliberate signal = from an AQM or a sign of a queue shedding packets due to buffer exhaustion.= Therefore, because the network cannot universally do size-dependent drop, = it should not do it all.
>> >
>> > Whereas universa= lity is desirable in the network, diversity is desirable between different = transport layer protocols - some, like NewReno TCP [RFC5681], may not choos= e to make their rate response proportionate to the size of each dropped pac= ket, while others will (e.g. TFRC-SP [RFC4828]).
>> > =3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
>> >
>> >
>> >=
>> >
>> > Bob
>> >
>> > At= 13:13 04/10/2012, gorry@erg.abdn.a= c.uk wrote:
>> >> That would be brilliant!
>> &= gt;>
>> >> Gorry
>> >>
>> >>= ; > Will try to look at this later today.
>> >> >
&= gt;> >> >
>> >> > Bob
>> >> &g= t;
>> >> > At 10:42 02/10/2012, philip.eardley@bt.com wrote:
>> >> >&= gt;Think the token is with bob
>> >> >>
>> &g= t;> >>Re your comment - yes, I think you could move 3.4 to the end= of S3 -
>> >> >>or to the start - and do some re-phra= sing, maybe something like I tried.
>> >> >>
>&g= t; >> >>-----Original Message-----
>> >> >>= ;From: Manner Jukka [ mailto:jukka= .manner@aalto.fi]
>> >> >>Sent: 01 October 2012 20= :18
>> >> >>To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,B= ob,DUB8 R
>> >> >>Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst
>> >> &g= t;>Subject: Re: [REVISED I-D]: Document writeup for
>> >>= >>draft-ietf-tsvwg-byte-pkt-congest
>> >> >>>> >> >>Phil, Bob, can we close this finally? It's three= weeks now since
>> >> >>this previous message.
>= ;> >> >>
>> >> >>Jukka
>> >= > >>
>> >> >>On Sep 10, 2012, at 4:42 PM, Juk= ka Manner wrote:
>> >> >>
>> >> >>= ; > Ack, I'm getting there...;)
>> >> >> >
&g= t;> >> >> > So, we could move 3.4 at the end of Section 3= and rephrase it to
>> >> >> not talk about scaling pe= r se, but rather about how Req 2.2
>> >> >> eventually= leads to Req 2.3?
>> >> >> >
>> >> = >> > Jukka
>> >> >> >
>> >>= >> > On Sep 7, 2012, at 4:07 PM, <philip.eardley@bt.com>
>> >> >> &g= t; <philip.eardley@bt.com&g= t; wrote:
>> >> >> >
>> >> >> = >> 3.4 is, in my mind, completely different from 3.1, 3.2, 3.3 and 3.= 5.
>> >> >> >>
>> >> >> >= ;> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for Recommendation=
>> >> >> >> 2.2 & a lesser extent 2.3
&g= t;> >> >> >> 3.4 makes doesn't make a motivating argum= ent - it explains that  Rec
>> >> >> >> 2.2= & 2.3 come as a pair (if you recommend one, then inevitably you
>= ;> >> >> >> recommend the other) (delta some politenes= s about TCP)
>> >> >> >>
>> >> &g= t;> >>
>> >> >> >>
>> >>= >> >> -----Original Message-----
>> >> >>= >> From: Manner Jukka [ mai= lto:jukka.manner@aalto.fi]
>> >> >> >> Sent:= 07 September 2012 13:24
>> >> >> >> To: Eardley= ,PL,Philip,DUB8 R
>> >> >> >> Cc: Briscoe,RJ,Bob= ,DUB8 R; <tsvwg-chairs@ietf.org= >;
>> >> >> >> <gorry@erg.abdn.ac.uk>
>> >> >>= ; >> Subject: Re: [REVISED I-D]: Document writeup for
>> >= ;> >> >> draft-ietf-tsvwg-byte-pkt-congest
>> >&= gt; >> >>
>> >> >> >> Hi, I'm trying= to follow your reasoning, with little luck. ;)
>> >> >&g= t; >>
>> >> >> >> After having read Sectio= n 3 again, I could think of a few
>> >> >> updates, bu= t I'm not fully following what you want to see:
>> >> >&g= t; >>
>> >> >> >> - S3.5 is kind of small = and lonely by itself. It could be either
>> >> >> long= er or merged somewhere. Not a major issue though and could remain as
>= ;> >> >> is.
>> >> >> >>
>&= gt; >> >> >> - S3.3: Yes, probably could be turned upside= down, good first,
>> >> >> bad later. Don't have a st= rong opinion.
>> >> >> >>
>> >> &= gt;> >> - S3.4: Here the scaling is used many times and in the tit= le,
>> >> >> although we talk about the end host side.= This could be rephrased
>> >> >> and slightly reworde= d to talk about hosts and their operation
>> >> >> alt= ogether. Also the word scaling can turn the readers expectation
>>= >> >> into the wrong direction.
>> >> >> = >>
>> >> >> >> - S3 altogether: It would h= elp to have introductory text about
>> >> >> networks = vs. end host side, but I fail to see why  (& how) to
>> &= gt;> >> restructure everything.
>> >> >> >= >
>> >> >> >> cheers,
>> >> &g= t;> >> Jukka
>> >> >> >>
>> &g= t;> >> >> On Sep 6, 2012, at 6:18 PM,
>> >> &= gt;> <philip.eardley@bt.com<= /a>>  <philip.eardley@b= t.com> wrote:
>> >> >> >>
>> >= ;> >> >>> Ps otherwise Bob's comments are fine, though I = suggest for S3.5 you
>> >> >> >>> give more c= ontext (ie are you knocking down what you recommend
>> >> &g= t;> >>> against, or building up what you recommend?)  and = in S3.3 think
>> >> >> >>> would be better if= you re-structured slightly [first talk about what
>> >> >= ;> >>> you like - penult para + 1st sentence of last para - the= n talk about
>> >> >> >>> what you don't like= - rest of text]
>> >> >> >>>
>> >= ;> >> >>> From: Eardley,PL,Philip,DUB8 R
>> >= > >> >>> Sent: 06 September 2012 16:12
>> >&g= t; >> >>> To: Briscoe,RJ,Bob,DUB8 R; Manner Jukka
>>= ; >> >> >>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst
>> >> >>= >>> Subject: RE: [REVISED I-D]: Document writeup for
>> = >> >> >>> draft-ietf-tsvwg-byte-pkt-congest
>>= ; >> >> >>>
>> >> >> >>>= Thanks bob. Have now re-booted some state.
>> >> >> &= gt;>> I don't like S3.4. My basic problem with it is that it isn't a<= br>>> >> >> "motivating argument" (S3 title). I= t's an explanation about the
>> >> >> consequences of = assuming either [option 1] do pkt-size biasing in
>> >> >= > the transport; [option 2]; do pkt-size biasing in the nw.
>> = >> >> >>> Perhaps your effort to buy peace with those = who won't change
>> >> >> TCP has obfuscated the basic= point?
>> >> >> >>> The title of S3.4 (Scali= ng...) and the early text "scaling
>> >> >> argum= ent" suggests that you're going to argue there is some reason
>&= gt; >> >> why X scales as order N rather than N^2 or something = like that -
>> >> >> which isn't what S3.4 is about.>> >> >> >>>
>> >> >> >= ;>> I actually think it would be better to put S3.4 at the start of>> >> >> S3 - it's background where you say there are 2= options. After that,
>> >> >> you can explain the rea= sons why option 1 [pkt biasing in the
>> >> >> transpo= rt] is better - the reasons being:-  S3.1 (security etc
>> &g= t;> >> attacks if small pkts get preferential treatment), S3.2 (re= ally a
>> >> >> side note to S3.1; ie doesn't really p= resent a "motivating
>> >> >> argument"), S3= .3 (nw guessing MTU vs transport knowing pkt size),
>> >> &g= t;> S3.5 (easier implementation).
>> >> >> >>= >
>> >> >> >>> Something like...
>&g= t; >> >> >>> The behaviour of the network and transpor= t together needs to
>> >> >> >>> alleviate co= ngestion. We assume the network is bit-congestible
>> >> >= ;> (currently packet-congestible resources are rate). Therefore
>&= gt; >> >> overall the response of the {network + transport} sho= uld be the
>> >> >> same for the same congestion - whe= ther the congestion is caused by
>> >> >> a lot of sma= ll packets or a smaller number of larger packets. The
>> >> = >> implication is that the transport's behaviour should depend on
= >> >> >> whether the network takes account (or not) of pa= cket size when it
>> >> >> generates congestion indica= tions:- Case 1: If the network
>> >> >> implements pac= ket-mode drop, ie its algorithm treats all packets
>> >> >= ;> equally regardless of their size, then the transport should take
&= gt;> >> >> account of the size of the packet - in other word= s, the transport's
>> >> >> congestion response should= depend on the number of dropped bytes.
>> >> >> >&= gt;> Case 2: If the network implements byte-mode drop, ie its
>>= ; >> >> algorithm treats packets differently depending on their= size, then
>> >> >> the transport should not take acc= ount of the size of the packet -
>> >> >> in other wor= ds, the transport's congestion response should depend
>> >> = >> on the number of dropped packets.
>> >> >> &g= t;>>
>> >> >> >>> These cases are expla= ined in more detail in sub-section below.
>> >> >> >= ;>>
>> >> >> >>> In both cases the same= discussion applies if packets are
>> >> >> ECN-marked= rather than dropped.
>> >> >> >>> In the fol= lowing sections we explain why Case 1 is preferable,
>> >> &= gt;> and hence why we make the Recommendations of S2.2 and S3.3
>&= gt; >> >> (respectively, drop/mark pkts equally regardless of t= heir size, and
>> >> >> the strength of the transport'= s response should be proportionate to
>> >> >> the siz= e of the dropped/marked pkt).
>> >> >> >>> No= te that TCP responds to dropped or marked packets, which differs
>>= ; >> >> >>> from our recommendation for transports. Ho= wever, we are not
>> >> >> >>> recommending t= hat TCP  should be changed; to date it hasn't been a
>> >&= gt; >> >>> significant problem because most TCP implementati= ons  have been
>> >> >> used with similar packet = sizes. But we do recommend that future
>> >> >> transp= ort protocols should  respond to dropped or marked bytes (as
>&g= t; >> >> for example TFRC-SP [RFC4828]effectively does).
>= ;> >> >> >>>
>> >> >> >>= >
>> >> >> >>> Sub-section
>> >= ;> >> >>> You could use much of S3.3, I suggest supplemen= t with numerical
>> >> >> >>> examples contin= uing S1.2
>> >> >> >>> --
>> >>= ; >> >>> << This gives a get-out clause to any transpo= rt that isn't
>> >> >> >>> packet-size depend= ent (e.g. current TCP). Lacking packet-size
>> >> >> &= gt;>> dependence just means they don't scale correctly with packet si= ze -
>> >> >> >>> but they are at liberty not= to scale with packet size (particularly
>> >> >> >= >> given MTU growth isn't often being used to increase link rates at<= br>>> >> >> >>> this stage in history).>><= br>>> >> >> >>>
>> >> >> &g= t;>> This is introducing a different point. it's saying that your
= >> >> >> recommendation 2 [drop/mark pkts equally regardl= ess of their size]
>> >> >> is a really strong reco wh= ilst recommendation 3 [strength of
>> >> >> transport'= s response proportionate to the size of the
>> >> >> d= ropped/marked pkt] is a much less important reco.  I can see this
&= gt;> >> >> might be true, but I don't think the i-d talks ab= out this.
>> >> >> >>>
>> >> &= gt;> >>> --
>> >> >> >>>
>&= gt; >> >> >>> From: Briscoe,RJ,Bob,DUB8 R
>> = >> >> >>> Sent: 05 September 2012 16:41
>> &g= t;> >> >>> To: Manner Jukka
>> >> >>= >>> Cc: tsvwg-chairs@iet= f.org; Gorry Fairhurst; Eardley,PL,Philip,DUB8 R
>> >> &= gt;> >>> Subject: Re: [REVISED I-D]: Document writeup for
&g= t;> >> >> >>> draft-ietf-tsvwg-byte-pkt-congest
= >> >> >> >>>
>> >> >> >&= gt;> Jukka,
>> >> >> >>>
>> >&= gt; >> >>> I've repeated Phil's suggestions as quoted email = then made some
>> >> >> alterations.
>> >&= gt; >> >>>
>> >> >> >>> Phil a= sked me to send this, then he will think about it.
>> >> >= ;> >>>
>> >> >> >>> I'll respond = about John Leslie's argument next...
>> >> >> >>= >
>> >> >> >>>
>> >> >&g= t; >>> 2.2. Recommendation on Encoding Congestion Notification
= >> >> >> >>>
>> >> >> >&= gt;> [...]
>> >> >> >>>
>> >&g= t; >> >>>  1.  AQM algorithms such as RED SHOULD u= se packet-mode drop, ie they
>> >> >> >>>&nbs= p;     SHOULD NOT use byte-mode drop. The latter is mor= e complex,
>> >> >> >>>   &nbs= p;  it creates the perverse incentive to fragment segments into
>= ;> >> >> tiny
>> >> >> >>>&nbs= p;     pieces and it is vulnerable to floods of small p= ackets.
>> >> >> >>>
>> >> >= ;> >>>  2.  If a vendor has implemented byte-mode dro= p, and an operator has
>> >> >> >>> &nbs= p;    turned it on, it is RECOMMENDED to turn it off, after<= br>>> >> >> establishing
>> >> >> &g= t;>>      if there are any implications on t= he relative performance of
>> >> >> >>> =      applications using different packet sizes.
>= > >> >> >>>
>> >> >> >>&= gt;      RED as a whole SHOULD NOT be turned off. = Without RED, a drop
>> >> >> tail
>> >>= >> >>>      queue biases against l= arge packets
>> >> >> >>>
>> >>= ; >> >>> [BB adds]:       = ;            &n= bsp;            = ; and it is vulnerable to
>> >> >> floods
>> = >> >> >>>       of small= -packets.
>> >> >> >>>
>> >> &= gt;> >>> (I suggest the last para just qualifies item 2. It doe= sn't warrant
>> >> >> >>> another item number= .)
>> >> >> >>>
>> >> >>= >>> <Agree with Phil; Don't indent "Note well...">= ;
>> >> >> >>>
>> >> >> = >>> [PE:] S3.3
>> >> >> >>> The sect= ion could be slightly clearer. Starting with the second
>> >>= ; >> para, where you start talking about something you don't recommen= d
>> >> >> (ie you have to remember that you're talkin= g about the consequences
>> >> >> of not following you= r recommendation).
>> >> >> >>>
>> &= gt;> >> >>> 3.3 Transport-Independent Network
>>= >> >> >>>
>> >> >> >>>&= nbsp; TCP congestion control ensures that flows competing for the same
&= gt;> >> >> >>> resource each maintain the same numb= er of segments in flight,
>> >> >> >>> irresp= ective of segment size.  So under similar conditions, flows
>>= ; >> >> >>> with different segment sizes will get diff= erent bit-rates.
>> >> >> >>>
>> >= ;> >> >>> [OLD:]
>> >> >> >>&g= t;  One motivation for the network biasing congestion notification by<= br>>> >> >> >>> packet size is to counter this e= ffect and try to equalise the bit-
>> >> >> >>&g= t; rates of flows with different packet sizes.
>> >> >>= ; >>> [SUGGESTED:]
>> >> >> >>> = ; To counter this effect it seems tempting not to follow our
>> &g= t;> >> >>> recommendation,  and instead for the netw= ork to bias congestion
>> >> >> >>> notificat= ion by  packet size in order to equalise the bit-rates of
>> = >> >> >>> flows with different  packet sizes.
= >> >> >> >>> [CONTINUE AS BEFORE:]
>> &= gt;> >> >>>       &nbs= p;        However, in order to do  = this, the queuing algorithm
>> >> >> >>> has = to make assumptions about the  transport, which become embedded
>= ;> >> >> >>> in the network.  Specifically:>> >> >> >>> [...]
>> >> >>= ; >>>
>> >> >> >>>
>> >&= gt; >> >>>
>> >> >> >>> S3.3>> >> >> >>>  o  The queuing algorit= hm has to assume how aggressively the
>> >> >> transpo= rt
>> >> >> >>>     will = respond to congestion (see Section 4.2.4).  If the network
>>= >> >> >>>     assumes the transpo= rt responds as aggressively as TCP NewReno,
>> >> >> i= t
>> >> >> >>>     will b= e wrong for Compound TCP and differently wrong for Cubic
>> >&g= t; >> >>>     TCP, etc.  To achieve= equal bit-rates, each transport then has
>> >> >> to<= br>>> >> >> >>>     guess wh= at assumption the network made, and work out how to
>> >> &g= t;> >>>     replace this assumed aggressive= ness with its own aggressiveness.
>> >> >> >>>= ;  o  Also, if the network biases congestion notification by pack= et
>> >> >> size
>> >> >> >>= ;>     it has to assume a baseline packet size--all = proposed algorithms
>> >> >> >>>  &= nbsp;  use the local MTU.  Then transports have to guess which li= nk was
>> >> >> >>>     c= ongested and what its local MTU was, in order to know how to
>> &g= t;> >> >>>     tailor their congestio= n response to that link.
>> >> >> >>>
>= > >> >> >>> So you're saying that for byte-mode dro= p, the network element
>> >> >> has to compare the siz= e of the current pkt with the MTU, and if
>> >> >> it'= s 25* smaller then reduce the pkt loss probably by 25*? And if
>> = >> >> the MTU was bigger, then the current pkt would be dropped= with
>> >> >> greater probability? And both of these = things are hard to do.
>> >> >> >>>
>&g= t; >> >> >>> [BB]: SUGGESTED REPLACEMENT to 2nd bullet= :
>> >> >> >>>
>> >> >> = >>>  o  Also, if the network biases congestion notificat= ion by packet
>> >> >> size
>> >> >&= gt; >>>     it has to assume a baseline packet= size--all proposed algorithms
>> >> >> >>>&n= bsp;    use the local MTU (for example see the byte-mode los= s
>> >> >> probability
>> >> >> &= gt;>>     formula in Table 1).  Then if the = non-Reno transports mentioned
>> >> >> above
>&g= t; >> >> >>>     are trying to rev= erse engineer what the network assumed, they
>> >> >> = also
>> >> >> >>>     hav= e to guess the MTU of the congested link.
>> >> >> >= ;>>
>> >> >> >>> [Aside for Phil: The b= yte-mode algo uses MTU as its baseline because
>> >> >>= ; >>> a link cannot send a packet bigger than its MTU so the algo = won't
>> >> >> >>> ever give a drop probabili= ty >1).]
>> >> >> >>>
>> >>= >> >>>
>> >> >> >>> S3.4 (&am= p; knock-on effect on 3.3)
>> >> >> >>> I thi= nk this could be better.
>> >> >> >>> I agree= with your arguments in S3.1 & 3.2 that dropping or
>> >>= ; >> marking should be independent of pkt size.
>> >> = >> >>> You now go into a couple of pages, which I think coul= d be boiled
>> >> >> >>> down to a paragraph,= saying something like:-
>> >> >> >>> * the o= verall system (network + transport) has to be packet-size
>> >&= gt; >> >>> dependent in order to drive out the right amount = of traffic so the
>> >> >> >>> resource becom= es uncongested (since we assume all resources are in
>> >> &= gt;> >>> practice byte rather than packet limited)
>> = >> >> >>> * from S3.1 and S3.2 the IETF is convinced t= hat the network
>> >> >> should notify independent of = packet-size.
>> >> >> >>> * therefore the tra= nsport must act dependent on packet-size.
>> >> >> >= ;>>
>> >> >> >>> It seems to me this is= a necessary consequence of your earlier
>> >> >> assu= mptions /arguments.
>> >> >> >>>
>> = >> >> >>> [BB:] This isn't at all obvious. Until I wor= ked it through, it
>> >> >> wasn't obvious to me. I th= ink it needs to be spelled out.
>> >> >> >>><= br>>> >> >> >>>
>> >> >> &g= t;>>
>> >> >> >>> [On the other hand, i= f someone disagrees with the arguments and
>> >> >> &g= t;>> thinks that the network should notify dependent on packet-size, = then
>> >> >> >>> it follows that the transpo= rt can act independent of packet-size.]
>> >> >> >&= gt;>
>> >> >> >>> I think in S3.3 you're t= rying to make another argument (?):-
>> >> >> >>= > * we can either do packet-size biasing in the network element or on>> >> >> >>> the end host transport (see argume= nt above)
>> >> >> >>> * packet-size biasing = in the network is quite tricky, because
>> >> >> then = both the network element & the transport have to make some
>> = >> >> guesses about MTU - whereas with packet-size biasing in t= he
>> >> >> transport, neither network element nor tra= nsport needs to know what the
>> >> >> MTU is.
>= > >> >> >>> * it is also easier to implement packet= -size biasing in the
>> >> >> transport than in the ne= twork.
>> >> >> >>>
>> >> >= > >>> [BB] ...and all the other arguments about vulnerability t= o
>> >> >> flooding etc, transport-independence etc.>> >> >> >>>
>> >> >> >= ;>> Our argument is sort of like how Phil summarises it, but with
= >> >> >> an added nuance. It's also saying no-one has to = do packet-size
>> >> >> biasing anyway. It's not sayin= g "The transport should given the
>> >> >> networ= k shouldn't". It's saying "*If the transport wants to claim
&g= t;> >> >> to be scalable wrt packet size* it should if the n= etwork shouldn't".
>> >> >> >>>
>&= gt; >> >> >>> This gives a get-out clause to any trans= port that isn't
>> >> >> packet-size dependent (e.g. c= urrent TCP). Lacking packet-size
>> >> >> dependence j= ust means they don't scale correctly with packet size -
>> >>= ; >> but they are at liberty not to scale with packet size (particula= rly
>> >> >> given MTU growth isn't often being used t= o increase link rates at
>> >> >> this stage in histor= y).
>> >> >> >>>
>> >> >>= ; >>> None of what Phil says convinces me we could say 3.4 (or 3.3= )
>> >> >> any more briefly or differently. It's easie= r to summarise what you
>> >> >> understand having rea= d something. But that's not the same as
>> >> >> writi= ng the thing that helped you understand. There doesn't seem to
>> = >> >> be any argument for why anything needs to be changed, so = I'm going
>> >> >> to leave it as is, unless pushed.>> >> >> >>>
>> >> >> >= ;>>
>> >> >> >>>
>> >> &= gt;> >>> On the last bullet, I didn't really follow your argume= nt in
>> >> >> S3.5. Might be easier to follow if S3.5= also talked about how a
>> >> >> network element woul= d take account of pkt size?
>> >> >> >>> Also= , does the following argument also apply?:
>> >> >> &g= t;>> * if pkt-size biasing is done in the transport, then the work (t= o do
>> >> >> >>> the biasing) is spread over= many end hosts,
>> >> >> >>> * whereas if pk= t-size biasing is done in the network, then the
>> >> >&g= t; work is concentrated in just the congested network element, which
>= ;> >> >> has to operate on all the traffic at line speed.>> >> >> >>>
>> >> >> >= >> [BB]: 3.5. Implementation Efficiency
>> >> >>= >>>
>> >> >> >>> [ADD:]
>>= >> >> >>>  Biasing against large packets typical= ly requires an extra multiply
>> >> >> >>> an= d  divide in the network (see the example byte-mode drop
>> &= gt;> >> formula in table 1).
>> >> >> >>= ;> [CONTINUE AS BEFORE:]
>> >> >> >>> = ; Allowing for packet size at the transport rather than in the
>> = >> >> >>> network  ensures that neither the netwo= rk nor the transport needs to
>> >> >> >>> do= a  multiply operation--multiplication by packet size is
>> &= gt;> >> >>> effectively  achieved as a repeated add = when the transport adds to
>> >> >> >>> its c= ount of  marked bytes as each congestion event is fed to it.
>&g= t; >> >> >>> [ADD:]
>> >> >> >= >>  Also the work to do the biasing is spread over many hosts, r= ather
>> >> >> >>> than  concentrated in= just the congested network element.
>> >> >> >>= > [CONTINUE AS BEFORE:]
>> >> >> >>> =             &nb= sp;            =             &nb= sp;            =    These aren't
>> >> >> >>> princi= pled reasons in themselves, but they are a happy consequence
>> &g= t;> >> >>> of the  other principled reasons.
>= > >> >> >>>
>> >> >> >>&= gt;
>> >> >> >>> Bob
>> >> >= ;> >>>
>> >> >> >>> At 13:36 05/0= 9/2012, Manner Jukka wrote:
>> >> >> >>>
&= gt;> >> >> >>> Hi Bob,
>> >> >>= ; >>>
>> >> >> >>> Since Phil is you= r colleague at BT, even at Ipswich (?), can
>> >> >> y= ou check those and agree with Phil how to go forward? Some of
>> &= gt;> >> those are clear, others need discussion with Phil.
>= > >> >> >>>
>> >> >> >>&= gt; Gorry, on point 2) below, I don't follow Leslie's arguments. I
>&= gt; >> >> asked from him detailed comments and resolutions mont= hs ago, and nothing
>> >> >> came.
>> >>= ; >> >>>
>> >> >> >>> cheers,<= br>>> >> >> >>> Jukka
>> >> >&= gt; >>>
>> >> >> >>> On Sep 5, 2012,= at 3:26 PM, Gorry Fairhurst wrote:
>> >> >> >>&= gt;
>> >> >> >>>> Bob and Jukka,
>&g= t; >> >> >>>>
>> >> >> >>= ;>> I think I need your help to resolve this... Some of the
>&g= t; >> >> comments raised by John Leslie appear to have substanc= e, and I'm
>> >> >> not sure what you plan to do to ad= dress these.
>> >> >> >>>>
>> >= ;> >> >>>> It would be good to do something quick so t= hat I can complete
>> >> >> the submission to the IESG= .
>> >> >> >>>>
>> >> >&= gt; >>>> The issues I particularly note are:
>> >&g= t; >> >>>>
>> >> >> >>>>= 1) This contribution from Phil appears to be within scope and
>> = >> >> it seems may have been overlooked (sorry):
>> &g= t;> >> >>>> http://www.ietf.org/mail-archive/web/tsv= wg/current/msg11234.html
>> >> >> >>>>=
>> >> >> >>>> 2) Can you be clear here ab= out what is actually been said -
>> >> >> because the = point below seems to be a misunderstanding of language
>> >>= >> to me, and I hoped we did not claim this:
>> >> &g= t;> >>>>
>> >> >> >>>>>&= gt; ] Alas, when I read it carefully this week, I find that Bob is
>&= gt; >> >> >>>>>> actually ] saying that trans= port-layer should _only_ consider
>> >> >> >>>= ;>>> "congested bytes", not ] "congested packets&qu= ot;.
>> >> >> >>>>>> ]
>> &= gt;> >> >>>>
>> >> >> >>>= ;> 3) You'll need to post the updated draft and send a note to
>&g= t; >> >> the group to confirm that the new version indeed concl= udes the
>> >> >> WGLC. I'll add a note to the writeup= to indicate the draft content
>> >> >> has been stabl= e since Oct 2011.
>> >> >> >>>>
>>= ; >> >> >>>> Gorry (with my TSVWG Documnent Shepher= d hat)
>> >> >> >>>> cc: Co-Chairs for inf= o.
>> >> >> >>>>
>> >> >= > >>>>>
>> >> >> >>>>>= ;> -----Original Message-----
>> >> >> >>>= >>> From: Gorry Fairhurst [ mailto:gorry@erg.abdn.ac.uk]
>> >> >> >>&g= t;>>> Sent: Mittwoch, 15. August 2012 21:41
>> >> &= gt;> >>>>>> To: tsvwg chair
>> >> >&= gt; >>>>>> Subject: Fwd: Re: [tsvwg] FYI: Document writeu= p for
>> >> >> >>>>>> draft-ietf-tsv= wg- byte-pkt-congest
>> >> >> >>>>>>=
>> >> >> >>>>>>
>> >>= ; >> >>>>>>
>> >> >> >>&= gt;>>> Hi guys,
>> >> >> >>>>>= >
>> >> >> >>>>>>
>> >= ;> >> >>>>>> Apart form the usual rhetoric, ther= e are some points here that we
>> >> >> >>>&g= t;>> should note as chairs. What are you own thoughts? And was
>= ;> >> >> >>>>>> anything noted at the IETF= in Vancouver concerning this draft?
>> >> >> >>= >>>>
>> >> >> >>>>>> Gor= ry
>> >> >> >>>>>>
>> >&= gt; >> >>>>>>
>> >> >> >>= ;>>>>
>> >> >> >>>>>> --= ------ Original Message --------
>> >> >> >>>= >>> Subject: Re: [tsvwg] FYI: Document writeup for
>> >= ;> >> >>>>>> draft-ietf-tsvwg-byte- pkt-congest<= br>>> >> >> >>>>>> Date: Wed, 15 Aug 20= 12 15:07:28 -0400
>> >> >> >>>>>> Fr= om: John Leslie <john@jlc.net>>> >> >> >>>>>> To: Gorry Fairhurst &l= t;gorry@erg.abdn.ac.uk>
&= gt;> >> >> >>>>>> CC: tsvwg@ietf.org
>> >> >> >>>= >>>
>> >> >> >>>>>> Gorry F= airhurst <gorry@erg.abdn.ac.uk> wrote:
>> >> >> >>>>>>>>> >> >> >>>>>>> The following docu= ment has been revised after receiving
>> >> >> WGLC co= mments.
>> >> >> >>>>>>
>> = >> >> >>>>>>   The changes are most= ly refreshing a document scheduled to
>> >> >> >>= ;>>>> expire this month.
>> >> >> >>= >>>>
>> >> >> >>>>>>>= No issues were found:
>> >> >> >>>>>&g= t;
>> >> >> >>>>>>   Is th= at with WGC-hat-on?
>> >> >> >>>>>><= br>>> >> >> >>>>>>   Neither = my issues nor Philip Eardley's comments were addressed.
>> >>= ; >> >>>>>> In fact, not even the changes Bob Brisc= oe mentioned on-list have
>> >> >> >>>>>= ;> been included.
>> >> >> >>>>>>=
>> >> >> >>>>>>> As required by = RFC 4858, this is the current template for the
>> >> >>= ; >>>>>> Document
>> >> >> >>&= gt;>>>> Shepherd Write-Up.
>> >> >> >&g= t;>>>>> ...
>> >> >> >>>>&g= t;>> (1) What type of RFC is being requested (BCP, Proposed Standard,=
>> >> >> >>>>>>> Internet Standa= rd, Informational, Experimental, or Historic)?
>> >> >>= ; >>>>>>> Why is this the proper type of RFC? Is this = type of RFC
>> >> >> >>>>>>> indi= cated in the title page header?
>> >> >> >>>&= gt;>>>
>> >> >> >>>>>>> = This document is intended as BCP. (This was discussed at IETF-81
>>= ; >> >> >>>>>>> and that the status change= d from Informational to BCP since it
>> >> >> >>= >>>>> provides guidance to implementors and people configuri= ng
>> >> >> routers and hosts).
>> >> &= gt;> >>>>>>
>> >> >> >>>= >>>   Thank you for finally answering my question about = BCP status.
>> >> >> >>>>>>
>&= gt; >> >> >>>>>>> ...
>> >>= >> >>>>>>> Working Group Summary
>> &g= t;> >> >>>>>>>
>> >> >> = >>>>>>> There was consensus to publish this as a WG do= cument and
>> >> >> >>>>>>> agree= ment at
>> >> >> >>>>>>> IETF-82 = that the document was now complete.
>> >> >> >>&= gt;>>>
>> >> >> >>>>>> = ;  Was that reviewed on-list?
>> >> >> >>&g= t;>>>
>> >> >> >>>>>>> .= ..
>> >> >> >>>>>>> (3) Briefly d= escribe the review of this document that was
>> >> >> = >>>>>>> performed
>> >> >> >&g= t;>>>> by
>> >> >> >>>>>>= ;> the Document Shepherd. If this version of the document is not
>= > >> >> >>>>>>> ready for publication, = please explain why the document is being
>> >> >> >= >>>>>> forwarded to the IESG.
>> >> >&g= t; >>>>>>>
>> >> >> >>>&= gt;>>> The document was presented at IEWTF-82 (Taipei), with a req= uest
>> >> >> >>>>>>> for
>= > >> >> >>>>>> WGLC.
>> >> = >> >>>>>>> WGLC concluded with some discussion b= ut no substantive changes
>> >> >> >>>>>= ;>> on Friday 30th March 2012.
>> >> >> >>= >>>>
>> >> >> >>>>>>&nbs= p;  Yes, I guess that is true; but ignoring substantive comments
&g= t;> >> >> >>>>>> isn't a good practice IMH= O.
>> >> >> >>>>>>
>> >&= gt; >> >>>>>>> (4) Does the document Shepherd ha= ve any concerns about the depth
>> >> >> >>>&= gt;>>> or breadth of the reviews that have been performed?
>= > >> >> >>>>>>>
>> >> &g= t;> >>>>>>> No - the original draft had a lot of ba= ckground material, much
>> >> >> >>>>>&= gt;> of
>> >> >> >>>>>> this
&= gt;> >> >> >>>>>>> has been condensed o= r removed, resulting in a smaller document.
>> >> >> &= gt;>>>>>
>> >> >> >>>>>&= gt;   That is indeed what I basically asked for, but I don't see = any
>> >> >> >>>>>> evidence of it:<= br>>> >> >> >>>>>>
>> >>= >> >>>>>> - diff(07,08)  48 lines changed or = deleted;  53 lines changed or
>> >> >> added
&= gt;> >> >> >>>>>> - diff(06,07)  = ; 8 lines changed or deleted;  13 lines changed or
>> >>= ; >> added
>> >> >> >>>>>> - d= iff(05,06)  64 lines changed or deleted;  69 lines changed or
= >> >> >> >>>>>> added
>> >&= gt; >> >>>>>> - diff(04,05) 823 lines changed or de= leted; 864 lines changed or
>> >> >> >>>>&= gt;> added
>> >> >> >>>>>>
>= ;> >> >> >>>>>> (Need I go farther? That g= ets us back to March 2011...)
>> >> >> >>>>= ;>>
>> >> >> >>>>>>> (9) Ho= w solid is the WG consensus behind this document? Does it
>> >&= gt; >> >>>>>>> represent the strong concurrence = of a few individuals, with
>> >> >> >>>>&g= t;>> others being silent, or does the WG as a whole understand
>= ;> >> >> and agree with it?
>> >> >> &g= t;>>>>>>
>> >> >> >>>>&g= t;>> The document has WG support and there is consensus to publish.>> >> >> >>>>>>
>> >> = >> >>>>>>   This, IMHO, doesn't answer th= e question. :^(
>> >> >> >>>>>>
&= gt;> >> >> >>>>>>   Does it repr= esent the concurrence of a few individuals, or does
>> >> &g= t;> >>>>>> the WG as a whole understand and agree with= it?
>> >> >> >>>>>>
>> >= ;> >> >>>>>> For reference, my comments included= :
>> >> >> >>>>>> ]
>> >= > >> >>>>>> ] When I previously skimmed this doc= ument, I believed it
>> >> >> >>>>>>= contained only ] common ground: that AQM should drop/mark packets
>&= gt; >> >> >>>>>> without favoring small ] pac= kets, and that to whatever extent
>> >> >> >>>= ;>>> packet size _is_ considered, that ] should be a
>> &= gt;> >> transport-layer responsibility.
>> >> >&= gt; >>>>>> ]
>> >> >> >>>&g= t;>> ] Alas, when I read it carefully this week, I find that Bob is>> >> >> >>>>>> actually ] saying tha= t transport-layer should _only_ consider
>> >> >> >= >>>>> "congested bytes", not ] "congested pac= kets".
>> >> >> >>>>>> ]
>= ;> >> >> >>>>>> ] In fact, Bob openly endo= rses replacing TCP congestion-control
>> >> >> >>= ;>>>> with an ] algorithm which calculates "fair-share byt= es" and
>> >> >> >>>>>> doesn't= back off at all ] (even in the presence of 20% packet
>> >>= >> >>>>>> loss) unless you're already sending ] mo= re than this
>> >> >> "fair-share".
>&= gt; >> >> >>>>>> ]
>> >> >&= gt; >>>>>> ]    I do not believe that is t= he consensus of this WG; and I
>> >> >> believe
>= ;> >> >> >>>>>> if
>> >> &g= t;> >>>>>> ] that were the consensus it would exceed o= ur charter.
>> >> >> >>>>>> ]
>= ;> >> >> >>>>>> ] The draft contains a num= ber of things I _do_ support; and I'd
>> >> >> >>= ;>>>> be happy ] to support a considerably shorter draft which<= br>>> >> >> >>>>>> concentrates on the = AQM ] recommendation, omitting any
>> >> >> >>&g= t;>>> suggestions of modifying TCP congestion ] control.
>&g= t; >> >> >>>>>>
>> >> >>= >>>>>> and Philip's comments included:
>> >&= gt; >> >>>>>> ]
>> >> >> >&= gt;>>>> ] S2.2 I thought the numbered bullets could be better p= hrased,
>> >> >> >>>>>> something li= ke ] +this:- ]
>> >> >> >>>>>> ]&nbs= p;  1.  AQM algorithms such as RED SHOULD use packet-mode
>= > >> >> drop, ie they
>> >> >> >>= >>>> SHOULD NOT
>> >> >> >>>>&= gt;> ] +use byte-mode drop. The latter ] is more complex,
>> &g= t;> >> >>>>>> ]     &nb= sp;  it creates the perverse incentive to fragment segments
>>= ; >> >> into
>> >> >> >>>>>= > tiny
>> >> >> >>>>>> ] &nb= sp;      pieces and it is vulnerable to floods of = small-
>> >> >> >>>>>> ]  =       packets.
>> >> >> >&= gt;>>>> ]
>> >> >> >>>>>>= ; ]    2.  If a vendor has implemented byte-mode drop, = and an
>> >> >> operator
>> >> >>= >>>>>> has
>> >> >> >>>>= ;>> ]        turned it on, it is R= ECOMMENDED to turn it off, after
>> >> >> >>>= >>> establishing if
>> >> >> >>>>= >> ] +there are any implications on
>> >> >> >= ;>>>>> ] the relative performance of
>> >> &g= t;> >>>>>> ]       = applications using different packet sizes.
>> >> >> &= gt;>>>>> ]
>> >> >> >>>>>= ;> ]   3.  RED SHOULD NOT be turned off. Without RED, a d= rop tail
>> >> >> >>>>>> ] &nbs= p;      queue biases against large packets.
>= ;> >> >> >>>>>> ]
>> >> >= ;> >>>>>> ] Nit - the following paragraph shouldn't be= indented (Note well
>> >> >> >>>>>>= that
>> >> >> >>>>>> RED's...)
&= gt;> >> >> >>>>>> ]
>> >> &= gt;> >>>>>> ] S3.3
>> >> >> >&= gt;>>>> ] The section could be slightly clearer. Starting with = the second
>> >> >> >>>>>> para, whe= re you ] +start talking about something you don't
>> >> >= > >>>>>> recommend (ie you have to remember that ] +yo= u're talking about
>> >> >> >>>>>> t= he consequences of not following your recommendation).
>> >>= >> >>>>>> ]
>> >> >> >>= >>>> ] S3.3
>> >> >> >>>>>&= gt; ]    o  Also, if the network biases congestion noti= fication by
>> >> >> packet
>> >> >&= gt; >>>>>> size
>> >> >> >>>= ;>>> ]       it has to assume a base= line packet size--all proposed
>> >> >> >>>&g= t;>> algorithms
>> >> >> >>>>>>= ; ]       use the local MTU.  Then trans= ports have to guess which
>> >> >> link
>> &g= t;> >> >>>>>> was
>> >> >> = >>>>>> ]       congested an= d what its local MTU was, in order to know
>> >> >> ho= w to
>> >> >> >>>>>> ]  &n= bsp;    tailor their congestion response to that link.
&g= t;> >> >> >>>>>> ] So you're saying that f= or byte-mode drop, the network element
>> >> >> >&g= t;>>>> has to compare the ] +size of the current pkt with the M= TU, and
>> >> >> >>>>>> if it's 25* = smaller then reduce the ] +pkt loss probably by 25*?
>> >> &= gt;> >>>>>> And if the MTU was bigger, then the curren= t pkt would ] +be
>> >> >> >>>>>> dr= opped with greater probability? And both of these things
>> >&g= t; >> are hard to do.
>> >> >> >>>>&= gt;> ]
>> >> >> >>>>>> ] S3.4 (&a= mp; knock-on effect on 3.3) ] I think this could be better.
>> >= ;> >> >>>>>> ] I agree with your arguments in S3= .1 & 3.2 that dropping or
>> >> >> >>>>= ;>> marking should be ] +independent of pkt size.
>> >>= ; >> >>>>>> ] You now go into a couple of pages, wh= ich I think could be
>> >> >> >>>>>>= boiled down to a ] +paragraph, saying something like:- ] * the
>>= >> >> >>>>>> overall system (network + trans= port) has to be packet-size
>> >> >> >>>>&= gt;> dependent in ]
>> >> >> >>>>>&g= t; +order to drive out the right amount of traffic so the resource
>&= gt; >> >> >>>>>> becomes ]
>> >&g= t; >> >>>>>> +uncongested (since we assume all reso= urces are in practice byte
>> >> >> >>>>&g= t;> +rather
>> >> >> >>>>>> than = ] +packet limited) ] * from S3.1 and S3.2 the IETF is
>> >> = >> >>>>>> convinced that the network should notify = ] +independent of
>> >> >> packet-size.
>> &g= t;> >> >>>>>> ] * therefore the transport must a= ct dependent on packet-size.
>> >> >> >>>>= >> ]
>> >> >> >>>>>> ] It seem= s to me this is a necessary consequence of your earlier
>> >>= ; >> >>>>>> assumptions ] +/arguments.
>> = >> >> >>>>>> ]
>> >> >> = >>>>>> ] [On the other hand, if someone disagrees with th= e arguments and
>> >> >> >>>>>> thin= ks that the ] +network should notify dependent on
>> >> >= > >>>>>> packet-size, then it follows that the ] +tran= sport can act
>> >> >> >>>>>> indepe= ndent of
>> >> >> >>>>>> packet- siz= e.] ] ] I think in S3.3 you're trying to make another
>> >> = >> >>>>>> argument (?):-  ] * we can either do= packet-size biasing in the
>> >> >> >>>>&= gt;> network element or on the end host ] +transport (see argument
&g= t;> >> >> >>>>>> above) ] * packet-size bi= asing in the network is quite tricky,
>> >> >> >>= ;>>>> because then both the ] +network element & the transp= ort have to
>> >> >> >>>>>> make som= e guesses about MTU - whereas ]
>> >> >> >>>&= gt;>> +with packet-size biasing in the transport, neither network
= >> >> >> >>>>>> +element
>> &g= t;> >> >>>>>> nor ] +transport needs to know wha= t the MTU is.
>> >> >> >>>>>> ] * it= is also easier to implement packet-size biasing in the
>> >>= ; >> >>>>>> transport than in ] +the network.
&g= t;> >> >> >>>>>> ]
>> >> &g= t;> >>>>>> ] On the last bullet, I didn't really follo= w your argument in
>> >> >> S3.5.
>> >>= >> >>>>>> Might be ] +easier to follow if S3.5 als= o talked about how a
>> >> >> >>>>>>= network element would take ] +account of pkt size? Also, does the
>&= gt; >> >> >>>>>> following argument also appl= y?:
>> >> >> >>>>>> ] * if pkt-size = biasing is done in the transport, then the work
>> >> >&g= t; >>>>>> (to do the ] +biasing) is spread over many end = hosts, ] * whereas
>> >> >> >>>>>> i= f pkt-size biasing is done in the network, then the work is ]
>> &= gt;> >> >>>>>> +concentrated in just the congest= ed network element, which has to
>> >> >> >>>= >>> operate on all ] +the traffic at line speed.
>> >&= gt; >> >>>>>>
>> >> >> >>= ;>>>>   (Has there perhaps been some confusion about = what went into the
>> >> >> >>>>>> -= 08
>> >> >> >>>>>> version?)
>= > >> >> >>>>>>
>> >> >&g= t; >>>>>> --
>> >> >> >>>&g= t;>> John Leslie <john@jlc.net= >
>> >> >> >>>>>>
>> >= ;> >> >>>>>>
>> >> >> >&= gt;>>>
>> >> >> >>>>
>> = >> >> >>> ____________________________________________= ____________________
>> >> >> >>> Bob Briscoe= ,            &n= bsp;            = ;       BT Innovate & Design
>> = >> >> >>>
>> >> >> >>
&g= t;> >> >> >
>> >> >
>> >>= ; > ________________________________________________________________
= >> >> > Bob Briscoe,      &nbs= p;            &= nbsp;            BT = Innovate & Design
>> >> >
>> >
>>= ; > ________________________________________________________________
= >> > Bob Briscoe,        &= nbsp;           &nbs= p;           BT Innovate = & Design
>
> _____________________________________________= ___________________
> Bob Briscoe,      = ;            &n= bsp;            = ; BT Innovate & Design

______________________________= __________________________________
Bob Briscoe,    &= nbsp;           &nbs= p;            &= nbsp;  BT Innovate & Design

= --_000_9510D26531EF184D9017DF24659BB87F33DD2D3573EMV65UKRDdoma_-- From jukka.manner@aalto.fi Mon Oct 15 07:31:42 2012 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 B7ACB11E80E7; Mon, 15 Oct 2012 07:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyf+dDOB3v0q; Mon, 15 Oct 2012 07:31:39 -0700 (PDT) Received: from mx05.aalto.fi (mx05.aalto.fi [130.233.222.104]) by ietfa.amsl.com (Postfix) with ESMTP id CF1BB21F86D3; Mon, 15 Oct 2012 07:31:38 -0700 (PDT) Received: from mx05.aalto.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6B4AF808C4; Mon, 15 Oct 2012 17:31:37 +0300 (EEST) Received: from EXHUB03.org.aalto.fi (ex-hub03.org.aalto.fi [130.233.222.116]) by mx05.aalto.fi (Postfix) with ESMTP id 3D818808AD; Mon, 15 Oct 2012 17:31:37 +0300 (EEST) Received: from EXMDB04.org.aalto.fi ([169.254.1.56]) by EXHUB03.org.aalto.fi ([130.233.222.116]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 17:31:07 +0300 From: Manner Jukka To: Bob Briscoe Thread-Topic: [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest Thread-Index: AQHNp6lsRPJg5MIAXUex2DyM9GzvLZez196AgAZEzWCAACUigA== Date: Mon, 15 Oct 2012 14:31:06 +0000 Message-ID: <3A5279D338C75C40B4B3DA15BA47D6330B703707@EXMDB04.org.aalto.fi> References: <20120815190728.GQ15012@verdi> <502BFB47.7010803@erg.abdn.ac.uk> <791AD3077F94194BB2BDD13565B6295D45A6212A@PALLENE.office.hd> <15181_1346848013_5047450C_15181_645_1_50474507.3090706@erg.abdn.ac.uk> <3A5279D338C75C40B4B3DA15BA47D6330B616BD2@EXMDB04.org.aalto.fi> <201209051541.q85FfCs0019699@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F33D793B351@EMV65-UKRD.domain1.systemhost.net> <3A5279D338C75C40B4B3DA15BA47D6330B69261A@EXMDB04.org.aalto.fi> <9510D26531EF184D9017DF24659BB87F33D793B845@EMV65-UKRD.domain1.systemhost.net> <04AC95B5-A2B1-4DD2-B765-E20A4C1A69A3@aalto.fi> <3A5279D338C75C40B4B3DA15BA47D6330B6E81E4@EXMDB04.org.aalto.fi> <9510D26531EF184D9017DF24659BB87F33DCE34251@EMV65-UKRD.domain1.systemhost.net> <201210041126.q94BQ0hx002951@bagheera.jungle.bt.co.uk> <1904eec816d080f886f5bf8685358ddc.squirrel@www.erg.abdn.ac.uk> <201210101525.q9AFP4Mi008013@bagheera.jungle.bt.co.uk> <3A5279D338C75C40B4B3DA15BA47D6330B6FC2BB@EXMDB04.org.aalto.fi> <201210111208.q9BC8BAU012305@bagheera.jungle.bt.co.uk> <3A5279D338C75C40B4B3DA15BA47D6330B6FD072@EXMDB04.org.aalto.fi> <201210150917.q9F9HwIG006958@bagheera.jungle.bt.co.uk> In-Reply-To: <201210150917.q9F9HwIG006958@bagheera.jungle.bt.co.uk> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.152.186.160] Content-Type: text/plain; charset="us-ascii" Content-ID: <5B93A89AA980024EAA611B3287112669@aalto.fi> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , tsvwg IETF list Subject: Re: [tsvwg] [REVISED I-D]: Document writeup for draft-ietf-tsvwg-byte-pkt-congest 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, 15 Oct 2012 14:31:42 -0000 Hi, works with me. :) If we are done, then I can submit a revision asap. Jukka On Oct 15, 2012, at 12:17 PM, Bob Briscoe wrote: > Jukka, >=20 > OK, 2nd attempt below, annotated with HTML formatting. Rather than predic= ting the future, I have confined the text to the lack of universal deployme= nt in the present. If you're happy with this, pls go ahead and re-issue the= draft. >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 3.4. Permanent Partial Deployment of AQM >=20 > In overview, the argument in this section runs as follows:=20 > * Because the network does will not and cannot always drop packets in pro= portion to their size, it shouldn't be given the task of making drop signal= s depend on packet size at all.=20 > * Transports on the other hand don't always want to make their rate respo= nse proportional to the size of dropped packets, but if they want to, they = always can. >=20 > The argument is similar to the end-to-end argument that says "Don't do X = in the network if end-systems can do X by themselves, and they want to be a= ble to choose whether to do X anyway." Actually the following argument is s= tronger; in addition it says "Don't give the network task X that could be d= one by the end-systems, if X is not won't ever be deployed on all network n= odes, and end-systems won't be able to tell whether their network is doing = X, or whether they need to do X themselves." In this case, the X in questio= n is "making the response to congestion depend on packet size".=20 >=20 > We will now re-run this argument taking each step in more depth. The argu= ment applies solely to drop, not to ECN marking.=20 >=20 > A queue drops packets for either of two reasons: a) to signal to host con= gestion controls that they should reduce the load and b) because there is n= o buffer left to store the packets. Active queue management tries to use dr= ops as a signal for hosts to slow down (case a) so that drop due to buffer = exhaustion (case b) should not be necessary.=20 >=20 > No-one expects AQM is not to ever be universally deployed in every queue = in the Internet; many cheap ethernet bridges, software firewalls, NATs on c= onsumer devices, etc implement simple tail-drop buffers. and, eEven if AQM = were universal, it has to be able to cope with buffer exhaustion (by switch= ing to a behaviour like tail-drop), in order to cope with unresponsive or e= xcessive transports. Therefore For both these reasons networks will often b= e dropping packets as a last resort (case b) rather than under AQM control = (case a). >=20 > When buffers are exhausted (case b), they don't naturally drop packets in= proportion to their size. The network can only reduce the probability of d= ropping smaller packets if it has enough space to store them somewhere whil= e it waits for a larger packet that it can drop. If the buffer is exhausted= , it does not have this choice. Admittedly tail-drop does naturally drop so= mewhat fewer small packets, but exactly how few depends more on the mix of = sizes than the size of the packet in question. Nonetheless, in general, if = we wanted networks to do size-dependent drop, we would need universal deplo= yment of (packet-size dependent) AQM code, which is currently unrealistic. >=20 > A host transport cannot know whether any particular drop was a deliberate= signal from an AQM or a sign of a queue shedding packets due to buffer exh= austion. Therefore, because the network cannot universally do size-dependen= t drop, it should not do it all.=20 >=20 > Whereas universality is desirable in the network, diversity is desirable = between different transport layer protocols - some, like NewReno TCP [RFC56= 81], may not choose to make their rate response proportionate to the size o= f each dropped packet, while others will (e.g. TFRC-SP [RFC4828]). > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 > Bob >=20 > At 13:34 11/10/2012, Manner Jukka wrote: >> Hi, >>=20 >> Yeah, please at the point about cheap devices, still, I wonder what the = cost of AQM is on those devices. Maybe 1 cnt in mass production? Thus, I st= ill wonder if it is worth arguing something about the future that strongly. >>=20 >> Sorry, but the same goes for AQM in general, and where it is, or will no= t be deployed. I understand technical reasons why not something is feasible= , but business or monetary reasons can change very quickly. ;) >>=20 >> Jukka >>=20 >> On Oct 11, 2012, at 3:08 PM, Bob Briscoe wrote: >>=20 >> > Jukka, >> >=20 >> > What I had in mind is all low level buffers in cheap pure L2 devices, = in cheap NATs etc. I was going to list some of these, but instead chose to = say "no-one expects AQM to be universally deployed". This clearly missed th= e mark. >> >=20 >> > Should we include some of these concrete examples of where AQM won't b= e deployed instead? >> >=20 >> > [I've cc'd the list, given we're starting to wordsmith significantly n= ew text added since WG last call.] >> >=20 >> >=20 >> > Bob >> >=20 >> > At 20:04 10/10/2012, Manner Jukka wrote: >> >> Hi, looked good to me. Just one comment, I wouldn't put that much emp= hasis on what is a probably state of things, e.g. >> >>=20 >> >> "no-one expects AQM to ever be .." > in the future it might, we don'= t know, and since the paragraph says that it doesn't matter anyway, I would= formulate this paragraph a bit towards that we have partial deployment now= and even with a full deployment, ... >> >>=20 >> >> and similarly with the unrealistic deployment of AQM in the subsequen= t paragraph. >> >>=20 >> >> cheers, >> >> Jukka >> >>=20 >> >> On Oct 10, 2012, at 6:25 PM, Bob Briscoe wrote: >> >>=20 >> >> > Phil, >> >> > >> >> > Sorry for delay, my round-robin scheduler is taking so long to get = round all the tasks that I keep finding dead robins (that reminds me of a b= ike ride my grandmother took. On her return, she said there were a worrying= ly large number of robins run over on the roads. It turned out that she had= been going round the same small triangle of roads multiple times). >> >> > >> >> > I've done a complete re-write of 3.4. I hope you will agree that it= really is a motivating argument now and it can stay where it is - it is no= t just a preamble. >> >> > >> >> > I've gone back to the very first version of 3.4 I wrote and I now r= ealise that I had written the core of the argument so badly that even I for= got what it was meant to say when we started editing it. In the draft-08 ve= rsion, the original meaning is lost and in your re-wording it is entirely l= ost. The link with the draft-08 version is nearly unrecognisable, but it's = the argument I intended here. >> >> > >> >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> > 3.4. Permanent Partial Deployment of AQM >> >> > >> >> > In overview, the argument in this section runs as follows: >> >> > * Because the network will not and cannot always drop packets in pr= oportion to their size, it shouldn't be given the task of making drop signa= ls depend on packet size at all. >> >> > * Transports on the other hand don't always want to make their rate= response proportional to the size of dropped packets, but if they want to,= they always can. >> >> > >> >> > The argument is similar to the end-to-end argument that says "Don't= do X in the network if end-systems can do X by themselves, and they want t= o be able to choose whether to do X anyway." Actually the following argumen= t is stronger; in addition it says "Don't give the network task X that coul= d be done by the end-systems, if X won't ever be deployed on all network no= des, and end-systems won't be able to tell whether their network is doing X= , or whether they need to do X themselves." In this case, the X in question= is "making the response to congestion depend on packet size". >> >> > >> >> > We will now re-run this argument taking each step in more depth. Th= e argument applies solely to drop, not ECN marking. >> >> > >> >> > A queue drops packets for either of two reasons: a) to signal to ho= st congestion controls that they should reduce the load and b) because ther= e is no buffer left to store the packets. Active queue management tries to = use drops as a signal for hosts to slow down (case a) so that drop due to b= uffer exhaustion (case b) should not be necessary. >> >> > >> >> > No-one expects AQM to ever be universally deployed in every queue i= n the Internet; and, even if AQM were universal, it has to be able to cope = with buffer exhaustion (by switching to a behaviour like tail-drop), in ord= er to cope with unresponsive or excessive transports. Therefore networks wi= ll often be dropping packets as a last resort (case b) rather than under AQ= M control (case a). >> >> > >> >> > When buffers are exhausted (case b), they don't naturally drop pack= ets in proportion to their size. The network can only reduce the probabilit= y of dropping smaller packets if it has enough space to store them somewher= e while it waits for a larger packet that it can drop. If the buffer is exh= austed, it does not have this choice. Admittedly tail-drop does naturally d= rop somewhat fewer small packets, but exactly how few depends more on the m= ix of sizes than the size of the packet in question. Nonetheless, in genera= l, if we wanted networks to do size-dependent drop, we would need universal= deployment of (packet-size dependent) AQM code, which is unrealistic. >> >> > >> >> > A host transport cannot know whether any particular drop was a deli= berate signal from an AQM or a sign of a queue shedding packets due to buff= er exhaustion. Therefore, because the network cannot universally do size-de= pendent drop, it should not do it all. >> >> > >> >> > Whereas universality is desirable in the network, diversity is desi= rable between different transport layer protocols - some, like NewReno TCP = [RFC5681], may not choose to make their rate response proportionate to the = size of each dropped packet, while others will (e.g. TFRC-SP [RFC4828]). >> >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> > >> >> > >> >> > >> >> > >> >> > Bob >> >> > >> >> > At 13:13 04/10/2012, gorry@erg.abdn.ac.uk wrote: >> >> >> That would be brilliant! >> >> >> >> >> >> Gorry >> >> >> >> >> >> > Will try to look at this later today. >> >> >> > >> >> >> > >> >> >> > Bob >> >> >> > >> >> >> > At 10:42 02/10/2012, philip.eardley@bt.com wrote: >> >> >> >>Think the token is with bob >> >> >> >> >> >> >> >>Re your comment - yes, I think you could move 3.4 to the end of = S3 - >> >> >> >>or to the start - and do some re-phrasing, maybe something like = I tried. >> >> >> >> >> >> >> >>-----Original Message----- >> >> >> >>From: Manner Jukka [ mailto:jukka.manner@aalto.fi] >> >> >> >>Sent: 01 October 2012 20:18 >> >> >> >>To: Eardley,PL,Philip,DUB8 R; Briscoe,RJ,Bob,DUB8 R >> >> >> >>Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst >> >> >> >>Subject: Re: [REVISED I-D]: Document writeup for >> >> >> >>draft-ietf-tsvwg-byte-pkt-congest >> >> >> >> >> >> >> >>Phil, Bob, can we close this finally? It's three weeks now since >> >> >> >>this previous message. >> >> >> >> >> >> >> >>Jukka >> >> >> >> >> >> >> >>On Sep 10, 2012, at 4:42 PM, Jukka Manner wrote: >> >> >> >> >> >> >> >> > Ack, I'm getting there...;) >> >> >> >> > >> >> >> >> > So, we could move 3.4 at the end of Section 3 and rephrase it= to >> >> >> >> not talk about scaling per se, but rather about how Req 2.2 >> >> >> >> eventually leads to Req 2.3? >> >> >> >> > >> >> >> >> > Jukka >> >> >> >> > >> >> >> >> > On Sep 7, 2012, at 4:07 PM, >> >> >> >> > wrote: >> >> >> >> > >> >> >> >> >> 3.4 is, in my mind, completely different from 3.1, 3.2, 3.3 = and 3.5. >> >> >> >> >> >> >> >> >> >> 3.1, 3.2, 3.3 and 3.5 present motivating arguments for Recom= mendation >> >> >> >> >> 2.2 & a lesser extent 2.3 >> >> >> >> >> 3.4 makes doesn't make a motivating argument - it explains t= hat Rec >> >> >> >> >> 2.2 & 2.3 come as a pair (if you recommend one, then inevita= bly you >> >> >> >> >> recommend the other) (delta some politeness about TCP) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> >> >> From: Manner Jukka [ mailto:jukka.manner@aalto.fi] >> >> >> >> >> Sent: 07 September 2012 13:24 >> >> >> >> >> To: Eardley,PL,Philip,DUB8 R >> >> >> >> >> Cc: Briscoe,RJ,Bob,DUB8 R; ; >> >> >> >> >> >> >> >> >> >> Subject: Re: [REVISED I-D]: Document writeup for >> >> >> >> >> draft-ietf-tsvwg-byte-pkt-congest >> >> >> >> >> >> >> >> >> >> Hi, I'm trying to follow your reasoning, with little luck. ;= ) >> >> >> >> >> >> >> >> >> >> After having read Section 3 again, I could think of a few >> >> >> >> updates, but I'm not fully following what you want to see: >> >> >> >> >> >> >> >> >> >> - S3.5 is kind of small and lonely by itself. It could be ei= ther >> >> >> >> longer or merged somewhere. Not a major issue though and could = remain as >> >> >> >> is. >> >> >> >> >> >> >> >> >> >> - S3.3: Yes, probably could be turned upside down, good firs= t, >> >> >> >> bad later. Don't have a strong opinion. >> >> >> >> >> >> >> >> >> >> - S3.4: Here the scaling is used many times and in the title= , >> >> >> >> although we talk about the end host side. This could be rephras= ed >> >> >> >> and slightly reworded to talk about hosts and their operation >> >> >> >> altogether. Also the word scaling can turn the readers expectat= ion >> >> >> >> into the wrong direction. >> >> >> >> >> >> >> >> >> >> - S3 altogether: It would help to have introductory text abo= ut >> >> >> >> networks vs. end host side, but I fail to see why (& how) to >> >> >> >> restructure everything. >> >> >> >> >> >> >> >> >> >> cheers, >> >> >> >> >> Jukka >> >> >> >> >> >> >> >> >> >> On Sep 6, 2012, at 6:18 PM, >> >> >> >> wrote: >> >> >> >> >> >> >> >> >> >>> Ps otherwise Bob's comments are fine, though I suggest for = S3.5 you >> >> >> >> >>> give more context (ie are you knocking down what you recomm= end >> >> >> >> >>> against, or building up what you recommend?) and in S3.3 t= hink >> >> >> >> >>> would be better if you re-structured slightly [first talk a= bout what >> >> >> >> >>> you like - penult para + 1st sentence of last para - then t= alk about >> >> >> >> >>> what you don't like - rest of text] >> >> >> >> >>> >> >> >> >> >>> From: Eardley,PL,Philip,DUB8 R >> >> >> >> >>> Sent: 06 September 2012 16:12 >> >> >> >> >>> To: Briscoe,RJ,Bob,DUB8 R; Manner Jukka >> >> >> >> >>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst >> >> >> >> >>> Subject: RE: [REVISED I-D]: Document writeup for >> >> >> >> >>> draft-ietf-tsvwg-byte-pkt-congest >> >> >> >> >>> >> >> >> >> >>> Thanks bob. Have now re-booted some state. >> >> >> >> >>> I don't like S3.4. My basic problem with it is that it isn'= t a >> >> >> >> "motivating argument" (S3 title). It's an explanation about the >> >> >> >> consequences of assuming either [option 1] do pkt-size biasing = in >> >> >> >> the transport; [option 2]; do pkt-size biasing in the nw. >> >> >> >> >>> Perhaps your effort to buy peace with those who won't chang= e >> >> >> >> TCP has obfuscated the basic point? >> >> >> >> >>> The title of S3.4 (Scaling...) and the early text "scaling >> >> >> >> argument" suggests that you're going to argue there is some rea= son >> >> >> >> why X scales as order N rather than N^2 or something like that = - >> >> >> >> which isn't what S3.4 is about. >> >> >> >> >>> >> >> >> >> >>> I actually think it would be better to put S3.4 at the star= t of >> >> >> >> S3 - it's background where you say there are 2 options. After t= hat, >> >> >> >> you can explain the reasons why option 1 [pkt biasing in the >> >> >> >> transport] is better - the reasons being:- S3.1 (security etc >> >> >> >> attacks if small pkts get preferential treatment), S3.2 (really= a >> >> >> >> side note to S3.1; ie doesn't really present a "motivating >> >> >> >> argument"), S3.3 (nw guessing MTU vs transport knowing pkt size= ), >> >> >> >> S3.5 (easier implementation). >> >> >> >> >>> >> >> >> >> >>> Something like... >> >> >> >> >>> The behaviour of the network and transport together needs t= o >> >> >> >> >>> alleviate congestion. We assume the network is bit-congesti= ble >> >> >> >> (currently packet-congestible resources are rate). Therefore >> >> >> >> overall the response of the {network + transport} should be the >> >> >> >> same for the same congestion - whether the congestion is caused= by >> >> >> >> a lot of small packets or a smaller number of larger packets. T= he >> >> >> >> implication is that the transport's behaviour should depend on >> >> >> >> whether the network takes account (or not) of packet size when = it >> >> >> >> generates congestion indications:- Case 1: If the network >> >> >> >> implements packet-mode drop, ie its algorithm treats all packet= s >> >> >> >> equally regardless of their size, then the transport should tak= e >> >> >> >> account of the size of the packet - in other words, the transpo= rt's >> >> >> >> congestion response should depend on the number of dropped byte= s. >> >> >> >> >>> Case 2: If the network implements byte-mode drop, ie its >> >> >> >> algorithm treats packets differently depending on their size, t= hen >> >> >> >> the transport should not take account of the size of the packet= - >> >> >> >> in other words, the transport's congestion response should depe= nd >> >> >> >> on the number of dropped packets. >> >> >> >> >>> >> >> >> >> >>> These cases are explained in more detail in sub-section bel= ow. >> >> >> >> >>> >> >> >> >> >>> In both cases the same discussion applies if packets are >> >> >> >> ECN-marked rather than dropped. >> >> >> >> >>> In the following sections we explain why Case 1 is preferab= le, >> >> >> >> and hence why we make the Recommendations of S2.2 and S3.3 >> >> >> >> (respectively, drop/mark pkts equally regardless of their size,= and >> >> >> >> the strength of the transport's response should be proportionat= e to >> >> >> >> the size of the dropped/marked pkt). >> >> >> >> >>> Note that TCP responds to dropped or marked packets, which = differs >> >> >> >> >>> from our recommendation for transports. However, we are not >> >> >> >> >>> recommending that TCP should be changed; to date it hasn't= been a >> >> >> >> >>> significant problem because most TCP implementations have = been >> >> >> >> used with similar packet sizes. But we do recommend that future >> >> >> >> transport protocols should respond to dropped or marked bytes = (as >> >> >> >> for example TFRC-SP [RFC4828]effectively does). >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> Sub-section >> >> >> >> >>> You could use much of S3.3, I suggest supplement with numer= ical >> >> >> >> >>> examples continuing S1.2 >> >> >> >> >>> -- >> >> >> >> >>> << This gives a get-out clause to any transport that isn't >> >> >> >> >>> packet-size dependent (e.g. current TCP). Lacking packet-si= ze >> >> >> >> >>> dependence just means they don't scale correctly with packe= t size - >> >> >> >> >>> but they are at liberty not to scale with packet size (part= icularly >> >> >> >> >>> given MTU growth isn't often being used to increase link ra= tes at >> >> >> >> >>> this stage in history).>> >> >> >> >> >>> >> >> >> >> >>> This is introducing a different point. it's saying that you= r >> >> >> >> recommendation 2 [drop/mark pkts equally regardless of their si= ze] >> >> >> >> is a really strong reco whilst recommendation 3 [strength of >> >> >> >> transport's response proportionate to the size of the >> >> >> >> dropped/marked pkt] is a much less important reco. I can see t= his >> >> >> >> might be true, but I don't think the i-d talks about this. >> >> >> >> >>> >> >> >> >> >>> -- >> >> >> >> >>> >> >> >> >> >>> From: Briscoe,RJ,Bob,DUB8 R >> >> >> >> >>> Sent: 05 September 2012 16:41 >> >> >> >> >>> To: Manner Jukka >> >> >> >> >>> Cc: tsvwg-chairs@ietf.org; Gorry Fairhurst; Eardley,PL,Phil= ip,DUB8 R >> >> >> >> >>> Subject: Re: [REVISED I-D]: Document writeup for >> >> >> >> >>> draft-ietf-tsvwg-byte-pkt-congest >> >> >> >> >>> >> >> >> >> >>> Jukka, >> >> >> >> >>> >> >> >> >> >>> I've repeated Phil's suggestions as quoted email then made = some >> >> >> >> alterations. >> >> >> >> >>> >> >> >> >> >>> Phil asked me to send this, then he will think about it. >> >> >> >> >>> >> >> >> >> >>> I'll respond about John Leslie's argument next... >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> 2.2. Recommendation on Encoding Congestion Notification >> >> >> >> >>> >> >> >> >> >>> [...] >> >> >> >> >>> >> >> >> >> >>> 1. AQM algorithms such as RED SHOULD use packet-mode drop= , ie they >> >> >> >> >>> SHOULD NOT use byte-mode drop. The latter is more comp= lex, >> >> >> >> >>> it creates the perverse incentive to fragment segments= into >> >> >> >> tiny >> >> >> >> >>> pieces and it is vulnerable to floods of small packets= . >> >> >> >> >>> >> >> >> >> >>> 2. If a vendor has implemented byte-mode drop, and an ope= rator has >> >> >> >> >>> turned it on, it is RECOMMENDED to turn it off, after >> >> >> >> establishing >> >> >> >> >>> if there are any implications on the relative performa= nce of >> >> >> >> >>> applications using different packet sizes. >> >> >> >> >>> >> >> >> >> >>> RED as a whole SHOULD NOT be turned off. Without RED, = a drop >> >> >> >> tail >> >> >> >> >>> queue biases against large packets >> >> >> >> >>> >> >> >> >> >>> [BB adds]: and it is vulner= able to >> >> >> >> floods >> >> >> >> >>> of small-packets. >> >> >> >> >>> >> >> >> >> >>> (I suggest the last para just qualifies item 2. It doesn't = warrant >> >> >> >> >>> another item number.) >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> [PE:] S3.3 >> >> >> >> >>> The section could be slightly clearer. Starting with the se= cond >> >> >> >> para, where you start talking about something you don't recomme= nd >> >> >> >> (ie you have to remember that you're talking about the conseque= nces >> >> >> >> of not following your recommendation). >> >> >> >> >>> >> >> >> >> >>> 3.3 Transport-Independent Network >> >> >> >> >>> >> >> >> >> >>> TCP congestion control ensures that flows competing for th= e same >> >> >> >> >>> resource each maintain the same number of segments in fligh= t, >> >> >> >> >>> irrespective of segment size. So under similar conditions,= flows >> >> >> >> >>> with different segment sizes will get different bit-rates. >> >> >> >> >>> >> >> >> >> >>> [OLD:] >> >> >> >> >>> One motivation for the network biasing congestion notifica= tion by >> >> >> >> >>> packet size is to counter this effect and try to equalise t= he bit- >> >> >> >> >>> rates of flows with different packet sizes. >> >> >> >> >>> [SUGGESTED:] >> >> >> >> >>> To counter this effect it seems tempting not to follow our >> >> >> >> >>> recommendation, and instead for the network to bias conges= tion >> >> >> >> >>> notification by packet size in order to equalise the bit-r= ates of >> >> >> >> >>> flows with different packet sizes. >> >> >> >> >>> [CONTINUE AS BEFORE:] >> >> >> >> >>> However, in order to do this, the queuing a= lgorithm >> >> >> >> >>> has to make assumptions about the transport, which become = embedded >> >> >> >> >>> in the network. Specifically: >> >> >> >> >>> [...] >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> S3.3 >> >> >> >> >>> o The queuing algorithm has to assume how aggressively th= e >> >> >> >> transport >> >> >> >> >>> will respond to congestion (see Section 4.2.4). If the= network >> >> >> >> >>> assumes the transport responds as aggressively as TCP N= ewReno, >> >> >> >> it >> >> >> >> >>> will be wrong for Compound TCP and differently wrong fo= r Cubic >> >> >> >> >>> TCP, etc. To achieve equal bit-rates, each transport t= hen has >> >> >> >> to >> >> >> >> >>> guess what assumption the network made, and work out ho= w to >> >> >> >> >>> replace this assumed aggressiveness with its own aggres= siveness. >> >> >> >> >>> o Also, if the network biases congestion notification by = packet >> >> >> >> size >> >> >> >> >>> it has to assume a baseline packet size--all proposed a= lgorithms >> >> >> >> >>> use the local MTU. Then transports have to guess which= link was >> >> >> >> >>> congested and what its local MTU was, in order to know = how to >> >> >> >> >>> tailor their congestion response to that link. >> >> >> >> >>> >> >> >> >> >>> So you're saying that for byte-mode drop, the network eleme= nt >> >> >> >> has to compare the size of the current pkt with the MTU, and if >> >> >> >> it's 25* smaller then reduce the pkt loss probably by 25*? And = if >> >> >> >> the MTU was bigger, then the current pkt would be dropped with >> >> >> >> greater probability? And both of these things are hard to do. >> >> >> >> >>> >> >> >> >> >>> [BB]: SUGGESTED REPLACEMENT to 2nd bullet: >> >> >> >> >>> >> >> >> >> >>> o Also, if the network biases congestion notification by = packet >> >> >> >> size >> >> >> >> >>> it has to assume a baseline packet size--all proposed a= lgorithms >> >> >> >> >>> use the local MTU (for example see the byte-mode loss >> >> >> >> probability >> >> >> >> >>> formula in Table 1). Then if the non-Reno transports m= entioned >> >> >> >> above >> >> >> >> >>> are trying to reverse engineer what the network assumed= , they >> >> >> >> also >> >> >> >> >>> have to guess the MTU of the congested link. >> >> >> >> >>> >> >> >> >> >>> [Aside for Phil: The byte-mode algo uses MTU as its baselin= e because >> >> >> >> >>> a link cannot send a packet bigger than its MTU so the algo= won't >> >> >> >> >>> ever give a drop probability >1).] >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> S3.4 (& knock-on effect on 3.3) >> >> >> >> >>> I think this could be better. >> >> >> >> >>> I agree with your arguments in S3.1 & 3.2 that dropping or >> >> >> >> marking should be independent of pkt size. >> >> >> >> >>> You now go into a couple of pages, which I think could be b= oiled >> >> >> >> >>> down to a paragraph, saying something like:- >> >> >> >> >>> * the overall system (network + transport) has to be packet= -size >> >> >> >> >>> dependent in order to drive out the right amount of traffic= so the >> >> >> >> >>> resource becomes uncongested (since we assume all resources= are in >> >> >> >> >>> practice byte rather than packet limited) >> >> >> >> >>> * from S3.1 and S3.2 the IETF is convinced that the network >> >> >> >> should notify independent of packet-size. >> >> >> >> >>> * therefore the transport must act dependent on packet-size= . >> >> >> >> >>> >> >> >> >> >>> It seems to me this is a necessary consequence of your earl= ier >> >> >> >> assumptions /arguments. >> >> >> >> >>> >> >> >> >> >>> [BB:] This isn't at all obvious. Until I worked it through,= it >> >> >> >> wasn't obvious to me. I think it needs to be spelled out. >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> [On the other hand, if someone disagrees with the arguments= and >> >> >> >> >>> thinks that the network should notify dependent on packet-s= ize, then >> >> >> >> >>> it follows that the transport can act independent of packet= -size.] >> >> >> >> >>> >> >> >> >> >>> I think in S3.3 you're trying to make another argument (?):= - >> >> >> >> >>> * we can either do packet-size biasing in the network eleme= nt or on >> >> >> >> >>> the end host transport (see argument above) >> >> >> >> >>> * packet-size biasing in the network is quite tricky, becau= se >> >> >> >> then both the network element & the transport have to make some >> >> >> >> guesses about MTU - whereas with packet-size biasing in the >> >> >> >> transport, neither network element nor transport needs to know = what the >> >> >> >> MTU is. >> >> >> >> >>> * it is also easier to implement packet-size biasing in the >> >> >> >> transport than in the network. >> >> >> >> >>> >> >> >> >> >>> [BB] ...and all the other arguments about vulnerability to >> >> >> >> flooding etc, transport-independence etc. >> >> >> >> >>> >> >> >> >> >>> Our argument is sort of like how Phil summarises it, but wi= th >> >> >> >> an added nuance. It's also saying no-one has to do packet-size >> >> >> >> biasing anyway. It's not saying "The transport should given the >> >> >> >> network shouldn't". It's saying "*If the transport wants to cla= im >> >> >> >> to be scalable wrt packet size* it should if the network should= n't". >> >> >> >> >>> >> >> >> >> >>> This gives a get-out clause to any transport that isn't >> >> >> >> packet-size dependent (e.g. current TCP). Lacking packet-size >> >> >> >> dependence just means they don't scale correctly with packet si= ze - >> >> >> >> but they are at liberty not to scale with packet size (particul= arly >> >> >> >> given MTU growth isn't often being used to increase link rates = at >> >> >> >> this stage in history). >> >> >> >> >>> >> >> >> >> >>> None of what Phil says convinces me we could say 3.4 (or 3.= 3) >> >> >> >> any more briefly or differently. It's easier to summarise what = you >> >> >> >> understand having read something. But that's not the same as >> >> >> >> writing the thing that helped you understand. There doesn't see= m to >> >> >> >> be any argument for why anything needs to be changed, so I'm go= ing >> >> >> >> to leave it as is, unless pushed. >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> On the last bullet, I didn't really follow your argument in >> >> >> >> S3.5. Might be easier to follow if S3.5 also talked about how a >> >> >> >> network element would take account of pkt size? >> >> >> >> >>> Also, does the following argument also apply?: >> >> >> >> >>> * if pkt-size biasing is done in the transport, then the wo= rk (to do >> >> >> >> >>> the biasing) is spread over many end hosts, >> >> >> >> >>> * whereas if pkt-size biasing is done in the network, then = the >> >> >> >> work is concentrated in just the congested network element, whi= ch >> >> >> >> has to operate on all the traffic at line speed. >> >> >> >> >>> >> >> >> >> >>> [BB]: 3.5. Implementation Efficiency >> >> >> >> >>> >> >> >> >> >>> [ADD:] >> >> >> >> >>> Biasing against large packets typically requires an extra = multiply >> >> >> >> >>> and divide in the network (see the example byte-mode drop >> >> >> >> formula in table 1). >> >> >> >> >>> [CONTINUE AS BEFORE:] >> >> >> >> >>> Allowing for packet size at the transport rather than in t= he >> >> >> >> >>> network ensures that neither the network nor the transport= needs to >> >> >> >> >>> do a multiply operation--multiplication by packet size is >> >> >> >> >>> effectively achieved as a repeated add when the transport = adds to >> >> >> >> >>> its count of marked bytes as each congestion event is fed = to it. >> >> >> >> >>> [ADD:] >> >> >> >> >>> Also the work to do the biasing is spread over many hosts,= rather >> >> >> >> >>> than concentrated in just the congested network element. >> >> >> >> >>> [CONTINUE AS BEFORE:] >> >> >> >> >>> These = aren't >> >> >> >> >>> principled reasons in themselves, but they are a happy cons= equence >> >> >> >> >>> of the other principled reasons. >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> Bob >> >> >> >> >>> >> >> >> >> >>> At 13:36 05/09/2012, Manner Jukka wrote: >> >> >> >> >>> >> >> >> >> >>> Hi Bob, >> >> >> >> >>> >> >> >> >> >>> Since Phil is your colleague at BT, even at Ipswich (?), ca= n >> >> >> >> you check those and agree with Phil how to go forward? Some of >> >> >> >> those are clear, others need discussion with Phil. >> >> >> >> >>> >> >> >> >> >>> Gorry, on point 2) below, I don't follow Leslie's arguments= . I >> >> >> >> asked from him detailed comments and resolutions months ago, an= d nothing >> >> >> >> came. >> >> >> >> >>> >> >> >> >> >>> cheers, >> >> >> >> >>> Jukka >> >> >> >> >>> >> >> >> >> >>> On Sep 5, 2012, at 3:26 PM, Gorry Fairhurst wrote: >> >> >> >> >>> >> >> >> >> >>>> Bob and Jukka, >> >> >> >> >>>> >> >> >> >> >>>> I think I need your help to resolve this... Some of the >> >> >> >> comments raised by John Leslie appear to have substance, and I'= m >> >> >> >> not sure what you plan to do to address these. >> >> >> >> >>>> >> >> >> >> >>>> It would be good to do something quick so that I can compl= ete >> >> >> >> the submission to the IESG. >> >> >> >> >>>> >> >> >> >> >>>> The issues I particularly note are: >> >> >> >> >>>> >> >> >> >> >>>> 1) This contribution from Phil appears to be within scope = and >> >> >> >> it seems may have been overlooked (sorry): >> >> >> >> >>>> http://www.ietf.org/mail-archive/web/tsvwg/current/msg1123= 4.html >> >> >> >> >>>> >> >> >> >> >>>> 2) Can you be clear here about what is actually been said = - >> >> >> >> because the point below seems to be a misunderstanding of langu= age >> >> >> >> to me, and I hoped we did not claim this: >> >> >> >> >>>> >> >> >> >> >>>>>> ] Alas, when I read it carefully this week, I find that = Bob is >> >> >> >> >>>>>> actually ] saying that transport-layer should _only_ con= sider >> >> >> >> >>>>>> "congested bytes", not ] "congested packets". >> >> >> >> >>>>>> ] >> >> >> >> >>>> >> >> >> >> >>>> 3) You'll need to post the updated draft and send a note t= o >> >> >> >> the group to confirm that the new version indeed concludes the >> >> >> >> WGLC. I'll add a note to the writeup to indicate the draft cont= ent >> >> >> >> has been stable since Oct 2011. >> >> >> >> >>>> >> >> >> >> >>>> Gorry (with my TSVWG Documnent Shepherd hat) >> >> >> >> >>>> cc: Co-Chairs for info. >> >> >> >> >>>> >> >> >> >> >>>>> >> >> >> >> >>>>>> -----Original Message----- >> >> >> >> >>>>>> From: Gorry Fairhurst [ mailto:gorry@erg.abdn.ac.uk] >> >> >> >> >>>>>> Sent: Mittwoch, 15. August 2012 21:41 >> >> >> >> >>>>>> To: tsvwg chair >> >> >> >> >>>>>> Subject: Fwd: Re: [tsvwg] FYI: Document writeup for >> >> >> >> >>>>>> draft-ietf-tsvwg- byte-pkt-congest >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> Hi guys, >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> Apart form the usual rhetoric, there are some points her= e that we >> >> >> >> >>>>>> should note as chairs. What are you own thoughts? And wa= s >> >> >> >> >>>>>> anything noted at the IETF in Vancouver concerning this = draft? >> >> >> >> >>>>>> >> >> >> >> >>>>>> Gorry >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> -------- Original Message -------- >> >> >> >> >>>>>> Subject: Re: [tsvwg] FYI: Document writeup for >> >> >> >> >>>>>> draft-ietf-tsvwg-byte- pkt-congest >> >> >> >> >>>>>> Date: Wed, 15 Aug 2012 15:07:28 -0400 >> >> >> >> >>>>>> From: John Leslie >> >> >> >> >>>>>> To: Gorry Fairhurst >> >> >> >> >>>>>> CC: tsvwg@ietf.org >> >> >> >> >>>>>> >> >> >> >> >>>>>> Gorry Fairhurst wrote: >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> The following document has been revised after receiving >> >> >> >> WGLC comments. >> >> >> >> >>>>>> >> >> >> >> >>>>>> The changes are mostly refreshing a document scheduled= to >> >> >> >> >>>>>> expire this month. >> >> >> >> >>>>>> >> >> >> >> >>>>>>> No issues were found: >> >> >> >> >>>>>> >> >> >> >> >>>>>> Is that with WGC-hat-on? >> >> >> >> >>>>>> >> >> >> >> >>>>>> Neither my issues nor Philip Eardley's comments were a= ddressed. >> >> >> >> >>>>>> In fact, not even the changes Bob Briscoe mentioned on-l= ist have >> >> >> >> >>>>>> been included. >> >> >> >> >>>>>> >> >> >> >> >>>>>>> As required by RFC 4858, this is the current template f= or the >> >> >> >> >>>>>> Document >> >> >> >> >>>>>>> Shepherd Write-Up. >> >> >> >> >>>>>>> ... >> >> >> >> >>>>>>> (1) What type of RFC is being requested (BCP, Proposed = Standard, >> >> >> >> >>>>>>> Internet Standard, Informational, Experimental, or Hist= oric)? >> >> >> >> >>>>>>> Why is this the proper type of RFC? Is this type of RFC >> >> >> >> >>>>>>> indicated in the title page header? >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> This document is intended as BCP. (This was discussed a= t IETF-81 >> >> >> >> >>>>>>> and that the status changed from Informational to BCP s= ince it >> >> >> >> >>>>>>> provides guidance to implementors and people configurin= g >> >> >> >> routers and hosts). >> >> >> >> >>>>>> >> >> >> >> >>>>>> Thank you for finally answering my question about BCP = status. >> >> >> >> >>>>>> >> >> >> >> >>>>>>> ... >> >> >> >> >>>>>>> Working Group Summary >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> There was consensus to publish this as a WG document an= d >> >> >> >> >>>>>>> agreement at >> >> >> >> >>>>>>> IETF-82 that the document was now complete. >> >> >> >> >>>>>> >> >> >> >> >>>>>> Was that reviewed on-list? >> >> >> >> >>>>>> >> >> >> >> >>>>>>> ... >> >> >> >> >>>>>>> (3) Briefly describe the review of this document that w= as >> >> >> >> >>>>>>> performed >> >> >> >> >>>>>> by >> >> >> >> >>>>>>> the Document Shepherd. If this version of the document = is not >> >> >> >> >>>>>>> ready for publication, please explain why the document = is being >> >> >> >> >>>>>>> forwarded to the IESG. >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> The document was presented at IEWTF-82 (Taipei), with a= request >> >> >> >> >>>>>>> for >> >> >> >> >>>>>> WGLC. >> >> >> >> >>>>>>> WGLC concluded with some discussion but no substantive = changes >> >> >> >> >>>>>>> on Friday 30th March 2012. >> >> >> >> >>>>>> >> >> >> >> >>>>>> Yes, I guess that is true; but ignoring substantive co= mments >> >> >> >> >>>>>> isn't a good practice IMHO. >> >> >> >> >>>>>> >> >> >> >> >>>>>>> (4) Does the document Shepherd have any concerns about = the depth >> >> >> >> >>>>>>> or breadth of the reviews that have been performed? >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> No - the original draft had a lot of background materia= l, much >> >> >> >> >>>>>>> of >> >> >> >> >>>>>> this >> >> >> >> >>>>>>> has been condensed or removed, resulting in a smaller d= ocument. >> >> >> >> >>>>>> >> >> >> >> >>>>>> That is indeed what I basically asked for, but I don't= see any >> >> >> >> >>>>>> evidence of it: >> >> >> >> >>>>>> >> >> >> >> >>>>>> - diff(07,08) 48 lines changed or deleted; 53 lines ch= anged or >> >> >> >> added >> >> >> >> >>>>>> - diff(06,07) 8 lines changed or deleted; 13 lines ch= anged or >> >> >> >> added >> >> >> >> >>>>>> - diff(05,06) 64 lines changed or deleted; 69 lines ch= anged or >> >> >> >> >>>>>> added >> >> >> >> >>>>>> - diff(04,05) 823 lines changed or deleted; 864 lines ch= anged or >> >> >> >> >>>>>> added >> >> >> >> >>>>>> >> >> >> >> >>>>>> (Need I go farther? That gets us back to March 2011...) >> >> >> >> >>>>>> >> >> >> >> >>>>>>> (9) How solid is the WG consensus behind this document?= Does it >> >> >> >> >>>>>>> represent the strong concurrence of a few individuals, = with >> >> >> >> >>>>>>> others being silent, or does the WG as a whole understa= nd >> >> >> >> and agree with it? >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> The document has WG support and there is consensus to p= ublish. >> >> >> >> >>>>>> >> >> >> >> >>>>>> This, IMHO, doesn't answer the question. :^( >> >> >> >> >>>>>> >> >> >> >> >>>>>> Does it represent the concurrence of a few individuals= , or does >> >> >> >> >>>>>> the WG as a whole understand and agree with it? >> >> >> >> >>>>>> >> >> >> >> >>>>>> For reference, my comments included: >> >> >> >> >>>>>> ] >> >> >> >> >>>>>> ] When I previously skimmed this document, I believed it >> >> >> >> >>>>>> contained only ] common ground: that AQM should drop/mar= k packets >> >> >> >> >>>>>> without favoring small ] packets, and that to whatever e= xtent >> >> >> >> >>>>>> packet size _is_ considered, that ] should be a >> >> >> >> transport-layer responsibility. >> >> >> >> >>>>>> ] >> >> >> >> >>>>>> ] Alas, when I read it carefully this week, I find that = Bob is >> >> >> >> >>>>>> actually ] saying that transport-layer should _only_ con= sider >> >> >> >> >>>>>> "congested bytes", not ] "congested packets". >> >> >> >> >>>>>> ] >> >> >> >> >>>>>> ] In fact, Bob openly endorses replacing TCP congestion-= control >> >> >> >> >>>>>> with an ] algorithm which calculates "fair-share bytes" = and >> >> >> >> >>>>>> doesn't back off at all ] (even in the presence of 20% p= acket >> >> >> >> >>>>>> loss) unless you're already sending ] more than this >> >> >> >> "fair-share". >> >> >> >> >>>>>> ] >> >> >> >> >>>>>> ] I do not believe that is the consensus of this WG; = and I >> >> >> >> believe >> >> >> >> >>>>>> if >> >> >> >> >>>>>> ] that were the consensus it would exceed our charter. >> >> >> >> >>>>>> ] >> >> >> >> >>>>>> ] The draft contains a number of things I _do_ support; = and I'd >> >> >> >> >>>>>> be happy ] to support a considerably shorter draft which >> >> >> >> >>>>>> concentrates on the AQM ] recommendation, omitting any >> >> >> >> >>>>>> suggestions of modifying TCP congestion ] control. >> >> >> >> >>>>>> >> >> >> >> >>>>>> and Philip's comments included: >> >> >> >> >>>>>> ] >> >> >> >> >>>>>> ] S2.2 I thought the numbered bullets could be better ph= rased, >> >> >> >> >>>>>> something like ] +this:- ] >> >> >> >> >>>>>> ] 1. AQM algorithms such as RED SHOULD use packet-mod= e >> >> >> >> drop, ie they >> >> >> >> >>>>>> SHOULD NOT >> >> >> >> >>>>>> ] +use byte-mode drop. The latter ] is more complex, >> >> >> >> >>>>>> ] it creates the perverse incentive to fragment s= egments >> >> >> >> into >> >> >> >> >>>>>> tiny >> >> >> >> >>>>>> ] pieces and it is vulnerable to floods of small- >> >> >> >> >>>>>> ] packets. >> >> >> >> >>>>>> ] >> >> >> >> >>>>>> ] 2. If a vendor has implemented byte-mode drop, and= an >> >> >> >> operator >> >> >> >> >>>>>> has >> >> >> >> >>>>>> ] turned it on, it is RECOMMENDED to turn it off,= after >> >> >> >> >>>>>> establishing if >> >> >> >> >>>>>> ] +there are any implications on >> >> >> >> >>>>>> ] the relative performance of >> >> >> >> >>>>>> ] applications using different packet sizes. >> >> >> >> >>>>>> ] >> >> >> >> >>>>>> ] 3. RED SHOULD NOT be turned off. Without RED, a dro= p tail >> >> >> >> >>>>>> ] queue biases against large packets. >> >> >> >> >>>>>> ] >> >> >> >> >>>>>> ] Nit - the following paragraph shouldn't be indented (N= ote well >> >> >> >> >>>>>> that >> >> >> >> >>>>>> RED's...) >> >> >> >> >>>>>> ] >> >> >> >> >>>>>> ] S3.3 >> >> >> >> >>>>>> ] The section could be slightly clearer. Starting with t= he second >> >> >> >> >>>>>> para, where you ] +start talking about something you don= 't >> >> >> >> >>>>>> recommend (ie you have to remember that ] +you're talkin= g about >> >> >> >> >>>>>> the consequences of not following your recommendation). >> >> >> >> >>>>>> ] >> >> >> >> >>>>>> ] S3.3 >> >> >> >> >>>>>> ] o Also, if the network biases congestion notificat= ion by >> >> >> >> packet >> >> >> >> >>>>>> size >> >> >> >> >>>>>> ] it has to assume a baseline packet size--all pro= posed >> >> >> >> >>>>>> algorithms >> >> >> >> >>>>>> ] use the local MTU. Then transports have to gues= s which >> >> >> >> link >> >> >> >> >>>>>> was >> >> >> >> >>>>>> ] congested and what its local MTU was, in order t= o know >> >> >> >> how to >> >> >> >> >>>>>> ] tailor their congestion response to that link. >> >> >> >> >>>>>> ] So you're saying that for byte-mode drop, the network = element >> >> >> >> >>>>>> has to compare the ] +size of the current pkt with the M= TU, and >> >> >> >> >>>>>> if it's 25* smaller then reduce the ] +pkt loss probably= by 25*? >> >> >> >> >>>>>> And if the MTU was bigger, then the current pkt would ] = +be >> >> >> >> >>>>>> dropped with greater probability? And both of these thin= gs >> >> >> >> are hard to do. >> >> >> >> >>>>>> ] >> >> >> >> >>>>>> ] S3.4 (& knock-on effect on 3.3) ] I think this could b= e better. >> >> >> >> >>>>>> ] I agree with your arguments in S3.1 & 3.2 that droppin= g or >> >> >> >> >>>>>> marking should be ] +independent of pkt size. >> >> >> >> >>>>>> ] You now go into a couple of pages, which I think could= be >> >> >> >> >>>>>> boiled down to a ] +paragraph, saying something like:- ]= * the >> >> >> >> >>>>>> overall system (network + transport) has to be packet-si= ze >> >> >> >> >>>>>> dependent in ] >> >> >> >> >>>>>> +order to drive out the right amount of traffic so the r= esource >> >> >> >> >>>>>> becomes ] >> >> >> >> >>>>>> +uncongested (since we assume all resources are in pract= ice byte >> >> >> >> >>>>>> +rather >> >> >> >> >>>>>> than ] +packet limited) ] * from S3.1 and S3.2 the IETF = is >> >> >> >> >>>>>> convinced that the network should notify ] +independent = of >> >> >> >> packet-size. >> >> >> >> >>>>>> ] * therefore the transport must act dependent on packet= -size. >> >> >> >> >>>>>> ] >> >> >> >> >>>>>> ] It seems to me this is a necessary consequence of your= earlier >> >> >> >> >>>>>> assumptions ] +/arguments. >> >> >> >> >>>>>> ] >> >> >> >> >>>>>> ] [On the other hand, if someone disagrees with the argu= ments and >> >> >> >> >>>>>> thinks that the ] +network should notify dependent on >> >> >> >> >>>>>> packet-size, then it follows that the ] +transport can a= ct >> >> >> >> >>>>>> independent of >> >> >> >> >>>>>> packet- size.] ] ] I think in S3.3 you're trying to make= another >> >> >> >> >>>>>> argument (?):- ] * we can either do packet-size biasing= in the >> >> >> >> >>>>>> network element or on the end host ] +transport (see arg= ument >> >> >> >> >>>>>> above) ] * packet-size biasing in the network is quite t= ricky, >> >> >> >> >>>>>> because then both the ] +network element & the transport= have to >> >> >> >> >>>>>> make some guesses about MTU - whereas ] >> >> >> >> >>>>>> +with packet-size biasing in the transport, neither netw= ork >> >> >> >> >>>>>> +element >> >> >> >> >>>>>> nor ] +transport needs to know what the MTU is. >> >> >> >> >>>>>> ] * it is also easier to implement packet-size biasing i= n the >> >> >> >> >>>>>> transport than in ] +the network. >> >> >> >> >>>>>> ] >> >> >> >> >>>>>> ] On the last bullet, I didn't really follow your argume= nt in >> >> >> >> S3.5. >> >> >> >> >>>>>> Might be ] +easier to follow if S3.5 also talked about h= ow a >> >> >> >> >>>>>> network element would take ] +account of pkt size? Also,= does the >> >> >> >> >>>>>> following argument also apply?: >> >> >> >> >>>>>> ] * if pkt-size biasing is done in the transport, then t= he work >> >> >> >> >>>>>> (to do the ] +biasing) is spread over many end hosts, ] = * whereas >> >> >> >> >>>>>> if pkt-size biasing is done in the network, then the wor= k is ] >> >> >> >> >>>>>> +concentrated in just the congested network element, whi= ch has to >> >> >> >> >>>>>> operate on all ] +the traffic at line speed. >> >> >> >> >>>>>> >> >> >> >> >>>>>> (Has there perhaps been some confusion about what went= into the >> >> >> >> >>>>>> -08 >> >> >> >> >>>>>> version?) >> >> >> >> >>>>>> >> >> >> >> >>>>>> -- >> >> >> >> >>>>>> John Leslie >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>> >> >> >> >> >>>> >> >> >> >> >>> ___________________________________________________________= _____ >> >> >> >> >>> Bob Briscoe, BT Innovate & D= esign >> >> >> >> >>> >> >> >> >> >> >> >> >> >> > >> >> >> > >> >> >> > ________________________________________________________________ >> >> >> > Bob Briscoe, BT Innovate & Design >> >> >> > >> >> > >> >> > ________________________________________________________________ >> >> > Bob Briscoe, BT Innovate & Design >> >=20 >> > ________________________________________________________________ >> > Bob Briscoe, BT Innovate & Design > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design >=20 From Michael.Tuexen@lurchi.franken.de Mon Oct 15 10:19:00 2012 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 2A17C21F86C3 for ; Mon, 15 Oct 2012 10:19:00 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sERldIR2clJe for ; Mon, 15 Oct 2012 10:18:59 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id DFFDD21F8713 for ; Mon, 15 Oct 2012 10:18:55 -0700 (PDT) Received: from [192.168.1.103] (p508FAC0A.dip.t-dialin.net [80.143.172.10]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id EBCB91C0C0695; Mon, 15 Oct 2012 19:18:53 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: <50794E7B.6020903@erg.abdn.ac.uk> Date: Mon, 15 Oct 2012 19:18:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B0B4AD0-81FC-4534-942B-BB4D433719F4@lurchi.franken.de> References: <50794E7B.6020903@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1283) Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Post WGLC, comments on revised draft for draft-ietf-tsvwg-sctp-udp-encaps 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, 15 Oct 2012 17:19:00 -0000 Dear Gorry, see my comments below. Best regards Michael On Oct 13, 2012, at 1:20 PM, Gorry Fairhurst wrote: > The questions and comments below are intended to help conclude the = edits after the close of the WGLC in April. Comments are welcome. >=20 > Gorry Fairhurst > (as TSVWG-Co Chair) >=20 > ----- >=20 > 1) Which RFCs does this document formally update? Not sure why it has to? The boiler plate of the ID doesn't indicate that = any RFC is=20 >=20 > 2) I assume we will intended to publish as PS (rather than BCP). The boiler plate says Intended status: Standards Track, so I guess it is = PS. >=20 > 3) Please can each author confirm that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP = 78 > and BCP 79 have already been filed? The "Status of this Memo" says: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. What kind of additional statement are you looking for. >=20 > ----- >=20 > Review comments on this revision of the draft: >=20 > Section 4.3 - IPv6 UDP checksum change for tunnel APIs. > The text says: > / The UDP checksum SHOULD be computed and the SCTP checksum MUST be > computed./ > - This needs to cite draft-ietf-6man-udpzero and ietf-6man-udpchecksum > - If the intent is to allow IPv6 UDP zero checksum it must explain how = it meets the requirements for detecting paths that do not support this - = and caution that NAPT/NAT/Firewall,etc traversal may be impacted. > - The issues in firewall traversal may also be noted in the security = considerations section. > - This draft also needs to say that enabling IPv6 UDP zero checksum = supports requires that SCTP registers the used port(s) as supporting the = zero checksum option with the UDP module. > - I do not see a way defined for probing whether a path will actually = support a UDP zero checksum. This is needed for a transport - otherwise = a change of path could result in a broken connection (no IPv6 zero = checksum support). >=20 > - Thoughts welcome on this, since it is a new addition to the draft, = and incorporating this adds new things to check. The original text was a MUST for both checksums. Based on comments on = the list, we changed it to a SHOULD for UDP. If I remember things correctly, the = comments were mostly related to IPv4. In the FreeBSD implementation this also = covers only IPv4. What about just requiring the UDP checksum for IPv6? This would make = things simpler, right? >=20 > Section 4.3 - Editorial > /port number stored for the destination > address the packet is sent to (see Section 4.1)./ > may be could be better: > /port number stored for the destination > address to which the packet is sent (see Section 4.1)./ ACK. This change will be in the next revision of the ID. >=20 > Section 4.3 - Editorial > /Then a lookup is performed to find the association the received SCTP > packet belongs to./ > may be could be better: > /Then a lookup is performed to find the association for the received = SCTP > packet./ ACK. This change will be in the next revision of the ID. >=20 > and > /The UDP source port is stored as the > encapsulation port for the destination address the SCTP packet is > received from (see Section 4.1)./ > may be could be better: > /The UDP source port is stored as the > encapsulation port for the destination address in the received SCTP = packet (see Section 4.1)./ NACK. You take the UDP source port and store it for the destination, = which is the source address of received packet. You text change would use the destination address of the = received packet, which is not the same. >=20 > Section 4.5 - RFC 2119 language? > /There MAY be implementation constraints not > allowing to process received ICMP or ICMPv6 messages at all./ > - may be better written as below, and I am not sure this is a = requirement, this seems to be captured in the previous 'MUST'. >=20 > Section 4.5 - Need to clarify corner cases: > /Implementation constraints could prevent processing received ICMP or = ICMPv6 messages./ >=20 > Consider adding something like: > [RFC5927] describes precautions that are desirable before TCP acts on = the receipt of an ICMP message. > Similar precautions are desirable prior to forwarding a UDP Datagram = to the SCTP module. > The minimal length ICMP error message generated in response to > processing a UDP Datagram only identifies the Source UDP Port and > Destination UDP Port. This ICMP message does not carry sufficient > information to discover the encapsulated SCTP association. I didn't had anything related to RFC5927 in mind. I had two things in = mind: * You can process received ICMP/ICMPv6 messages but you can't correlate = them to an SCTP association and to the v-tag verification. * You simply can't process them, because the stack doesn't provide them, you don't have the privileges to receive them or so on. To make the first point clearer, the next revision will contain: If a received ICMP or ICMPv6 packet can not be related to a specific SCTP association or the verification tag can't be verified, it MUST be discarded silently. So I use your suggested text Implementation constraints could prevent processing received ICMP or = ICMPv6 messages. to cover the second point. >=20 > Section 4.6 - editorial > Should this Path MTU - with a capital 'P'? ACK. This change will be in the next revision of the ID. >=20 > Section 4.6 - editorial > / If the implementation does not allow to control the dont't fragment > (DF)-bit contained in the IPv4 header, path MTU discovery can't be > used. / > may be better as: > / If an implementation does not allow control of the dont't fragment > (DF)-bit contained in the IPv4 header, then Path MTU Discovery can = not be > used. / ACK. This change will be in the next revision of the ID. >=20 >=20 > Section 4.7 - Info REF to behave RFC? >=20 > Is the intention to suggest using dns names instead of IP addresses, = this would seem reasonable, and must surely be recommended in an RFC? NACK: We are not requesting to use DNS names at all. We are just saying (in the first paragraph) that you MUST NOT put any address in the SCTP packet (which is the IP payload), which may required NAT translation. The second paragraph describes how to handle multihomed associations and the third one how to change addresses during the lifetime of the association. This is the same way, how it is done for SCTP NAT traversal. >=20 > Section 4.8 - Query > / the ECN > bits MUST NOT be changed during encapsulation and decapsulation./ > - I assume this refers to the ECN field in the IP header? (please = explain) Yes. > - I assume that on reception this field SHOULD be passed to SCTP? = (please say) Yes. But isn't the IP header passed to SCTP anyway? At least this is my understanding. > - Is there any procedure that needs to be specified here... or does = SCTP detect that ECB marks are not being sent to the receiver and elect = not to mark as ECN-capable, please explain. If the implementation knowns that it can't send or receive the ECN bits, = it shouldn't announce ECN support. >=20 From gorry@erg.abdn.ac.uk Mon Oct 15 11:34:27 2012 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 7E03321F8876 for ; Mon, 15 Oct 2012 11:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKHGTH2fgclc for ; Mon, 15 Oct 2012 11:34:26 -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 7978921F8870 for ; Mon, 15 Oct 2012 11:34:26 -0700 (PDT) Received: from [10.174.0.231] (unknown [213.205.233.2]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id D9DCE2B435B; Mon, 15 Oct 2012 19:34:18 +0100 (BST) References: <50794E7B.6020903@erg.abdn.ac.uk> <9B0B4AD0-81FC-4534-942B-BB4D433719F4@lurchi.franken.de> Mime-Version: 1.0 (1.0) In-Reply-To: <9B0B4AD0-81FC-4534-942B-BB4D433719F4@lurchi.franken.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <885C8964-FE72-4266-BCF3-9F8D2B17F43D@erg.abdn.ac.uk> X-Mailer: iPhone Mail (10A403) From: "Gorry (erg)" Date: Mon, 15 Oct 2012 19:34:14 +0100 To: Michael Tuexen Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Post WGLC, comments on revised draft for draft-ietf-tsvwg-sctp-udp-encaps 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, 15 Oct 2012 18:34:27 -0000 Looks like we are nearly there, see in-line Gorry On 15 Oct 2012, at 18:18, Michael Tuexen w= rote: > Dear Gorry, >=20 > see my comments below. >=20 > Best regards > Michael >=20 > On Oct 13, 2012, at 1:20 PM, Gorry Fairhurst wrote: >=20 >> The questions and comments below are intended to help conclude the edits a= fter the close of the WGLC in April. Comments are welcome. >>=20 >> Gorry Fairhurst >> (as TSVWG-Co Chair) >>=20 >> ----- >>=20 >> 1) Which RFCs does this document formally update? > Not sure why it has to? The boiler plate of the ID doesn't indicate that a= ny RFC is=20 Ok find with this - I need to ask. >>=20 >> 2) I assume we will intended to publish as PS (rather than BCP). > The boiler plate says Intended status: Standards Track, so I guess it is P= S. Ok >>=20 >> 3) Please can each author confirm that any and all appropriate IPR >> disclosures required for full conformance with the provisions of BCP 78 >> and BCP 79 have already been filed? > The "Status of this Memo" says: > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > What kind of additional statement are you looking for. Each author needs to just affirm this (sorry for extra red tape) drop me an e= mail off-list and I can tick this off:-) >> ----- >>=20 >> Review comments on this revision of the draft: >>=20 >> Section 4.3 - IPv6 UDP checksum change for tunnel APIs. >> The text says: >> / The UDP checksum SHOULD be computed and the SCTP checksum MUST be >> computed./ >> - This needs to cite draft-ietf-6man-udpzero and ietf-6man-udpchecksum >> - If the intent is to allow IPv6 UDP zero checksum it must explain how it= meets the requirements for detecting paths that do not support this - and c= aution that NAPT/NAT/Firewall,etc traversal may be impacted. >> - The issues in firewall traversal may also be noted in the security cons= iderations section. >> - This draft also needs to say that enabling IPv6 UDP zero checksum suppo= rts requires that SCTP registers the used port(s) as supporting the zero che= cksum option with the UDP module. >> - I do not see a way defined for probing whether a path will actually su= pport a UDP zero checksum. This is needed for a transport - otherwise a chan= ge of path could result in a broken connection (no IPv6 zero checksum suppor= t). >>=20 >> - Thoughts welcome on this, since it is a new addition to the draft, and i= ncorporating this adds new things to check. > The original text was a MUST for both checksums. Based on comments on the l= ist, > we changed it to a SHOULD for UDP. If I remember things correctly, the com= ments > were mostly related to IPv4. In the FreeBSD implementation this also cover= s only IPv4. > What about just requiring the UDP checksum for IPv6? This would make thing= s simpler, right? You could require checksum for both or define simple machinery for IPv6 - ei= ther way is fine for me.=20 >> Section 4.3 - Editorial >> /port number stored for the destination >> address the packet is sent to (see Section 4.1)./ >> may be could be better: >> /port number stored for the destination >> address to which the packet is sent (see Section 4.1)./ > ACK. This change will be in the next revision of the ID. >>=20 >> Section 4.3 - Editorial >> /Then a lookup is performed to find the association the received SCTP >> packet belongs to./ >> may be could be better: >> /Then a lookup is performed to find the association for the received SCTP= >> packet./ > ACK. This change will be in the next revision of the ID. >>=20 >> and >> /The UDP source port is stored as the >> encapsulation port for the destination address the SCTP packet is >> received from (see Section 4.1)./ >> may be could be better: >> /The UDP source port is stored as the >> encapsulation port for the destination address in the received SCTP pack= et (see Section 4.1)./ > NACK. You take the UDP source port and store it for the destination, which= is the source address of received > packet. You text change would use the destination address of the received p= acket, which is > not the same. Fine with adding your clarification! >>=20 >> Section 4.5 - RFC 2119 language? >> /There MAY be implementation constraints not >> allowing to process received ICMP or ICMPv6 messages at all./ >> - may be better written as below, and I am not sure this is a requirement= , this seems to be captured in the previous 'MUST'. >>=20 >> Section 4.5 - Need to clarify corner cases: >> /Implementation constraints could prevent processing received ICMP or ICM= Pv6 messages./ >>=20 >> Consider adding something like: >> [RFC5927] describes precautions that are desirable before TCP acts on the= receipt of an ICMP message. >> Similar precautions are desirable prior to forwarding a UDP Datagram to t= he SCTP module. >> The minimal length ICMP error message generated in response to >> processing a UDP Datagram only identifies the Source UDP Port and >> Destination UDP Port. This ICMP message does not carry sufficient >> information to discover the encapsulated SCTP association. > I didn't had anything related to RFC5927 in mind. I had two things in mind= : > * You can process received ICMP/ICMPv6 messages but you can't correlate th= em > to an SCTP association and to the v-tag verification. > * You simply can't process them, because the stack doesn't provide them, > you don't have the privileges to receive them or so on. >=20 > To make the first point clearer, the next revision will contain: > If a received ICMP or ICMPv6 packet can not be related to a specific > SCTP association or the verification tag can't be verified, > it MUST be discarded silently. >=20 > So I use your suggested text > Implementation constraints could prevent processing received ICMP or ICMPv= 6 messages. > to cover the second point. I recall we talked before on this - and some new text would be fine in the w= ay you suggest. >>=20 >> Section 4.6 - editorial >> Should this Path MTU - with a capital 'P'? > ACK. This change will be in the next revision of the ID. >>=20 >> Section 4.6 - editorial >> / If the implementation does not allow to control the dont't fragment >> (DF)-bit contained in the IPv4 header, path MTU discovery can't be >> used. / >> may be better as: >> / If an implementation does not allow control of the dont't fragment >> (DF)-bit contained in the IPv4 header, then Path MTU Discovery can not b= e >> used. / > ACK. This change will be in the next revision of the ID. >>=20 >>=20 >> Section 4.7 - Info REF to behave RFC? >>=20 >> Is the intention to suggest using dns names instead of IP addresses, this= would seem reasonable, and must surely be recommended in an RFC? > NACK: We are not requesting to use DNS names at all. > We are just saying (in the first paragraph) that you MUST NOT put > any address in the SCTP packet (which is the IP payload), which may > required NAT translation. >=20 > The second paragraph describes how to handle multihomed associations > and the third one how to change addresses during the lifetime of the > association. >=20 > This is the same way, how it is done for SCTP NAT traversal. If this cites SCTP NAT this should be sufficient for me >> Section 4.8 - Query >> / the ECN >> bits MUST NOT be changed during encapsulation and decapsulation./ >> - I assume this refers to the ECN field in the IP header? (please explain= ) > Yes. >> - I assume that on reception this field SHOULD be passed to SCTP? (please= say) > Yes. But isn't the IP header passed to SCTP anyway? At least this is my > understanding. Ok - it was just to note this because as I understand this could be implemen= ted as a user-space udp app. >> - Is there any procedure that needs to be specified here... or does SCTP d= etect that ECN marks are not being sent to the receiver and elect not to mar= k as ECN-capable, please explain. > If the implementation knowns that it can't send or receive the ECN bits, i= t > shouldn't announce ECN support. That's ok but: Do you know via the api whether udp provided ecn ? I assume y= ou rely on the handshake to know whether the peer supports ecn (as usual)= From Michael.Tuexen@lurchi.franken.de Mon Oct 15 12:15:05 2012 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 416FC21F85EA for ; Mon, 15 Oct 2012 12:15:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjtFPuLeu+lF for ; Mon, 15 Oct 2012 12:15:04 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id A01D021F85C7 for ; Mon, 15 Oct 2012 12:15:03 -0700 (PDT) Received: from [192.168.1.103] (p508F9129.dip.t-dialin.net [80.143.145.41]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 84BF81C0C0695; Mon, 15 Oct 2012 21:15:02 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <885C8964-FE72-4266-BCF3-9F8D2B17F43D@erg.abdn.ac.uk> Date: Mon, 15 Oct 2012 21:15:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50794E7B.6020903@erg.abdn.ac.uk> <9B0B4AD0-81FC-4534-942B-BB4D433719F4@lurchi.franken.de> <885C8964-FE72-4266-BCF3-9F8D2B17F43D@erg.abdn.ac.uk> To: Gorry (erg) X-Mailer: Apple Mail (2.1283) Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Post WGLC, comments on revised draft for draft-ietf-tsvwg-sctp-udp-encaps 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, 15 Oct 2012 19:15:05 -0000 On Oct 15, 2012, at 8:34 PM, Gorry (erg) wrote: > Looks like we are nearly there, see in-line >=20 > Gorry >=20 > On 15 Oct 2012, at 18:18, Michael Tuexen = wrote: >=20 >> Dear Gorry, >>=20 >> see my comments below. >>=20 >> Best regards >> Michael >>=20 >> On Oct 13, 2012, at 1:20 PM, Gorry Fairhurst wrote: >>=20 >>> The questions and comments below are intended to help conclude the = edits after the close of the WGLC in April. Comments are welcome. >>>=20 >>> Gorry Fairhurst >>> (as TSVWG-Co Chair) >>>=20 >>> ----- >>>=20 >>> 1) Which RFCs does this document formally update? >> Not sure why it has to? The boiler plate of the ID doesn't indicate = that any RFC is=20 >=20 > Ok find with this - I need to ask. >>>=20 >>> 2) I assume we will intended to publish as PS (rather than BCP). >> The boiler plate says Intended status: Standards Track, so I guess it = is PS. > Ok >>>=20 >>> 3) Please can each author confirm that any and all appropriate IPR >>> disclosures required for full conformance with the provisions of BCP = 78 >>> and BCP 79 have already been filed? >> The "Status of this Memo" says: >> This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79. >> What kind of additional statement are you looking for. >=20 > Each author needs to just affirm this (sorry for extra red tape) drop = me an email off-list and I can tick this off:-) Done. >>> ----- >>>=20 >>> Review comments on this revision of the draft: >>>=20 >>> Section 4.3 - IPv6 UDP checksum change for tunnel APIs. >>> The text says: >>> / The UDP checksum SHOULD be computed and the SCTP checksum MUST be >>> computed./ >>> - This needs to cite draft-ietf-6man-udpzero and = ietf-6man-udpchecksum >>> - If the intent is to allow IPv6 UDP zero checksum it must explain = how it meets the requirements for detecting paths that do not support = this - and caution that NAPT/NAT/Firewall,etc traversal may be impacted. >>> - The issues in firewall traversal may also be noted in the security = considerations section. >>> - This draft also needs to say that enabling IPv6 UDP zero checksum = supports requires that SCTP registers the used port(s) as supporting the = zero checksum option with the UDP module. >>> - I do not see a way defined for probing whether a path will = actually support a UDP zero checksum. This is needed for a transport - = otherwise a change of path could result in a broken connection (no IPv6 = zero checksum support). >>>=20 >>> - Thoughts welcome on this, since it is a new addition to the draft, = and incorporating this adds new things to check. >> The original text was a MUST for both checksums. Based on comments on = the list, >> we changed it to a SHOULD for UDP. If I remember things correctly, = the comments >> were mostly related to IPv4. In the FreeBSD implementation this also = covers only IPv4. >> What about just requiring the UDP checksum for IPv6? This would make = things simpler, right? >=20 > You could require checksum for both or define simple machinery for = IPv6 - either way is fine for me.=20 Using MUST for both is what we had and was not acceptable... Isn't SHOULD for IPv4 and MUST for IPv6 acceptable? Is defining the machinery for IPv6 related to SCTP. For me it looks like a generic problem, completely unrelated to SCTP. Am I missing something? >=20 >>> Section 4.3 - Editorial >>> /port number stored for the destination >>> address the packet is sent to (see Section 4.1)./ >>> may be could be better: >>> /port number stored for the destination >>> address to which the packet is sent (see Section 4.1)./ >> ACK. This change will be in the next revision of the ID. >>>=20 >>> Section 4.3 - Editorial >>> /Then a lookup is performed to find the association the received = SCTP >>> packet belongs to./ >>> may be could be better: >>> /Then a lookup is performed to find the association for the received = SCTP >>> packet./ >> ACK. This change will be in the next revision of the ID. >>>=20 >>> and >>> /The UDP source port is stored as the >>> encapsulation port for the destination address the SCTP packet is >>> received from (see Section 4.1)./ >>> may be could be better: >>> /The UDP source port is stored as the >>> encapsulation port for the destination address in the received SCTP = packet (see Section 4.1)./ >> NACK. You take the UDP source port and store it for the destination, = which is the source address of received >> packet. You text change would use the destination address of the = received packet, which is >> not the same. > Fine with adding your clarification! >>>=20 >>> Section 4.5 - RFC 2119 language? >>> /There MAY be implementation constraints not >>> allowing to process received ICMP or ICMPv6 messages at all./ >>> - may be better written as below, and I am not sure this is a = requirement, this seems to be captured in the previous 'MUST'. >>>=20 >>> Section 4.5 - Need to clarify corner cases: >>> /Implementation constraints could prevent processing received ICMP = or ICMPv6 messages./ >>>=20 >>> Consider adding something like: >>> [RFC5927] describes precautions that are desirable before TCP acts = on the receipt of an ICMP message. >>> Similar precautions are desirable prior to forwarding a UDP Datagram = to the SCTP module. >>> The minimal length ICMP error message generated in response to >>> processing a UDP Datagram only identifies the Source UDP Port and >>> Destination UDP Port. This ICMP message does not carry sufficient >>> information to discover the encapsulated SCTP association. >> I didn't had anything related to RFC5927 in mind. I had two things in = mind: >> * You can process received ICMP/ICMPv6 messages but you can't = correlate them >> to an SCTP association and to the v-tag verification. >> * You simply can't process them, because the stack doesn't provide = them, >> you don't have the privileges to receive them or so on. >>=20 >> To make the first point clearer, the next revision will contain: >> If a received ICMP or ICMPv6 packet can not be related to a specific >> SCTP association or the verification tag can't be verified, >> it MUST be discarded silently. >>=20 >> So I use your suggested text >> Implementation constraints could prevent processing received ICMP or = ICMPv6 messages. >> to cover the second point. >=20 > I recall we talked before on this - and some new text would be fine in = the way you suggest. >>>=20 >>> Section 4.6 - editorial >>> Should this Path MTU - with a capital 'P'? >> ACK. This change will be in the next revision of the ID. >>>=20 >>> Section 4.6 - editorial >>> / If the implementation does not allow to control the dont't = fragment >>> (DF)-bit contained in the IPv4 header, path MTU discovery can't be >>> used. / >>> may be better as: >>> / If an implementation does not allow control of the dont't fragment >>> (DF)-bit contained in the IPv4 header, then Path MTU Discovery can = not be >>> used. / >> ACK. This change will be in the next revision of the ID. >>>=20 >>>=20 >>> Section 4.7 - Info REF to behave RFC? >>>=20 >>> Is the intention to suggest using dns names instead of IP addresses, = this would seem reasonable, and must surely be recommended in an RFC? >> NACK: We are not requesting to use DNS names at all. >> We are just saying (in the first paragraph) that you MUST NOT put >> any address in the SCTP packet (which is the IP payload), which may >> required NAT translation. >>=20 >> The second paragraph describes how to handle multihomed associations >> and the third one how to change addresses during the lifetime of the >> association. >>=20 >> This is the same way, how it is done for SCTP NAT traversal. >=20 > If this cites SCTP NAT this should be sufficient for me I'll add it. >=20 >>> Section 4.8 - Query >>> / the ECN >>> bits MUST NOT be changed during encapsulation and decapsulation./ >>> - I assume this refers to the ECN field in the IP header? (please = explain) >> Yes. >>> - I assume that on reception this field SHOULD be passed to SCTP? = (please say) >> Yes. But isn't the IP header passed to SCTP anyway? At least this is = my >> understanding. > Ok - it was just to note this because as I understand this could be = implemented as a user-space udp app. Ahh, OK. I agree, we can only pass what we need. So I'll change it to: If the implementation supports the sending and receiving of the ECN bits for the IP protocols being used by an SCTP association, the ECN bits MUST NOT be changed during sending and receiving. This covers both the case where you pass it down/up via the complete IPv[46] header or via an additional parameter. OK? >>> - Is there any procedure that needs to be specified here... or does = SCTP detect that ECN marks are not being sent to the receiver and elect = not to mark as ECN-capable, please explain. >> If the implementation knowns that it can't send or receive the ECN = bits, it >> shouldn't announce ECN support. >=20 > That's ok but: Do you know via the api whether udp provided ecn ? I = assume you rely on the handshake to know whether the peer I know because of I know if I'm running on a platform which provides the = IP header or provides (for example via CMSGs) the DSCP. This can be used to trigger = the appropriate SCTP handshake. > supports ecn (as usual) From Michael.Tuexen@lurchi.franken.de Mon Oct 15 12:26:49 2012 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 CA0B521F8925 for ; Mon, 15 Oct 2012 12:26:49 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2Bta--iKHCw for ; Mon, 15 Oct 2012 12:26:48 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 2416321F890E for ; Mon, 15 Oct 2012 12:26:48 -0700 (PDT) Received: from [192.168.1.103] (p508F9129.dip.t-dialin.net [80.143.145.41]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 641981C0C0695; Mon, 15 Oct 2012 21:26:46 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <885C8964-FE72-4266-BCF3-9F8D2B17F43D@erg.abdn.ac.uk> Date: Mon, 15 Oct 2012 21:26:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4018E2DE-F8F8-4951-BAF5-F43C53B2D1A3@lurchi.franken.de> References: <50794E7B.6020903@erg.abdn.ac.uk> <9B0B4AD0-81FC-4534-942B-BB4D433719F4@lurchi.franken.de> <885C8964-FE72-4266-BCF3-9F8D2B17F43D@erg.abdn.ac.uk> To: Gorry (erg) X-Mailer: Apple Mail (2.1283) Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Post WGLC, comments on revised draft for draft-ietf-tsvwg-sctp-udp-encaps 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, 15 Oct 2012 19:26:49 -0000 On Oct 15, 2012, at 8:34 PM, Gorry (erg) wrote: > Looks like we are nearly there, see in-line >=20 > Gorry >=20 > On 15 Oct 2012, at 18:18, Michael Tuexen = wrote: >=20 >> Dear Gorry, >>=20 >> see my comments below. >>=20 >> Best regards >> Michael >>=20 >> On Oct 13, 2012, at 1:20 PM, Gorry Fairhurst wrote: >>=20 >>> The questions and comments below are intended to help conclude the = edits after the close of the WGLC in April. Comments are welcome. >>>=20 >>> Gorry Fairhurst >>> (as TSVWG-Co Chair) >>>=20 >>> ----- >>>=20 >>> 1) Which RFCs does this document formally update? >> Not sure why it has to? The boiler plate of the ID doesn't indicate = that any RFC is=20 >=20 > Ok find with this - I need to ask. >>>=20 >>> 2) I assume we will intended to publish as PS (rather than BCP). >> The boiler plate says Intended status: Standards Track, so I guess it = is PS. > Ok >>>=20 >>> 3) Please can each author confirm that any and all appropriate IPR >>> disclosures required for full conformance with the provisions of BCP = 78 >>> and BCP 79 have already been filed? >> The "Status of this Memo" says: >> This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79. >> What kind of additional statement are you looking for. >=20 > Each author needs to just affirm this (sorry for extra red tape) drop = me an email off-list and I can tick this off:-) >>> ----- >>>=20 >>> Review comments on this revision of the draft: >>>=20 >>> Section 4.3 - IPv6 UDP checksum change for tunnel APIs. >>> The text says: >>> / The UDP checksum SHOULD be computed and the SCTP checksum MUST be >>> computed./ >>> - This needs to cite draft-ietf-6man-udpzero and = ietf-6man-udpchecksum >>> - If the intent is to allow IPv6 UDP zero checksum it must explain = how it meets the requirements for detecting paths that do not support = this - and caution that NAPT/NAT/Firewall,etc traversal may be impacted. >>> - The issues in firewall traversal may also be noted in the security = considerations section. >>> - This draft also needs to say that enabling IPv6 UDP zero checksum = supports requires that SCTP registers the used port(s) as supporting the = zero checksum option with the UDP module. >>> - I do not see a way defined for probing whether a path will = actually support a UDP zero checksum. This is needed for a transport - = otherwise a change of path could result in a broken connection (no IPv6 = zero checksum support). >>>=20 >>> - Thoughts welcome on this, since it is a new addition to the draft, = and incorporating this adds new things to check. >> The original text was a MUST for both checksums. Based on comments on = the list, >> we changed it to a SHOULD for UDP. If I remember things correctly, = the comments >> were mostly related to IPv4. In the FreeBSD implementation this also = covers only IPv4. >> What about just requiring the UDP checksum for IPv6? This would make = things simpler, right? >=20 > You could require checksum for both or define simple machinery for = IPv6 - either way is fine for me.=20 >=20 >>> Section 4.3 - Editorial >>> /port number stored for the destination >>> address the packet is sent to (see Section 4.1)./ >>> may be could be better: >>> /port number stored for the destination >>> address to which the packet is sent (see Section 4.1)./ >> ACK. This change will be in the next revision of the ID. >>>=20 >>> Section 4.3 - Editorial >>> /Then a lookup is performed to find the association the received = SCTP >>> packet belongs to./ >>> may be could be better: >>> /Then a lookup is performed to find the association for the received = SCTP >>> packet./ >> ACK. This change will be in the next revision of the ID. >>>=20 >>> and >>> /The UDP source port is stored as the >>> encapsulation port for the destination address the SCTP packet is >>> received from (see Section 4.1)./ >>> may be could be better: >>> /The UDP source port is stored as the >>> encapsulation port for the destination address in the received SCTP = packet (see Section 4.1)./ >> NACK. You take the UDP source port and store it for the destination, = which is the source address of received >> packet. You text change would use the destination address of the = received packet, which is >> not the same. > Fine with adding your clarification! >>>=20 >>> Section 4.5 - RFC 2119 language? >>> /There MAY be implementation constraints not >>> allowing to process received ICMP or ICMPv6 messages at all./ >>> - may be better written as below, and I am not sure this is a = requirement, this seems to be captured in the previous 'MUST'. >>>=20 >>> Section 4.5 - Need to clarify corner cases: >>> /Implementation constraints could prevent processing received ICMP = or ICMPv6 messages./ >>>=20 >>> Consider adding something like: >>> [RFC5927] describes precautions that are desirable before TCP acts = on the receipt of an ICMP message. >>> Similar precautions are desirable prior to forwarding a UDP Datagram = to the SCTP module. >>> The minimal length ICMP error message generated in response to >>> processing a UDP Datagram only identifies the Source UDP Port and >>> Destination UDP Port. This ICMP message does not carry sufficient >>> information to discover the encapsulated SCTP association. >> I didn't had anything related to RFC5927 in mind. I had two things in = mind: >> * You can process received ICMP/ICMPv6 messages but you can't = correlate them >> to an SCTP association and to the v-tag verification. >> * You simply can't process them, because the stack doesn't provide = them, >> you don't have the privileges to receive them or so on. >>=20 >> To make the first point clearer, the next revision will contain: >> If a received ICMP or ICMPv6 packet can not be related to a specific >> SCTP association or the verification tag can't be verified, >> it MUST be discarded silently. >>=20 >> So I use your suggested text >> Implementation constraints could prevent processing received ICMP or = ICMPv6 messages. >> to cover the second point. >=20 > I recall we talked before on this - and some new text would be fine in = the way you suggest. >>>=20 >>> Section 4.6 - editorial >>> Should this Path MTU - with a capital 'P'? >> ACK. This change will be in the next revision of the ID. >>>=20 >>> Section 4.6 - editorial >>> / If the implementation does not allow to control the dont't = fragment >>> (DF)-bit contained in the IPv4 header, path MTU discovery can't be >>> used. / >>> may be better as: >>> / If an implementation does not allow control of the dont't fragment >>> (DF)-bit contained in the IPv4 header, then Path MTU Discovery can = not be >>> used. / >> ACK. This change will be in the next revision of the ID. >>>=20 >>>=20 >>> Section 4.7 - Info REF to behave RFC? >>>=20 >>> Is the intention to suggest using dns names instead of IP addresses, = this would seem reasonable, and must surely be recommended in an RFC? >> NACK: We are not requesting to use DNS names at all. >> We are just saying (in the first paragraph) that you MUST NOT put >> any address in the SCTP packet (which is the IP payload), which may >> required NAT translation. >>=20 >> The second paragraph describes how to handle multihomed associations >> and the third one how to change addresses during the lifetime of the >> association. >>=20 >> This is the same way, how it is done for SCTP NAT traversal. >=20 > If this cites SCTP NAT this should be sufficient for me Correction: In case of the NAT (supporting SCTP) traversal, you have = special parameters in the ASCONF. So I would prefer to not refer to the SCTP NAT = documents. I think the text is clear as is. Or do you have a suggestion for a = clarification? Best regards Michael >=20 >>> Section 4.8 - Query >>> / the ECN >>> bits MUST NOT be changed during encapsulation and decapsulation./ >>> - I assume this refers to the ECN field in the IP header? (please = explain) >> Yes. >>> - I assume that on reception this field SHOULD be passed to SCTP? = (please say) >> Yes. But isn't the IP header passed to SCTP anyway? At least this is = my >> understanding. > Ok - it was just to note this because as I understand this could be = implemented as a user-space udp app. >>> - Is there any procedure that needs to be specified here... or does = SCTP detect that ECN marks are not being sent to the receiver and elect = not to mark as ECN-capable, please explain. >> If the implementation knowns that it can't send or receive the ECN = bits, it >> shouldn't announce ECN support. >=20 > That's ok but: Do you know via the api whether udp provided ecn ? I = assume you rely on the handshake to know whether the peer supports ecn = (as usual) From jmpolk@cisco.com Tue Oct 16 23:15:11 2012 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 7E18421F87A7 for ; Tue, 16 Oct 2012 23:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id In1MHCgXgkRm for ; Tue, 16 Oct 2012 23:15:10 -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 BC0DB21F875C for ; Tue, 16 Oct 2012 23:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2004; q=dns/txt; s=iport; t=1350454511; x=1351664111; h=message-id:date:to:from:subject:mime-version; bh=KkwvbMAoqB34f7JLifhnckzi8NQD8vofNuSvLzfeF7g=; b=W6qRRc4mpj0ju34It6UwC2dF6JYLLsxoq82YAddgP86iYE+erOq5wUuZ ZE3WQ09VYWs2RFlx4rQS7qKalsxvBituAhq9OyEontwesHKBfK+feBm2B PtPU3wgqUUfLyHfFMymSntjROZAdX2MmdXLZ/uAFMFKBdpdNYpzehZKRL E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANlLflCtJV2b/2dsb2JhbABFwCqBCII5ASUCVjopYBIHh2ILmXaBK5FsjjKOboMhA4hYjiiIKYUJgWuCYCs X-IronPort-AV: E=Sophos;i="4.80,597,1344211200"; d="scan'208";a="132462475" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 17 Oct 2012 06:15:10 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) (authenticated bits=0) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9H6F9uW021974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Oct 2012 06:15:10 GMT Message-Id: <201210170615.q9H6F9uW021974@rcdn-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 17 Oct 2012 01:15:08 -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] New ID creating the RSVP MULTI_INSTANCE Object 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, 17 Oct 2012 06:15:11 -0000 TSVWG [with my author hat on] This is to announce that I (finally!) got the new draft creating the MULTI_INSTANCE Object done. Many of you will remember that Lou Berger proposed that I take the MULTI_TSPEC Object (a current WG item) out of IntServ (the sender_descriptor) and place it in a new RSVP Object that can carry any additional copies of *SPECs, Objects or elements from anywhere within the RSVP message. I have done this and added a bonus by including the now dormant draft on MULTI_PREEMPTION Object into this draft (which can set a establishing and defending priority for each TSPEC included in the message). This was a logical inclusion, as I see good usage for this added feature. All the URLs are below for each to attain a copy of the draft. Comments are welcome. I will be proposing this draft replace draft-ietf-tsvwg-intserv-multiple-tspec to meet the existing milestone we have in TSVWG, as I believe this is a better solution, and gets things out of IntServ, if folks agree. James Filename: draft-polk-rsvp-multi-instance-object Revision: 00 Title: Resource Reservation Protocol Multiple Instance Object Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 19 URL: http://www.ietf.org/internet-drafts/draft-polk-rsvp-multi-instance-object-00.txt Status: http://datatracker.ietf.org/doc/draft-polk-rsvp-multi-instance-object Htmlized: http://tools.ietf.org/html/draft-polk-rsvp-multi-instance-object-00 Abstract: This document creates the framework for a new Resource Reservation Protocol version 1 (RSVP) object for instances in which there are multiple occurrences of existing RSVP objects is to be included within the same RSVP message. This document offers two instances for multiple versions of the same object will be valid in RSVP messages, for more than one traffic specification object (TSPEC), and more than one TSPEC priority object (PREEMPTION_PRI). From Martin.Stiemerling@neclab.eu Wed Oct 17 03:45:42 2012 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 7AB1D21F87E8 for ; Wed, 17 Oct 2012 03:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.048 X-Spam-Level: X-Spam-Status: No, score=-103.048 tagged_above=-999 required=5 tests=[AWL=0.551, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoiCM0iWLJVE for ; Wed, 17 Oct 2012 03:45:42 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E72EA21F87A2 for ; Wed, 17 Oct 2012 03:45:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5BC861021EC for ; Wed, 17 Oct 2012 12:45:41 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fm0N3d8PfZKa for ; Wed, 17 Oct 2012 12:45:41 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 436DD1021DB for ; Wed, 17 Oct 2012 12:45:36 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 17 Oct 2012 12:45:36 +0200 Message-ID: <507E8C4F.1090007@neclab.eu> Date: Wed, 17 Oct 2012 12:45:35 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Subject: [tsvwg] Status of SCTP: Meet with your ADs X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "tsv-ads@tools.ietf.org" List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 10:45:42 -0000 Dear all friends of SCTP, Your fellow ADs would like to meet with you and sync on the current status of SCTP, i.e., basically getting in touch with you. I am writing to the tsvwg list, as I am not fully sure who is working on SCTP or is interested in SCTP. Anyhow, if you are interest, please let Wes and me know until Oct 31st, if you have time to come to the TSV AD office hours for 30 or 45 minutes. The TSV AD office hours will be: Tuesday, Nov 6, 1pm to 3pm. Room: to be announced. Thanks, Martin -- IETF Transport Area Director martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From gorry@erg.abdn.ac.uk Fri Oct 19 03:09:43 2012 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 8CDB621F86AB for ; Fri, 19 Oct 2012 03:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNn-zDZ8klnz for ; Fri, 19 Oct 2012 03:09:42 -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 38A2521F844B for ; Fri, 19 Oct 2012 03:09:42 -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 1A5CF2B45A0 for ; Fri, 19 Oct 2012 11:09:40 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 19 Oct 2012 11:09:40 +0100 Message-ID: Date: Fri, 19 Oct 2012 11:09:40 +0100 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org 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 Subject: [tsvwg] TSVWG DRAFT STATUS October 2012 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, 19 Oct 2012 10:09:43 -0000 The list below shows the status of the working group documents as we see it. Please check below and comment on drafts using the list. **PLEASE** do send any corrections/omissions to the chairs. Best wishes, James, Rolf and Gorry (TSVWG Chairs) --- Recently published: draft-ietf-tsvwg-rsvp-security-groupkeying was published as RFC 6411. draft-ietf-tsvwg-sctpsocket was published as RFC 6458. draft-ietf-tsvwg-sctp-strrst was published as RFC 6535. draft-ietf-tsvwg-source-quench was published as RFC 6633. ------------------------------------------------------------------- IDs in RFC Editor Queue: http://www.rfc-editor.org/queue.html None. ------------------------------------------------------------------- IDs in IESG processing: None. ------------------------------------------------------------------- NOTE: ITU-T Study Group 12 - TSVWG needs to respond to the ITU-T Liaison on QoS Classes & markings for interconnection ------------------------------------------------------------------- WG Drafts with Chairs: draft-ietf-tsvwg-sctp-udp-encap (Replaced: draft-tuexen-sctp-udp-encap) Lars sent a note as AD agreeing to progress this work. Work was coordinated with DCCP work on encaps. draft-tuexen-sctp-udp-encaps-06, January 10, 2011 Adopted as a work item 21 Sept 2011 (Gorry) WG -02 8 Dec 2011 WGLC completed Friday 20th April 2012, many discussion and notes that there were implementations. 13th Oct 2012, comments sent on draft to prepare for submission. DUE: Revised ID needed prior to AD submission, changes agreed. --- draft-ietf-tsvwg-byte-pkt-congest New editor added Jul 2010. New revision 25 Oct 2010. WG -01, June 10, 2011 IETF-81: discussed whether this should be BCP. ADs & Chairs agree to progress as a BCP Status changed to BCP (new-ID WG -05) Presented at IETF-82 (Taipei), request for WGLC. Gorry added as Shepherd (Jan 2012), Wes added as responsible AD (Jun 2012). WGLC concluded with comments on I-D, Friday 30th March 2012. Draft version of write-up sent to list, comments received. - Gorry working with authors to clear list of WGLC questions (5 sept 2012) DUE: WG Chair waiting for version that includes additional feedback during WGLC ------------------------------------------------------------------- WG Drafts: draft-ietf-tsvwg-rsvp-pcn Previous version : draft-karagiannis-pcn-tsvwg-rsvp-pcn WG interest in this topic recorded at IETF-81. Individual -01, 2011-07-11 AD decision allowed this to be added to the milestones The document was adopted, status will be EXP (IETF-84 due to dependencies on PCN RFCs) WG -00 8 Oct 2011 DUE: Please comment on RVSP aspects (RSVP-DIR review requested 13th Oct 2012) draft-ietf-tsvwg-natsupp-tsvwg (Replaced: draft-stewart-natsupp-tsvwg) http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-natsupp/ Dependency from BEHAVE WG. Adopted as a work item 21 Sept 2010 (Gorry). WG -00, 29/11/2010 Uploaded as: draft-ietf-natsupp-tsvwg WG -01, June 1, 2011 Authors restructured draft (-03) DUE: Discussion needed on list. draft-nishida-tsvwg-sctp-failover Individual-00 Presented in Prague, IETF-80. - understood not to conflict with draft-tuexen-tsvwg-sctp-multipath - PF has been coded into FreeBSD DUE: WG adoption being considered - please comment to list 26/6/2012. Adopted by WG DUE: Please comment on list. draft-ietf-tsvwg-intserv-multiple-tspec WG interest in this topic recorded at IETF-78. Charter update would be needed to progress this work. 5 Reviews needed to determine energy/technical direction. WG -05 (presented in Beijing, IETF-79) WG -06 (presented in Prague, IETF-80) RSVP directorate was consulted. 2 reviews from RSVP-DIR received (Bruce Davie, ?) 2 additional reviews promised (Ken Carlberg, Francois LeF) Chairs asked AD for a Charter update (IESG agreed) Draft discussed at IETF-80, and request to update charter agreed - AD advised 4 named reviewers will be required Adopted for progression as PS, for May 2012 - New approach presented following WG comments DUE: Discussion needed on list. draft-ietf-tsvwg-port-use-00 (replaces draft-touch-tsvwg-port-use-00) - Intended to be advice to protocol designers needing a port. 5 people have looked at this document, Prague IETF-80 Individual -01 July 2011 IETF-81 insufficient feedback from WG at this time. WG needs to assess if the new draft should be a work item. IETF-82, discussed - Chairs will ask WG to consider. Adopted by WG DUE: Revised ID expected to complete missing sections ------------------------------------------------------------------- WG action required: draft-polk-tsvwg-rsvp-app-id-vv-profiles -01 Presented in Beijing, IETF-79. -02, 14-Mar-2011 Presented IET-80. WG needs to assess if the new draft should be a work item. Seek to coordinate with music with partner ID: draft-polk-mmusic-traffic-class-for-sdp Author requests to make a WG work item... Gorry liaised with MMUSIC WG Chairs on companion draft, intended for LC early 2013. Gorry - not much discussion on this list, please assess as a candidate working document. DUE: ***PLEASE*** comment on list. draft-polk-tsvwg-rfc4594-update - noted at IETF-84, but not discussed (no time). draft-polk-tsvwg-new-dscp-assignments - noted at IETF-84, but not discussed (no time). WG action required (Transport Protocols): draft-tuexen-tsvwg-sctp-multipath -00 Presented in Prague, IETF-80. - understood not to conflict with draft-nishida-tsvwg-sctp-failover -01, 2010-12-27 DUE: Please comment to list. ------------------------------------------------------------------- The following have received recent discussion at TSVWG meetings or on the list. Inclusion in the list below does not indicate support for these specific drafts and other contributions are also warmly welcomed. draft-carlberg-tsvwg-ecn-reactions Reactions to Signaling from ECN Support for RTP/RTCP -00 presented IETF-82 Not yet requested to become a work item. - This draft is related to the new rmcat work. DUE: Please comment on list. draft-tuexen-tsvwg-sctp-sack-immediately -05, 2011-01-02 - Aug 2011, discussed on list and issues raised. DUE: Chairs need to confirm adoption (need to do work). DUE: New revision need (to address comments) Please comment on list. draft-stewart-tsvwg-sctpecn-02 Partially replaces (draft-stewart-tsvwg-sctp-nonce) IETF-78 suggested there was interest in this topic. Discussed at IETF-83, Paris. DUE: ECN is within the TSVWG Charter, will call for adoption on the list. DUE: Please comment on list. draft-polk-tsvwg-rfc4594-update-00 Discussed at IETF-83, Paris DUE: A Revised ID is needed. ------------------------------------------------------------------- Related non-TSVWG items: draft-ietf-behave-sctpnat-03.txt BEHAVE WG item linked to SCTP encapsulation work. draft-ietf-6man-udpzero Previously: draft-fairhurst-tsvwg-6man-udpzero Draft was adopted by 6man, please discuss on the 6man list. A WGLC of this draft is expected in 6MAN WG. Related draft: draft-ietf-6man-udpchecksums-00 This draft was also LC'ed in TSVWG (end 3rd May 2012) draft-ohanlon-rmcat-dflow Discussed at IETF-84, Vancouver This draft is related to the new rmcat work. In IESG discussion on making this a PS for UDP tunnels using IPv6 DUE: Revised ID needed ------------------------------------------------------------------ Other news: RSVP Directorate (formed in May 2010) Charter updated Aug 2011. New co-chair: Rolf Winter ITU-T Study Group 12 Liaison on QoS Classes & markings for interconnection From carlberg@g11.org.uk Fri Oct 19 04:36:31 2012 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 35A9221F8608 for ; Fri, 19 Oct 2012 04:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANIvKrP2MhWT for ; Fri, 19 Oct 2012 04:36:29 -0700 (PDT) Received: from portland.eukhosting.net (portland.ukserverhosting.net [92.48.103.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5596821F846F for ; Fri, 19 Oct 2012 04:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=DtSLNoyUQa3AcQgNPk7csyZSjQe2WldBYUE5m2HbEQ0=; b=ps8xLawvLqv1KIZ3oenoNa2lcNETbFOk+4ZAHyzTopLt33Yp46uHzY5W4c93Jk3YKBGSOP9BRAuma5pbvWie2nzMtcExWq2RKdUBe8+t0kc2bOwychXiHLuEQFWrulj3; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:60692 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.80) (envelope-from ) id 1TPAsH-000149-AX; Fri, 19 Oct 2012 11:36:21 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: ken carlberg X-Priority: 3 (Normal) In-Reply-To: Date: Fri, 19 Oct 2012 07:36:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8C3E5C88-ED49-484A-BE24-A3CEBA2621E8@g11.org.uk> References: To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: tsvwg Subject: Re: [tsvwg] TSVWG DRAFT STATUS October 2012 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, 19 Oct 2012 11:36:31 -0000 Hi Gorry, Thanks for sending the update out to the list. just a couple of minor = corrections on the following... > draft-carlberg-tsvwg-ecn-reactions > Reactions to Signaling from ECN Support for RTP/RTCP > -00 presented IETF-82 > Not yet requested to become a work item. > - This draft is related to the new rmcat work. > DUE: Please comment on list. at past meetings, we've have made requests for the document to become a = working group item. However, at the same time, since its been a work in = progress, we kept finding things to modify/update/clarify. And while = part of the draft is somewhat related to the new rmcat work, its more = closely related to rfc-6679 (ECN for RTP over UDP). So if there are no objections or concerns, I'd like to make a request = (on the list this time :-) to make this individual contribution into a = working group document. cheers, -ken From internet-drafts@ietf.org Fri Oct 19 05:41:18 2012 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 6AC8021F8633; Fri, 19 Oct 2012 05:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0cvBIjwEN44; Fri, 19 Oct 2012 05:41:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522D821F85AE; Fri, 19 Oct 2012 05:41:17 -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.34 Message-ID: <20121019124117.16212.80074.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2012 05:41:17 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-udp-encaps-05.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: Fri, 19 Oct 2012 12:41:18 -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 : UDP Encapsulation of SCTP Packets Author(s) : Michael Tuexen Randall R. Stewart Filename : draft-ietf-tsvwg-sctp-udp-encaps-05.txt Pages : 10 Date : 2012-10-19 Abstract: This document describes a simple method of encapsulating SCTP Packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NAT not supporting SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP-layer, for example implementing it as part of the application without requiring special privileges. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-udp-encaps-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gorry@erg.abdn.ac.uk Fri Oct 19 05:49:07 2012 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 9DB9B21F8490 for ; Fri, 19 Oct 2012 05:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYbaF7lRMm05 for ; Fri, 19 Oct 2012 05:49:07 -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 CF28821F848D for ; Fri, 19 Oct 2012 05:49:06 -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 C6B692B45A0; Fri, 19 Oct 2012 13:49:05 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 19 Oct 2012 13:49:06 +0100 Message-ID: <9a8e932f4baf3964b931e7cfe7d64bdf.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <8C3E5C88-ED49-484A-BE24-A3CEBA2621E8@g11.org.uk> References: <8C3E5C88-ED49-484A-BE24-A3CEBA2621E8@g11.org.uk> Date: Fri, 19 Oct 2012 13:49:06 +0100 From: gorry@erg.abdn.ac.uk To: "tsvwg" 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@erg.abdn.ac.uk Subject: [tsvwg] draft-carlberg-tsvwg-ecn-reactions - Has anyone read this? 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, 19 Oct 2012 12:49:07 -0000 I'll update the status. I also changed the subject - so hopefully people will see this draft and start to look at this. I'm keen that we get some feedback from people, and then see this sort of work progress. Has anyone on the TSVWG list read this .... - do people think we should be working on this topic at the IETF? - what sort of recommendations are needed - and who needs these? - do you have other ideas or experience that may be relevant? Gorry P.S. Ken let's discuss off-line with the co-chairs about the next steps. > Hi Gorry, > > Thanks for sending the update out to the list. just a couple of minor > corrections on the following... > >> draft-carlberg-tsvwg-ecn-reactions >> Reactions to Signaling from ECN Support for RTP/RTCP >> -00 presented IETF-82 >> Not yet requested to become a work item. >> - This draft is related to the new rmcat work. >> DUE: Please comment on list. > > at past meetings, we've have made requests for the document to become a > working group item. However, at the same time, since its been a work in > progress, we kept finding things to modify/update/clarify. And while part > of the draft is somewhat related to the new rmcat work, its more closely > related to rfc-6679 (ECN for RTP over UDP). > > So if there are no objections or concerns, I'd like to make a request (on > the list this time :-) to make this individual contribution into a working > group document. > > cheers, > > -ken > From jsaldana@unizar.es Fri Oct 19 07:04:33 2012 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 B73B321F8594; Fri, 19 Oct 2012 07:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.279 X-Spam-Level: X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jeDBsRPvhy9; Fri, 19 Oct 2012 07:04:32 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8EB21F8570; Fri, 19 Oct 2012 07:04:31 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q9JE4Ktx013820; Fri, 19 Oct 2012 16:04:21 +0200 From: "Jose Saldana" To: References: In-Reply-To: Date: Fri, 19 Oct 2012 16:04:28 +0200 Organization: Universidad de Zaragoza Message-ID: <00c401cdae02$a7b9ed40$f72dc7c0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG2sptoaZunU8wbOB1jbEmul7uvZpfukp1Q Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsvwg@ietf.org Subject: Re: [tsvwg] TSVWG DRAFT STATUS October 2012 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:04:33 -0000 Hello. Regarding draft-saldana-tsvwg-tcmtf, the question is that there is a specific mailing list (tcmtf@ietf.org), and we are currently discussing about it there. One of the topics of the discussion is if a Working Group should be created for it. This is the reason why it does not appear in your mail, isn't it? Thank you very much, Jose > -----Mensaje original----- > De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre de > gorry@erg.abdn.ac.uk > Enviado el: viernes, 19 de octubre de 2012 12:10 > Para: tsvwg@ietf.org > Asunto: [tsvwg] TSVWG DRAFT STATUS October 2012 > > The list below shows the status of the working group documents as we see > it. Please check below and comment on drafts using the list. **PLEASE** do > send any corrections/omissions to the chairs. > > Best wishes, > > James, Rolf and Gorry > (TSVWG Chairs) > > --- > Recently published: > > draft-ietf-tsvwg-rsvp-security-groupkeying was published as RFC 6411. > draft-ietf-tsvwg-sctpsocket was published as RFC 6458. > draft-ietf-tsvwg-sctp-strrst was published as RFC 6535. > draft-ietf-tsvwg-source-quench was published as RFC 6633. > > ------------------------------------------------------------------- > IDs in RFC Editor Queue: > http://www.rfc-editor.org/queue.html > None. > > ------------------------------------------------------------------- > IDs in IESG processing: > None. > > ------------------------------------------------------------------- > > NOTE: > ITU-T Study Group 12 - TSVWG needs to respond to the ITU-T Liaison on QoS > Classes & markings for interconnection > > ------------------------------------------------------------------- > > WG Drafts with Chairs: > > draft-ietf-tsvwg-sctp-udp-encap > (Replaced: draft-tuexen-sctp-udp-encap) > Lars sent a note as AD agreeing to progress this work. > Work was coordinated with DCCP work on encaps. > draft-tuexen-sctp-udp-encaps-06, January 10, 2011 Adopted as a work item > 21 Sept 2011 (Gorry) WG -02 8 Dec 2011 WGLC completed Friday 20th April > 2012, many discussion and notes that there were implementations. > 13th Oct 2012, comments sent on draft to prepare for submission. > DUE: Revised ID needed prior to AD submission, changes agreed. > > --- > draft-ietf-tsvwg-byte-pkt-congest > New editor added Jul 2010. > New revision 25 Oct 2010. > WG -01, June 10, 2011 > IETF-81: discussed whether this should be BCP. > ADs & Chairs agree to progress as a BCP > Status changed to BCP (new-ID WG -05) > Presented at IETF-82 (Taipei), request for WGLC. > Gorry added as Shepherd (Jan 2012), Wes added as responsible AD (Jun > 2012). > WGLC concluded with comments on I-D, Friday 30th March 2012. > Draft version of write-up sent to list, comments received. > - Gorry working with authors to clear list of WGLC questions (5 sept 2012) > DUE: WG Chair waiting for version that includes additional feedback during > WGLC > > ------------------------------------------------------------------- > WG Drafts: > > draft-ietf-tsvwg-rsvp-pcn > Previous version : draft-karagiannis-pcn-tsvwg-rsvp-pcn > WG interest in this topic recorded at IETF-81. > Individual -01, 2011-07-11 > AD decision allowed this to be added to the milestones The document was > adopted, status will be EXP (IETF-84 due to dependencies on PCN RFCs) WG - > 00 8 Oct 2011 > DUE: Please comment on RVSP aspects (RSVP-DIR review requested 13th Oct > 2012) > > draft-ietf-tsvwg-natsupp-tsvwg > (Replaced: draft-stewart-natsupp-tsvwg) > http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-natsupp/ > Dependency from BEHAVE WG. > Adopted as a work item 21 Sept 2010 (Gorry). > WG -00, 29/11/2010 > Uploaded as: draft-ietf-natsupp-tsvwg > WG -01, June 1, 2011 > Authors restructured draft (-03) > DUE: Discussion needed on list. > > draft-nishida-tsvwg-sctp-failover > Individual-00 Presented in Prague, IETF-80. > - understood not to conflict with draft-tuexen-tsvwg-sctp-multipath > - PF has been coded into FreeBSD > DUE: WG adoption being considered - please comment to list 26/6/2012. > Adopted by WG > DUE: Please comment on list. > > draft-ietf-tsvwg-intserv-multiple-tspec > WG interest in this topic recorded at IETF-78. > Charter update would be needed to progress this work. > 5 Reviews needed to determine energy/technical direction. > WG -05 (presented in Beijing, IETF-79) > WG -06 (presented in Prague, IETF-80) > RSVP directorate was consulted. > 2 reviews from RSVP-DIR received (Bruce Davie, ?) > 2 additional reviews promised (Ken Carlberg, Francois LeF) Chairs asked AD > for a Charter update (IESG agreed) Draft discussed at IETF-80, and request to > update charter agreed > - AD advised 4 named reviewers will be required Adopted for progression as > PS, for May 2012 > - New approach presented following WG comments > DUE: Discussion needed on list. > > draft-ietf-tsvwg-port-use-00 > (replaces draft-touch-tsvwg-port-use-00) > - Intended to be advice to protocol designers needing a port. > 5 people have looked at this document, Prague IETF-80 Individual -01 July > 2011 > IETF-81 insufficient feedback from WG at this time. > WG needs to assess if the new draft should be a work item. > IETF-82, discussed - Chairs will ask WG to consider. > Adopted by WG > DUE: Revised ID expected to complete missing sections > > ------------------------------------------------------------------- > WG action required: > > draft-polk-tsvwg-rsvp-app-id-vv-profiles > -01 Presented in Beijing, IETF-79. > -02, 14-Mar-2011 > Presented IET-80. > WG needs to assess if the new draft should be a work item. > Seek to coordinate with music with partner ID: > draft-polk-mmusic-traffic-class-for-sdp > Author requests to make a WG work item... > Gorry liaised with MMUSIC WG Chairs on companion draft, intended for LC > early 2013. > Gorry - not much discussion on this list, please assess as a candidate working > document. > DUE: ***PLEASE*** comment on list. > > draft-polk-tsvwg-rfc4594-update > - noted at IETF-84, but not discussed (no time). > draft-polk-tsvwg-new-dscp-assignments > - noted at IETF-84, but not discussed (no time). > WG action required (Transport Protocols): > > draft-tuexen-tsvwg-sctp-multipath > -00 Presented in Prague, IETF-80. > - understood not to conflict with draft-nishida-tsvwg-sctp-failover -01, 2010- > 12-27 > DUE: Please comment to list. > > ------------------------------------------------------------------- > The following have received recent discussion at TSVWG meetings or on the > list. Inclusion in the list below does not indicate support for these specific > drafts and other contributions are also warmly welcomed. > > draft-carlberg-tsvwg-ecn-reactions > Reactions to Signaling from ECN Support for RTP/RTCP > -00 presented IETF-82 > Not yet requested to become a work item. > - This draft is related to the new rmcat work. > DUE: Please comment on list. > > draft-tuexen-tsvwg-sctp-sack-immediately > -05, 2011-01-02 > - Aug 2011, discussed on list and issues raised. > DUE: Chairs need to confirm adoption (need to do work). > DUE: New revision need (to address comments) Please comment on list. > > draft-stewart-tsvwg-sctpecn-02 > Partially replaces (draft-stewart-tsvwg-sctp-nonce) > IETF-78 suggested there was interest in this topic. > Discussed at IETF-83, Paris. > DUE: ECN is within the TSVWG Charter, > will call for adoption on the list. > DUE: Please comment on list. > > draft-polk-tsvwg-rfc4594-update-00 > Discussed at IETF-83, Paris > DUE: A Revised ID is needed. > > ------------------------------------------------------------------- > Related non-TSVWG items: > > draft-ietf-behave-sctpnat-03.txt > BEHAVE WG item linked to SCTP encapsulation work. > > draft-ietf-6man-udpzero > Previously: draft-fairhurst-tsvwg-6man-udpzero > Draft was adopted by 6man, please discuss on the 6man list. > A WGLC of this draft is expected in 6MAN WG. > Related draft: draft-ietf-6man-udpchecksums-00 This draft was also LC'ed in > TSVWG (end 3rd May 2012) > > draft-ohanlon-rmcat-dflow > Discussed at IETF-84, Vancouver > This draft is related to the new rmcat work. > In IESG discussion on making this a PS for UDP tunnels using IPv6 > DUE: Revised ID needed > > ------------------------------------------------------------------ > Other news: > > RSVP Directorate (formed in May 2010) > Charter updated Aug 2011. > New co-chair: Rolf Winter > > ITU-T Study Group 12 Liaison on QoS Classes & markings for interconnection From bob.briscoe@bt.com Fri Oct 19 10:29:42 2012 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 8271421F86A4 for ; Fri, 19 Oct 2012 10:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.825 X-Spam-Level: X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9imaCSsigqVb for ; Fri, 19 Oct 2012 10:29:41 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 5905821F857A for ; Fri, 19 Oct 2012 10:29:41 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 19 Oct 2012 18:29:40 +0100 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 19 Oct 2012 18:29:39 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.309.2; Fri, 19 Oct 2012 18:29:38 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1350667777115; Fri, 19 Oct 2012 18:29:37 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q9JHTarm031903; Fri, 19 Oct 2012 18:29:36 +0100 Message-ID: <201210191729.q9JHTarm031903@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 19 Oct 2012 18:29:36 +0100 To: Ken Carlberg , Piers O'HANLON From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tsvwg IETF list Subject: [tsvwg] Review of draft-carlberg-tsvwg-ecn-reactions-03 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, 19 Oct 2012 17:29:42 -0000 Ken & Piers, I finally got round to reviewing this draft. 1/ Where you refer to RFC6679 as more fine-grained information than TCP, you might want to refer to this one too, which the Vancouver TCPM meeting agreed to include in the TCPM charter: There are currently two possible proposals to satisfy these requirements: S.3.1 " TFRC ... is seeing ... deployment in .... Empathy/Farsight, and GoogleTalk [googl]. However it should be noted that TFRC is only recommended for real-time media use with ECN response. TFRC is not recommended for non-ECN paths due to its loss based operation which leads to full queues with maximised latencies. " Are you saying Empathy/Farsight and GoogleTalk only recommend TFRC if with ECN, or is this document doing the recommending? "It is assumed that ECN markings will usually occur with lower queue occupancy and thus lower latency. " That can't be right. RFC3168 insists that an AQM signals ECN where it would otherwise have signalled a drop for a non-ECN packet. There is only one queue for them both, so the occupancy has to be the same for both to satisfy RFC3168. The whole point of the RFC3168 requirement is to ensure that non-ECN cannot starve ECN traffic. If an AQM were to mark ECN traffic at a shorter queue length, then non-ECN traffic would drive up the (same) queue length to the larger non-ECN operating point, and the algo would be marking ECN traffic with a lot higher probability than non-ECN. ECN would then starve itself given RFC3168 insists an ECN transport is meant to react to a mark as if it were a drop. This assumption seems to be the justification for TFRC being appropriate for ECN, where it might not be for non-ECN. If the assumption isn't correct, where does that leave the main message of the document? S.5.2 Fault Tolerance I don't see why either redundant (duplicate) transmission or FEC are relevant to a document about using ECN, as opposed to loss, for congestion signalling. S.5.3 I wholly agree that flows that consider themselves important could use a substantially less aggressive back-off. But I complete exemption is of great concern to me. Therein lies a congestion collapse. There is no need for complete exemption, if a flow can respond very little to congestion. At least then if congestion gets really bad, it will still respond a lot. But if congestion is not so bad, it will seem pretty much unresponsive. I know you report experiments where ECN exemption has limited effect on normal flows, but the experiments assume low numbers of exempt flows relative to non-exempt. Each individual flow cannot know whether that assumption holds, so making this assumption is a recipe for boiling a network during an emergency - just when we need it most. S.5.3 " This applies to all flows that utilize some form of the rate control that is inversely proportional to the loss rate, which includes TCP-like algorithms or equation-based approaches. " s/inversely proportional to/inverse in some degree to/ "Inversely proportional to" means rate = k/p, where p is loss probability and k is a constant TCP New Reno rate = k/p^0.5 TFRC rate = k/p^0.5 TCP Cubic rate = k/p^0.75 Compound TCP rate = k/p^0.8 None have rate = k/p S.5.3. penultimate para: I don't see how the normal flows can have a different latency from the exempt flows. If they all share the same queue, they all see the same latency at any one time. Certainly the average latency may be different for long-running flows that are present during times when shorter flows are there and when they are not. But the _instantaneous_ latency will be the same for any flows sharing a single queue. Nits: S.3. s/to quickly/too quickly/ Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From jmpolk@cisco.com Fri Oct 19 12:45:23 2012 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 EB2C121F8551; Fri, 19 Oct 2012 12:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaSIVPyEx3fF; Fri, 19 Oct 2012 12:45:22 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADA621F8744; Fri, 19 Oct 2012 12:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9765; q=dns/txt; s=iport; t=1350675922; x=1351885522; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=VVySZTWHQXGRYaKJaVIgNOI+0qgYSDm05I6DiLone2k=; b=GYedmunxMNb20lpQGbH+U+IonQi/Skt8oOYBArriAz9M8hODksSVsV3Y ejl62TxBV0wwGVjHyYtD769JVnPthlVtyzys17hU/zlC9fm8FcwLe9HS/ gB/K43HV3FU1mheX9jqbFxKF9BuRlWrOe6KFbNRYnQjkreJYwIhQY7ddQ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAN2sgVCtJXG9/2dsb2JhbABFwHSBCIIgAQEBBBIBChsCNAMIEAcEGB4JBxktEQYBEhoIh2ILnAegIYtaGoZVA4hajiyNNoFrgw2BRRc X-IronPort-AV: E=Sophos;i="4.80,615,1344211200"; d="scan'208";a="130550860" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 19 Oct 2012 19:45:10 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) (authenticated bits=0) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9JJj96t029160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 19:45:09 GMT Message-Id: <201210191945.q9JJj96t029160@rcdn-core2-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 19 Oct 2012 14:45:09 -0500 To: , From: James Polk In-Reply-To: <00c401cdae02$a7b9ed40$f72dc7c0$@unizar.es> References: <00c401cdae02$a7b9ed40$f72dc7c0$@unizar.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: tsvwg@ietf.org Subject: Re: [tsvwg] TSVWG DRAFT STATUS October 2012 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, 19 Oct 2012 19:45:24 -0000 At 09:04 AM 10/19/2012, Jose Saldana wrote: >Hello. > >Regarding draft-saldana-tsvwg-tcmtf, the question is that there is a >specific mailing list (tcmtf@ietf.org), and we are currently discussing >about it there. One of the topics of the discussion is if a Working Group >should be created for it. This is the reason why it does not appear in your >mail, isn't it? correct General question - from your lists's discussions, is there enough interested people to think about attempting to form a WG, in your view? If so, are you having an unofficial meeting (often called a 'Bar BoF', that doesn't meet during any other normal session slot to maximize attendance) during the Atlanta meeting? This type of meeting could demonstrate to the ADs that you might justify an official BoF at the next meeting (Orlando). There are some hoops that need to be jumped through though. I'm just wondering how far along and how organized your topic has come. James >Thank you very much, > >Jose > > > -----Mensaje original----- > > De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre de > > gorry@erg.abdn.ac.uk > > Enviado el: viernes, 19 de octubre de 2012 12:10 > > Para: tsvwg@ietf.org > > Asunto: [tsvwg] TSVWG DRAFT STATUS October 2012 > > > > The list below shows the status of the working group documents as we see > > it. Please check below and comment on drafts using the list. **PLEASE** do > > send any corrections/omissions to the chairs. > > > > Best wishes, > > > > James, Rolf and Gorry > > (TSVWG Chairs) > > > > --- > > Recently published: > > > > draft-ietf-tsvwg-rsvp-security-groupkeying was published as RFC 6411. > > draft-ietf-tsvwg-sctpsocket was published as RFC 6458. > > draft-ietf-tsvwg-sctp-strrst was published as RFC 6535. > > draft-ietf-tsvwg-source-quench was published as RFC 6633. > > > > ------------------------------------------------------------------- > > IDs in RFC Editor Queue: > > http://www.rfc-editor.org/queue.html > > None. > > > > ------------------------------------------------------------------- > > IDs in IESG processing: > > None. > > > > ------------------------------------------------------------------- > > > > NOTE: > > ITU-T Study Group 12 - TSVWG needs to respond to the ITU-T Liaison on QoS > > Classes & markings for interconnection > > > > ------------------------------------------------------------------- > > > > WG Drafts with Chairs: > > > > draft-ietf-tsvwg-sctp-udp-encap > > (Replaced: draft-tuexen-sctp-udp-encap) > > Lars sent a note as AD agreeing to progress this work. > > Work was coordinated with DCCP work on encaps. > > draft-tuexen-sctp-udp-encaps-06, January 10, 2011 Adopted as a work item > > 21 Sept 2011 (Gorry) WG -02 8 Dec 2011 WGLC completed Friday 20th April > > 2012, many discussion and notes that there were implementations. > > 13th Oct 2012, comments sent on draft to prepare for submission. > > DUE: Revised ID needed prior to AD submission, changes agreed. > > > > --- > > draft-ietf-tsvwg-byte-pkt-congest > > New editor added Jul 2010. > > New revision 25 Oct 2010. > > WG -01, June 10, 2011 > > IETF-81: discussed whether this should be BCP. > > ADs & Chairs agree to progress as a BCP > > Status changed to BCP (new-ID WG -05) > > Presented at IETF-82 (Taipei), request for WGLC. > > Gorry added as Shepherd (Jan 2012), Wes added as responsible AD (Jun > > 2012). > > WGLC concluded with comments on I-D, Friday 30th March 2012. > > Draft version of write-up sent to list, comments received. > > - Gorry working with authors to clear list of WGLC questions (5 sept 2012) > > DUE: WG Chair waiting for version that includes additional feedback during > > WGLC > > > > ------------------------------------------------------------------- > > WG Drafts: > > > > draft-ietf-tsvwg-rsvp-pcn > > Previous version : draft-karagiannis-pcn-tsvwg-rsvp-pcn > > WG interest in this topic recorded at IETF-81. > > Individual -01, 2011-07-11 > > AD decision allowed this to be added to the milestones The document was > > adopted, status will be EXP (IETF-84 due to dependencies on PCN RFCs) WG - > > 00 8 Oct 2011 > > DUE: Please comment on RVSP aspects (RSVP-DIR review requested 13th Oct > > 2012) > > > > draft-ietf-tsvwg-natsupp-tsvwg > > (Replaced: draft-stewart-natsupp-tsvwg) > > http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-natsupp/ > > Dependency from BEHAVE WG. > > Adopted as a work item 21 Sept 2010 (Gorry). > > WG -00, 29/11/2010 > > Uploaded as: draft-ietf-natsupp-tsvwg > > WG -01, June 1, 2011 > > Authors restructured draft (-03) > > DUE: Discussion needed on list. > > > > draft-nishida-tsvwg-sctp-failover > > Individual-00 Presented in Prague, IETF-80. > > - understood not to conflict with draft-tuexen-tsvwg-sctp-multipath > > - PF has been coded into FreeBSD > > DUE: WG adoption being considered - please comment to list 26/6/2012. > > Adopted by WG > > DUE: Please comment on list. > > > > draft-ietf-tsvwg-intserv-multiple-tspec > > WG interest in this topic recorded at IETF-78. > > Charter update would be needed to progress this work. > > 5 Reviews needed to determine energy/technical direction. > > WG -05 (presented in Beijing, IETF-79) > > WG -06 (presented in Prague, IETF-80) > > RSVP directorate was consulted. > > 2 reviews from RSVP-DIR received (Bruce Davie, ?) > > 2 additional reviews promised (Ken Carlberg, Francois LeF) Chairs asked AD > > for a Charter update (IESG agreed) Draft discussed at IETF-80, and request >to > > update charter agreed > > - AD advised 4 named reviewers will be required Adopted for progression as > > PS, for May 2012 > > - New approach presented following WG comments > > DUE: Discussion needed on list. > > > > draft-ietf-tsvwg-port-use-00 > > (replaces draft-touch-tsvwg-port-use-00) > > - Intended to be advice to protocol designers needing a port. > > 5 people have looked at this document, Prague IETF-80 Individual -01 July > > 2011 > > IETF-81 insufficient feedback from WG at this time. > > WG needs to assess if the new draft should be a work item. > > IETF-82, discussed - Chairs will ask WG to consider. > > Adopted by WG > > DUE: Revised ID expected to complete missing sections > > > > ------------------------------------------------------------------- > > WG action required: > > > > draft-polk-tsvwg-rsvp-app-id-vv-profiles > > -01 Presented in Beijing, IETF-79. > > -02, 14-Mar-2011 > > Presented IET-80. > > WG needs to assess if the new draft should be a work item. > > Seek to coordinate with music with partner ID: > > draft-polk-mmusic-traffic-class-for-sdp > > Author requests to make a WG work item... > > Gorry liaised with MMUSIC WG Chairs on companion draft, intended for LC > > early 2013. > > Gorry - not much discussion on this list, please assess as a candidate >working > > document. > > DUE: ***PLEASE*** comment on list. > > > > draft-polk-tsvwg-rfc4594-update > > - noted at IETF-84, but not discussed (no time). > > draft-polk-tsvwg-new-dscp-assignments > > - noted at IETF-84, but not discussed (no time). > > WG action required (Transport Protocols): > > > > draft-tuexen-tsvwg-sctp-multipath > > -00 Presented in Prague, IETF-80. > > - understood not to conflict with draft-nishida-tsvwg-sctp-failover -01, >2010- > > 12-27 > > DUE: Please comment to list. > > > > ------------------------------------------------------------------- > > The following have received recent discussion at TSVWG meetings or on the > > list. Inclusion in the list below does not indicate support for these >specific > > drafts and other contributions are also warmly welcomed. > > > > draft-carlberg-tsvwg-ecn-reactions > > Reactions to Signaling from ECN Support for RTP/RTCP > > -00 presented IETF-82 > > Not yet requested to become a work item. > > - This draft is related to the new rmcat work. > > DUE: Please comment on list. > > > > draft-tuexen-tsvwg-sctp-sack-immediately > > -05, 2011-01-02 > > - Aug 2011, discussed on list and issues raised. > > DUE: Chairs need to confirm adoption (need to do work). > > DUE: New revision need (to address comments) Please comment on list. > > > > draft-stewart-tsvwg-sctpecn-02 > > Partially replaces (draft-stewart-tsvwg-sctp-nonce) > > IETF-78 suggested there was interest in this topic. > > Discussed at IETF-83, Paris. > > DUE: ECN is within the TSVWG Charter, > > will call for adoption on the list. > > DUE: Please comment on list. > > > > draft-polk-tsvwg-rfc4594-update-00 > > Discussed at IETF-83, Paris > > DUE: A Revised ID is needed. > > > > ------------------------------------------------------------------- > > Related non-TSVWG items: > > > > draft-ietf-behave-sctpnat-03.txt > > BEHAVE WG item linked to SCTP encapsulation work. > > > > draft-ietf-6man-udpzero > > Previously: draft-fairhurst-tsvwg-6man-udpzero > > Draft was adopted by 6man, please discuss on the 6man list. > > A WGLC of this draft is expected in 6MAN WG. > > Related draft: draft-ietf-6man-udpchecksums-00 This draft was also LC'ed >in > > TSVWG (end 3rd May 2012) > > > > draft-ohanlon-rmcat-dflow > > Discussed at IETF-84, Vancouver > > This draft is related to the new rmcat work. > > In IESG discussion on making this a PS for UDP tunnels using IPv6 > > DUE: Revised ID needed > > > > ------------------------------------------------------------------ > > Other news: > > > > RSVP Directorate (formed in May 2010) > > Charter updated Aug 2011. > > New co-chair: Rolf Winter > > > > ITU-T Study Group 12 Liaison on QoS Classes & markings for interconnection From gorry@erg.abdn.ac.uk Sat Oct 20 00:16:47 2012 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 3B21821F8532; Sat, 20 Oct 2012 00:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztzRRC4hLu1r; Sat, 20 Oct 2012 00:16:46 -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 ED87121F84BC; Sat, 20 Oct 2012 00:16:45 -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 09A552B4521; Sat, 20 Oct 2012 08:16:44 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Sat, 20 Oct 2012 08:16:44 +0100 Message-ID: <7c2a90042fa8b65e9d51dde32ab82e11.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <201210191945.q9JJj96t029160@rcdn-core2-2.cisco.com> References: <00c401cdae02$a7b9ed40$f72dc7c0$@unizar.es> <201210191945.q9JJj96t029160@rcdn-core2-2.cisco.com> Date: Sat, 20 Oct 2012 08:16:44 +0100 From: gorry@erg.abdn.ac.uk To: "James Polk" 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: tsvwg@ietf.org, tsvwg-chairs@ietf.org Subject: Re: [tsvwg] TSVWG DRAFT STATUS October 2012 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: Sat, 20 Oct 2012 07:16:47 -0000 I agree. At the moment I do not see drafts from this group that look like they are mature enough to progress within TSVWG. it t is hard to comment further though until we see a set of drafts that people may read. Gorry Fairhurst > At 09:04 AM 10/19/2012, Jose Saldana wrote: >>Hello. >> >>Regarding draft-saldana-tsvwg-tcmtf, the question is that there is a >>specific mailing list (tcmtf@ietf.org), and we are currently discussing >>about it there. One of the topics of the discussion is if a Working Group >>should be created for it. This is the reason why it does not appear in >> your >>mail, isn't it? > > correct > > General question - from your lists's discussions, is there enough > interested people to think about attempting to form a WG, in your view? > > If so, are you having an unofficial meeting (often called a 'Bar > BoF', that doesn't meet during any other normal session slot to > maximize attendance) during the Atlanta meeting? This type of meeting > could demonstrate to the ADs that you might justify an official BoF > at the next meeting (Orlando). There are some hoops that need to be > jumped through though. I'm just wondering how far along and how > organized your topic has come. > > James > > >>Thank you very much, >> >>Jose >> >> > -----Mensaje original----- >> > De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre >> de >> > gorry@erg.abdn.ac.uk >> > Enviado el: viernes, 19 de octubre de 2012 12:10 >> > Para: tsvwg@ietf.org >> > Asunto: [tsvwg] TSVWG DRAFT STATUS October 2012 >> > >> > The list below shows the status of the working group documents as we >> see >> > it. Please check below and comment on drafts using the list. >> **PLEASE** do >> > send any corrections/omissions to the chairs. >> > >> > Best wishes, >> > >> > James, Rolf and Gorry >> > (TSVWG Chairs) >> > >> > --- >> > Recently published: >> > >> > draft-ietf-tsvwg-rsvp-security-groupkeying was published as RFC 6411. >> > draft-ietf-tsvwg-sctpsocket was published as RFC 6458. >> > draft-ietf-tsvwg-sctp-strrst was published as RFC 6535. >> > draft-ietf-tsvwg-source-quench was published as RFC 6633. >> > >> > ------------------------------------------------------------------- >> > IDs in RFC Editor Queue: >> > http://www.rfc-editor.org/queue.html >> > None. >> > >> > ------------------------------------------------------------------- >> > IDs in IESG processing: >> > None. >> > >> > ------------------------------------------------------------------- >> > >> > NOTE: >> > ITU-T Study Group 12 - TSVWG needs to respond to the ITU-T Liaison on >> QoS >> > Classes & markings for interconnection >> > >> > ------------------------------------------------------------------- >> > >> > WG Drafts with Chairs: >> > >> > draft-ietf-tsvwg-sctp-udp-encap >> > (Replaced: draft-tuexen-sctp-udp-encap) >> > Lars sent a note as AD agreeing to progress this work. >> > Work was coordinated with DCCP work on encaps. >> > draft-tuexen-sctp-udp-encaps-06, January 10, 2011 Adopted as a work >> item >> > 21 Sept 2011 (Gorry) WG -02 8 Dec 2011 WGLC completed Friday 20th >> April >> > 2012, many discussion and notes that there were implementations. >> > 13th Oct 2012, comments sent on draft to prepare for submission. >> > DUE: Revised ID needed prior to AD submission, changes agreed. >> > >> > --- >> > draft-ietf-tsvwg-byte-pkt-congest >> > New editor added Jul 2010. >> > New revision 25 Oct 2010. >> > WG -01, June 10, 2011 >> > IETF-81: discussed whether this should be BCP. >> > ADs & Chairs agree to progress as a BCP >> > Status changed to BCP (new-ID WG -05) >> > Presented at IETF-82 (Taipei), request for WGLC. >> > Gorry added as Shepherd (Jan 2012), Wes added as responsible AD (Jun >> > 2012). >> > WGLC concluded with comments on I-D, Friday 30th March 2012. >> > Draft version of write-up sent to list, comments received. >> > - Gorry working with authors to clear list of WGLC questions (5 sept >> 2012) >> > DUE: WG Chair waiting for version that includes additional feedback >> during >> > WGLC >> > >> > ------------------------------------------------------------------- >> > WG Drafts: >> > >> > draft-ietf-tsvwg-rsvp-pcn >> > Previous version : draft-karagiannis-pcn-tsvwg-rsvp-pcn >> > WG interest in this topic recorded at IETF-81. >> > Individual -01, 2011-07-11 >> > AD decision allowed this to be added to the milestones The document >> was >> > adopted, status will be EXP (IETF-84 due to dependencies on PCN RFCs) >> WG - >> > 00 8 Oct 2011 >> > DUE: Please comment on RVSP aspects (RSVP-DIR review requested 13th >> Oct >> > 2012) >> > >> > draft-ietf-tsvwg-natsupp-tsvwg >> > (Replaced: draft-stewart-natsupp-tsvwg) >> > http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-natsupp/ >> > Dependency from BEHAVE WG. >> > Adopted as a work item 21 Sept 2010 (Gorry). >> > WG -00, 29/11/2010 >> > Uploaded as: draft-ietf-natsupp-tsvwg >> > WG -01, June 1, 2011 >> > Authors restructured draft (-03) >> > DUE: Discussion needed on list. >> > >> > draft-nishida-tsvwg-sctp-failover >> > Individual-00 Presented in Prague, IETF-80. >> > - understood not to conflict with draft-tuexen-tsvwg-sctp-multipath >> > - PF has been coded into FreeBSD >> > DUE: WG adoption being considered - please comment to list 26/6/2012. >> > Adopted by WG >> > DUE: Please comment on list. >> > >> > draft-ietf-tsvwg-intserv-multiple-tspec >> > WG interest in this topic recorded at IETF-78. >> > Charter update would be needed to progress this work. >> > 5 Reviews needed to determine energy/technical direction. >> > WG -05 (presented in Beijing, IETF-79) >> > WG -06 (presented in Prague, IETF-80) >> > RSVP directorate was consulted. >> > 2 reviews from RSVP-DIR received (Bruce Davie, ?) >> > 2 additional reviews promised (Ken Carlberg, Francois LeF) Chairs >> asked AD >> > for a Charter update (IESG agreed) Draft discussed at IETF-80, and >> request >>to >> > update charter agreed >> > - AD advised 4 named reviewers will be required Adopted for >> progression as >> > PS, for May 2012 >> > - New approach presented following WG comments >> > DUE: Discussion needed on list. >> > >> > draft-ietf-tsvwg-port-use-00 >> > (replaces draft-touch-tsvwg-port-use-00) >> > - Intended to be advice to protocol designers needing a port. >> > 5 people have looked at this document, Prague IETF-80 Individual -01 >> July >> > 2011 >> > IETF-81 insufficient feedback from WG at this time. >> > WG needs to assess if the new draft should be a work item. >> > IETF-82, discussed - Chairs will ask WG to consider. >> > Adopted by WG >> > DUE: Revised ID expected to complete missing sections >> > >> > ------------------------------------------------------------------- >> > WG action required: >> > >> > draft-polk-tsvwg-rsvp-app-id-vv-profiles >> > -01 Presented in Beijing, IETF-79. >> > -02, 14-Mar-2011 >> > Presented IET-80. >> > WG needs to assess if the new draft should be a work item. >> > Seek to coordinate with music with partner ID: >> > draft-polk-mmusic-traffic-class-for-sdp >> > Author requests to make a WG work item... >> > Gorry liaised with MMUSIC WG Chairs on companion draft, intended for >> LC >> > early 2013. >> > Gorry - not much discussion on this list, please assess as a candidate >>working >> > document. >> > DUE: ***PLEASE*** comment on list. >> > >> > draft-polk-tsvwg-rfc4594-update >> > - noted at IETF-84, but not discussed (no time). >> > draft-polk-tsvwg-new-dscp-assignments >> > - noted at IETF-84, but not discussed (no time). >> > WG action required (Transport Protocols): >> > >> > draft-tuexen-tsvwg-sctp-multipath >> > -00 Presented in Prague, IETF-80. >> > - understood not to conflict with draft-nishida-tsvwg-sctp-failover >> -01, >>2010- >> > 12-27 >> > DUE: Please comment to list. >> > >> > ------------------------------------------------------------------- >> > The following have received recent discussion at TSVWG meetings or on >> the >> > list. Inclusion in the list below does not indicate support for these >>specific >> > drafts and other contributions are also warmly welcomed. >> > >> > draft-carlberg-tsvwg-ecn-reactions >> > Reactions to Signaling from ECN Support for RTP/RTCP >> > -00 presented IETF-82 >> > Not yet requested to become a work item. >> > - This draft is related to the new rmcat work. >> > DUE: Please comment on list. >> > >> > draft-tuexen-tsvwg-sctp-sack-immediately >> > -05, 2011-01-02 >> > - Aug 2011, discussed on list and issues raised. >> > DUE: Chairs need to confirm adoption (need to do work). >> > DUE: New revision need (to address comments) Please comment on list. >> > >> > draft-stewart-tsvwg-sctpecn-02 >> > Partially replaces (draft-stewart-tsvwg-sctp-nonce) >> > IETF-78 suggested there was interest in this topic. >> > Discussed at IETF-83, Paris. >> > DUE: ECN is within the TSVWG Charter, >> > will call for adoption on the list. >> > DUE: Please comment on list. >> > >> > draft-polk-tsvwg-rfc4594-update-00 >> > Discussed at IETF-83, Paris >> > DUE: A Revised ID is needed. >> > >> > ------------------------------------------------------------------- >> > Related non-TSVWG items: >> > >> > draft-ietf-behave-sctpnat-03.txt >> > BEHAVE WG item linked to SCTP encapsulation work. >> > >> > draft-ietf-6man-udpzero >> > Previously: draft-fairhurst-tsvwg-6man-udpzero >> > Draft was adopted by 6man, please discuss on the 6man list. >> > A WGLC of this draft is expected in 6MAN WG. >> > Related draft: draft-ietf-6man-udpchecksums-00 This draft was also >> LC'ed >>in >> > TSVWG (end 3rd May 2012) >> > >> > draft-ohanlon-rmcat-dflow >> > Discussed at IETF-84, Vancouver >> > This draft is related to the new rmcat work. >> > In IESG discussion on making this a PS for UDP tunnels using IPv6 >> > DUE: Revised ID needed >> > >> > ------------------------------------------------------------------ >> > Other news: >> > >> > RSVP Directorate (formed in May 2010) >> > Charter updated Aug 2011. >> > New co-chair: Rolf Winter >> > >> > ITU-T Study Group 12 Liaison on QoS Classes & markings for >> interconnection > From internet-drafts@ietf.org Sat Oct 20 06:32:52 2012 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 4E66421F84A6; Sat, 20 Oct 2012 06:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adUbVQlDe+jX; Sat, 20 Oct 2012 06:32:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AE221F8490; Sat, 20 Oct 2012 06:32: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.34 Message-ID: <20121020133251.32573.84830.idtracker@ietfa.amsl.com> Date: Sat, 20 Oct 2012 06:32:51 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-udp-encaps-06.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: Sat, 20 Oct 2012 13:32: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 : UDP Encapsulation of SCTP Packets Author(s) : Michael Tuexen Randall R. Stewart Filename : draft-ietf-tsvwg-sctp-udp-encaps-06.txt Pages : 10 Date : 2012-10-20 Abstract: This document describes a simple method of encapsulating SCTP Packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NAT not supporting SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP-layer, for example implementing it as part of the application without requiring special privileges. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-udp-encaps-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Michael.Tuexen@lurchi.franken.de Sun Oct 21 11:50:40 2012 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 6D05621F8695 for ; Sun, 21 Oct 2012 11:50:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAcF+FKN9zcu for ; Sun, 21 Oct 2012 11:50:39 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 8B38D21F8634 for ; Sun, 21 Oct 2012 11:50:39 -0700 (PDT) Received: from [192.168.1.103] (p5481A50C.dip.t-dialin.net [84.129.165.12]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 72C611C0C069A; Sun, 21 Oct 2012 20:50:36 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: Date: Sun, 21 Oct 2012 20:50:35 +0200 Content-Transfer-Encoding: 7bit Message-Id: <0526B4E7-FAEA-4D94-9A26-288EE2B5B32C@lurchi.franken.de> References: To: Steve Padgett X-Mailer: Apple Mail (2.1283) Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-natsupp-02.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: Sun, 21 Oct 2012 18:50:40 -0000 Hi Steve, I'm sorry for the late rely. See my comments in-line. Best regards Michael On Mar 27, 2012, at 12:59 PM, Steve Padgett wrote: > A couple comments on the SCTP NAT doc: > > 1) In section 8, "Handling of Missing State", an ERROR packet is > being sent in response to a packet other than a "ABORT, > SHUTDOWN-COMPLETE or INIT-ACK" packet that doesn't exist in the > translation table on the inside. > > It doesn't explicitly exclude ERROR messages here as well, but it > seems like it should (it may be implied, but I just don't see it > explicitly stated anywhere. I could be missing it). Having this error > being generated because of another error seems like it has the > potential for creating an error storm/loop. I added a sentence to avoid this. Thanks for bringing this up. > > 2) As a more generalized comment, it'd be nice to support a scenario > where the NAT box itself "supports" SCTP nat but only in a "passive" > mode where the nat box itself does not ever generate sctp packets. The > difference with the passive mode is that if there is an error or > collision in port #s/verification tags the just have the nat box drop > the packet, instead of responding with an error packet. This would be > less graceful to the protocol itself (a significant negative), but, as > an advantage: > - would make the nat-box implementation easier (arguably) > - would be closer to the current NAT situation in > firewalls/routers/nat boxes today for TCP/UDP/ICMP > - would likely generate less security risk (having the router respond > to every error'd packet may allow a dos attack against the router > itself if you flooded it with bad packets) > > In a "tiny" nat box (aka a home CPE or phone tethering nat), not > sending the error codes may be ok because the risk of collisions is so > low (eg, possibly left up to the implementor). In a "larger" nat box, > the customer may need these error packets. Well, the end-points have to deal with the case that these packets are dropped anyway. So this would result in a suboptimal behavior. > > It's also not clear if these error packets must be sent in response to > every packet or not (eg, if there can be rate-limiting, etc). Yes. We have not limitation. Best regards Michael > > Thanks! > Steve > From internet-drafts@ietf.org Sun Oct 21 11:53:22 2012 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 8654521F8A7D; Sun, 21 Oct 2012 11:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjmFmprmgBjB; Sun, 21 Oct 2012 11:53:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D514821F8A16; Sun, 21 Oct 2012 11:53:21 -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.34 Message-ID: <20121021185321.5277.22834.idtracker@ietfa.amsl.com> Date: Sun, 21 Oct 2012 11:53:21 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-04.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: Sun, 21 Oct 2012 18:53:22 -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 : Stream Control Transmission Protocol (SCTP) Network Addr= ess Translation Support Author(s) : Randall R. Stewart Michael Tuexen Irene Ruengeler Filename : draft-ietf-tsvwg-natsupp-04.txt Pages : 20 Date : 2012-10-21 Abstract: Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind a NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation (NAPT). To date, specialized code for SCTP has not yet been added to most NATs so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. This document describes the protocol extensions required for the SCTP endpoints to help NAT's provide similar features of NAPT in the single-point and multi-point traversal scenario. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-natsupp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-natsupp-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Ruediger.Geib@telekom.de Mon Oct 22 00:32:27 2012 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 C0AB921F84CA for ; Mon, 22 Oct 2012 00:32:27 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S51S6Ytv8oJJ for ; Mon, 22 Oct 2012 00:32:26 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 845C221F84C9 for ; Mon, 22 Oct 2012 00:32:25 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 22 Oct 2012 09:32:15 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 22 Oct 2012 09:31:54 +0200 From: To: Date: Mon, 22 Oct 2012 09:31:52 +0200 Thread-Topic: [tsvwg] draft-carlberg-tsvwg-ecn-reactions - Has anyone read this? Thread-Index: Ac2t+DgZ9DCZDjRASW21CZykxbHzVgCKtjsg Message-ID: References: <8C3E5C88-ED49-484A-BE24-A3CEBA2621E8@g11.org.uk> <9a8e932f4baf3964b931e7cfe7d64bdf.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <9a8e932f4baf3964b931e7cfe7d64bdf.squirrel@www.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] draft-carlberg-tsvwg-ecn-reactions - Has anyone read this? 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, 22 Oct 2012 07:32:27 -0000 Gorry, the topic in general is relevant for IETF, I think. draft-carlberg mentions that recently the RTP Media Congestion Avoidance Techniques (rmcat) working group has been set up. It would be useful to understand how draft-carlberg is related to the scope of the rmcat WG (e.g. whether draft-carlberg only suggests a basic real time congestion control mechanism and leaves all further work to rmcat). Side-note: If congestion control is a chartered task of TSVWG, then there might be a question whether there's an overlap ov TSVWG and rmcat. Notes on the draft (in adddition to Bob's ones): 5.1.2 Differentiated Services As in the case of RSVP, applications could rely on the reception of CE feedback to initiate a subsequent setting of diff-serv code points to provide additional protection or explicit association of forwarding characteristics of a given flow of packets. In addition, the setting of diff-serv code points would be done on an as-needed basis in reaction to CE feedback. Recommendations concerning specific diff-serv values are outside the scope of this document. It is common to use words like "DiffServ Codepoint" to mean "a QoS class" (correct DiffServ wording "a PHB <-Group>"). The authors here want to use an IP QoS class and should say so. There's no standard relation of DiffServ Codepoints to IP QoS classes (PHB <-Groups>). Apart from that, I wonder whether an application which had used class X so far can instantly and seemlessly flip to class Y. Especially, if there's an expectation of admission control features in a traffic class, it won't be done with simply marking traffic differently. Admission Control doesn't mean RSVP to me, it could be measurement based as well. PCN defines and discussed relevant mechanisms. The issue here is, that admissiion control is performed prior to setting up a media session, whereas here, the authors seem to suggest to change the class of a media session to avoid packet loss and queuing delay. Regards, Ruediger -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of g= orry@erg.abdn.ac.uk Sent: Friday, October 19, 2012 2:49 PM To: tsvwg Cc: gorry@erg.abdn.ac.uk Subject: [tsvwg] draft-carlberg-tsvwg-ecn-reactions - Has anyone read this? I'll update the status. I also changed the subject - so hopefully people will see this draft and start to look at this. I'm keen that we get some feedback from people, and then see this sort of work progress. Has anyone on the TSVWG list read this .... - do people think we should be working on this topic at the IETF? - what sort of recommendations are needed - and who needs these? - do you have other ideas or experience that may be relevant? Gorry P.S. Ken let's discuss off-line with the co-chairs about the next steps. > Hi Gorry, > > Thanks for sending the update out to the list. just a couple of minor > corrections on the following... > >> draft-carlberg-tsvwg-ecn-reactions >> Reactions to Signaling from ECN Support for RTP/RTCP >> -00 presented IETF-82 >> Not yet requested to become a work item. >> - This draft is related to the new rmcat work. >> DUE: Please comment on list. > > at past meetings, we've have made requests for the document to become a > working group item. However, at the same time, since its been a work in > progress, we kept finding things to modify/update/clarify. And while par= t > of the draft is somewhat related to the new rmcat work, its more closely > related to rfc-6679 (ECN for RTP over UDP). > > So if there are no objections or concerns, I'd like to make a request (on > the list this time :-) to make this individual contribution into a workin= g > group document. > > cheers, > > -ken > From gorry@erg.abdn.ac.uk Mon Oct 22 00:36:15 2012 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 A060521F8550; Mon, 22 Oct 2012 00:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNIhki2tU6DK; Mon, 22 Oct 2012 00:36:14 -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 8A78A21F854F; Mon, 22 Oct 2012 00:36:14 -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 A58902B4356; Mon, 22 Oct 2012 08:36:12 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 22 Oct 2012 08:36:12 +0100 Message-ID: <648f586cc4fa41164a9fd33dfa072aa8.squirrel@www.erg.abdn.ac.uk> Date: Mon, 22 Oct 2012 08:36:12 +0100 From: gorry@erg.abdn.ac.uk To: iesg-secretary@ietf.org, tsv-ads@ietf.org 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 X-Mailman-Approved-At: Mon, 22 Oct 2012 01:21:14 -0700 Cc: tsvwg-chairs@ietf.org Subject: [tsvwg] Request by TSV WG to publish draft-ietf-tsvwg-sctp-udp-encaps 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, 22 Oct 2012 07:36:15 -0000 ADs, I enclose a request by tsvwg to publish ""UDP Encapsulation of SCTP Packets". Gorry Fairhurst (TSV WG Co-Chair) ---- As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document is intended as a PS. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes a simple method of encapsulating SCTP Packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NAT not supporting SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP-layer, for example implementing it as part of the application without requiring special privileges. Working Group Summary There was consensus to adopt this as a WG document alongside other drafts in the Behave WG on NAT/NAPT traversal and agreement by the WG to publish this. Document Quality The document is complete. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? I am the document shepherd, G Fairhurst. The responsible AD is Wes Eddy. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. This draft was adopted as a work item 21 Sept 2011. WGLC completed Friday 20th April 2012, there was discussion and the draft was updated in response to discussion. There was agreement on these amendments. The specification in the document is believed to be implemented in FreeBSD. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes - they have confirmed conformance to BCP 78/79. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. As far as I know, no IPR disclosures have been submitted. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has WG support and there is consensus to publish. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) N/A. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There are no IANA requirements because this draft mentions only an already allocated port. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. From jsaldana@unizar.es Tue Oct 23 01:16:30 2012 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 51F7021F85A3; Tue, 23 Oct 2012 01:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.347 X-Spam-Level: X-Spam-Status: No, score=-6.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RFUuHzcdggE; Tue, 23 Oct 2012 01:16:24 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1117E21F8563; Tue, 23 Oct 2012 01:16:23 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q9N8GI74025748; Tue, 23 Oct 2012 10:16:18 +0200 From: "Jose Saldana" To: References: <00c401cdae02$a7b9ed40$f72dc7c0$@unizar.es> <201210191945.q9JJj96t029160@rcdn-core2-2.cisco.com> <7c2a90042fa8b65e9d51dde32ab82e11.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <7c2a90042fa8b65e9d51dde32ab82e11.squirrel@www.erg.abdn.ac.uk> Date: Tue, 23 Oct 2012 10:16:21 +0200 Organization: Universidad de Zaragoza Message-ID: <003501cdb0f6$afc9e520$0f5daf60$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG2sptoaZunU8wbOB1jbEmul7uvZgJOLxeuAqZxQVEA8iEu/pfBOuSQ Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsvwg@ietf.org Subject: Re: [tsvwg] TSVWG DRAFT STATUS October 2012 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:16:31 -0000 Hello, thanks for your feedback. Regrettably, I will not be able to attend the IETF meeting in Atlanta, = so there will be no possibility for me to organize a "side meeting". Thus, = we will have to work using the mailing lists (according to Scott Bradner's presentation for newcomers, "most working group work must be done on = mailing lists"). The Euro Zone crisis cannot stop this work. Nevertheless, I = will try to get funds to attend the next one in Orlando.=20 In the meantime, we are receiving a lot of feedback in the mailing list tcmtf@ietf.org, which will be taken into account for the next versions = of the draft(s). So the answer to the question of James is: perhaps the = number of interested people is still low, but it is growing. I have just = checked the archives, and 17 different people have posted something in the list (http://www.ietf.org/mail-archive/web/tcmtf/current/maillist.html). They = are from 13 different companies or universities. We have even received some feedback from LISP WG people.=20 As James says, we have to "jump through some hoops", but I think we have already jumped some of them. Thank you very much! Jose -----Mensaje original----- De: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk]=20 Enviado el: s=E1bado, 20 de octubre de 2012 9:17 Para: James Polk CC: jsaldana@unizar.es; tsvwg-chairs@ietf.org; tsvwg@ietf.org Asunto: Re: [tsvwg] TSVWG DRAFT STATUS October 2012 I agree. At the moment I do not see drafts from this group that look like they = are mature enough to progress within TSVWG. it t is hard to comment further though until we see a set of drafts that people may read. Gorry Fairhurst > At 09:04 AM 10/19/2012, Jose Saldana wrote: >>Hello. >> >>Regarding draft-saldana-tsvwg-tcmtf, the question is that there is a=20 >>specific mailing list (tcmtf@ietf.org), and we are currently=20 >>discussing about it there. One of the topics of the discussion is if a = >>Working Group should be created for it. This is the reason why it does = >>not appear in your mail, isn't it? > > correct > > General question - from your lists's discussions, is there enough=20 > interested people to think about attempting to form a WG, in your = view? > > If so, are you having an unofficial meeting (often called a 'Bar BoF', = > that doesn't meet during any other normal session slot to maximize=20 > attendance) during the Atlanta meeting? This type of meeting could=20 > demonstrate to the ADs that you might justify an official BoF at the=20 > next meeting (Orlando). There are some hoops that need to be jumped=20 > through though. I'm just wondering how far along and how organized=20 > your topic has come. > > James > > >>Thank you very much, >> >>Jose >> >> > -----Mensaje original----- >> > De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En=20 >> > nombre >> de >> > gorry@erg.abdn.ac.uk >> > Enviado el: viernes, 19 de octubre de 2012 12:10 >> > Para: tsvwg@ietf.org >> > Asunto: [tsvwg] TSVWG DRAFT STATUS October 2012 >> > >> > The list below shows the status of the working group documents as=20 >> > we >> see >> > it. Please check below and comment on drafts using the list. >> **PLEASE** do >> > send any corrections/omissions to the chairs. >> > >> > Best wishes, >> > >> > James, Rolf and Gorry >> > (TSVWG Chairs) >> > >> > --- >> > Recently published: >> > >> > draft-ietf-tsvwg-rsvp-security-groupkeying was published as RFC = 6411. >> > draft-ietf-tsvwg-sctpsocket was published as RFC 6458. >> > draft-ietf-tsvwg-sctp-strrst was published as RFC 6535. >> > draft-ietf-tsvwg-source-quench was published as RFC 6633. >> > >> > ------------------------------------------------------------------- >> > IDs in RFC Editor Queue: >> > http://www.rfc-editor.org/queue.html >> > None. >> > >> > ------------------------------------------------------------------- >> > IDs in IESG processing: >> > None. >> > >> > ------------------------------------------------------------------- >> > >> > NOTE: >> > ITU-T Study Group 12 - TSVWG needs to respond to the ITU-T Liaison=20 >> > on >> QoS >> > Classes & markings for interconnection >> > >> > ------------------------------------------------------------------- >> > >> > WG Drafts with Chairs: >> > >> > draft-ietf-tsvwg-sctp-udp-encap >> > (Replaced: draft-tuexen-sctp-udp-encap) Lars sent a note as AD=20 >> > agreeing to progress this work. >> > Work was coordinated with DCCP work on encaps. >> > draft-tuexen-sctp-udp-encaps-06, January 10, 2011 Adopted as a work >> item >> > 21 Sept 2011 (Gorry) WG -02 8 Dec 2011 WGLC completed Friday 20th >> April >> > 2012, many discussion and notes that there were implementations. >> > 13th Oct 2012, comments sent on draft to prepare for submission. >> > DUE: Revised ID needed prior to AD submission, changes agreed. >> > >> > --- >> > draft-ietf-tsvwg-byte-pkt-congest >> > New editor added Jul 2010. >> > New revision 25 Oct 2010. >> > WG -01, June 10, 2011 >> > IETF-81: discussed whether this should be BCP. >> > ADs & Chairs agree to progress as a BCP Status changed to BCP=20 >> > (new-ID WG -05) Presented at IETF-82 (Taipei), request for WGLC. >> > Gorry added as Shepherd (Jan 2012), Wes added as responsible AD=20 >> > (Jun 2012). >> > WGLC concluded with comments on I-D, Friday 30th March 2012. >> > Draft version of write-up sent to list, comments received. >> > - Gorry working with authors to clear list of WGLC questions (5=20 >> > sept >> 2012) >> > DUE: WG Chair waiting for version that includes additional feedback >> during >> > WGLC >> > >> > ------------------------------------------------------------------- >> > WG Drafts: >> > >> > draft-ietf-tsvwg-rsvp-pcn >> > Previous version : draft-karagiannis-pcn-tsvwg-rsvp-pcn >> > WG interest in this topic recorded at IETF-81. >> > Individual -01, 2011-07-11 >> > AD decision allowed this to be added to the milestones The document >> was >> > adopted, status will be EXP (IETF-84 due to dependencies on PCN=20 >> > RFCs) >> WG - >> > 00 8 Oct 2011 >> > DUE: Please comment on RVSP aspects (RSVP-DIR review requested 13th >> Oct >> > 2012) >> > >> > draft-ietf-tsvwg-natsupp-tsvwg >> > (Replaced: draft-stewart-natsupp-tsvwg)=20 >> > http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-natsupp/ >> > Dependency from BEHAVE WG. >> > Adopted as a work item 21 Sept 2010 (Gorry). >> > WG -00, 29/11/2010 >> > Uploaded as: draft-ietf-natsupp-tsvwg WG -01, June 1, 2011 Authors=20 >> > restructured draft (-03) >> > DUE: Discussion needed on list. >> > >> > draft-nishida-tsvwg-sctp-failover >> > Individual-00 Presented in Prague, IETF-80. >> > - understood not to conflict with draft-tuexen-tsvwg-sctp-multipath >> > - PF has been coded into FreeBSD >> > DUE: WG adoption being considered - please comment to list = 26/6/2012. >> > Adopted by WG >> > DUE: Please comment on list. >> > >> > draft-ietf-tsvwg-intserv-multiple-tspec >> > WG interest in this topic recorded at IETF-78. >> > Charter update would be needed to progress this work. >> > 5 Reviews needed to determine energy/technical direction. >> > WG -05 (presented in Beijing, IETF-79) WG -06 (presented in Prague, = >> > IETF-80) RSVP directorate was consulted. >> > 2 reviews from RSVP-DIR received (Bruce Davie, ?) >> > 2 additional reviews promised (Ken Carlberg, Francois LeF) Chairs >> asked AD >> > for a Charter update (IESG agreed) Draft discussed at IETF-80, and >> request >>to >> > update charter agreed >> > - AD advised 4 named reviewers will be required Adopted for >> progression as >> > PS, for May 2012 >> > - New approach presented following WG comments >> > DUE: Discussion needed on list. >> > >> > draft-ietf-tsvwg-port-use-00 >> > (replaces draft-touch-tsvwg-port-use-00) >> > - Intended to be advice to protocol designers needing a port. >> > 5 people have looked at this document, Prague IETF-80 Individual=20 >> > -01 >> July >> > 2011 >> > IETF-81 insufficient feedback from WG at this time. >> > WG needs to assess if the new draft should be a work item. >> > IETF-82, discussed - Chairs will ask WG to consider. >> > Adopted by WG >> > DUE: Revised ID expected to complete missing sections >> > >> > ------------------------------------------------------------------- >> > WG action required: >> > >> > draft-polk-tsvwg-rsvp-app-id-vv-profiles >> > -01 Presented in Beijing, IETF-79. >> > -02, 14-Mar-2011 >> > Presented IET-80. >> > WG needs to assess if the new draft should be a work item. >> > Seek to coordinate with music with partner ID: >> > draft-polk-mmusic-traffic-class-for-sdp >> > Author requests to make a WG work item... >> > Gorry liaised with MMUSIC WG Chairs on companion draft, intended=20 >> > for >> LC >> > early 2013. >> > Gorry - not much discussion on this list, please assess as a=20 >> > candidate >>working >> > document. >> > DUE: ***PLEASE*** comment on list. >> > >> > draft-polk-tsvwg-rfc4594-update >> > - noted at IETF-84, but not discussed (no time). >> > draft-polk-tsvwg-new-dscp-assignments >> > - noted at IETF-84, but not discussed (no time). >> > WG action required (Transport Protocols): >> > >> > draft-tuexen-tsvwg-sctp-multipath >> > -00 Presented in Prague, IETF-80. >> > - understood not to conflict with draft-nishida-tsvwg-sctp-failover >> -01, >>2010- >> > 12-27 >> > DUE: Please comment to list. >> > >> > ------------------------------------------------------------------- >> > The following have received recent discussion at TSVWG meetings or=20 >> > on >> the >> > list. Inclusion in the list below does not indicate support for=20 >> > these >>specific >> > drafts and other contributions are also warmly welcomed. >> > >> > draft-carlberg-tsvwg-ecn-reactions >> > Reactions to Signaling from ECN Support for RTP/RTCP >> > -00 presented IETF-82 >> > Not yet requested to become a work item. >> > - This draft is related to the new rmcat work. >> > DUE: Please comment on list. >> > >> > draft-tuexen-tsvwg-sctp-sack-immediately >> > -05, 2011-01-02 >> > - Aug 2011, discussed on list and issues raised. >> > DUE: Chairs need to confirm adoption (need to do work). >> > DUE: New revision need (to address comments) Please comment on = list. >> > >> > draft-stewart-tsvwg-sctpecn-02 >> > Partially replaces (draft-stewart-tsvwg-sctp-nonce) >> > IETF-78 suggested there was interest in this topic. >> > Discussed at IETF-83, Paris. >> > DUE: ECN is within the TSVWG Charter, will call for adoption on the = >> > list. >> > DUE: Please comment on list. >> > >> > draft-polk-tsvwg-rfc4594-update-00 >> > Discussed at IETF-83, Paris >> > DUE: A Revised ID is needed. >> > >> > ------------------------------------------------------------------- >> > Related non-TSVWG items: >> > >> > draft-ietf-behave-sctpnat-03.txt >> > BEHAVE WG item linked to SCTP encapsulation work. >> > >> > draft-ietf-6man-udpzero >> > Previously: draft-fairhurst-tsvwg-6man-udpzero >> > Draft was adopted by 6man, please discuss on the 6man list. >> > A WGLC of this draft is expected in 6MAN WG. >> > Related draft: draft-ietf-6man-udpchecksums-00 This draft was also >> LC'ed >>in >> > TSVWG (end 3rd May 2012) >> > >> > draft-ohanlon-rmcat-dflow >> > Discussed at IETF-84, Vancouver >> > This draft is related to the new rmcat work. >> > In IESG discussion on making this a PS for UDP tunnels using IPv6 >> > DUE: Revised ID needed >> > >> > ------------------------------------------------------------------ >> > Other news: >> > >> > RSVP Directorate (formed in May 2010) Charter updated Aug 2011. >> > New co-chair: Rolf Winter >> > >> > ITU-T Study Group 12 Liaison on QoS Classes & markings for >> interconnection > From lei.zhu@huawei.com Tue Oct 23 01:38:37 2012 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 4770D21F869E for ; Tue, 23 Oct 2012 01:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.548 X-Spam-Level: X-Spam-Status: No, score=-5.548 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Blev8dW5vJK for ; Tue, 23 Oct 2012 01:38:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 577E821F8690 for ; Tue, 23 Oct 2012 01:38:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALZ21182; Tue, 23 Oct 2012 08:38:35 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 09:38:28 +0100 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 09:38:33 +0100 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.86]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Tue, 23 Oct 2012 16:38:24 +0800 From: Zhulei To: "tsvwg@ietf.org" Thread-Topic: New draft needs readers Thread-Index: Ac2w+cF1BRCm7HLhRrGy7yQE+TVxAQ== Date: Tue, 23 Oct 2012 08:38:23 +0000 Message-ID: <470F27D1263A1B4EB73491ED995DE625249B572B@szxeml504-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.64.213] Content-Type: multipart/alternative; boundary="_000_470F27D1263A1B4EB73491ED995DE625249B572Bszxeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [tsvwg] New draft needs readers 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, 23 Oct 2012 08:38:37 -0000 --_000_470F27D1263A1B4EB73491ED995DE625249B572Bszxeml504mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, I would be seeing some of your reading 00-version draft http://tools.ietf.o= rg/html/draft-zhang-tsvwg-tunnel-congestion-exposure-00. This problem statement mentions the ingress of a tunnel protocol would be g= ood to read congestion feedback from egress of tunnel if ingress has policy= , flow control, admission control behavior. We assumed a possible standard proposal in this draft if we recognize this,= on the other hand marking problem is our issue may alternatively use PCN e= xtensions. Best regards, Zhu Lei Huawei Wireless network research department E-mail address: lei.zhu@huawei.com Phone: +86-10-60611961 Mobile: +86-13910157020 --_000_470F27D1263A1B4EB73491ED995DE625249B572Bszxeml504mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi folks,

 

I would be seeing some of your = reading 00-version draft http://tools.ietf.org/html/draft-zhang-tsvwg-tunnel-congestion-exposure-00<= /a>.

 

This problem statement mentions= the ingress of a tunnel protocol would be good to read congestion feedback= from egress of tunnel if ingress has policy, flow control, admission contr= ol behavior.

 

We assumed a possible standard = proposal in this draft if we recognize this, on the other hand marking prob= lem is our issue may alternatively use PCN extensions.

 

Best regards,=

Zhu Lei

Huawei

Wireless network research depar= tment

E-mail address: lei.zhu@huawei.= com

Phone: +86-10-60611961=

Mobile: +86-13910157020

 

--_000_470F27D1263A1B4EB73491ED995DE625249B572Bszxeml504mbxchi_-- From carlberg@g11.org.uk Tue Oct 23 06:15:31 2012 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 5D30921F8705 for ; Tue, 23 Oct 2012 06:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.045 X-Spam-Level: X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCeDR0pjftW7 for ; Tue, 23 Oct 2012 06:15:30 -0700 (PDT) Received: from portland.eukhosting.net (portland.ukserverhosting.net [92.48.103.133]) by ietfa.amsl.com (Postfix) with ESMTP id A8D1321F86FA for ; Tue, 23 Oct 2012 06:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=Mime-Version:To:Message-Id:Date:Subject:Content-Transfer-Encoding:Content-Type:From; bh=besAkfMnbzPsNBE9D8/QxBm6k+GaGcEzLVEzAwyrJyY=; b=L9Nkp3OGOoNdyh84eI+cNQTxfUs6lQ7xfCAivhzJ3M5OSkxvI1IXq8oudSbYa2mMtUNKQYMurUPIiwkoxOdYhqggRDs1bAKkwd3j/sC0+SmcYP35x7+AIt17IuRloNvB; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:56840 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.80) (envelope-from ) id 1TQeKK-0006ao-KH for tsvwg@ietf.org; Tue, 23 Oct 2012 13:15:24 +0000 From: ken carlberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Oct 2012 09:15:26 -0400 Message-Id: To: tsvwg Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Subject: [tsvwg] draft-carlberg-tsvwg-ecn-reactions -- which WG? 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, 23 Oct 2012 13:15:31 -0000 Hi, I've been asked publically and privately about my thoughts as to where = this document should end up -- TSVWG or RMCAT. When the question was = first brought up I was indifferent because I could see a case for both. = However, when I thought about it for a while, I felt more comfortable = advancing this through TSVWG. =20 The reason for this line of thoughts is that only a portion of the ECN = Reactions draft deals with congestion control algorithms. And while = RMCAT talks about the generic term of "mechanisms" in its charter, the = heart of the charter and deliverables seems to focus on algorithms, = which is really just one type of mechanism. On the other hand, the = Reactions draft looks into other "mechanisms" like FEC, signaling, and = most importantly, the impact of a set of users not responding to ECN. = And its this last item where we bring in some simulation work and is = probably the strongest reason (ie, the simulation results) as to why its = beneficial to have this in an IETF document. And its these other items = that seem out of scope of RMCAT. Assuming this draft is accepted as a working group item in TSVWG, I = would also want to send the document to RMCAT for review when we get to = a WG last call for comments stage, though I sure the core set of folks = will be attending both sets of meetings and mailing lists. If folks feel I've missed something, please don't be shy in letting us = know :-) -ken From carlberg@g11.org.uk Tue Oct 23 07:41:04 2012 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 25B1E1F0C61 for ; Tue, 23 Oct 2012 07:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=1.269, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqgjBqshV5lL for ; Tue, 23 Oct 2012 07:41:02 -0700 (PDT) Received: from portland.eukhosting.net (portland.ukserverhosting.net [92.48.103.133]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0D71F0C60 for ; Tue, 23 Oct 2012 07:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=wNJ28/0sq8xxegUmuVnN8nGEEI8a9fV0ZH4O2z3nldE=; b=UT+c1fDovxuzpje/98xIzwVhGFSaL/gCeOSuTqJjT4Yczc1WyWMxwwYpkBIu1yiDMZkjVCmORDHmN5QcklV0YlDAaoedux6f4rPBIn4MpX5s0/c7TEeune33xsvJL0Bl; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:57165 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.80) (envelope-from ) id 1TQff7-0008EP-Bt; Tue, 23 Oct 2012 14:40:57 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: ken carlberg In-Reply-To: Date: Tue, 23 Oct 2012 10:40:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <34FDE688-D697-4284-8F45-425EC4B0806E@g11.org.uk> References: <8C3E5C88-ED49-484A-BE24-A3CEBA2621E8@g11.org.uk> <9a8e932f4baf3964b931e7cfe7d64bdf.squirrel@www.erg.abdn.ac.uk> To: X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org Subject: Re: [tsvwg] draft-carlberg-tsvwg-ecn-reactions - Has anyone read this? 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, 23 Oct 2012 14:41:04 -0000 Ruediger. Thanks for your comments. > the topic in general is relevant for IETF, I think. draft-carlberg > mentions that recently the RTP Media Congestion Avoidance Techniques > (rmcat) working group has been set up. It would be useful to = understand > how draft-carlberg is related to the scope of the rmcat WG (e.g. > whether draft-carlberg only suggests a basic real time congestion > control mechanism and leaves all further work to rmcat). >=20 > Side-note: If congestion control is a chartered task of TSVWG, then = there > might be a question whether there's an overlap ov TSVWG and rmcat. ok, the previous email I sent out on whether the Reactions draft should = be in TSVWG or RMCAT should address this point. > Notes on the draft (in adddition to Bob's ones): >=20 > 5.1.2 Differentiated Services >=20 > As in the case of RSVP, applications could rely on the reception of = CE > feedback to initiate a subsequent setting of diff-serv code points = to > provide additional protection or explicit association of forwarding > characteristics of a given flow of packets. In addition, the = setting of > diff-serv code points would be done on an as-needed basis in = reaction to > CE feedback. Recommendations concerning specific diff-serv values = are > outside the scope of this document. >=20 > It is common to use words like "DiffServ Codepoint" to mean "a QoS = class" > (correct DiffServ wording "a PHB <-Group>"). The authors here want to > use an IP QoS class and should say so. There's no standard relation of > DiffServ Codepoints to IP QoS classes (PHB <-Groups>). >=20 > Apart from that, I wonder whether an application which had used class = X > so far can instantly and seemlessly flip to class Y. Especially, if > there's an expectation of admission control features in a traffic > class, it won't be done with simply marking traffic differently. > Admission Control doesn't mean RSVP to me, it could be measurement > based as well. PCN defines and discussed relevant mechanisms. The > issue here is, that admissiion control is performed prior to setting > up a media session, whereas here, the authors seem to suggest to = change > the class of a media session to avoid packet loss and queuing delay. several thoughts had come to mind in writing the original text above = that were to a degree scenario dependent. if we're talking about = interactive voice/video, one possibility existed in terms of adding EF = to the packet when congestion was occuring and potentially incuring an = additional "charge" for maintaining the minimal delay characteristics. = This was based on the assumption that the unmarked traffic was still = being forwarded with acceptable end-to-end delays during non-persistant = congested conditions. Or, another possibility could be a switch from EF = to the EF-admit code point to reflect the added admission control = attribute associated with the flow/packet. Another thought was to possibly use an AF code point for voice/video = traffic that was associated with a non-interactive broadcast type of = flow that could support a greater end-to-end delay while at the same = time trying to minimize loss. But as we stated in the text, we didn't = want to focus on one particular recommendation because these may very = per scenario and environment (e.g., public carrier/provider versus = private LMR). cheers, -ken ps, my comments to Bob's email will eventually hit the list. I sent it = from another email address, so it will have to be resent by the list = monitor. mea culpa. From p.ohanlon@gmail.com Tue Oct 23 08:19:52 2012 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 193A011E80CC for ; Tue, 23 Oct 2012 08:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5efYqtPfjCi for ; Tue, 23 Oct 2012 08:19:51 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D496A11E80A6 for ; Tue, 23 Oct 2012 08:19:50 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2411146wey.31 for ; Tue, 23 Oct 2012 08:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Tyd9CULrf4eFwCKeV6cGoEnqheWVzw6PsFg5Gmqnqto=; b=NN43QiRA1Acp6ybQIGZZGzjTd72NHQQwVaoYsKkdAt4F5ru/4dvVfUUXv2w9J1xJeq TkzosZu7dpp38Dr7WtdZvAHScoBgkEi0U/hodmbpVKiVEZNBeUNqrfstaePct6wlPBcw fMfaia7bv06X8r2nyD3xTSGOh/AGPrx28CnG8ERI2fGpV/p2mGyhnoE3Irw/xyOaR5ep iBo1wR02rlgEUHnxBWS6BqC2HT5ClAyJgSJf/mjS4lvuw7IKMeEiWv9Rrbxlqko8N59V OSkKIWAupL7zD7zZhfuxahevzdt9snPi3z7TXg5Ge6M/EmnkLHrYCZTKzwsSroULfmE+ pWqQ== Received: by 10.216.217.38 with SMTP id h38mr6857089wep.82.1351005585492; Tue, 23 Oct 2012 08:19:45 -0700 (PDT) Received: from ?IPv6:2001:470:1f09:d24:28a9:537e:d9ee:89a9? ([2001:470:1f09:d24:28a9:537e:d9ee:89a9]) by mx.google.com with ESMTPS id cn6sm28444061wib.9.2012.10.23.08.19.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Oct 2012 08:19:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Piers O'Hanlon In-Reply-To: <201210191729.q9JHTarm031903@bagheera.jungle.bt.co.uk> Date: Tue, 23 Oct 2012 16:19:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <89AE31B0-17D3-4526-BDF9-A4CE9578B5F1@gmail.com> References: <201210191729.q9JHTarm031903@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1283) Cc: Ken Carlberg , tsvwg IETF list Subject: Re: [tsvwg] Review of draft-carlberg-tsvwg-ecn-reactions-03 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, 23 Oct 2012 15:19:52 -0000 Hi Bob, Thanks for the review. Comments inline. On 19 Oct 2012, at 18:29, Bob Briscoe wrote: > Ken & Piers, >=20 > I finally got round to reviewing this draft. >=20 > 1/ Where you refer to RFC6679 as more fine-grained information than = TCP, you might want to refer to this one too, which the Vancouver TCPM = meeting agreed to include in the TCPM charter: > >=20 > There are currently two possible proposals to satisfy these = requirements: > > = >=20 Sure. > S.3.1 > " TFRC ... is seeing ... deployment in .... Empathy/Farsight, and = GoogleTalk [googl]. >=20 > However it should be noted that TFRC is only recommended for = real-time > media use with ECN response. TFRC is not recommended for non-ECN = paths > due to its loss based operation which leads to full queues with > maximised latencies. > " >=20 > Are you saying Empathy/Farsight and GoogleTalk only recommend TFRC if = with ECN, or is this document doing the recommending? >=20 We're just saying that TFRC has seen some [partial] deployment in = Empathy/Farsight and GoogleTalk. We suggested in the draft that if = you're going use TFRC then one should use TFRC with ECN. > "It is assumed that ECN markings will usually occur > with lower queue occupancy and thus lower latency. " >=20 > That can't be right. RFC3168 insists that an AQM signals ECN where it = would otherwise have signalled a drop for a non-ECN packet. There is = only one queue for them both, so the occupancy has to be the same for = both to satisfy RFC3168. >=20 > The whole point of the RFC3168 requirement is to ensure that non-ECN = cannot starve ECN traffic. If an AQM were to mark ECN traffic at a = shorter queue length, then non-ECN traffic would drive up the (same) = queue length to the larger non-ECN operating point, and the algo would = be marking ECN traffic with a lot higher probability than non-ECN. ECN = would then starve itself given RFC3168 insists an ECN transport is meant = to react to a mark as if it were a drop. >=20 > This assumption seems to be the justification for TFRC being = appropriate for ECN, where it might not be for non-ECN. If the = assumption isn't correct, where does that leave the main message of the = document? >=20 Sure - when comparing an ECN enabled RFC3168 compliant queue with and = without ECN. However it depends whether the queue complies with RFC3168 = - there are a number of alternative approaches using ECN but not = compliant to RFC3168 - such as DCTCP and others. Also there is quite a = bit of leeway in the definition of the AQM behaviour in RFC3168. But if = one is comparing an RFC3168 queue using ECN against against a drop-tail = queue then the ECN/RFC3168 queue is generally more favourable to = real-time flows due to the probabilistic nature of the marking/dropping. But to be fair you have a point in the case of a direct comparison of = RFC3168 ECN or drop. I think that the more important aspect of using = ECN is that it provide for back-off before loss occurs - allowing for = flows to adapt earlier and minimise loss. > S.5.2 Fault Tolerance > I don't see why either redundant (duplicate) transmission or FEC are = relevant to a document about using ECN, as opposed to loss, for = congestion signalling. >=20 Well one could take a variety of actions on the reception of ECN (or = loss) - the 3GPP specs suggest some interesting things... We've = mentioned them as they're one of many possibilities. > S.5.3 > I wholly agree that flows that consider themselves important could use = a substantially less aggressive back-off. But I complete exemption is of = great concern to me. Therein lies a congestion collapse. There is no = need for complete exemption, if a flow can respond very little to = congestion. At least then if congestion gets really bad, it will still = respond a lot. But if congestion is not so bad, it will seem pretty much = unresponsive. >=20 True complete exemption probably should not be generally used. > I know you report experiments where ECN exemption has limited effect = on normal flows, but the experiments assume low numbers of exempt flows = relative to non-exempt. Each individual flow cannot know whether that = assumption holds, so making this assumption is a recipe for boiling a = network during an emergency - just when we need it most. >=20 The simulations are of flows that have finite rate limits - so the = exempt can take all the bandwidth they need, leaving the rest to be = shared amongst the non-exempt flows. > S.5.3 > " This applies to all > flows that utilize some form of the rate control that is inversely > proportional to the loss rate, which includes TCP-like algorithms or > equation-based approaches. > " > s/inversely proportional to/inverse in some degree to/ >=20 Sure - we should add some 'approximate' qualification to that statement. > "Inversely proportional to" means rate =3D k/p, > where p is loss probability and k is a constant > TCP New Reno rate =3D k/p^0.5 > TFRC rate =3D k/p^0.5 > TCP Cubic rate =3D k/p^0.75 > Compound TCP rate =3D k/p^0.8 > None have rate =3D k/p >=20 > S.5.3. penultimate para: > I don't see how the normal flows can have a different latency from the = exempt flows. If they all share the same queue, they all see the same = latency at any one time. Certainly the average latency may be different = for long-running flows that are present during times when shorter flows = are there and when they are not. But the _instantaneous_ latency will be = the same for any flows sharing a single queue. >=20 Yes the delay incurred on the shared bottleneck queue is the same for = all flows, however relatively 'higher delay' seen by the exempt flows = but it is actually mostly in the sender node transmit queue (which is = the normal situation in this general scenario). That is where queuing = should be occurring most of the time as the access link (1Mb/s) is lower = than the backhaul link (100Mb/s) - it is in effect the bottleneck queue. = So the situation of higher delays is actually the norm and only when ECN = marking kicks in on the backhaul link does it actually lead to reduced = delays for those flows responding to the marking - reducing their rate - = and thus their delay. But the exempt flows that don't react to the = marking continue with their normal higher delay. The queue in the = backhaul link does build once the combined rates of the node exceeds the = backhaul capacity but as the other nodes are ECN enabled they reduce = their rate so that queue doesn't build beyond the [RED] queue marking = thresholds. >=20 > Nits: > S.3. s/to quickly/too quickly/ >=20 Thanks, Piers. >=20 > Bob >=20 >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 From ken.carlberg@gmail.com Tue Oct 23 06:45:11 2012 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 73A2321F8706 for ; Tue, 23 Oct 2012 06:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rFBkyU5scwe for ; Tue, 23 Oct 2012 06:45:09 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 01F0821F86F0 for ; Tue, 23 Oct 2012 06:45:08 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4640416vcb.31 for ; Tue, 23 Oct 2012 06:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=1oPPu1+ZF9zXuf5srwqPsupoalWvMpvA7rTBOmJUAG4=; b=Q27voqOelPV/O8YaTqd5GSseAMLryVsgyg/JZ0Pvh8KKLIq/jUrjqXnrM+LcHd3qAD PlACdNg2Goby9FUsKUtTMEDCIpzTBu9R0HsRvfgb58klkcLdlirmIR7SbAJE/XeO/2mT Tx2aWZSSsN6eds2sP+Zyo4B7POWC9dY1j+FH/n/dMPMnvG99e66TsrlhCQDQFDFh1dpo jkfCGS+u/ZgflSszHMd2mwcX2bL64Ik1lpwBiC2U/iOn2q6PoGjksbUoHl2MjEN6Hon1 QLPkQCnVdAi46FK/F4/Cg1nPj/blNImmqsUjwnIFhn0ZreF9kzLNUB2a5uHINkiTPac9 IJbQ== Received: by 10.220.157.75 with SMTP id a11mr2201233vcx.27.1350999905244; Tue, 23 Oct 2012 06:45:05 -0700 (PDT) Received: from [192.168.0.20] (c-76-111-69-4.hsd1.va.comcast.net. [76.111.69.4]) by mx.google.com with ESMTPS id l15sm13171675vdt.14.2012.10.23.06.45.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Oct 2012 06:45:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <201210191729.q9JHTarm031903@bagheera.jungle.bt.co.uk> Date: Tue, 23 Oct 2012 09:45:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7C75DFAD-B8B8-485B-B019-21BBCCE92D42@gmail.com> References: <201210191729.q9JHTarm031903@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Tue, 23 Oct 2012 09:55:15 -0700 Cc: Piers O'HANLON , tsvwg IETF list Subject: Re: [tsvwg] Review of draft-carlberg-tsvwg-ecn-reactions-03 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, 23 Oct 2012 13:45:12 -0000 Bob, thanks for the review. I'll take a stab at some of the comments, and = leave some fo the others for Piers to respond to (or correct me where he = may have a different opinion :-) > 1/ Where you refer to RFC6679 as more fine-grained information than = TCP, you might want to refer to this one too, which the Vancouver TCPM = meeting agreed to include in the TCPM charter: > >=20 > There are currently two possible proposals to satisfy these = requirements: > > = Agreed. Under the context you mention in terms of more granular = information, it sounds good to add text and the references to the above. > S.5.2 Fault Tolerance > I don't see why either redundant (duplicate) transmission or FEC are = relevant to a document about using ECN, as opposed to loss, for = congestion signalling. Its relevant in the sense that it is a *type* of reaction from the ECN = signaling. One vendor has told me in private that they have a = preference for this approach, and I think its of value because it = introduces the reaction on an ass needed basis instead of from the very = begining and through the session. But the gist of your concern is taken = and we should probably add text that if this kind of reaction is taken, = which would increase offered load, then an additional reaction (eg, = employing CC algorithm, swapping to a lower load codec) should/must also = be taken. > S.5.3 > I wholly agree that flows that consider themselves important could use = a substantially less aggressive back-off. But I complete exemption is of = great concern to me. Therein lies a congestion collapse. There is no = need for complete exemption, if a flow can respond very little to = congestion. At least then if congestion gets really bad, it will still = respond a lot. But if congestion is not so bad, it will seem pretty much = unresponsive. >=20 > I know you report experiments where ECN exemption has limited effect = on normal flows, but the experiments assume low numbers of exempt flows = relative to non-exempt. Each individual flow cannot know whether that = assumption holds, so making this assumption is a recipe for boiling a = network during an emergency - just when we need it most. points well taken. Within the context of the IETF, ETS is a generic = term for preferential services that are deployed in some form in some of = today's cellular networks. And the numbers in terms of percentage of = ETS users we used in our simulation are reflective at a very high and = abstract level of what exists today in some cases. (I'm sorry to be = hand wavy, but I'm trying to be careful in my statements). And we also agree that individual flows from the end-host/UE perspective = will not know what percentage of exempt users co-exist in the same = "area" where congestion has occured. This is why we added the word = "authorized" to help distinguish the two sets in that some added element = needs to exist to help minimize the set of exempt users. We also would agree that it would be preferable to have a less = aggressive back-off algorithm for these otehrs users -- particularly in = the case of typically higher bandwidth video users. There is an ITU = document that is also discussing this same topic. One thing to keep in mind is that the Reactions draft isn't meant to be = a recommendation of what should be done. Its means to be information = and point out what can be done. However, I think the section can be = improved a bit to make sure the concern you bring up above is well = understood. > S.5.3 > " This applies to all > flows that utilize some form of the rate control that is inversely > proportional to the loss rate, which includes TCP-like algorithms or > equation-based approaches. > " > s/inversely proportional to/inverse in some degree to/ >=20 > "Inversely proportional to" means rate =3D k/p, > where p is loss probability and k is a constant > TCP New Reno rate =3D k/p^0.5 > TFRC rate =3D k/p^0.5 > TCP Cubic rate =3D k/p^0.75 > Compound TCP rate =3D k/p^0.8 > None have rate =3D k/p okey dokey and thanks again for the comments. -ken From bob.briscoe@bt.com Tue Oct 23 11:22:14 2012 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 A79B611E80FF for ; Tue, 23 Oct 2012 11:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRjcFAjvIw0J for ; Tue, 23 Oct 2012 11:22:14 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 8247F11E8101 for ; Tue, 23 Oct 2012 11:22:13 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 23 Oct 2012 19:22:11 +0100 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 23 Oct 2012 19:22:10 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.309.2; Tue, 23 Oct 2012 19:22:10 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1351016528778; Tue, 23 Oct 2012 19:22:08 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q9NIM8hP021179; Tue, 23 Oct 2012 19:22:08 +0100 Message-ID: <201210231822.q9NIM8hP021179@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 23 Oct 2012 19:22:11 +0100 To: ken carlberg From: Bob Briscoe In-Reply-To: <7C75DFAD-B8B8-485B-B019-21BBCCE92D42@gmail.com> References: <201210191729.q9JHTarm031903@bagheera.jungle.bt.co.uk> <7C75DFAD-B8B8-485B-B019-21BBCCE92D42@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: Piers O'HANLON , tsvwg IETF list Subject: Re: [tsvwg] Review of draft-carlberg-tsvwg-ecn-reactions-03 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, 23 Oct 2012 18:22:14 -0000 Ken, At 14:45 23/10/2012, ken carlberg wrote: >Bob, > >thanks for the review. I'll take a stab at some of the comments, >and leave some fo the others for Piers to respond to (or correct me >where he may have a different opinion :-) > > S.5.2 Fault Tolerance > > I don't see why either redundant (duplicate) transmission or FEC > are relevant to a document about using ECN, as opposed to loss, for > congestion signalling. > >Its relevant in the sense that it is a *type* of reaction from the >ECN signaling. One vendor has told me in private that they have a >preference for this approach, and I think its of value because it >introduces the reaction on an ass needed basis instead of from the >very begining and through the session. But the gist of your concern >is taken and we should probably add text that if this kind of >reaction is taken, which would increase offered load, then an >additional reaction (eg, employing CC algorithm, swapping to a lower >load codec) should/must also be taken. I clearly don't understand what S5.2 is about (which may be taken as a hint that the doc probably needs to explain better). I still don't get it... redundancy & FEC fix loss. ECN isn't a loss, so why would anyone trigger a redundant transmission or FEC after an ECN mark? > > S.5.3 > > I wholly agree that flows that consider themselves important > could use a substantially less aggressive back-off. But I complete > exemption is of great concern to me. Therein lies a congestion > collapse. There is no need for complete exemption, if a flow can > respond very little to congestion. At least then if congestion gets > really bad, it will still respond a lot. But if congestion is not > so bad, it will seem pretty much unresponsive. > > > > I know you report experiments where ECN exemption has limited > effect on normal flows, but the experiments assume low numbers of > exempt flows relative to non-exempt. Each individual flow cannot > know whether that assumption holds, so making this assumption is a > recipe for boiling a network during an emergency - just when we need it most. > >points well taken. Within the context of the IETF, ETS is a generic >term for preferential services that are deployed in some form in >some of today's cellular networks. And the numbers in terms of >percentage of ETS users we used in our simulation are reflective at >a very high and abstract level of what exists today in some >cases. (I'm sorry to be hand wavy, but I'm trying to be careful in >my statements). > >And we also agree that individual flows from the end-host/UE >perspective will not know what percentage of exempt users co-exist >in the same "area" where congestion has occured. This is why we >added the word "authorized" to help distinguish the two sets in that >some added element needs to exist to help minimize the set of exempt users. Even if you're talking about authorized users, if you get an emergency, you might get an influx of authorized users into an area to deal with the emergency. I don't need to teach granny that the main characteristic of emergencies is unpredictability. >We also would agree that it would be preferable to have a less >aggressive back-off algorithm for these otehrs users -- particularly >in the case of typically higher bandwidth video users. There is an >ITU document that is also discussing this same topic. > >One thing to keep in mind is that the Reactions draft isn't meant to >be a recommendation of what should be done. Its means to be >information and point out what can be done. However, I think the >section can be improved a bit to make sure the concern you bring up >above is well understood. Yup, certainly. >and thanks again for the comments. No problem. Now on to Piers's Bob >-ken ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Tue Oct 23 11:49:53 2012 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 9DD6D1F0CA6 for ; Tue, 23 Oct 2012 11:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.936 X-Spam-Level: X-Spam-Status: No, score=-2.936 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyZxzch0NZU6 for ; Tue, 23 Oct 2012 11:49:52 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 5B07F1F0CA4 for ; Tue, 23 Oct 2012 11:49:51 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 23 Oct 2012 19:49:49 +0100 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 23 Oct 2012 19:49:48 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.309.2; Tue, 23 Oct 2012 19:49:45 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1351018184313; Tue, 23 Oct 2012 19:49:44 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q9NIngtU021236; Tue, 23 Oct 2012 19:49:42 +0100 Message-ID: <201210231849.q9NIngtU021236@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 23 Oct 2012 19:49:46 +0100 To: Piers O'Hanlon From: Bob Briscoe In-Reply-To: <89AE31B0-17D3-4526-BDF9-A4CE9578B5F1@gmail.com> References: <201210191729.q9JHTarm031903@bagheera.jungle.bt.co.uk> <89AE31B0-17D3-4526-BDF9-A4CE9578B5F1@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: Ken Carlberg , tsvwg IETF list Subject: Re: [tsvwg] Review of draft-carlberg-tsvwg-ecn-reactions-03 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, 23 Oct 2012 18:49:53 -0000 Piers, At 16:19 23/10/2012, Piers O'Hanlon wrote: >Hi Bob, > >Thanks for the review. Comments inline. > >On 19 Oct 2012, at 18:29, Bob Briscoe wrote: > > > Ken & Piers, > > > > I finally got round to reviewing this draft. > > S.3.1 > > " TFRC ... is seeing ... deployment in .... Empathy/Farsight, > and GoogleTalk [googl]. > > > > However it should be noted that TFRC is only recommended for real-time > > media use with ECN response. TFRC is not recommended for non-ECN paths > > due to its loss based operation which leads to full queues with > > maximised latencies. > > " > > > > Are you saying Empathy/Farsight and GoogleTalk only recommend > TFRC if with ECN, or is this document doing the recommending? > > >We're just saying that TFRC has seen some [partial] deployment in >Empathy/Farsight and GoogleTalk. We suggested in the draft that if >you're going use TFRC then one should use TFRC with ECN. [BB]: My point was merely to suggest you clarify the text - putting 'recommended' in the passive voice makes it unclear whether you or Google are doing the recommending. > > "It is assumed that ECN markings will usually occur > > with lower queue occupancy and thus lower latency. " > > > > That can't be right. RFC3168 insists that an AQM signals ECN > where it would otherwise have signalled a drop for a non-ECN > packet. There is only one queue for them both, so the occupancy has > to be the same for both to satisfy RFC3168. > > > > The whole point of the RFC3168 requirement is to ensure that > non-ECN cannot starve ECN traffic. If an AQM were to mark ECN > traffic at a shorter queue length, then non-ECN traffic would drive > up the (same) queue length to the larger non-ECN operating point, > and the algo would be marking ECN traffic with a lot higher > probability than non-ECN. ECN would then starve itself given > RFC3168 insists an ECN transport is meant to react to a mark as if > it were a drop. > > > > This assumption seems to be the justification for TFRC being > appropriate for ECN, where it might not be for non-ECN. If the > assumption isn't correct, where does that leave the main message of > the document? > > >Sure - when comparing an ECN enabled RFC3168 compliant queue with >and without ECN. However it depends whether the queue complies with >RFC3168 - there are a number of alternative approaches using ECN but >not compliant to RFC3168 - such as DCTCP and others. Also there is >quite a bit of leeway in the definition of the AQM behaviour in RFC3168. [BB]: I should have been clearer. The requirement of RFC3168 for the queue to behave equivalently for drop and ECN packets isn't just a quirk of RFC3168, it's very hard (impossible?) to avoid starvation of one or the other (ECN or non-ECN) unless the queue uses the same algorithm and parameters for both. > But if one is comparing an RFC3168 queue using ECN against against > a drop-tail queue then the ECN/RFC3168 queue is generally more > favourable to real-time flows due to the probabilistic nature of > the marking/dropping. [BB]: Eh? There aren't two queues. There's only one. If there were two queues, it would be hard (impossible?) to know which one to serve by how much given packets sometimes arriving as ECN and sometimes not - I suspect even an adaptive approach would just end up looking like a single FIFO. I gave a presentation at the last IETF (Transport Area Plenary) about a possible way to get DCTCP/ECN to interwork with classic non-ECN traffic (well I would have, but I was cut short due to severe overrun of the previous speaker). Here's what I would have said: >But to be fair you have a point in the case of a direct comparison >of RFC3168 ECN or drop. I think that the more important aspect of >using ECN is that it provide for back-off before loss occurs - >allowing for flows to adapt earlier and minimise loss. [BB]: There is a more subtle sense in which ECN reduces latency. I just wrote it into the opening para of this draft I just posted: " as ECN is used more widely by end-systems, it will gradually remove the need to configure a degree of delay into buffers before they start to notify congestion (the cause of bufferbloat). The latter delay is because drop involves a trade-off between sending a timely signal and trying to avoid impairment, whereas ECN is solely a signal so there is no harm triggering it earlier. " This is an emergent property that would only happen if ECN became predominant, so that the optimum point to set AQM parameters was determined mostly by ECN users, not legacy (drop) users. > > S.5.2 Fault Tolerance > > I don't see why either redundant (duplicate) transmission or FEC > are relevant to a document about using ECN, as opposed to loss, for > congestion signalling. > > >Well one could take a variety of actions on the reception of ECN (or >loss) - the 3GPP specs suggest some interesting things... We've >mentioned them as they're one of many possibilities. [BB]: I suggest there's no need to repeat things other people say unless they make sense. I still don't understand why these things make sense. > > S.5.3 > > I wholly agree that flows that consider themselves important > could use a substantially less aggressive back-off. But I complete > exemption is of great concern to me. Therein lies a congestion > collapse. There is no need for complete exemption, if a flow can > respond very little to congestion. At least then if congestion gets > really bad, it will still respond a lot. But if congestion is not > so bad, it will seem pretty much unresponsive. > > >True complete exemption probably should not be generally used. [BB]: I agree, if you delete 'generally' :) > > I know you report experiments where ECN exemption has limited > effect on normal flows, but the experiments assume low numbers of > exempt flows relative to non-exempt. Each individual flow cannot > know whether that assumption holds, so making this assumption is a > recipe for boiling a network during an emergency - just when we need it most. > > >The simulations are of flows that have finite rate limits - so the >exempt can take all the bandwidth they need, leaving the rest to be >shared amongst the non-exempt flows. [BB]: As I said, this depends on an assumption about proportions. > > S.5.3. penultimate para: > > I don't see how the normal flows can have a different latency > from the exempt flows. If they all share the same queue, they all > see the same latency at any one time. Certainly the average latency > may be different for long-running flows that are present during > times when shorter flows are there and when they are not. But the > _instantaneous_ latency will be the same for any flows sharing a single queue. > > >Yes the delay incurred on the shared bottleneck queue is the same >for all flows, however relatively 'higher delay' seen by the exempt >flows but it is actually mostly in the sender node transmit queue >(which is the normal situation in this general scenario). That is >where queuing should be occurring most of the time as the access >link (1Mb/s) is lower than the backhaul link (100Mb/s) - it is in >effect the bottleneck queue. So the situation of higher delays is >actually the norm and only when ECN marking kicks in on the backhaul >link does it actually lead to reduced delays for those flows >responding to the marking - reducing their rate - and thus their >delay. But the exempt flows that don't react to the marking continue >with their normal higher delay. The queue in the backhaul link does >build once the combined rates of the node exceeds the backhaul >capacity but as the other nodes are ECN enabled they reduce their >rate so that queue doesn't build beyond the [RED] queue marking thresholds. [BB]: OK, I can see the point. I assume you are interpreting the results of a test or simulation here. I guess what you've actually got is a bottleneck shuttling between two points, so the explanation is a bit more complicated, but I get the idea. >Thanks, > >Piers. Cheers Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From carlberg@g11.org.uk Tue Oct 23 12:08:41 2012 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 7E0D811E80A4 for ; Tue, 23 Oct 2012 12:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=0.952, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vK2AHV53exRF for ; Tue, 23 Oct 2012 12:08:40 -0700 (PDT) Received: from portland.eukhosting.net (portland.ukserverhosting.net [92.48.103.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3CED321F864A for ; Tue, 23 Oct 2012 12:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=DJxSlOoP4EMRRuLxrpm29Zpqo7nMtIZVhretgMz++h8=; b=OLeGpgdRLItuxBNOrIuU4LVy42AThFMm3b0tsxLxdStalZzdtMRXHAoKDuxUzl1Eq3XiuzpusXxWqfxo0N9xH3OpfttnW0faI2LwtTEHWUR99ypsgphR2f60N/u2DT5K; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:57942 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.80) (envelope-from ) id 1TQjq6-0004Ld-PO; Tue, 23 Oct 2012 19:08:34 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <201210231822.q9NIM8hP021179@bagheera.jungle.bt.co.uk> Date: Tue, 23 Oct 2012 15:08:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8DD13F65-E4BB-4D07-8E7A-016F72F65A84@g11.org.uk> References: <201210191729.q9JHTarm031903@bagheera.jungle.bt.co.uk> <7C75DFAD-B8B8-485B-B019-21BBCCE92D42@gmail.com> <201210231822.q9NIM8hP021179@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: Piers O'HANLON , tsvwg IETF list Subject: Re: [tsvwg] Review of draft-carlberg-tsvwg-ecn-reactions-03 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, 23 Oct 2012 19:08:41 -0000 Bob, >> Its relevant in the sense that it is a *type* of reaction from the = ECN signaling. One vendor has told me in private that they have a = preference for this approach, and I think its of value because it = introduces the reaction on an ass needed basis instead of from the very = begining and through the session. But the gist of your concern is taken = and we should probably add text that if this kind of reaction is taken, = which would increase offered load, then an additional reaction (eg, = employing CC algorithm, swapping to a lower load codec) should/must also = be taken. >=20 > I clearly don't understand what S5.2 is about (which may be taken as a = hint that the doc probably needs to explain better). I still don't get = it... redundancy & FEC fix loss. ECN isn't a loss, so why would anyone = trigger a redundant transmission or FEC after an ECN mark? because its generally a fine line between the ECN marking and the point = where one needs to acually drop the packet because of queue overflow = (keeping in mind that we don't want huge queues for RTP flows). We've = done one simulation effort and a couple of implementations. And in the = latter case, it was a bit of a challenge to get that sweet spot of = generating traffic (in our case, from an actual video feed) that = triggered the ECN markings without overflowing the queue. And even = then, unless the feedback came back soon enough and there wasn't a = continually added influx of flows from additional users (eg, a flash = crowd), then the chances were quite good that some packets would be = dropped after the initial CE feedback occured. If my application or = session is considered mission critical, then using FEC in anticipation = of lost packets and only done as needed versus the lifetime of the = entire flowis a good thing. We'll definitely have to add some text to clarify our thought process on = this particular topic. >> > S.5.3 >> points well taken. Within the context of the IETF, ETS is a generic = term for preferential services that are deployed in some form in some of = today's cellular networks. And the numbers in terms of percentage of = ETS users we used in our simulation are reflective at a very high and = abstract level of what exists today in some cases. (I'm sorry to be = hand wavy, but I'm trying to be careful in my statements). >>=20 >> And we also agree that individual flows from the end-host/UE = perspective will not know what percentage of exempt users co-exist in = the same "area" where congestion has occured. This is why we added the = word "authorized" to help distinguish the two sets in that some added = element needs to exist to help minimize the set of exempt users. >=20 > Even if you're talking about authorized users, if you get an = emergency, you might get an influx of authorized users into an area to = deal with the emergency. I don't need to teach granny that the main = characteristic of emergencies is unpredictability. the numbers I've come across with today's deployed services in some = cellular networks has shown that less than 1% within a cellular = footprint are these "authorized" users. In our simulations, we aimed at = a worse case scenario of 10%. And yes, unpredicability is still a cause = for heartburn. =20 cheers, -ken From p.ohanlon@gmail.com Tue Oct 23 14:08:38 2012 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 C77C811E80A3 for ; Tue, 23 Oct 2012 14:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3i2ah7uQtBNJ for ; Tue, 23 Oct 2012 14:08:37 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB2C1F0424 for ; Tue, 23 Oct 2012 14:08:37 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so2396085wgb.13 for ; Tue, 23 Oct 2012 14:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=UYkFWVHH9G23wNuUkr22XninbOm1ghmPhuZBUF941xg=; b=kyQGcRT4dW5ClfGQX4vS+kYnZ4oAKpz0Jn14v3gNjy/pMur4rwuPut4iBVFo/Kict7 krY/jLFiijIMQU0bLCTG8CndNWWU9jZbQCBTGexn4IsyoBirEn17gPedc76lhyBzHKb1 sXZeaymsbJ6MP5/NWkKfGQkCb8gla3kjDKmhmWy3sbrRT2yvFObpXfidVAmWv/19Irsv B9xK93kaCeIGZtmdRWLJbhuBe2SV61dHijoZuDxhgLArlR4KKwsOpPcKoUOSW5I/X0He YXFTSoXt2pW7oEgPn80HCDUbyR0+hWB8lqSWgaF+JkYJE4nJ0GQWd4hTfMSLbvt366r7 8r2Q== Received: by 10.216.135.24 with SMTP id t24mr7831535wei.147.1351026516608; Tue, 23 Oct 2012 14:08:36 -0700 (PDT) Received: from black.lan ([149.241.132.141]) by mx.google.com with ESMTPS id ei1sm776512wid.7.2012.10.23.14.08.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Oct 2012 14:08:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Piers O'Hanlon In-Reply-To: <201210231849.q9NIngtU021236@bagheera.jungle.bt.co.uk> Date: Tue, 23 Oct 2012 22:08:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4F541946-BEB3-45C4-8167-349322CEA8F4@gmail.com> References: <201210191729.q9JHTarm031903@bagheera.jungle.bt.co.uk> <89AE31B0-17D3-4526-BDF9-A4CE9578B5F1@gmail.com> <201210231849.q9NIngtU021236@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1283) Cc: Ken Carlberg , tsvwg IETF list Subject: Re: [tsvwg] Review of draft-carlberg-tsvwg-ecn-reactions-03 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, 23 Oct 2012 21:08:38 -0000 Bob, On 23 Oct 2012, at 19:49, Bob Briscoe wrote: > Piers, >=20 > At 16:19 23/10/2012, Piers O'Hanlon wrote: >> Hi Bob, >>=20 >> Thanks for the review. Comments inline. >>=20 >> On 19 Oct 2012, at 18:29, Bob Briscoe wrote: >>=20 >> > Ken & Piers, >> > >> > I finally got round to reviewing this draft. >=20 >=20 >> > S.3.1 >> > " TFRC ... is seeing ... deployment in .... Empathy/Farsight, and = GoogleTalk [googl]. >> > >> > However it should be noted that TFRC is only recommended for = real-time >> > media use with ECN response. TFRC is not recommended for non-ECN = paths >> > due to its loss based operation which leads to full queues with >> > maximised latencies. >> > " >> > >> > Are you saying Empathy/Farsight and GoogleTalk only recommend TFRC = if with ECN, or is this document doing the recommending? >> > >> We're just saying that TFRC has seen some [partial] deployment in = Empathy/Farsight and GoogleTalk. We suggested in the draft that if = you're going use TFRC then one should use TFRC with ECN. >=20 > [BB]: My point was merely to suggest you clarify the text - putting = 'recommended' in the passive voice makes it unclear whether you or = Google are doing the recommending. >=20 Sure. >> > "It is assumed that ECN markings will usually occur >> > with lower queue occupancy and thus lower latency. " >> > >> > That can't be right. RFC3168 insists that an AQM signals ECN where = it would otherwise have signalled a drop for a non-ECN packet. There is = only one queue for them both, so the occupancy has to be the same for = both to satisfy RFC3168. >> > >> > The whole point of the RFC3168 requirement is to ensure that = non-ECN cannot starve ECN traffic. If an AQM were to mark ECN traffic at = a shorter queue length, then non-ECN traffic would drive up the (same) = queue length to the larger non-ECN operating point, and the algo would = be marking ECN traffic with a lot higher probability than non-ECN. ECN = would then starve itself given RFC3168 insists an ECN transport is meant = to react to a mark as if it were a drop. >> > >> > This assumption seems to be the justification for TFRC being = appropriate for ECN, where it might not be for non-ECN. If the = assumption isn't correct, where does that leave the main message of the = document? >> > >> Sure - when comparing an ECN enabled RFC3168 compliant queue with and = without ECN. However it depends whether the queue complies with RFC3168 = - there are a number of alternative approaches using ECN but not = compliant to RFC3168 - such as DCTCP and others. Also there is quite a = bit of leeway in the definition of the AQM behaviour in RFC3168. >=20 > [BB]: I should have been clearer. The requirement of RFC3168 for the = queue to behave equivalently for drop and ECN packets isn't just a quirk = of RFC3168, it's very hard (impossible?) to avoid starvation of one or = the other (ECN or non-ECN) unless the queue uses the same algorithm and = parameters for both. >=20 Agreed. >> But if one is comparing an RFC3168 queue using ECN against against a = drop-tail queue then the ECN/RFC3168 queue is generally more favourable = to real-time flows due to the probabilistic nature of the = marking/dropping. >=20 > [BB]: Eh? There aren't two queues. There's only one. If there were two = queues, it would be hard (impossible?) to know which one to serve by how = much given packets sometimes arriving as ECN and sometimes not - I = suspect even an adaptive approach would just end up looking like a = single FIFO. >=20 I was talking of a more of general comparison where one might consider = running TFRC on a droptail based network vs another one than runs ECN = enabled queues. > I gave a presentation at the last IETF (Transport Area Plenary) about = a possible way to get DCTCP/ECN to interwork with classic non-ECN = traffic (well I would have, but I was cut short due to severe overrun of = the previous speaker). Here's what I would have said: > >=20 >> But to be fair you have a point in the case of a direct comparison of = RFC3168 ECN or drop. I think that the more important aspect of using = ECN is that it provide for back-off before loss occurs - allowing for = flows to adapt earlier and minimise loss. >=20 > [BB]: There is a more subtle sense in which ECN reduces latency. I = just wrote it into the opening para of this draft I just posted: > = >=20 > " as ECN is > used more widely by end-systems, it will gradually remove the need = to > configure a degree of delay into buffers before they start to notify > congestion (the cause of bufferbloat). The latter delay is because > drop involves a trade-off between sending a timely signal and trying > to avoid impairment, whereas ECN is solely a signal so there is no > harm triggering it earlier. > " > This is an emergent property that would only happen if ECN became = predominant, so that the optimum point to set AQM parameters was = determined mostly by ECN users, not legacy (drop) users. >=20 Ok sounds good - though isn't one still limited by the BDP queue size = needed to accommodate TCP flows? >> > S.5.2 Fault Tolerance >> > I don't see why either redundant (duplicate) transmission or FEC = are relevant to a document about using ECN, as opposed to loss, for = congestion signalling. >> > >> Well one could take a variety of actions on the reception of ECN (or = loss) - the 3GPP specs suggest some interesting things... We've = mentioned them as they're one of many possibilities. >=20 > [BB]: I suggest there's no need to repeat things other people say = unless they make sense. I still don't understand why these things make = sense. >=20 You don't see why FEC makes sense as congestion reaction (or you're not = keen on FEC in general)? >=20 >> > S.5.3 >> > I wholly agree that flows that consider themselves important could = use a substantially less aggressive back-off. But I complete exemption = is of great concern to me. Therein lies a congestion collapse. There is = no need for complete exemption, if a flow can respond very little to = congestion. At least then if congestion gets really bad, it will still = respond a lot. But if congestion is not so bad, it will seem pretty much = unresponsive. >> > >> True complete exemption probably should not be generally used. >=20 > [BB]: I agree, if you delete 'generally' :) >=20 I thought you might say that! >=20 >> > I know you report experiments where ECN exemption has limited = effect on normal flows, but the experiments assume low numbers of exempt = flows relative to non-exempt. Each individual flow cannot know whether = that assumption holds, so making this assumption is a recipe for boiling = a network during an emergency - just when we need it most. >> > >> The simulations are of flows that have finite rate limits - so the = exempt can take all the bandwidth they need, leaving the rest to be = shared amongst the non-exempt flows. >=20 > [BB]: As I said, this depends on an assumption about proportions. >=20 Sure. >> > S.5.3. penultimate para: >> > I don't see how the normal flows can have a different latency from = the exempt flows. If they all share the same queue, they all see the = same latency at any one time. Certainly the average latency may be = different for long-running flows that are present during times when = shorter flows are there and when they are not. But the _instantaneous_ = latency will be the same for any flows sharing a single queue. >> > >> Yes the delay incurred on the shared bottleneck queue is the same for = all flows, however relatively 'higher delay' seen by the exempt flows = but it is actually mostly in the sender node transmit queue (which is = the normal situation in this general scenario). That is where queuing = should be occurring most of the time as the access link (1Mb/s) is lower = than the backhaul link (100Mb/s) - it is in effect the bottleneck queue. = So the situation of higher delays is actually the norm and only when ECN = marking kicks in on the backhaul link does it actually lead to reduced = delays for those flows responding to the marking - reducing their rate - = and thus their delay. But the exempt flows that don't react to the = marking continue with their normal higher delay. The queue in the = backhaul link does build once the combined rates of the node exceeds the = backhaul capacity but as the other nodes are ECN enabled they reduce = their rate so that queue doesn't build beyond the [RED] queue marking = thresholds. >=20 > [BB]: OK, I can see the point. I assume you are interpreting the = results of a test or simulation here. I guess what you've actually got = is a bottleneck shuttling between two points, so the explanation is a = bit more complicated, but I get the idea. >=20 Right. Cheers, Piers >> Thanks, >>=20 >> Piers. >=20 > Cheers >=20 >=20 > Bob >=20 >=20 >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 From Ruediger.Geib@telekom.de Tue Oct 23 23:50:37 2012 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 D5E2321F8C88 for ; Tue, 23 Oct 2012 23:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.920, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1VzAy0hI2S7 for ; Tue, 23 Oct 2012 23:50:33 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id E1CED21F8C94 for ; Tue, 23 Oct 2012 23:50:22 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 24 Oct 2012 08:50:20 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Wed, 24 Oct 2012 08:50:20 +0200 From: To: Date: Wed, 24 Oct 2012 08:50:19 +0200 Thread-Topic: [tsvwg] draft-carlberg-tsvwg-ecn-reactions - Has anyone read this? Thread-Index: Ac2xLR/1DMFt7+NtRWOGfDUtaddTxwAg7Dkg Message-ID: References: <8C3E5C88-ED49-484A-BE24-A3CEBA2621E8@g11.org.uk> <9a8e932f4baf3964b931e7cfe7d64bdf.squirrel@www.erg.abdn.ac.uk> <34FDE688-D697-4284-8F45-425EC4B0806E@g11.org.uk> In-Reply-To: <34FDE688-D697-4284-8F45-425EC4B0806E@g11.org.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] draft-carlberg-tsvwg-ecn-reactions - Has anyone read this? 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, 24 Oct 2012 06:50:38 -0000 Ken, it's not relevant which QoS class is used in particular (EF or AF). My comment didn't relate to a specific QoS class, it relates to QoS usage in general. The point is, it's not simply done by setting DiffServ codepoints in all operational environments. All those where e.g. admission control is applied will have a mechanism to decide whether an additional flow can be admitted prior to remarking. This mechanism must be addressed You further assume that nothing like QoS aware routing is deployed (i.e. you assume packets of a flow take the same path independant of the DSCP). That holds today I guess, but it may not hold in future. Wireless 4G networks (on which I'm not an expert!) may neither allow you to simply change DSCPs nor offer the same delay properties in different traffic classes. To sum up: simply changing DSCPs may help in a limited set of operational environments. Your text should reflect that. Regards, Ruediger > Notes on the draft (in adddition to Bob's ones): > > 5.1.2 Differentiated Services > > As in the case of RSVP, applications could rely on the reception of CE > feedback to initiate a subsequent setting of diff-serv code points to > provide additional protection or explicit association of forwarding > characteristics of a given flow of packets. In addition, the setting o= f > diff-serv code points would be done on an as-needed basis in reaction t= o > CE feedback. Recommendations concerning specific diff-serv values are > outside the scope of this document. > > It is common to use words like "DiffServ Codepoint" to mean "a QoS class" > (correct DiffServ wording "a PHB <-Group>"). The authors here want to > use an IP QoS class and should say so. There's no standard relation of > DiffServ Codepoints to IP QoS classes (PHB <-Groups>). > > Apart from that, I wonder whether an application which had used class X > so far can instantly and seemlessly flip to class Y. Especially, if > there's an expectation of admission control features in a traffic > class, it won't be done with simply marking traffic differently. > Admission Control doesn't mean RSVP to me, it could be measurement > based as well. PCN defines and discussed relevant mechanisms. The > issue here is, that admissiion control is performed prior to setting > up a media session, whereas here, the authors seem to suggest to change > the class of a media session to avoid packet loss and queuing delay. several thoughts had come to mind in writing the original text above that w= ere to a degree scenario dependent. if we're talking about interactive voi= ce/video, one possibility existed in terms of adding EF to the packet when = congestion was occuring and potentially incuring an additional "charge" for= maintaining the minimal delay characteristics. This was based on the assu= mption that the unmarked traffic was still being forwarded with acceptable = end-to-end delays during non-persistant congested conditions. Or, another = possibility could be a switch from EF to the EF-admit code point to reflect= the added admission control attribute associated with the flow/packet. Another thought was to possibly use an AF code point for voice/video traffi= c that was associated with a non-interactive broadcast type of flow that co= uld support a greater end-to-end delay while at the same time trying to min= imize loss. But as we stated in the text, we didn't want to focus on one p= articular recommendation because these may very per scenario and environmen= t (e.g., public carrier/provider versus private LMR). cheers, -ken ps, my comments to Bob's email will eventually hit the list. I sent it fro= m another email address, so it will have to be resent by the list monitor. = mea culpa. From Ruediger.Geib@telekom.de Wed Oct 24 00:11:51 2012 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 59FF221F8BCA for ; Wed, 24 Oct 2012 00:11:51 -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=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDV3xwYLTjDN for ; Wed, 24 Oct 2012 00:11:50 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0F64F21F8C9F for ; Wed, 24 Oct 2012 00:11:43 -0700 (PDT) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 24 Oct 2012 09:11:42 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 24 Oct 2012 09:11:42 +0200 From: To: , Date: Wed, 24 Oct 2012 09:11:41 +0200 Thread-Topic: [tsvwg] Review of draft-carlberg-tsvwg-ecn-reactions-03 - FEC/Duplication Thread-Index: Ac2xYph6i9HY1YFNQ8OpBFdizm4DAQAUV8kg Message-ID: References: <201210191729.q9JHTarm031903@bagheera.jungle.bt.co.uk> <89AE31B0-17D3-4526-BDF9-A4CE9578B5F1@gmail.com> <201210231849.q9NIngtU021236@bagheera.jungle.bt.co.uk> <4F541946-BEB3-45C4-8167-349322CEA8F4@gmail.com> In-Reply-To: <4F541946-BEB3-45C4-8167-349322CEA8F4@gmail.com> 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] Review of draft-carlberg-tsvwg-ecn-reactions-03 - FEC/Duplication 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, 24 Oct 2012 07:11:51 -0000 BB > S.5.2 Fault Tolerance >> > I don't see why either redundant (duplicate) transmission or FEC are relevant to a document about using ECN, as opposed to loss, for congestion signalling. P> Well one could take a variety of actions on the reception of ECN ( or loss) - the 3GPP specs suggest some interesting things... We've mentioned them as they're one of many possibilities. > [BB]: I suggest there's no need to repeat things other people say unless they make sense. I still don't understand why these things make sense. > [PO'H]You don't see why FEC makes sense as congestion reaction (or you're not keen on FEC in general)? [RG] Not talking for Bob, just for me: ECN is used to inform senders, that they cause congestion and should reduce rate. What you seemingly propose to do by FEC or duplication is the opposite, increase the load. I think to have read that Skype behaves like that. I also recall that there was an early WLAN "QoS" implementation which simply ignored the resource sharing mechanism and thus looked for unfair advantage. If you are not aware of Bobs Conex efforts, please read into that. To me, Conex seems to be a reasonable approach to deal with senders reacting with FEC or duplication on ECN signals. [RG] To be constructive: if an application requires QoS with a minimum bandwidth requirement scheme (would mean admission control in the network), then go for a propper QoS class. I'd recommend that for UDP flows without TFRC or any other possibility to reduce rate. [RG] ECN should be used to trigger a reduction of load. Sure enough, also some RTP based applications benefit from ECN in that sense. So there's a point in your draft. Regards, Ruediger From bob.briscoe@bt.com Wed Oct 24 10:59:36 2012 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 82A3F21F8632 for ; Wed, 24 Oct 2012 10:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbxZFSyL7DgV for ; Wed, 24 Oct 2012 10:59:35 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDE621F8593 for ; Wed, 24 Oct 2012 10:59:35 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 24 Oct 2012 18:59:26 +0100 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 24 Oct 2012 18:59:31 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.309.2; Wed, 24 Oct 2012 18:59:28 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1351101566940; Wed, 24 Oct 2012 18:59:26 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q9OHxPwP025144; Wed, 24 Oct 2012 18:59:25 +0100 Message-ID: <201210241759.q9OHxPwP025144@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 24 Oct 2012 18:59:24 +0100 To: ken carlberg From: Bob Briscoe In-Reply-To: <8DD13F65-E4BB-4D07-8E7A-016F72F65A84@g11.org.uk> References: <201210191729.q9JHTarm031903@bagheera.jungle.bt.co.uk> <7C75DFAD-B8B8-485B-B019-21BBCCE92D42@gmail.com> <201210231822.q9NIM8hP021179@bagheera.jungle.bt.co.uk> <8DD13F65-E4BB-4D07-8E7A-016F72F65A84@g11.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: Piers O'HANLON , tsvwg IETF list Subject: Re: [tsvwg] Review of draft-carlberg-tsvwg-ecn-reactions-03 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, 24 Oct 2012 17:59:36 -0000 Ken, inline At 20:08 23/10/2012, ken carlberg wrote: >Bob, > > >> Its relevant in the sense that it is a *type* of reaction from > the ECN signaling. One vendor has told me in private that they > have a preference for this approach, and I think its of value > because it introduces the reaction on an ass needed basis instead > of from the very begining and through the session. But the gist of > your concern is taken and we should probably add text that if this > kind of reaction is taken, which would increase offered load, then > an additional reaction (eg, employing CC algorithm, swapping to a > lower load codec) should/must also be taken. > > > > I clearly don't understand what S5.2 is about (which may be taken > as a hint that the doc probably needs to explain better). I still > don't get it... redundancy & FEC fix loss. ECN isn't a loss, so why > would anyone trigger a redundant transmission or FEC after an ECN mark? > >because its generally a fine line between the ECN marking and the >point where one needs to acually drop the packet because of queue >overflow (keeping in mind that we don't want huge queues for RTP >flows). We've done one simulation effort and a couple of >implementations. And in the latter case, it was a bit of a >challenge to get that sweet spot of generating traffic (in our case, >from an actual video feed) that triggered the ECN markings without >overflowing the queue. And even then, unless the feedback came back >soon enough and there wasn't a continually added influx of flows >from additional users (eg, a flash crowd), then the chances were >quite good that some packets would be dropped after the initial CE >feedback occured. If my application or session is considered mission >critical, then using FEC in anticipation of lost packets and only >done as needed versus the lifetime of the entire flowis a good thing. The chances of much loss following ECN CE are, I assume, fairly low, so it seems very tenuous to be thinking of adding the complexity of FEC when a small amount of loss can probably be handled just fine. >We'll definitely have to add some text to clarify our thought >process on this particular topic. > > >> > S.5.3 > >> points well taken. Within the context of the IETF, ETS is a > generic term for preferential services that are deployed in some > form in some of today's cellular networks. And the numbers in > terms of percentage of ETS users we used in our simulation are > reflective at a very high and abstract level of what exists today > in some cases. (I'm sorry to be hand wavy, but I'm trying to be > careful in my statements). > >> > >> And we also agree that individual flows from the end-host/UE > perspective will not know what percentage of exempt users co-exist > in the same "area" where congestion has occured. This is why we > added the word "authorized" to help distinguish the two sets in > that some added element needs to exist to help minimize the set of > exempt users. > > > > Even if you're talking about authorized users, if you get an > emergency, you might get an influx of authorized users into an area > to deal with the emergency. I don't need to teach granny that the > main characteristic of emergencies is unpredictability. > >the numbers I've come across with today's deployed services in some >cellular networks has shown that less than 1% within a cellular >footprint are these "authorized" users. In our simulations, we >aimed at a worse case scenario of 10%. And yes, unpredicability is >still a cause for heartburn. I still think a nearly unresponsive algo would give you nearly exactly the same behaviour as exemption if 1% or 10% authorized users did happen, but it would still avoid boiling the network if you did get 90%. Whereas completely unresponsive would not. Bob >cheers, > >-ken ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Wed Oct 24 11:10:04 2012 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 A8FA821F8818 for ; Wed, 24 Oct 2012 11:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.018 X-Spam-Level: X-Spam-Status: No, score=-3.018 tagged_above=-999 required=5 tests=[AWL=0.581, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHZEJ47xP25T for ; Wed, 24 Oct 2012 11:10:03 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 6571D21F873F for ; Wed, 24 Oct 2012 11:10:03 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 24 Oct 2012 19:10:02 +0100 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 24 Oct 2012 19:09:59 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.309.2; Wed, 24 Oct 2012 19:09:54 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1351102192760; Wed, 24 Oct 2012 19:09:52 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q9OI9pfJ025180; Wed, 24 Oct 2012 19:09:51 +0100 Message-ID: <201210241809.q9OI9pfJ025180@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 24 Oct 2012 19:09:50 +0100 To: Piers O'Hanlon From: Bob Briscoe In-Reply-To: <4F541946-BEB3-45C4-8167-349322CEA8F4@gmail.com> References: <201210191729.q9JHTarm031903@bagheera.jungle.bt.co.uk> <89AE31B0-17D3-4526-BDF9-A4CE9578B5F1@gmail.com> <201210231849.q9NIngtU021236@bagheera.jungle.bt.co.uk> <4F541946-BEB3-45C4-8167-349322CEA8F4@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: Ken Carlberg , tsvwg IETF list Subject: Re: [tsvwg] Review of draft-carlberg-tsvwg-ecn-reactions-03 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, 24 Oct 2012 18:10:04 -0000 Piers, One response, plus two redirects to Ken's thread, inline... At 22:08 23/10/2012, Piers O'Hanlon wrote: >Bob, > >On 23 Oct 2012, at 19:49, Bob Briscoe wrote: > > > Piers, > > > > At 16:19 23/10/2012, Piers O'Hanlon wrote: > >> Hi Bob, > >> > >> Thanks for the review. Comments inline. > >> > >> On 19 Oct 2012, at 18:29, Bob Briscoe wrote: > >> > >> > Ken & Piers, > >> But to be fair you have a point in the case of a direct > comparison of RFC3168 ECN or drop. I think that the more important > aspect of using ECN is that it provide for back-off before loss > occurs - allowing for flows to adapt earlier and minimise loss. > > > > [BB]: There is a more subtle sense in which ECN reduces latency. > I just wrote it into the opening para of this draft I just posted: > > > > > > " as ECN is > > used more widely by end-systems, it will gradually remove the need to > > configure a degree of delay into buffers before they start to notify > > congestion (the cause of bufferbloat). The latter delay is because > > drop involves a trade-off between sending a timely signal and trying > > to avoid impairment, whereas ECN is solely a signal so there is no > > harm triggering it earlier. > > " > > This is an emergent property that would only happen if ECN became > predominant, so that the optimum point to set AQM parameters was > determined mostly by ECN users, not legacy (drop) users. > > >Ok sounds good - though isn't one still limited by the BDP queue >size needed to accommodate TCP flows? No. If ever ECN users become the large majority, you still have a BDP /buffer/ that can accomodate TCP, but it becomes an optimal compromise to set a much tighter threshold on the AQM. The few legacy TCP users would see loss earlier, but the majority (ECN) users who see ECN earlier don't care, because it's not an impairment, it's only a signal. So their short flows etc still finish quickly without timeouts etc. > >> > S.5.2 Fault Tolerance > >> > I don't see why either redundant (duplicate) transmission or > FEC are relevant to a document about using ECN, as opposed to loss, > for congestion signalling. > >> > > >> Well one could take a variety of actions on the reception of ECN > (or loss) - the 3GPP specs suggest some interesting things... We've > mentioned them as they're one of many possibilities. > > > > [BB]: I suggest there's no need to repeat things other people say > unless they make sense. I still don't understand why these things make sense. > > >You don't see why FEC makes sense as congestion reaction (or you're >not keen on FEC in general)? Ken has answered this one, and I've responded in the other part of this thread. > > > >> > S.5.3 > >> > I wholly agree that flows that consider themselves important > could use a substantially less aggressive back-off. But I complete > exemption is of great concern to me. Therein lies a congestion > collapse. There is no need for complete exemption, if a flow can > respond very little to congestion. At least then if congestion gets > really bad, it will still respond a lot. But if congestion is not > so bad, it will seem pretty much unresponsive. > >> > > >> True complete exemption probably should not be generally used. > > > > [BB]: I agree, if you delete 'generally' :) > > >I thought you might say that! Again, this discussion is progressing in the Ken thread. >Cheers, > >Piers > > >> Thanks, > >> > >> Piers. > > > > Cheers > > > > > > Bob > > > > > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Wed Oct 24 11:16:12 2012 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 4E38821F8522 for ; Wed, 24 Oct 2012 11:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.053 X-Spam-Level: X-Spam-Status: No, score=-3.053 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOPgoA7tBWX7 for ; Wed, 24 Oct 2012 11:16:11 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 066F121F851E for ; Wed, 24 Oct 2012 11:16:11 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 24 Oct 2012 19:16:04 +0100 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 24 Oct 2012 19:16:09 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.309.2; Wed, 24 Oct 2012 19:16:06 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1351102565152; Wed, 24 Oct 2012 19:16:05 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q9OIG4oh025197; Wed, 24 Oct 2012 19:16:04 +0100 Message-ID: <201210241816.q9OIG4oh025197@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 24 Oct 2012 19:16:02 +0100 To: ken carlberg From: Bob Briscoe In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tsvwg Subject: Re: [tsvwg] draft-carlberg-tsvwg-ecn-reactions -- which WG? 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, 24 Oct 2012 18:16:12 -0000 Ken, Perhaps we could bounce this question back to you: what is the main single take-home message you want us to get from this draft? THat should decide which WG it's in. I believe the primary message is "TFRC is good enough if you've got ECN, so we can get started without RMCAT if we have ECN." I don't think that's true (as I have been arguing on the list), but I think that's the message the draft is wanting people to hear most. If that were the case, then TSVWG would be reasonable. I would have thought the impact of users not responding to ECN would be just as much in scope for RMCAT as TSVWG (and ConEx is where policing/non-compliance is most being addressed, which is the other side of this problem). Regarding FEC, I think this is a bit of a corner-case in this draft, so I wouldn't decide which WG based on that. Bob At 14:15 23/10/2012, ken carlberg wrote: >Hi, > >I've been asked publically and privately about my thoughts as to >where this document should end up -- TSVWG or RMCAT. When the >question was first brought up I was indifferent because I could see >a case for both. However, when I thought about it for a while, I >felt more comfortable advancing this through TSVWG. > >The reason for this line of thoughts is that only a portion of the >ECN Reactions draft deals with congestion control algorithms. And >while RMCAT talks about the generic term of "mechanisms" in its >charter, the heart of the charter and deliverables seems to focus on >algorithms, which is really just one type of mechanism. On the >other hand, the Reactions draft looks into other "mechanisms" like >FEC, signaling, and most importantly, the impact of a set of users >not responding to ECN. And its this last item where we bring in >some simulation work and is probably the strongest reason (ie, the >simulation results) as to why its beneficial to have this in an IETF >document. And its these other items that seem out of scope of RMCAT. > >Assuming this draft is accepted as a working group item in TSVWG, I >would also want to send the document to RMCAT for review when we get >to a WG last call for comments stage, though I sure the core set of >folks will be attending both sets of meetings and mailing lists. > >If folks feel I've missed something, please don't be shy in letting >us know :-) > >-ken ________________________________________________________________ Bob Briscoe, BT Innovate & Design From carlberg@g11.org.uk Thu Oct 25 04:06:17 2012 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 8E18521F895B for ; Thu, 25 Oct 2012 04:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.755 X-Spam-Level: X-Spam-Status: No, score=-0.755 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHTVHgDXIK6P for ; Thu, 25 Oct 2012 04:06:17 -0700 (PDT) Received: from portland.eukhosting.net (portland.ukserverhosting.net [92.48.103.133]) by ietfa.amsl.com (Postfix) with ESMTP id A137721F8920 for ; Thu, 25 Oct 2012 04:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=95+maffRGsEepT23VjUKhTtBExnxTqKMaA9Rk/MuNOk=; b=yZiYfu+8YCqU8ijBOGyf7yeJiETJZ2b6WnIMpg3+1x7sMvP7e8Fr4GjAoiCwG3WaAN7Ow3YOpkGyskH2iqorZ9QGJnFjekJ8HflpbC1xt/rwLtXJ0Z+KhqRJsN8jAX85; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:49394 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.80) (envelope-from ) id 1TRLGN-0003Pt-Bc; Thu, 25 Oct 2012 11:06:11 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <201210241759.q9OHxPwP025144@bagheera.jungle.bt.co.uk> Date: Thu, 25 Oct 2012 07:06:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <549A1F93-77FE-4EBB-BC2A-D845E4C9BCD4@g11.org.uk> References: <201210191729.q9JHTarm031903@bagheera.jungle.bt.co.uk> <7C75DFAD-B8B8-485B-B019-21BBCCE92D42@gmail.com> <201210231822.q9NIM8hP021179@bagheera.jungle.bt.co.uk> <8DD13F65-E4BB-4D07-8E7A-016F72F65A84@g11.org.uk> <201210241759.q9OHxPwP025144@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: Piers O'HANLON , tsvwg IETF list Subject: Re: [tsvwg] Review of draft-carlberg-tsvwg-ecn-reactions-03 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, 25 Oct 2012 11:06:17 -0000 On Oct 24, 2012, at 1:59 PM, Bob Briscoe wrote: >=20 > The chances of much loss following ECN CE are, I assume, fairly low, = so it seems very tenuous to be thinking of adding the complexity of FEC = when a small amount of loss can probably be handled just fine. depends on the event causing the congestion. my assumption is that the = vast majority of these events are brief transitive events, and as you = say, can be handled fine. however, the events I get exposed to (eg, = disasters, sudden weather events, sustained flash crowds) last from tens = of minutes, hours, and even days, which is much too long for certain = folks. =20 > I still think a nearly unresponsive algo would give you nearly exactly = the same behaviour as exemption if 1% or 10% authorized users did = happen, but it would still avoid boiling the network if you did get 90%. = Whereas completely unresponsive would not. yes, a fair point, which we need to make clear in the document. -ken From michawe@ifi.uio.no Thu Oct 25 04:06:35 2012 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 41F5821F8920 for ; Thu, 25 Oct 2012 04:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MaShTIoVJ5L for ; Thu, 25 Oct 2012 04:06:34 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id EA2ED21F89B4 for ; Thu, 25 Oct 2012 04:06:33 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TRLGh-0001lt-Vr; Thu, 25 Oct 2012 13:06:31 +0200 Received: from 108.134.189.109.customer.cdi.no ([109.189.134.108] helo=[192.168.0.197]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TRLGh-0003hJ-5V; Thu, 25 Oct 2012 13:06:31 +0200 Message-Id: From: Michael Welzl To: Bob Briscoe In-Reply-To: <201210241816.q9OIG4oh025197@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 25 Oct 2012 13:06:08 +0200 References: <201210241816.q9OIG4oh025197@bagheera.jungle.bt.co.uk> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 4 sum msgs/h 2 total rcpts 25035 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 07E2300A817328027B824B5890FCCA6E21F16304 X-UiO-SPAM-Test: remote_host: 109.189.134.108 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1571 max/h 15 blacklist 0 greylist 0 ratelimit 0 Cc: tsvwg Subject: Re: [tsvwg] draft-carlberg-tsvwg-ecn-reactions -- which WG? 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, 25 Oct 2012 11:06:35 -0000 Hi all, I have read the document and only now got around to look at the thread. The view that I got from reading the document seems to match a lot of the criticism that this draft is receiving. One first concern is: the draft seems to consist of one recommendation (using TFRC), and a ton of ideas (using DiffServ, using RSVP, using FEC, whatnot). I think that listing all the possible ideas of things one could possibly do in response to an ECN-mark is pretty pointless. Why not add NSIS? Why not change the packet size in response to ECN? Why not stop the flow if there is heavy congestion? And (rinse and) repeat? Why not change this in the codec, this in the codec, that in the codec? It's really an endless list! So, why are the "ideas" only listed as such, and not as recommendations? Because you don't back them up with enough "meat" to make them recommendable. There's a ton of literature out there, on all these things - if you find something in it that lets you make a recommendation, go ahead, but as long as the things seem fishy to you, I would refrain from listing them because they end up being useless to the reader, too. (note, I have nothing against recommending things other than "let's just use TFRC", if this is convincingly written, based on citations to documents that make it clear that these things are indeed good ideas). As for the simulation study, this looks pretty useless. It doesn't have enough details to be repeatable (e.g., the queue length is missing, and "RED parameters as recommended by Sally Floyd" isn't quite telling us all we need to know, either (e.g., gentle mode used or not?) ). As Bob has pointed out, it's also only one specific scenario, omitting other possible situations... if the point of documenting a simulation is just to illustrate a case with numbers to be able to explain them better, then that may be okay to have in a draft, but if the point is to justify a decision, as here, this would be better published in a paper, after peer review, and then cited, I think. So, now I can get to what Bob wrote below - this message seems to be the most fitting one to answer: If we could agree on removing ideas and sticking with just recommendations, then: On Oct 24, 2012, at 8:16 PM, Bob Briscoe wrote: > Ken, > > Perhaps we could bounce this question back to you: what is the main > single take-home message you want us to get from this draft? THat > should decide which WG it's in. > > I believe the primary message is "TFRC is good enough if you've got > ECN, so we can get started without RMCAT if we have ECN." I don't > think that's true (as I have been arguing on the list), but I think > that's the message the draft is wanting people to hear most. If that > were the case, then TSVWG would be reasonable. ...this would be true, but: > I would have thought the impact of users not responding to ECN would > be just as much in scope for RMCAT as TSVWG (and ConEx is where > policing/non-compliance is most being addressed, which is the other > side of this problem). indeed, I would have thought that too. > Regarding FEC, I think this is a bit of a corner-case in this draft, > so I wouldn't decide which WG based on that. FEC is just one of the ideas I talk about above, and, as such, should be removed IMO. Cheers, Michael PS: a nit: section 3: you can't say that "TCP congestion control ... favours reliability over timeliness." TCP does, but this is not its congestion control. From carlberg@g11.org.uk Thu Oct 25 04:25:47 2012 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 A5C3421F8994 for ; Thu, 25 Oct 2012 04:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eg3nMtZTjw5x for ; Thu, 25 Oct 2012 04:25:46 -0700 (PDT) Received: from portland.eukhosting.net (portland.ukserverhosting.net [92.48.103.133]) by ietfa.amsl.com (Postfix) with ESMTP id 891D821F898F for ; Thu, 25 Oct 2012 04:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=DXQpjAj1yRQqWh5dxhaUiKpqQBWiQK67H0zCWm7+sBU=; b=0CKaVFAYzMnQCkJFh4/7IvYAFicGBZcZVvEag1Ia383lLBlXrc+sxhfIi5kmUrE8kCWHbOlnjwbOiAwy6iLaiofNEzVxPVLBPu1J1m1WgsTd5qWJuSsQx7zLuF422N/8; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:49476 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.80) (envelope-from ) id 1TRLZH-00017c-4C; Thu, 25 Oct 2012 11:25:43 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <201210241816.q9OIG4oh025197@bagheera.jungle.bt.co.uk> Date: Thu, 25 Oct 2012 07:25:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4AE5C6BA-E35C-4268-A778-3BA77EE6C7CD@g11.org.uk> References: <201210241816.q9OIG4oh025197@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: tsvwg Subject: Re: [tsvwg] draft-carlberg-tsvwg-ecn-reactions -- which WG? 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, 25 Oct 2012 11:25:47 -0000 Bob, a good bounceback question. It wasn't our intention to say that "TFRC is good eough if you've got = ECN". The main point we wanted to make is that TFRC exists now, but = there are some issues and that is being addressed in RMCAT in the form = of requirements and potentially new CC algorithms. So we'll need to fix = our text to convey this properly. Also, if our draft was that narrowly = focused, then yes, we'd move the Reactions draft to RMCAT and probably = fold that into one fo the deliverables in the RMCAT charter. In writing RFC-6679 (ECN for RTP over UDP), the authors agreed that a = default approach of using a CC algorithm is what is needed to reduce = load when congestion is signaled. Later on, I came across some carriers = (as well as some vendors) who were of the mind set that they have a = preference to swap codecs to one that produced less load instead of = using a CC algorithm. =46rom my perspective, this is outside the scope = and intent of RMCAT, and yet its a perfectly reasonable approach to = consider. And discussions with others brought up the ideas of on-demand = invocation of FEC and RSVP as a means of further protecting certain = flows. =46rom my perspective, this is outside the scope and intent of = RMCAT, and yet its a perfectly reasonable approach to consider. In = addition, sets of users not responding to ECN would seem to be at the = fringe of RMCAT's charter. And so we use the title "Reactions to ECN" to purposely be broad in = scope and not just focused on CC algorithms reactions to ECN. That is = why I think this document should stay with TSVWG. Piers and I will also = be participating in RMCAT, so we'll be sure to bring up items that can = contribute to the discussion and advancement of RMCAT. cheers, -ken On Oct 24, 2012, at 2:16 PM, Bob Briscoe wrote: > Ken, >=20 > Perhaps we could bounce this question back to you: what is the main = single take-home message you want us to get from this draft? THat should = decide which WG it's in. >=20 > I believe the primary message is "TFRC is good enough if you've got = ECN, so we can get started without RMCAT if we have ECN." I don't think = that's true (as I have been arguing on the list), but I think that's the = message the draft is wanting people to hear most. If that were the case, = then TSVWG would be reasonable. >=20 > I would have thought the impact of users not responding to ECN would = be just as much in scope for RMCAT as TSVWG (and ConEx is where = policing/non-compliance is most being addressed, which is the other side = of this problem). >=20 > Regarding FEC, I think this is a bit of a corner-case in this draft, = so I wouldn't decide which WG based on that. >=20 >=20 > Bob >=20 > At 14:15 23/10/2012, ken carlberg wrote: >> Hi, >>=20 >> I've been asked publically and privately about my thoughts as to = where this document should end up -- TSVWG or RMCAT. When the question = was first brought up I was indifferent because I could see a case for = both. However, when I thought about it for a while, I felt more = comfortable advancing this through TSVWG. >>=20 >> The reason for this line of thoughts is that only a portion of the = ECN Reactions draft deals with congestion control algorithms. And while = RMCAT talks about the generic term of "mechanisms" in its charter, the = heart of the charter and deliverables seems to focus on algorithms, = which is really just one type of mechanism. On the other hand, the = Reactions draft looks into other "mechanisms" like FEC, signaling, and = most importantly, the impact of a set of users not responding to ECN. = And its this last item where we bring in some simulation work and is = probably the strongest reason (ie, the simulation results) as to why its = beneficial to have this in an IETF document. And its these other items = that seem out of scope of RMCAT. >>=20 >> Assuming this draft is accepted as a working group item in TSVWG, I = would also want to send the document to RMCAT for review when we get to = a WG last call for comments stage, though I sure the core set of folks = will be attending both sets of meetings and mailing lists. >>=20 >> If folks feel I've missed something, please don't be shy in letting = us know :-) >>=20 >> -ken >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 From ken.carlberg@gmail.com Thu Oct 25 04:30:16 2012 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 C210F21F8A1F for ; Thu, 25 Oct 2012 04:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-lRRVxqoBj1 for ; Thu, 25 Oct 2012 04:30:16 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2653121F8A1C for ; Thu, 25 Oct 2012 04:30:16 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so1882645vbb.31 for ; Thu, 25 Oct 2012 04:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=HUxOarAB81SpGEjyYeHG8fkbEwp/5RnsGJqAO4vpscw=; b=O+xycHNjnZiEtzpwHg1+f/DDqUIVlBx466cFt0/x8CgrKnCHJpo7KqxZjU5zFWXMgH V2hq8hYvJkgjdfKB1PsADUWkpW3xsiINsmmHSBlRAxauT5KKQNbjW78YwFftSUPnTH8g 5YS25fXJQXAEb/++5qcScQucNKL05yagRkJCGQO2GV+7U9dKdo8R8e99zk/Flff1Jqnj K5niKIkPCxRC3QK8o1d7L0pv8wm6O7hy5Rtgh9+yHPLxN0d1mNUOailhFGCrhkhcLYV3 KegGbrXoTFieUfmfLR/sY/1xzsqldSaErzSAOAIhaS+2DxlE7TKB8a/CU+4AaDAsI8lg klvw== Received: by 10.220.38.73 with SMTP id a9mr13453088vce.72.1351164615356; Thu, 25 Oct 2012 04:30:15 -0700 (PDT) Received: from [192.168.0.20] (c-76-111-69-4.hsd1.va.comcast.net. [76.111.69.4]) by mx.google.com with ESMTPS id i15sm18698499vdt.0.2012.10.25.04.30.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Oct 2012 04:30:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: ken carlberg In-Reply-To: Date: Thu, 25 Oct 2012 07:30:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201210191729.q9JHTarm031903@bagheera.jungle.bt.co.uk> <89AE31B0-17D3-4526-BDF9-A4CE9578B5F1@gmail.com> <201210231849.q9NIngtU021236@bagheera.jungle.bt.co.uk> <4F541946-BEB3-45C4-8167-349322CEA8F4@gmail.com> To: X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Thu, 25 Oct 2012 04:31:52 -0700 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Review of draft-carlberg-tsvwg-ecn-reactions-03 - FEC/Duplication 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, 25 Oct 2012 11:30:16 -0000 Understood. I'll need to give some thought as to how to exactly convey = these points about QoS into the draft. As for Conex, I was one of the early ones arguing for its formation, = though in truth, I hadn't thought about entwining it in some form to the = Reactions draft. Again, some more stuff I'll need to think about. cheers, -ken On Oct 24, 2012, at 3:11 AM, = wrote: > [RG] Not talking for Bob, just for me: ECN is used to inform senders, > that they cause congestion and should reduce rate. What you seemingly > propose to do by FEC or duplication is the opposite, increase the > load. I think to have read that Skype behaves like that. I also > recall that there was an early WLAN "QoS" implementation which > simply ignored the resource sharing mechanism and thus looked > for unfair advantage. If you are not aware of Bobs Conex efforts, > please read into that. To me, Conex seems to be a reasonable > approach to deal with senders reacting with FEC or duplication > on ECN signals. >=20 > [RG] To be constructive: if an application requires QoS with a > minimum bandwidth requirement scheme (would mean admission control > in the network), then go for a propper QoS class. I'd recommend > that for UDP flows without TFRC or any other possibility to > reduce rate. >=20 > [RG] ECN should be used to trigger a reduction of load. Sure > enough, also some RTP based applications benefit from ECN in that > sense. So there's a point in your draft. From bob.briscoe@bt.com Thu Oct 25 05:51:07 2012 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 0039C21F86E1 for ; Thu, 25 Oct 2012 05:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.083 X-Spam-Level: X-Spam-Status: No, score=-3.083 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vV8631rS8H3 for ; Thu, 25 Oct 2012 05:51:05 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id C44ED21F89D6 for ; Thu, 25 Oct 2012 05:51:04 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 25 Oct 2012 13:51:03 +0100 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 25 Oct 2012 13:51:01 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.309.2; Thu, 25 Oct 2012 13:50:57 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1351169456679; Thu, 25 Oct 2012 13:50:56 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.25.49]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q9PCosEG028217; Thu, 25 Oct 2012 13:50:54 +0100 Message-ID: <201210251250.q9PCosEG028217@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 25 Oct 2012 13:50:54 +0100 To: ken carlberg From: Bob Briscoe In-Reply-To: <4AE5C6BA-E35C-4268-A778-3BA77EE6C7CD@g11.org.uk> References: <201210241816.q9OIG4oh025197@bagheera.jungle.bt.co.uk> <4AE5C6BA-E35C-4268-A778-3BA77EE6C7CD@g11.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tsvwg Subject: Re: [tsvwg] draft-carlberg-tsvwg-ecn-reactions -- which WG? 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, 25 Oct 2012 12:51:07 -0000 Ken, Now I understand where you're coming from (which wasn't clear BTW) I can start to bite on your question... Changing codecs is driven by a cc algo, it's just an algo with a discrete output, not a continuous output. One can think of it like an internal continuous rate-vs-congestion response that drives step rate changes - once it has remained below or above a codec-change threshold for sufficiently long. Sometimes they are actually written like that. Other times they are driven by hi/lo watermarks in the playout buffer. But these are cc algorithms all the same. So if you think cc algos should go in RMCAT, then this should, because that is the main meat of this draft. Indeed, I imagine most of the RMCAT output will be targetted at codecs with discrete steps in spatial & temporal resolution. THe emergency comms section (5.3) is merely a different degree of cc response, so it ought to be under "CC ALgos" (section 3), not "Other responses" (section 5). On the other kitchen sink of responses (triggering RSVP, Diffserv, Redundancy, FEC etc), I'm with Michael W. If you're just listing what implementers might do, then it has little value. If you're recommending what implementers shouldn't do or what they should, it would be worth keeping these. But none of these other responses you list seem to be that prevalent, important or practical. If a codec isn't using RSVP, but the going gets tough part-way through, calling to RSVP for help would be a bit like a ship-wreck victim praying for a miracle to save them :) If RSVP is available on a particular network (<1% chance), and specific apps have been written to use it but they start-out not using it (<1% * <1%), I don't see it will help commentating on that remote possibility in this draft. Similarly, nowadays, nearly always where Diffserv is used, the network decides to apply the markings at the edge, not the host. So if there were a case where the network took account of host-initiated Diffserv markings (<1% chance), and specific apps have been written to use it but they start-out not using it (<1% * <1%), I don't see it will help commentating on that remote possibility in this draft. And I've already said the ECN + (Redundancy or FEC) items are pretty much corner-cases too. Bob At 12:25 25/10/2012, ken carlberg wrote: >Bob, > >a good bounceback question. > >It wasn't our intention to say that "TFRC is good eough if you've >got ECN". The main point we wanted to make is that TFRC exists now, >but there are some issues and that is being addressed in RMCAT in >the form of requirements and potentially new CC algorithms. So >we'll need to fix our text to convey this properly. Also, if our >draft was that narrowly focused, then yes, we'd move the Reactions >draft to RMCAT and probably fold that into one fo the deliverables >in the RMCAT charter. > >In writing RFC-6679 (ECN for RTP over UDP), the authors agreed that >a default approach of using a CC algorithm is what is needed to >reduce load when congestion is signaled. Later on, I came across >some carriers (as well as some vendors) who were of the mind set >that they have a preference to swap codecs to one that produced less >load instead of using a CC algorithm. From my perspective, this is >outside the scope and intent of RMCAT, and yet its a perfectly >reasonable approach to consider. And discussions with others >brought up the ideas of on-demand invocation of FEC and RSVP as a >means of further protecting certain flows. From my perspective, >this is outside the scope and intent of RMCAT, and yet its a >perfectly reasonable approach to consider. In addition, sets of >users not responding to ECN would seem to be at the fringe of RMCAT's charter. > >And so we use the title "Reactions to ECN" to purposely be broad in >scope and not just focused on CC algorithms reactions to ECN. That >is why I think this document should stay with TSVWG. Piers and I >will also be participating in RMCAT, so we'll be sure to bring up >items that can contribute to the discussion and advancement of RMCAT. > >cheers, > >-ken > > >On Oct 24, 2012, at 2:16 PM, Bob Briscoe wrote: > > > Ken, > > > > Perhaps we could bounce this question back to you: what is the > main single take-home message you want us to get from this draft? > THat should decide which WG it's in. > > > > I believe the primary message is "TFRC is good enough if you've > got ECN, so we can get started without RMCAT if we have ECN." I > don't think that's true (as I have been arguing on the list), but I > think that's the message the draft is wanting people to hear most. > If that were the case, then TSVWG would be reasonable. > > > > I would have thought the impact of users not responding to ECN > would be just as much in scope for RMCAT as TSVWG (and ConEx is > where policing/non-compliance is most being addressed, which is the > other side of this problem). > > > > Regarding FEC, I think this is a bit of a corner-case in this > draft, so I wouldn't decide which WG based on that. > > > > > > Bob > > > > At 14:15 23/10/2012, ken carlberg wrote: > >> Hi, > >> > >> I've been asked publically and privately about my thoughts as to > where this document should end up -- TSVWG or RMCAT. When the > question was first brought up I was indifferent because I could see > a case for both. However, when I thought about it for a while, I > felt more comfortable advancing this through TSVWG. > >> > >> The reason for this line of thoughts is that only a portion of > the ECN Reactions draft deals with congestion control > algorithms. And while RMCAT talks about the generic term of > "mechanisms" in its charter, the heart of the charter and > deliverables seems to focus on algorithms, which is really just one > type of mechanism. On the other hand, the Reactions draft looks > into other "mechanisms" like FEC, signaling, and most importantly, > the impact of a set of users not responding to ECN. And its this > last item where we bring in some simulation work and is probably > the strongest reason (ie, the simulation results) as to why its > beneficial to have this in an IETF document. And its these other > items that seem out of scope of RMCAT. > >> > >> Assuming this draft is accepted as a working group item in > TSVWG, I would also want to send the document to RMCAT for review > when we get to a WG last call for comments stage, though I sure the > core set of folks will be attending both sets of meetings and mailing lists. > >> > >> If folks feel I've missed something, please don't be shy in > letting us know :-) > >> > >> -ken > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design From carlberg@g11.org.uk Fri Oct 26 09:01:17 2012 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 D293E21F8633 for ; Fri, 26 Oct 2012 09:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjjgRU+WkrFj for ; Fri, 26 Oct 2012 09:01:17 -0700 (PDT) Received: from portland.eukhosting.net (portland.ukserverhosting.net [92.48.103.133]) by ietfa.amsl.com (Postfix) with ESMTP id B325821F8608 for ; Fri, 26 Oct 2012 09:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=GzIw9T33oXIEAC5c24zAlVXJ6gZayqL1PDKxiluQb3U=; b=u97xUxYGIQv5R11EIs0gnP+gcD8mDCc+6645b0+reNs4t6IKatqyJ2txbz45x+SI52glc5ZU+eAXzFwGAQ+IGXz+G4vnjXa6GmogNmzzyxAPkrk5ESDrbmq/rA3FN/3P; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:55992 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.80) (envelope-from ) id 1TRmLP-0003q9-RI; Fri, 26 Oct 2012 16:01:12 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: Date: Fri, 26 Oct 2012 12:01:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0E4DD97C-5C55-4FF2-AFD1-ED2F110A153A@g11.org.uk> References: <201210241816.q9OIG4oh025197@bagheera.jungle.bt.co.uk> To: Michael Welzl X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: tsvwg Subject: Re: [tsvwg] draft-carlberg-tsvwg-ecn-reactions -- which WG? 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, 26 Oct 2012 16:01:17 -0000 I'm sorry, but i think you need to take a little more time in reading = the related threads as well as the draft. > I have read the document and only now got around to look at the = thread. The view that I got from reading the document seems to match a = lot of the criticism that this draft is receiving. >=20 > One first concern is: the draft seems to consist of one recommendation = (using TFRC), As I told Bob previously, the draft is *not* meant to be a = recommendation. It is meant to discuss the various reactions that can = be used with ECN signaling -- and I'll add that we wanted to add some = insight as well. And with respect to TFRC, we are *not* recommending = its use as the default CC algorithm as stipulated in rfc-6679. If you = look carefully at the *end* of this paragraph... However it should be noted that TFRC is only recommended for = real-time media use with ECN response. TFRC is not recommended for non-ECN = paths due to its loss based operation which leads to full queues with maximised latencies. It is assumed that ECN markings will usually = occur with lower queue occupancy and thus lower latency. However it is understood that ECN marks may not provide for sufficiently low latencies in some situations so other congestion control solutions would be preferable. ...we state that "other congestion control solutions would be = preferable". The paragraph is meant to be read and taken as a whole. = What we can do, based on Bob's initial feedback, is to add/alter the = first part of the paragraph to reinforce the understanding that TFRC is = one example of a CC algorithm. > and a ton of ideas (using DiffServ, using RSVP, using FEC, whatnot). I = think that listing all the possible ideas of things one could possibly = do in response to an ECN-mark is pretty pointless. Why not add NSIS? Why = not change the packet size in response to ECN? Why not stop the flow if = there is heavy congestion? And (rinse and) repeat? Why not change this = in the codec, this in the codec, that in the codec? It's really an = endless list! how many implementations by vendors have you seen of NSIS? Which = vendors dynamically change packet size due to loss? Perhaps I'm long on = the tooth, but I've seen *deployed* implementations (outside of the = research/academic lab) of diff-serv, RSVP, FEC, and CODECS producing = different load rates, along with a number of protocols associated with = these designs. NSIS is an experimental protocol, which I didn't feel = comfortable including in the list, but if you feel differently, I'll be = happy to read any text you'd like to propose. > So, why are the "ideas" only listed as such, and not as = recommendations? Because you don't back them up with enough "meat" to = make them recommendable. There's a ton of literature out there, on all = these things - if you find something in it that lets you make a = recommendation, go ahead, but as long as the things seem fishy to you, I = would refrain from listing them because they end up being useless to the = reader, too. (note, I have nothing against recommending things other = than "let's just use TFRC", if this is convincingly written, based on = citations to documents that make it clear that these things are indeed = good ideas). see above. And if your sole interest is to see a set of recomendations, = I would suggest writing your own document and I'll be happy to review it = with the same courtesy that you have shown. But complaining about = something that the document is not meant to be is a bit pointless. > As for the simulation study, this looks pretty useless. It doesn't = have enough details to be repeatable (e.g., the queue length is missing, = and "RED parameters as recommended by Sally Floyd" isn't quite telling = us all we need to know, either (e.g., gentle mode used or not?) ). As = Bob has pointed out, it's also only one specific scenario, omitting = other possible situations... if the point of documenting a simulation is = just to illustrate a case with numbers to be able to explain them = better, then that may be okay to have in a draft, but if the point is to = justify a decision, as here, this would be better published in a paper, = after peer review, and then cited, I think. we shall add more information about the simulation, and see about = expanding its scope. As for the scenario, yes, it is speciic because = its reflective of what we've come across in the real world instead of = simply an academic paper exercise. kindest regards, -ken From carlberg@g11.org.uk Fri Oct 26 09:43:03 2012 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 0D42B21F8644 for ; Fri, 26 Oct 2012 09:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxwUkThLsc6Q for ; Fri, 26 Oct 2012 09:43:01 -0700 (PDT) Received: from portland.eukhosting.net (portland.ukserverhosting.net [92.48.103.133]) by ietfa.amsl.com (Postfix) with ESMTP id F18DD21F864A for ; Fri, 26 Oct 2012 09:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=ESDxZ9l/H2ryVlhuAOcjQCX4wohlnxKB1JOlXvfM3I8=; b=nY3LZNvPKjnJnhE8JpxbXGc//sGf0RHL8IEF+hC7Hhziu12EDPSjFKzsEhGFEM1S5cJj8qHxFFXWw57Uuofnfq+SD/YFbCOMbAv/X0modao3/eebzwGBPppk6IvU39WZ; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:56125 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.80) (envelope-from ) id 1TRmzc-0008FO-QA; Fri, 26 Oct 2012 16:42:45 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <201210251250.q9PCosEG028217@bagheera.jungle.bt.co.uk> Date: Fri, 26 Oct 2012 12:42:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <362F5AD2-725E-452D-B446-53EEFAB2C826@g11.org.uk> References: <201210241816.q9OIG4oh025197@bagheera.jungle.bt.co.uk> <4AE5C6BA-E35C-4268-A778-3BA77EE6C7CD@g11.org.uk> <201210251250.q9PCosEG028217@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: tsvwg Subject: Re: [tsvwg] draft-carlberg-tsvwg-ecn-reactions -- which WG? 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, 26 Oct 2012 16:43:03 -0000 Bob, > Ken, >=20 > Now I understand where you're coming from (which wasn't clear BTW) I = can start to bite on your question... >=20 > Changing codecs is driven by a cc algo, yes and no. In RMCAT, and what its trying to accomplish, I would = wholeheartedly agree. How this is done can still be an open question, = but we are in agreement that this approach is reasonable. Another = approach to take is to simply key off the presence of congestion (loss, = or CE feedback) and swap codecs to one that produces an average lower tx = rate without reliance on a particular CC algo. Now, before you express = your heartburn at that idea, I'm not advocateing (or recommending :-) = this idea. I'm just pointing out what others are considering. There is = an ITU document being written on this approach, and I'm waiting for it = to sttle down a bit before I include it as a reference. And i know in a previous response to Piers that you're not keen on = citing work from outside the IETF. But I think we want to do this so = that "our" community is aware of what's being proposed, or can be = considered, so that we can provide our own response (like this is a bad = idea for these specific reasons, blah, blah, blah). > it's just an algo with a discrete output, not a continuous output. One = can think of it like an internal continuous rate-vs-congestion response = that drives step rate changes - once it has remained below or above a = codec-change threshold for sufficiently long. Sometimes they are = actually written like that. Other times they are driven by hi/lo = watermarks in the playout buffer. >=20 > But these are cc algorithms all the same. So if you think cc algos = should go in RMCAT, then this should, because that is the main meat of = this draft. again, the purpose of the reactions draft is to point out one's options = and not be solely constrained with CC algorithms. I do agree what what = you say above, and this should find its way in another more focused = document in RMCAT. > Indeed, I imagine most of the RMCAT output will be targetted at codecs = with discrete steps in spatial & temporal resolution. >=20 > THe emergency comms section (5.3) is merely a different degree of cc = response, so it ought to be under "CC ALgos" (section 3), not "Other = responses" (section 5). well, we could split the "other responses" into a subsection that = describes a less aggressive CC algo into section 3, and a rationale = behind it. I need to give this more thought.=20 > On the other kitchen sink of responses (triggering RSVP, Diffserv, = Redundancy, FEC etc), I'm with Michael W. If you're just listing what = implementers might do, then it has little value. If you're recommending = what implementers shouldn't do or what they should, it would be worth = keeping these. But none of these other responses you list seem to be = that prevalent, important or practical. I think what is missing in those sections is more discussion about the = pro's and con's of the various approaches. For example, (a) the need = for, and difficulty in achieving, transitive trust between nodes under = different administrative control for diff-serv code points, or on the = other hand (b) the added value of adding markings to packets that could = influence downstream traffic engineering on an as-needed basis. I = prefer to stay away from recomendations because that can be entirely = scenario and user-group specific. =20 > If a codec isn't using RSVP, but the going gets tough part-way = through, calling to RSVP for help would be a bit like a ship-wreck = victim praying for a miracle to save them :) If RSVP is available on a = particular network (<1% chance), and specific apps have been written to = use it but they start-out not using it (<1% * <1%), I don't see it will = help commentating on that remote possibility in this draft. >=20 > Similarly, nowadays, nearly always where Diffserv is used, the network = decides to apply the markings at the edge, not the host. So if there = were a case where the network took account of host-initiated Diffserv = markings (<1% chance), and specific apps have been written to use it but = they start-out not using it (<1% * <1%), I don't see it will help = commentating on that remote possibility in this draft. >=20 > And I've already said the ECN + (Redundancy or FEC) items are pretty = much corner-cases too. agreed, these are corner cases. But I'm inclined to come across these = corner cases in real life, and i think we make a mistake in ignoring = them. They do exist, but just not in the scale that many others come = across. cheers, -ken From michawe@ifi.uio.no Sat Oct 27 01:55:18 2012 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 2879B21F8457 for ; Sat, 27 Oct 2012 01:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71r7ofoybawb for ; Sat, 27 Oct 2012 01:55:17 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id E3D4A21F84DF for ; Sat, 27 Oct 2012 01:55:16 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TS2Al-00068K-Gv; Sat, 27 Oct 2012 10:55:15 +0200 Received: from 108.134.189.109.customer.cdi.no ([109.189.134.108] helo=[192.168.0.197]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TS2Ak-0003od-T3; Sat, 27 Oct 2012 10:55:15 +0200 Message-Id: <6BA31ACB-4F59-43B8-8517-C0CB306CB8C2@ifi.uio.no> From: Michael Welzl To: ken carlberg In-Reply-To: <0E4DD97C-5C55-4FF2-AFD1-ED2F110A153A@g11.org.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 27 Oct 2012 10:54:52 +0200 References: <201210241816.q9OIG4oh025197@bagheera.jungle.bt.co.uk> <0E4DD97C-5C55-4FF2-AFD1-ED2F110A153A@g11.org.uk> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 11 sum msgs/h 5 total rcpts 25057 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DC1739B27D8D01BAC93788262696107E318176EA X-UiO-SPAM-Test: remote_host: 109.189.134.108 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 1575 max/h 15 blacklist 0 greylist 0 ratelimit 0 Cc: tsvwg Subject: Re: [tsvwg] draft-carlberg-tsvwg-ecn-reactions -- which WG? 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: Sat, 27 Oct 2012 08:55:18 -0000 Hi, On Oct 26, 2012, at 6:01 PM, ken carlberg wrote: > I'm sorry, but i think you need to take a little more time in > reading the related threads as well as the draft. I have given the draft a close read. It should be self-contained. >> I have read the document and only now got around to look at the >> thread. The view that I got from reading the document seems to >> match a lot of the criticism that this draft is receiving. >> >> One first concern is: the draft seems to consist of one >> recommendation (using TFRC), > > As I told Bob previously, the draft is *not* meant to be a > recommendation. It is meant to discuss the various reactions that > can be used with ECN signaling -- and I'll add that we wanted to add > some insight as well. And with respect to TFRC, we are *not* > recommending its use as the default CC algorithm as stipulated in > rfc-6679. If you look carefully at the *end* of this paragraph... "Not meant to be a recommendation": Here's the first sentence of your abstract: "This document presents recommendations for response to Congestion Experience (CE) notifications by real time applications that have negotiated end-to-end support of Explicit Congestion Notification (ECN)." So it's obvious that, upon reading it, I believe the draft is meant to be a recommendation, no? > However it should be noted that TFRC is only recommended for real- > time > media use with ECN response. TFRC is not recommended for non-ECN > paths > due to its loss based operation which leads to full queues with > maximised latencies. It is assumed that ECN markings will usually > occur > with lower queue occupancy and thus lower latency. However it is > understood that ECN marks may not provide for sufficiently low > latencies in some situations so other congestion control solutions > would be preferable. > > ...we state that "other congestion control solutions would be > preferable". The paragraph is meant to be read and taken as a > whole. What we can do, based on Bob's initial feedback, is to add/ > alter the first part of the paragraph to reinforce the understanding > that TFRC is one example of a CC algorithm. I got that. I agree, however, with Bob's point that you can't really expect ECN marking to lead to less delay (sure, AQMs might not follow RFC 3168, but that's rather speculative I guess? If it's not, a reference would be good). >> and a ton of ideas (using DiffServ, using RSVP, using FEC, >> whatnot). I think that listing all the possible ideas of things one >> could possibly do in response to an ECN-mark is pretty pointless. >> Why not add NSIS? Why not change the packet size in response to >> ECN? Why not stop the flow if there is heavy congestion? And (rinse >> and) repeat? Why not change this in the codec, this in the codec, >> that in the codec? It's really an endless list! > > how many implementations by vendors have you seen of NSIS? Which > vendors dynamically change packet size due to loss? Perhaps I'm > long on the tooth, but I've seen *deployed* implementations (outside > of the research/academic lab) of diff-serv, RSVP, FEC, and CODECS > producing different load rates, along with a number of protocols > associated with these designs. NSIS is an experimental protocol, > which I didn't feel comfortable including in the list, but if you > feel differently, I'll be happy to read any text you'd like to > propose. My point was just that DiffServ, RSVP, .... looks like a list of random ideas to me. If your basis for presenting them as possible reactions to ECN is that they are deployed, then what you're presenting is a survey of deployed work, which may have its own merits - but then this should be listed as such, with appropriate references wherever possible. >> So, why are the "ideas" only listed as such, and not as >> recommendations? Because you don't back them up with enough "meat" >> to make them recommendable. There's a ton of literature out there, >> on all these things - if you find something in it that lets you >> make a recommendation, go ahead, but as long as the things seem >> fishy to you, I would refrain from listing them because they end up >> being useless to the reader, too. (note, I have nothing against >> recommending things other than "let's just use TFRC", if this is >> convincingly written, based on citations to documents that make it >> clear that these things are indeed good ideas). > > see above. And if your sole interest is to see a set of > recomendations, I would suggest writing your own document and I'll > be happy to review it with the same courtesy that you have shown. > But complaining about something that the document is not meant to be > is a bit pointless. I agree with you that it's pointless to complain about something that the document is not meant to be. This is really the key issue here, I don't understand the purpose of this draft. I mean, yes, you have clearly stated that this is a follow- on effort of RFC6679, but why should anyone read it, and what should that person learn from it? It seems to me now that your draft is recommending one behavior and surveying some other implemented alternatives with a critical discussion of their value. Is that what it is? Then just state that. Personally, I'm not sure if the survey of implemented stuff is very useful unless it is an experience report, i.e. "this has been found to work well, as documented here..." and "this has been found to work poorly, as documented there...". Cheers, Michael From wes@mti-systems.com Sun Oct 28 19:47:44 2012 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 3DAA321F845E for ; Sun, 28 Oct 2012 19:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8bVOtyJVewG for ; Sun, 28 Oct 2012 19:47:43 -0700 (PDT) Received: from atl4mhob07.myregisteredsite.com (atl4mhob07.myregisteredsite.com [209.17.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9D45C21F8451 for ; Sun, 28 Oct 2012 19:47:43 -0700 (PDT) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id q9T2lgK1030718 for ; Sun, 28 Oct 2012 22:47:42 -0400 Received: (qmail 8397 invoked by uid 0); 29 Oct 2012 02:47:42 -0000 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.143.209) by 0 with ESMTPA; 29 Oct 2012 02:47:42 -0000 Message-ID: <508DEE4C.2020206@mti-systems.com> Date: Sun, 28 Oct 2012 22:47:40 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <8C3E5C88-ED49-484A-BE24-A3CEBA2621E8@g11.org.uk> <9a8e932f4baf3964b931e7cfe7d64bdf.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <9a8e932f4baf3964b931e7cfe7d64bdf.squirrel@www.erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tsvwg Subject: Re: [tsvwg] draft-carlberg-tsvwg-ecn-reactions - Has anyone read this? 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, 29 Oct 2012 02:47:44 -0000 On 10/19/2012 8:49 AM, gorry@erg.abdn.ac.uk wrote: > I'll update the status. I also changed the subject - so hopefully people > will see this draft and start to look at this. > > I'm keen that we get some feedback from people, and then see this sort of > work progress. > > Has anyone on the TSVWG list read this .... > > - do people think we should be working on this topic at the IETF? > - what sort of recommendations are needed - and who needs these? > - do you have other ideas or experience that may be relevant? I've read it. I think it would be fine to work on in TSVWG, if there's interest, and if the scope is limited to basically Informational guidance. I am not personally sure that such recommendations are needed, but from the range of different reactions the authors describe, I can see that there's room for someone to make bad decisions and think they're doing something smart. So, a document like this *could* help avoid some of those situations. As AD for RMCAT, I see this as supplementary, if it was to be taken up. RMCAT will do concrete algorithms, and this is more of a general guidance. Since RMCAT seems to have kind of a full plate and aggressive schedule with the existing charter, it may be a fair idea to handle this in TSVWG, if there's interest. -- Wes Eddy MTI Systems From Ruediger.Geib@telekom.de Mon Oct 29 01:20:02 2012 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 6DB3321F8516 for ; Mon, 29 Oct 2012 01:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, MANGLED_TIME=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xc2uDrOyfpn6 for ; Mon, 29 Oct 2012 01:20:01 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id CAC6821F851F for ; Mon, 29 Oct 2012 01:19:58 -0700 (PDT) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 29 Oct 2012 09:19:50 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113656.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 29 Oct 2012 09:19:50 +0100 From: To: Date: Mon, 29 Oct 2012 09:19:49 +0100 Thread-Topic: [tsvwg] draft-carlberg-tsvwg-ecn-reactions -- which WG? Thread-Index: Ac2zmQM+/XccDrziRh2eKXEjNTRUAgCDtoyQ Message-ID: References: <201210241816.q9OIG4oh025197@bagheera.jungle.bt.co.uk> <4AE5C6BA-E35C-4268-A778-3BA77EE6C7CD@g11.org.uk> <201210251250.q9PCosEG028217@bagheera.jungle.bt.co.uk> <362F5AD2-725E-452D-B446-53EEFAB2C826@g11.org.uk> In-Reply-To: <362F5AD2-725E-452D-B446-53EEFAB2C826@g11.org.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] draft-carlberg-tsvwg-ecn-reactions -- which WG? 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, 29 Oct 2012 08:20:02 -0000 Ken, my expertise is with QoS. I side with Michael and Bob that your document is= not very helpful if it is a list with possible maybe-measures how to deal = with congestion for real time applications. As mentioned earlier, PCN offer= s mechanisms with a scope on real tim,e services at least. So just stating = "remark to another DSCP" doesn't seem to bother to provide an argument as w= e've looked into PCN and don't think it's useful. A review of the state of = the art to me seems to be the least a what a reader may expect. Take PCN as= an example, there's more to review today if it comes to QoS. Regards, R=FCdiger [snip] [Bob] > On the other kitchen sink of responses (triggering RSVP, Diffserv, Redund= ancy, FEC etc), I'm with Michael W. If you're just listing what implementer= s might do, then it has little value. If you're recommending what implement= ers shouldn't do or what they should, it would be worth keeping these. But = none of these other responses you list seem to be that prevalent, important= or practical. [Ken] I think what is missing in those sections is more discussion about the pro'= s and con's of the various approaches. For example, (a) the need for, and = difficulty in achieving, transitive trust between nodes under different adm= inistrative control for diff-serv code points, or on the other hand (b) the= added value of adding markings to packets that could influence downstream = traffic engineering on an as-needed basis. I prefer to stay away from reco= mendations because that can be entirely scenario and user-group specific. [snip] From Ruediger.Geib@telekom.de Mon Oct 29 01:26:03 2012 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 9D2CF21F8539 for ; Mon, 29 Oct 2012 01:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.055 X-Spam-Level: X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nT406sVC7tq for ; Mon, 29 Oct 2012 01:26:01 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9115721F855B for ; Mon, 29 Oct 2012 01:26:01 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 29 Oct 2012 09:25:51 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 29 Oct 2012 09:25:51 +0100 From: To: Date: Mon, 29 Oct 2012 09:25:50 +0100 Thread-Topic: [tsvwg] draft-carlberg-tsvwg-ecn-reactions -- which WG? Thread-Index: Ac2zkyxQJjtfk8uOTNu8QiKv51KBZACGw7ow Message-ID: References: <201210241816.q9OIG4oh025197@bagheera.jungle.bt.co.uk> <0E4DD97C-5C55-4FF2-AFD1-ED2F110A153A@g11.org.uk> In-Reply-To: <0E4DD97C-5C55-4FF2-AFD1-ED2F110A153A@g11.org.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] draft-carlberg-tsvwg-ecn-reactions -- which WG? 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, 29 Oct 2012 08:26:03 -0000 Ken, You've asked: Which vendors dynamically change packet size due to loss? http://citeseer.ist.psu.edu/viewdoc/download?doi=3D10.1.1.161.226&rep=3Drep= 1&type=3Dpdf http://citeseer.ist.psu.edu/viewdoc/download?doi=3D10.1.1.161.5738&rep=3Dre= p1&type=3Dpdf If the links don't work, type in "Skype" and "Congestion" in citeseer or lo= ok for authors Dario Bonfiglio, Marco Mellia, Michela Meo, Nicol=F2 Ritacca= , Dario Rossi or Luca De Cicco, Saverio Mascolo, Vittorio Palmisano. Regards, R=FCdiger Michael: > and a ton of ideas (using DiffServ, using RSVP, using FEC, whatnot). I th= ink that listing all the possible ideas of things one could possibly do in = response to an ECN-mark is pretty pointless. Why not add NSIS? Why not chan= ge the packet size in response to ECN? Why not stop the flow if there is he= avy congestion? And (rinse and) repeat? Why not change this in the codec, t= his in the codec, that in the codec? It's really an endless list! Ken: how many implementations by vendors have you seen of NSIS? Which vendors d= ynamically change packet size due to loss? Perhaps I'm long on the tooth, = but I've seen *deployed* implementations (outside of the research/academic = lab) of diff-serv, RSVP, FEC, and CODECS producing different load rates, al= ong with a number of protocols associated with these designs. NSIS is an e= xperimental protocol, which I didn't feel comfortable including in the list= , but if you feel differently, I'll be happy to read any text you'd like to= propose. From Ruediger.Geib@telekom.de Mon Oct 29 02:11:34 2012 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 79C7721F8540; Mon, 29 Oct 2012 02:11:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWP0IzL8kHE5; Mon, 29 Oct 2012 02:11:32 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id B0A6921F8549; Mon, 29 Oct 2012 02:11:27 -0700 (PDT) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 29 Oct 2012 10:11:19 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 29 Oct 2012 10:11:15 +0100 From: To: Date: Mon, 29 Oct 2012 10:11:14 +0100 Thread-Topic: Informational: draft-geib-tsvwg-diffserv-interconnection-00.txt Thread-Index: Ac21tVjGMVqHKk3STny+++t4bxTNCw== 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] Informational: draft-geib-tsvwg-diffserv-interconnection-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: Mon, 29 Oct 2012 09:11:34 -0000 Dear TSVWG chairs, while I've missed the ID 00 submission deadline, I'd like to infom TSVWG th= at I've meanwhile written a draft-geib-tsvwg-diffserv-interconnection-00.tx= t. It sums up some of the discussion we've had on a revision of RFC5127 an= d 4594. I'm not applying for a time slot in Atlanta and I will not be prese= nt. The draft has been sent to some WG members who've discussed the subject= in the past. If others are interested to get a copy before ID submission is enabled agai= n, please drop me a private message. Regards, R=FCdiger From carlberg@g11.org.uk Mon Oct 29 02:49:18 2012 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 17C0421F85C6 for ; Mon, 29 Oct 2012 02:49:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGN1vg5uz7UI for ; Mon, 29 Oct 2012 02:49:17 -0700 (PDT) Received: from portland.eukhosting.net (portland.ukserverhosting.net [92.48.103.133]) by ietfa.amsl.com (Postfix) with ESMTP id 74E4A21F85E0 for ; Mon, 29 Oct 2012 02:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=gcYY4DiaOMhjyUFXKUaws6CB8GqBdXUedFayh2WbUz0=; b=PvxQXKkD1R0e8ZIuAyB+1ZrKjN2P75PBzEMko7lSlAfiZA8nc0C1UP+/HGj6KAfBA62fm5x0YmoOkgEX/3qCb+Wghhqt1oHaGIfp483uVdIQ+zs5pH5Xj5alxygBqA4S; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:50517 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.80) (envelope-from ) id 1TSly3-0003Sg-EV; Mon, 29 Oct 2012 09:49:11 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <6BA31ACB-4F59-43B8-8517-C0CB306CB8C2@ifi.uio.no> Date: Mon, 29 Oct 2012 05:49:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201210241816.q9OIG4oh025197@bagheera.jungle.bt.co.uk> <0E4DD97C-5C55-4FF2-AFD1-ED2F110A153A@g11.org.uk> <6BA31ACB-4F59-43B8-8517-C0CB306CB8C2@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: tsvwg Subject: Re: [tsvwg] draft-carlberg-tsvwg-ecn-reactions -- which WG? 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, 29 Oct 2012 09:49:18 -0000 >>> One first concern is: the draft seems to consist of one = recommendation (using TFRC), >>=20 >> As I told Bob previously, the draft is *not* meant to be a = recommendation. It is meant to discuss the various reactions that can = be used with ECN signaling -- and I'll add that we wanted to add some = insight as well. And with respect to TFRC, we are *not* recommending = its use as the default CC algorithm as stipulated in rfc-6679. If you = look carefully at the *end* of this paragraph... >=20 > "Not meant to be a recommendation": Here's the first sentence of your = abstract: > "This document presents recommendations for response to Congestion = Experience (CE) notifications by real time applications that have = negotiated end-to-end support of Explicit Congestion Notification = (ECN)." >=20 > So it's obvious that, upon reading it, I believe the draft is meant to = be a recommendation, no? A good catch, which is appreciated, but no. In previous versions of the = draft, we had made a recommendation of using TFRC as *the* default CC = algo discussed in rfc-6679. The rationale was that there was some = measure of implementation of TFRC and that we had an RFC to point to. = Feedback during meetings about this recommendation appeared to be in the = form of tepid agreement and disagreement. But our concerns about TFRC = and the work ramping up for RMCAT made it seem that it was best to = remove the recomendation and point to RMCAT. As you will have noticed further into the reactions draft, we state a = couple of times where in bringing up a type of reaction, we also bring = up some issues to consider, but we refrain from giving specific = recomendations. Andas I stated to Bob, we can add more text = (experience, best common practice, insights -- like what Ruediger = brought up earlier in this discussion) on some of the various reactions = we bring up. So again, thanks for the catch and we scrub the abstract more cleanly = next time. >> However it should be noted that TFRC is only recommended for = real-time >> media use with ECN response. TFRC is not recommended for non-ECN = paths >> due to its loss based operation which leads to full queues with >> maximised latencies. It is assumed that ECN markings will usually = occur >> with lower queue occupancy and thus lower latency. However it is >> understood that ECN marks may not provide for sufficiently low >> latencies in some situations so other congestion control solutions >> would be preferable. >>=20 >> ...we state that "other congestion control solutions would be = preferable". The paragraph is meant to be read and taken as a whole. = What we can do, based on Bob's initial feedback, is to add/alter the = first part of the paragraph to reinforce the understanding that TFRC is = one example of a CC algorithm. >=20 > I got that. I agree, however, with Bob's point that you can't really = expect ECN marking to lead to less delay (sure, AQMs might not follow = RFC 3168, but that's rather speculative I guess? If it's not, a = reference would be good). I couldn't give a definitive answer to your question. I think the = answer comes from how the CC algo's in RMCAT are designed and the = results we see in their simulation/implementation. I think I've responded to the rest of your comments in a previous = response to Bob's email. cheers, -ken >>> and a ton of ideas (using DiffServ, using RSVP, using FEC, whatnot). = I think that listing all the possible ideas of things one could possibly = do in response to an ECN-mark is pretty pointless. Why not add NSIS? Why = not change the packet size in response to ECN? Why not stop the flow if = there is heavy congestion? And (rinse and) repeat? Why not change this = in the codec, this in the codec, that in the codec? It's really an = endless list! >>=20 >> how many implementations by vendors have you seen of NSIS? Which = vendors dynamically change packet size due to loss? Perhaps I'm long on = the tooth, but I've seen *deployed* implementations (outside of the = research/academic lab) of diff-serv, RSVP, FEC, and CODECS producing = different load rates, along with a number of protocols associated with = these designs. NSIS is an experimental protocol, which I didn't feel = comfortable including in the list, but if you feel differently, I'll be = happy to read any text you'd like to propose. >=20 > My point was just that DiffServ, RSVP, .... looks like a list of = random ideas to me. If your basis for presenting them as possible = reactions to ECN is that they are deployed, then what you're presenting = is a survey of deployed work, which may have its own merits - but then = this should be listed as such, with appropriate references wherever = possible. >=20 >=20 >>> So, why are the "ideas" only listed as such, and not as = recommendations? Because you don't back them up with enough "meat" to = make them recommendable. There's a ton of literature out there, on all = these things - if you find something in it that lets you make a = recommendation, go ahead, but as long as the things seem fishy to you, I = would refrain from listing them because they end up being useless to the = reader, too. (note, I have nothing against recommending things other = than "let's just use TFRC", if this is convincingly written, based on = citations to documents that make it clear that these things are indeed = good ideas). >>=20 >> see above. And if your sole interest is to see a set of = recomendations, I would suggest writing your own document and I'll be = happy to review it with the same courtesy that you have shown. But = complaining about something that the document is not meant to be is a = bit pointless. >=20 > I agree with you that it's pointless to complain about something that = the document is not meant to be. >=20 > This is really the key issue here, I don't understand the purpose of = this draft. I mean, yes, you have clearly stated that this is a = follow-on effort of RFC6679, but why should anyone read it, and what = should that person learn from it? > It seems to me now that your draft is recommending one behavior and = surveying some other implemented alternatives with a critical discussion = of their value. Is that what it is? Then just state that. Personally, = I'm not sure if the survey of implemented stuff is very useful unless it = is an experience report, i.e. "this has been found to work well, as = documented here..." and "this has been found to work poorly, as = documented there...". >=20 >=20 > Cheers, > Michael >=20 From carlberg@g11.org.uk Mon Oct 29 02:57:46 2012 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 C147421F84E6 for ; Mon, 29 Oct 2012 02:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MANGLED_TIME=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqdPuqqgYQEP for ; Mon, 29 Oct 2012 02:57:46 -0700 (PDT) Received: from portland.eukhosting.net (portland.ukserverhosting.net [92.48.103.133]) by ietfa.amsl.com (Postfix) with ESMTP id B6AF321F8475 for ; Mon, 29 Oct 2012 02:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=r9vvPPdkhKBe7kj0suUV+B+hR04ccMsq0yCWBaBn6S0=; b=MVJjMoRw0TQJSxL9zh3zoW0oyXz8hlaKJlaj0Vj0s2QixH6V9xVmpwXjiU4V031rzMSFtbENe9lb8U83DDMQyQM72H2xQzNTvyfk5t8vnUoe14qCCcWSn2VlwVjIrAIF; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:50537 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.80) (envelope-from ) id 1TSm6I-0005v2-BF; Mon, 29 Oct 2012 09:57:42 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: ken carlberg In-Reply-To: Date: Mon, 29 Oct 2012 05:57:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201210241816.q9OIG4oh025197@bagheera.jungle.bt.co.uk> <4AE5C6BA-E35C-4268-A778-3BA77EE6C7CD@g11.org.uk> <201210251250.q9PCosEG028217@bagheera.jungle.bt.co.uk> <362F5AD2-725E-452D-B446-53EEFAB2C826@g11.org.uk> To: X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: tsvwg@ietf.org Subject: Re: [tsvwg] draft-carlberg-tsvwg-ecn-reactions -- which WG? 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, 29 Oct 2012 09:57:46 -0000 Ruediger, yes, a fair point. we'll add some more insight into the impact and = possibly pro's/con's of various type of reactions. And just to reinterate a point that I tried to make earlier in this = discussion. The fact that industry (vendors and providers) *are* doing = work on reactions other than, and not related to, using CC algo in = response to ECN signaling is a kind of reality check that we need to be = aware of and provide insight where we can. cheers, -ken On Oct 29, 2012, at 4:19 AM, = wrote: > Ken, >=20 > my expertise is with QoS. I side with Michael and Bob that your = document is not very helpful if it is a list with possible = maybe-measures how to deal with congestion for real time applications. = As mentioned earlier, PCN offers mechanisms with a scope on real tim,e = services at least. So just stating "remark to another DSCP" doesn't seem = to bother to provide an argument as we've looked into PCN and don't = think it's useful. A review of the state of the art to me seems to be = the least a what a reader may expect. Take PCN as an example, there's = more to review today if it comes to QoS. >=20 > Regards, >=20 > R=FCdiger >=20 >=20 > [snip] >=20 >=20 > [Bob] >> On the other kitchen sink of responses (triggering RSVP, Diffserv, = Redundancy, FEC etc), I'm with Michael W. If you're just listing what = implementers might do, then it has little value. If you're recommending = what implementers shouldn't do or what they should, it would be worth = keeping these. But none of these other responses you list seem to be = that prevalent, important or practical. >=20 > [Ken] > I think what is missing in those sections is more discussion about the = pro's and con's of the various approaches. For example, (a) the need = for, and difficulty in achieving, transitive trust between nodes under = different administrative control for diff-serv code points, or on the = other hand (b) the added value of adding markings to packets that could = influence downstream traffic engineering on an as-needed basis. I = prefer to stay away from recomendations because that can be entirely = scenario and user-group specific. >=20 > [snip] From carlberg@g11.org.uk Mon Oct 29 02:58:55 2012 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 50F9321F846D for ; Mon, 29 Oct 2012 02:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ewT4BuVnpl9 for ; Mon, 29 Oct 2012 02:58:54 -0700 (PDT) Received: from portland.eukhosting.net (portland.ukserverhosting.net [92.48.103.133]) by ietfa.amsl.com (Postfix) with ESMTP id 7878221F8475 for ; Mon, 29 Oct 2012 02:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=4RnIvZGOL2EwG52NltGFuaLWtVmkfso1o+eNdNLWihY=; b=ssMGSb6W2CCQkcn8jATU2Ry3/8Xz3e3H3iF/gKfYXYbhjcO6env/+sXrw5E3Uv6Ldhi/ubFZBToHtej+bLUnXXM1VUGQx+3UdzPM/SaQXl7CHvQsFCfqRz9kFC8m7DjV; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:50538 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.80) (envelope-from ) id 1TSm7P-000659-1f; Mon, 29 Oct 2012 09:58:51 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: ken carlberg In-Reply-To: Date: Mon, 29 Oct 2012 05:58:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201210241816.q9OIG4oh025197@bagheera.jungle.bt.co.uk> <0E4DD97C-5C55-4FF2-AFD1-ED2F110A153A@g11.org.uk> To: X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: tsvwg Subject: Re: [tsvwg] draft-carlberg-tsvwg-ecn-reactions -- which WG? 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, 29 Oct 2012 09:58:55 -0000 Excellent. Cool stuff. -ken On Oct 29, 2012, at 4:25 AM, = wrote: > Ken, >=20 > You've asked: Which vendors dynamically change packet size due to = loss? >=20 > = http://citeseer.ist.psu.edu/viewdoc/download?doi=3D10.1.1.161.226&rep=3Dre= p1&type=3Dpdf >=20 > = http://citeseer.ist.psu.edu/viewdoc/download?doi=3D10.1.1.161.5738&rep=3Dr= ep1&type=3Dpdf >=20 >=20 > If the links don't work, type in "Skype" and "Congestion" in citeseer = or look for authors Dario Bonfiglio, Marco Mellia, Michela Meo, Nicol=F2 = Ritacca, Dario Rossi or Luca De Cicco, Saverio Mascolo, Vittorio = Palmisano. >=20 > Regards, R=FCdiger >=20 >=20 >=20 >=20 > Michael: >> and a ton of ideas (using DiffServ, using RSVP, using FEC, whatnot). = I think that listing all the possible ideas of things one could possibly = do in response to an ECN-mark is pretty pointless. Why not add NSIS? Why = not change the packet size in response to ECN? Why not stop the flow if = there is heavy congestion? And (rinse and) repeat? Why not change this = in the codec, this in the codec, that in the codec? It's really an = endless list! >=20 > Ken: > how many implementations by vendors have you seen of NSIS? Which = vendors dynamically change packet size due to loss? Perhaps I'm long on = the tooth, but I've seen *deployed* implementations (outside of the = research/academic lab) of diff-serv, RSVP, FEC, and CODECS producing = different load rates, along with a number of protocols associated with = these designs. NSIS is an experimental protocol, which I didn't feel = comfortable including in the list, but if you feel differently, I'll be = happy to read any text you'd like to propose. >=20 From p.ohanlon@gmail.com Tue Oct 30 05:41:10 2012 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 BA6FF21F8599 for ; Tue, 30 Oct 2012 05:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, GB_I_LETTER=-2, MANGLED_FORM=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwrHNvFWh0cJ for ; Tue, 30 Oct 2012 05:41:09 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 673B221F8596 for ; Tue, 30 Oct 2012 05:41:08 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so2639590wib.13 for ; Tue, 30 Oct 2012 05:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=xT1OyEqMeDoTatJvq7qjAQ6Ou4xnCgALsOo9kyx6Xks=; b=WzSom+sG9vI01tY/08Yio4xNjn10n3VtGJW1SxHO26AMWIwSlStIxGo423PeHP3Cio TV/84n1S3UNwJ1o5wJgEfOJCmcZDBaVDYD24MC/5ItjxCxQgkjUpeDQfbDjKkK21ncZ8 Hw48BYPJKICfFXHYY6TRhaiQTM98XdkS29r+vuetX1hiuLKXPycq/YV6268gI5uRwD9c dNZshncCncoQfH6NierZHrekVvh3y9Uwjapu+UsNT/i1zz9uaIlkImQKHYI0kFmGvTuF G3xmo/0HGQi42gjD8cKTBb0fonRwQBSghaco/SuzaG7C6y+aHiK9egquPyV0KEgp+OHw WmgA== Received: by 10.180.95.97 with SMTP id dj1mr2637885wib.3.1351600867523; Tue, 30 Oct 2012 05:41:07 -0700 (PDT) Received: from ?IPv6:2001:470:1f09:d24:70a1:44da:3019:23ee? ([2001:470:1f09:d24:70a1:44da:3019:23ee]) by mx.google.com with ESMTPS id ei1sm1037310wid.7.2012.10.30.05.40.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Oct 2012 05:40:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Piers O'Hanlon In-Reply-To: <6BA31ACB-4F59-43B8-8517-C0CB306CB8C2@ifi.uio.no> Date: Tue, 30 Oct 2012 12:40:50 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201210241816.q9OIG4oh025197@bagheera.jungle.bt.co.uk> <0E4DD97C-5C55-4FF2-AFD1-ED2F110A153A@g11.org.uk> <6BA31ACB-4F59-43B8-8517-C0CB306CB8C2@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1283) Cc: tsvwg Subject: Re: [tsvwg] draft-carlberg-tsvwg-ecn-reactions -- which WG? 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, 30 Oct 2012 12:41:10 -0000 Hi, Thanks for your comments on the draft. Since Ken has addressed most of = your issues I thought I'd add a reference in response to your question = on RED and media flows below. On 27 Oct 2012, at 09:54, Michael Welzl wrote: [snip] >> ...we state that "other congestion control solutions would be = preferable". The paragraph is meant to be read and taken as a whole. = What we can do, based on Bob's initial feedback, is to add/alter the = first part of the paragraph to reinforce the understanding that TFRC is = one example of a CC algorithm. >=20 > I got that. I agree, however, with Bob's point that you can't really = expect ECN marking to lead to less delay (sure, AQMs might not follow = RFC 3168, but that's rather speculative I guess? If it's not, a = reference would be good). >=20 There has been some work done in this area - see for example: J.M. Pitts, X. Wang, Q. Yang, and J.A. Schormans, Excess-rate queuing = theory for M/M/1/RED with application to VoIP QoS, IET Electronics = Letters, 28 September 2006, Vol. 42, No. 20, pp.1188-1189 = http://academic.research.microsoft.com/Publication/26843304/excess-rate-qu= euing-theory-for-m-m-1-red-with-application-to-voip-qos >=20 >>> and a ton of ideas (using DiffServ, using RSVP, using FEC, whatnot). = I think that listing all the possible ideas of things one could possibly = do in response to an ECN-mark is pretty pointless. Why not add NSIS? Why = not change the packet size in response to ECN? Why not stop the flow if = there is heavy congestion? And (rinse and) repeat? Why not change this = in the codec, this in the codec, that in the codec? It's really an = endless list! >>=20 >> how many implementations by vendors have you seen of NSIS? Which = vendors dynamically change packet size due to loss? Perhaps I'm long on = the tooth, but I've seen *deployed* implementations (outside of the = research/academic lab) of diff-serv, RSVP, FEC, and CODECS producing = different load rates, along with a number of protocols associated with = these designs. NSIS is an experimental protocol, which I didn't feel = comfortable including in the list, but if you feel differently, I'll be = happy to read any text you'd like to propose. >=20 > My point was just that DiffServ, RSVP, .... looks like a list of = random ideas to me. If your basis for presenting them as possible = reactions to ECN is that they are deployed, then what you're presenting = is a survey of deployed work, which may have its own merits - but then = this should be listed as such, with appropriate references wherever = possible. >=20 >=20 >>> So, why are the "ideas" only listed as such, and not as = recommendations? Because you don't back them up with enough "meat" to = make them recommendable. There's a ton of literature out there, on all = these things - if you find something in it that lets you make a = recommendation, go ahead, but as long as the things seem fishy to you, I = would refrain from listing them because they end up being useless to the = reader, too. (note, I have nothing against recommending things other = than "let's just use TFRC", if this is convincingly written, based on = citations to documents that make it clear that these things are indeed = good ideas). >>=20 >> see above. And if your sole interest is to see a set of = recomendations, I would suggest writing your own document and I'll be = happy to review it with the same courtesy that you have shown. But = complaining about something that the document is not meant to be is a = bit pointless. >=20 > I agree with you that it's pointless to complain about something that = the document is not meant to be. >=20 > This is really the key issue here, I don't understand the purpose of = this draft. I mean, yes, you have clearly stated that this is a = follow-on effort of RFC6679, but why should anyone read it, and what = should that person learn from it? > It seems to me now that your draft is recommending one behavior and = surveying some other implemented alternatives with a critical discussion = of their value. Is that what it is? Then just state that. Personally, = I'm not sure if the survey of implemented stuff is very useful unless it = is an experience report, i.e. "this has been found to work well, as = documented here..." and "this has been found to work poorly, as = documented there...". >=20 >=20 > Cheers, > Michael >=20 From jmpolk@cisco.com Tue Oct 30 09:27:48 2012 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 AF3C521F84A0 for ; Tue, 30 Oct 2012 09:27:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt7G24TjR26n for ; Tue, 30 Oct 2012 09:27:48 -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 435E321F8484 for ; Tue, 30 Oct 2012 09:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=571; q=dns/txt; s=iport; t=1351614468; x=1352824068; h=message-id:date:to:from:subject:mime-version; bh=D3/03NZQ7ufmF/uSwjsBjivkE1QhTfHg9EFhzTvMimQ=; b=hqEkWnTyd8g6GGBBV38OGHwGJEjzZwfrUO2u2XMJIzMalIp1icwGHhqu vRTFrJgaJoeBrhScJXx2G4CbvgS1JUQRGJDQL7yYsw0qIOoNo/sTwa8H8 2ZaX+0z3K/7v0mO9HAtRG8RxKguCrYDWlP37uC+Qg2CVA6HuVQkKdRLnH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8OAHf/j1CtJV2b/2dsb2JhbAA+BoQDgU69eoEIgjcBJQJWOilgGYdkC5thgSyPZ5A9jB2DE4MkA4hZm3OBa4MN X-IronPort-AV: E=Sophos;i="4.80,680,1344211200"; d="scan'208";a="136958390" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 30 Oct 2012 16:27:48 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) (authenticated bits=0) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9UGRlGu011566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Oct 2012 16:27:47 GMT Message-Id: <201210301627.q9UGRlGu011566@rcdn-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Oct 2012 11:27:46 -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] TSVWG Agenda for IETF-85 (Atlanta) 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, 30 Oct 2012 16:27:48 -0000 TSVWG Below is the URL to our WG agenda. Please check it to ensure it is acceptable and not missing any items. http://www.ietf.org/proceedings/85/agenda/agenda-85-tsvwg We are meeting TWICE this time. Our 1 hour slot (on Thursday) is dedicated to DiffServ. Our 2 hour slot (on Friday) is for all the rest of our work. This arrangement is unusual for this WG, and will include the WG overview & status presentation on Friday, not Thursday. The schedule is too tight in our 1 hour slot Thursday. Let the agenda bashing begin now! James & Gorry From jsaldana@unizar.es Wed Oct 31 10:21:53 2012 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 385EB21F87EC for ; Wed, 31 Oct 2012 10:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFA1xOITnNkE for ; Wed, 31 Oct 2012 10:21:52 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 557BB21F87E8 for ; Wed, 31 Oct 2012 10:21:51 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q9VHLWZR018381; Wed, 31 Oct 2012 18:21:36 +0100 From: "Jose Saldana" To: "'Zhulei'" , References: <470F27D1263A1B4EB73491ED995DE625249B572B@szxeml504-mbx.china.huawei.com> In-Reply-To: <470F27D1263A1B4EB73491ED995DE625249B572B@szxeml504-mbx.china.huawei.com> Date: Wed, 31 Oct 2012 18:21:40 +0100 Organization: Universidad de Zaragoza Message-ID: <005d01cdb78c$337c6ff0$9a754fd0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUIZbAktrT0DreJUjRjEfTQfu2iJdG0WAA Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [tsvwg] New draft needs readers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 17:21:53 -0000 Hi, I have read your draft, and the idea of "identifying congestion in a tunnel segment of an end-to-end flow" seems interesting to me. Tunneling is something that is getting more and more used in different scenarios, as the ones you cite (VPNs, IPv6 over IPv4, etc.). I think it will become even more important. I have these comments in order to improve the draft: - Abstract: I do not understand what do you mean with this sentence "Because of the particularity of the scenario of the tunnel, the existing E2E traffic management mechanism cannot be directly be deployed". Perhaps you could explain it in two or three sentences. - Introduction, 3rd paragraph: The sentence " the amount of tunnel congestions is fed back to the ingress of the tunnel" could say "the tunnel congestion status is fed back to the ingress of the tunnel". - In 2.1. you could perhaps write the meaning of ECT and ECN, the first time they appear in the draft. - Regarding the structure of the draft, in 1.1. you say " The main section in this document is the basic model described in chapter 4. A". Perhaps chapter 4 is too late for the main section. I don't know, but perhaps you could put it first in order to better understand everything. - Page 9: I do not understand the sentence " The module records the outer header CE codepoint packets reaches the egress independently, and MAY need to estimate the congestion level inside the tunnel." There is something missing, I think. - Page 9: "Figure 3 demonstrates the general process" could say "Figure 3 shows/details the general process" - Page 11, beginning: "where the users locate" should say "where the users are located" - Page 11, there is something missing in the sentence " The two PEs are the powerful nodes that acting as the entry and egress of the tunnel, receiving and sending back the congestion information." Best regards, Jose Saldana _____________________ De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre de Zhulei Enviado el: martes, 23 de octubre de 2012 10:38 Para: tsvwg@ietf.org Asunto: [tsvwg] New draft needs readers Hi folks, I would be seeing some of your reading 00-version draft http://tools.ietf.org/html/draft-zhang-tsvwg-tunnel-congestion-exposure-00. This problem statement mentions the ingress of a tunnel protocol would be good to read congestion feedback from egress of tunnel if ingress has policy, flow control, admission control behavior. We assumed a possible standard proposal in this draft if we recognize this, on the other hand marking problem is our issue may alternatively use PCN extensions. Best regards, Zhu Lei Huawei Wireless network research department E-mail address: lei.zhu@huawei.com Phone: +86-10-60611961 Mobile: +86-13910157020