From dreibh@iem.uni-due.de Tue Sep 4 15:06:13 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 4BDA921E80A7 for ; Tue, 4 Sep 2012 15:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 q8DjnwlH+6Ji for ; Tue, 4 Sep 2012 15:06:13 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id D239E21E80A3 for ; Tue, 4 Sep 2012 15:06:12 -0700 (PDT) Received: from lupo.localnet (243-42-11.connect.netcom.no [176.11.42.243]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id q84M6AeR006503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 5 Sep 2012 00:06:11 +0200 From: Thomas Dreibholz To: tsvwg@ietf.org Date: Tue, 04 Sep 2012 22:08:07 +0200 Message-ID: <1558024.sDajvb5yRn@lupo> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.9 (Linux/3.2.0-29-generic; KDE/4.9.0; 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] 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, 04 Sep 2012 22:06:13 -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 Networkingand 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 01, 2012 * 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 gorry@erg.abdn.ac.uk Wed Sep 5 07:06: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 953D521F85E6 for ; Wed, 5 Sep 2012 07:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGuVaHh6-Oma for ; Wed, 5 Sep 2012 07:06:10 -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 74E7321F8508 for ; Wed, 5 Sep 2012 07:06:10 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 69C6E2B45C2; Wed, 5 Sep 2012 15:06:09 +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 92E462B451E; Wed, 5 Sep 2012 15:06:06 +0100 (BST) Message-ID: <50475C4D.2020303@erg.abdn.ac.uk> Date: Wed, 05 Sep 2012 15:06:05 +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/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: John Leslie References: <502B4E2D.7070700@abdn.ac.uk> <502B527E.5090700@erg.abdn.ac.uk> <20120815190728.GQ15012@verdi> In-Reply-To: <20120815190728.GQ15012@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org Subject: Re: [tsvwg] FYI: Document writeup for draft-ietf-tsvwg-byte-pkt-congest X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:06:11 -0000 We plan to review your message with the authors and will report back to the mailing list - I expect most issues can be resolved. Gorry On 15/08/2012 20:07, John Leslie wrote: > Gorry Fairhurst 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 > From Rolf.Winter@neclab.eu Wed Sep 5 07:58:56 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 98B4E21F85A8 for ; Wed, 5 Sep 2012 07:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.392 X-Spam-Level: X-Spam-Status: No, score=-101.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 m524xj5rkcdR for ; Wed, 5 Sep 2012 07:58:55 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 31D7921F864A for ; Wed, 5 Sep 2012 07:58:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 49612101D0C for ; Wed, 5 Sep 2012 16:58:54 +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 6Mxw9ffQUqV6 for ; Wed, 5 Sep 2012 16:58:54 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 32F00101D0B for ; Wed, 5 Sep 2012 16:58:49 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.159]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 5 Sep 2012 16:58:49 +0200 From: Rolf Winter To: "tsvwg@ietf.org" Thread-Topic: minutes posted Thread-Index: Ac2Ldv2icsRPu4mhSECl/rGbe6lSvA== Date: Wed, 5 Sep 2012 14:59:04 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D4E373DFD@Polydeuces.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tsvwg] minutes posted X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:58:56 -0000 Hi, the meeting minutes have been posted (thanks David for taking them!). Sorry= for the delay (my mistake). http://tools.ietf.org/wg/tsvwg/minutes?item=3Dminutes-84-tsvwg.html Please review and let us know if we missed anything. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From Rolf.Winter@neclab.eu Tue Sep 11 08:32: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 EE81D21F8639 for ; Tue, 11 Sep 2012 08:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.653 X-Spam-Level: X-Spam-Status: No, score=-101.653 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_05=-1.11, 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 69PxDUsPNsLa for ; Tue, 11 Sep 2012 08:32:48 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFCA21F861A for ; Tue, 11 Sep 2012 08:32:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 11003101D88 for ; Tue, 11 Sep 2012 17:32:47 +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 3TQ9nbcPemaj for ; Tue, 11 Sep 2012 17:32:46 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id EBD3F101D85 for ; Tue, 11 Sep 2012 17:32:41 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 11 Sep 2012 17:32:41 +0200 From: Rolf Winter To: "tsvwg@ietf.org" Thread-Topic: review(er)s for and/or comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles Thread-Index: Ac2QMqv9tqk9HyxTTIW6IEQ/crgmOQ== Date: Tue, 11 Sep 2012 15:32:38 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D5066E6AA@PALLENE.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tsvwg] review(er)s for and/or comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles 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, 11 Sep 2012 15:32:49 -0000 WG, draft-polk-tsvwg-rsvp-app-id-vv-profiles has been presented at the last mee= ting and we decided to defer the question of whether we'll make this a WG d= raft or not after we received comments from the list. If you would like to = volunteer to review the draft we'd like to hear from you. Also, if already = read the draft, we would like to hear your comments/opinion on the document= (in particular whether you support the document to become a WG item or not= ). Please read the draft! Best, The chairs NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From jsaldana@unizar.es Wed Sep 12 01:59:54 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 783D521F8621 for ; Wed, 12 Sep 2012 01:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.45 X-Spam-Level: X-Spam-Status: No, score=-4.45 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_50=0.001, 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 pIbbkOaVr1vB for ; Wed, 12 Sep 2012 01:59:53 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 6B23921F861E for ; Wed, 12 Sep 2012 01:59:51 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q8C8xh37003311; Wed, 12 Sep 2012 10:59:43 +0200 From: "Jose Saldana" To: "'Rolf Winter'" , , "James M. Polk" References: <791AD3077F94194BB2BDD13565B6295D5066E6AA@PALLENE.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D5066E6AA@PALLENE.office.hd> Date: Wed, 12 Sep 2012 10:59:47 +0200 Organization: Universidad de Zaragoza Message-ID: <005701cd90c4$f669a1c0$e33ce540$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01CD90D5.B9F33510" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIPfJABtzqQ5TAckaEuhLOu0krtF5cCiSYw Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [tsvwg] review(er)s for and/or comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles 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, 12 Sep 2012 08:59:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0058_01CD90D5.B9F33510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Here go two comments about the draft: - Second paragraph of Introduction: Current version: "One new attribute currently being defined is to establish the type of traffic contained that reservation." My proposal: "One new attribute is currently being defined so as to establish the type of traffic contained in that reservation path." - First paragraph of 3.2: Current version: "This traffic type will generally not be UDP based" There are online games using TCP and others using UDP. Examples of the former ones are almost every MMORPG (e.g. World of Warcraft, Diablo, Eve online, etc). However, there exist MMORPGs which use UDP (City of Heroes http://nslab.ee.ntu.edu.tw/publication/journal/7.pdf). And almost every First Person Shooter (FPS) uses UDP (Microsoft Halo, Counter Strike, Quake, etc.). And they are very popular: if you look here http://www.theclq.com/ags/games.php, you may see that in this moment, 121,000 people are playing Counter Strike there. Here is an article about the traffic of FPSs: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5445069 &tag=1 So my proposal for the sentence is "This traffic may be UDP or TCP based". Another option is to remove the sentence. I support the document to become a WG item. Best regards, Jose Saldana -----Mensaje original----- De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre de Rolf Winter Enviado el: martes, 11 de septiembre de 2012 17:33 Para: tsvwg@ietf.org Asunto: [tsvwg] review(er)s for and/or comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles WG, draft-polk-tsvwg-rsvp-app-id-vv-profiles has been presented at the last meeting and we decided to defer the question of whether we'll make this a WG draft or not after we received comments from the list. If you would like to volunteer to review the draft we'd like to hear from you. Also, if already read the draft, we would like to hear your comments/opinion on the document (in particular whether you support the document to become a WG item or not). Please read the draft! Best, The chairs NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 ------=_NextPart_000_0058_01CD90D5.B9F33510 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Here go two comments about the = draft:

 

- Second paragraph of Introduction:

Current version:  "One = new attribute currently being defined is to establish the type of = traffic contained that reservation."

My proposal: "One new = attribute is currently being defined so as to establish the type of = traffic contained in that reservation = path."

 

 

- First paragraph of 3.2:

Current version: "This = traffic type will generally not be UDP = based"

 

There are online games using TCP and others using UDP. = Examples of the former ones are almost every MMORPG (e.g. World of = Warcraft, Diablo, Eve online, etc). However, there exist MMORPGs which = use UDP (City of Heroes http://nsla= b.ee.ntu.edu.tw/publication/journal/7.pdf).

 

And almost every First Person = Shooter (FPS) uses UDP (Microsoft Halo, Counter Strike, Quake, etc.). = And they are very popular: if you look here http://www.theclq.com/ags/ga= mes.php, you may see that in this moment, 121,000 people are playing = Counter Strike there. Here is an article about the traffic of FPSs: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=3D5445069= &tag=3D1

 

So my proposal for the sentence is "This traffic may = be UDP or TCP based". Another option is to remove the = sentence.

 

 

I support the document to become a WG = item.

 

Best regards,

 

Jose = Saldana

 

-----Mensaje = original-----
De: tsvwg-bounces@ietf.org = [mailto:tsvwg-bounces@ietf.org] En nombre de Rolf Winter
Enviado el: = martes, 11 de septiembre de 2012 17:33
Para: = tsvwg@ietf.org
Asunto: [tsvwg] review(er)s for and/or comments on = draft-polk-tsvwg-rsvp-app-id-vv-profiles

 

WG,

 

draft-polk-tsvwg-rsvp-app-id-vv-profiles has been = presented at the last meeting and we decided to defer the question of = whether we'll make this a WG draft or not after we received comments = from the list. If you would like to volunteer to review the draft we'd = like to hear from you. Also, if already read the draft, we would like to = hear your comments/opinion on the document (in particular whether you = support the document to become a WG item or not).

 

Please = read the draft!

 

Best,

 

The = chairs

 

NEC Europe Limited | Registered Office: NEC House, = 1 Victoria Road, London W3 6BL | Registered in England 2832014 =

 

 

------=_NextPart_000_0058_01CD90D5.B9F33510-- From jmpolk@cisco.com Wed Sep 12 13:51: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 4B66121F857A for ; Wed, 12 Sep 2012 13:51:38 -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 prFiA4PrCEeU for ; Wed, 12 Sep 2012 13:51:36 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 035C321F8574 for ; Wed, 12 Sep 2012 13:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2823; q=dns/txt; s=iport; t=1347483095; x=1348692695; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=ZDe1mpOmPYo81bqea/3C21dHkuH3b1bW80cfRWjsmZg=; b=ffzadQrldg8kKtvJolvP42a1ESDGH6imqj1OxhKxIaS2eYH/RjnuWOHs YjN66MZUj+3IsHtavsc42fmE7JlpVe9kkL8mtCfJ9FHoGD4wfLPWJe8iq sn2Gs3Se540Ztkzgkj+AVpaloLeNH7PwXqak7ZEOHv8MDkJ/u+58iTFef g=; X-IronPort-AV: E=Sophos;i="4.80,413,1344211200"; d="scan'208";a="57985796" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 12 Sep 2012 20:51:35 +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 q8CKpYKF021441; Wed, 12 Sep 2012 20:51:34 GMT Message-Id: <201209122051.q8CKpYKF021441@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 12 Sep 2012 15:51:33 -0500 To: , "'Rolf Winter'" , , "James M. Polk" From: James Polk In-Reply-To: <005701cd90c4$f669a1c0$e33ce540$@unizar.es> References: <791AD3077F94194BB2BDD13565B6295D5066E6AA@PALLENE.office.hd> <005701cd90c4$f669a1c0$e33ce540$@unizar.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [tsvwg] review(er)s for and/or comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles 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, 12 Sep 2012 20:51:41 -0000 At 03:59 AM 9/12/2012, Jose Saldana wrote: >Hello, > >Here go two comments about the draft: > >- Second paragraph of Introduction: >Current version: "One new attribute currently being defined is to >establish the type of traffic contained that reservation." >My proposal: "One new attribute is currently being defined so as to >establish the type of traffic contained in that reservation path." I'll accept this change - it reads better. Thank you. > > >- First paragraph of 3.2: >Current version: "This traffic type will generally not be UDP based" > >There are online games using TCP and others using UDP. Examples of >the former ones are almost every MMORPG (e.g. World of Warcraft, >Diablo, Eve online, etc). However, there exist MMORPGs which use UDP >(City of Heroes >http://nslab.ee.ntu.edu.tw/publication/journal/7.pdf). > > >And almost every First Person Shooter (FPS) uses UDP (Microsoft >Halo, Counter Strike, Quake, etc.). And they are very popular: if >you look here >http://www.theclq.com/ags/games.php, >you may see that in this moment, 121,000 people are playing Counter >Strike there. Here is an article about the traffic of FPSs: >http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5445069&tag=1 > > >So my proposal for the sentence is "This traffic may be UDP or TCP >based". Another option is to remove the sentence. I'll change the existing text, but don't know yet which way above, as you suggest, I'll go at the moment. I need to think a bit more - unless others have an opinion one way or the other. > > >I support the document to become a WG item. Thank you James > >Best regards, > >Jose Saldana > >-----Mensaje original----- >De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre >de Rolf Winter >Enviado el: martes, 11 de septiembre de 2012 17:33 >Para: tsvwg@ietf.org >Asunto: [tsvwg] review(er)s for and/or comments on >draft-polk-tsvwg-rsvp-app-id-vv-profiles > >WG, > >draft-polk-tsvwg-rsvp-app-id-vv-profiles has been presented at the >last meeting and we decided to defer the question of whether we'll >make this a WG draft or not after we received comments from the >list. If you would like to volunteer to review the draft we'd like >to hear from you. Also, if already read the draft, we would like to >hear your comments/opinion on the document (in particular whether >you support the document to become a WG item or not). > >Please read the draft! > >Best, > >The chairs > >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >London W3 6BL | Registered in England 2832014 > > From karagian@cs.utwente.nl Wed Sep 12 22:33: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 7C4D821E8047 for ; Wed, 12 Sep 2012 22:33:18 -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 4rNex5ZGcfdZ for ; Wed, 12 Sep 2012 22:33:18 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id C470F21E8034 for ; Wed, 12 Sep 2012 22:33:17 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 13 Sep 2012 07:33:17 +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, 13 Sep 2012 07:33:15 +0200 From: To: , Thread-Topic: [tsvwg] review(er)s for and/or comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles Thread-Index: Ac2QMqv9tqk9HyxTTIW6IEQ/crgmOQBPi0m2 Date: Thu, 13 Sep 2012 05:33:14 +0000 Message-ID: References: <791AD3077F94194BB2BDD13565B6295D5066E6AA@PALLENE.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D5066E6AA@PALLENE.office.hd> 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: Re: [tsvwg] review(er)s for and/or comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 05:33:18 -0000 Hi all, I have already reviewd v03 of this draft and I am satsified with the way th= at the authors worked out my comments in v04. Therefore, I support the proposal that this ID becomes a WG draft! Best regards, Georgios ________________________________________ Van: tsvwg-bounces@ietf.org [tsvwg-bounces@ietf.org] namens Rolf Winter [Ro= lf.Winter@neclab.eu] Verzonden: dinsdag 11 september 2012 17:32 Aan: tsvwg@ietf.org Onderwerp: [tsvwg] review(er)s for and/or comments on draft-polk-tsvwg-rsvp= -app-id-vv-profiles WG, draft-polk-tsvwg-rsvp-app-id-vv-profiles has been presented at the last mee= ting and we decided to defer the question of whether we'll make this a WG d= raft or not after we received comments from the list. If you would like to = volunteer to review the draft we'd like to hear from you. Also, if already = read the draft, we would like to hear your comments/opinion on the document= (in particular whether you support the document to become a WG item or not= ). Please read the draft! Best, The chairs NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014= From paulej@packetizer.com Thu Sep 13 22:27: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 261BC21F8701 for ; Thu, 13 Sep 2012 22:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.434, 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 8LZUWfXXti9c for ; Thu, 13 Sep 2012 22:27:21 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF9221F86C8 for ; Thu, 13 Sep 2012 22:27:21 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q8E5RJuU003950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Sep 2012 01:27:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1347600440; bh=OfBg/K5fUK2JLHOTDi4ukPkJoUbhfqxv0PlZ06Evk5M=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=BTQ82WT4rjsZlocDgoWLw4Xvf2RU6LSZVCWxR2K//XnMoZg+6kz3xQGk7YgQhZ4lk IgI2riCaedrTG1/egnqXiuBz8UIclwmMHcQgQLGrBHJVgNlkgqr309wcqAm/zuO+vZ QCnJNck8S4b32xjuOkdG2ULfD2vyBGhdGSVvRhtM= From: "Paul E. Jones" To: "'Rolf Winter'" , References: <791AD3077F94194BB2BDD13565B6295D5066E6AA@PALLENE.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D5066E6AA@PALLENE.office.hd> Date: Fri, 14 Sep 2012 01:27:30 -0400 Message-ID: <0bf901cd9239$a30c83f0$e9258bd0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIPfJABtzqQ5TAckaEuhLOu0krtF5cFeBjg Content-Language: en-us Subject: Re: [tsvwg] review(er)s for and/or comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 05:27:22 -0000 Rolf, This draft has utility and I support it going forward as a WG document. There are some editorial work that needs to be done, but the utility is clear and ties together with the traffic class label work in MMUSIC. One noted change that was discussed is the P-type value. Previously, it was AUTH_APP and now the document shows AUTH_APP in some places and APP_TC in others. I would prefer to leave AUTH_APP as it was. The application string containing the GUID make it clear the nature of this policy object. Paul > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Rolf Winter > Sent: Tuesday, September 11, 2012 11:33 AM > To: tsvwg@ietf.org > Subject: [tsvwg] review(er)s for and/or comments on draft-polk-tsvwg-rsvp- > app-id-vv-profiles > > WG, > > draft-polk-tsvwg-rsvp-app-id-vv-profiles has been presented at the last > meeting and we decided to defer the question of whether we'll make this a > WG draft or not after we received comments from the list. If you would > like to volunteer to review the draft we'd like to hear from you. Also, if > already read the draft, we would like to hear your comments/opinion on the > document (in particular whether you support the document to become a WG > item or not). > > Please read the draft! > > Best, > > The chairs > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London > W3 6BL | Registered in England 2832014 > From jmpolk@cisco.com Fri Sep 14 12:54: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 F360E21F853D for ; Fri, 14 Sep 2012 12:54: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 HHwNBZFw1JJM for ; Fri, 14 Sep 2012 12:54:51 -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 8AAF021F8497 for ; Fri, 14 Sep 2012 12:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1802; q=dns/txt; s=iport; t=1347652491; x=1348862091; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=6RvNARcFU6YD0ycY5is9caFJtrwPrQi4pRboURf4Epg=; b=V0a94JZs2NmSUmcKwR1cZ0ckmB2XohCwJrtSFqnwz40LoOPNT4uW24dy oOxnVppeYrU8fSgjSoQDil35mARDXKpDpRqPQv9HRk0h2S0Ym5ZD+sI7R uaxADQCVH5vGE3jCJxDpzifDlkxENlnJmbB+xIhVibrtk7My8XPLbw7Vq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIWKU1CrRDoJ/2dsb2JhbABFvAqBB4IgAQEBBBIBJQJLBAcEEQQBAQEeCQcZLQkIBgESIodqmzugIosfFASGUAOIVptDgWmDBIE8 X-IronPort-AV: E=Sophos;i="4.80,424,1344211200"; d="scan'208";a="58281477" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 14 Sep 2012 19:54:49 +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 q8EJsm0U011147; Fri, 14 Sep 2012 19:54:49 GMT Message-Id: <201209141954.q8EJsm0U011147@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 14 Sep 2012 14:54:47 -0500 To: "Paul E. Jones" , "'Rolf Winter'" , From: James Polk In-Reply-To: <0bf901cd9239$a30c83f0$e9258bd0$@packetizer.com> References: <791AD3077F94194BB2BDD13565B6295D5066E6AA@PALLENE.office.hd> <0bf901cd9239$a30c83f0$e9258bd0$@packetizer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [tsvwg] review(er)s for and/or comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 19:54:52 -0000 Paul Thanks for the review. I have no problems changing the P-Type back to the original proposal (AUTH_APP). Regardless, consistency is necessary, and will be addressed. James At 12:27 AM 9/14/2012, Paul E. Jones wrote: >Rolf, > >This draft has utility and I support it going forward as a WG document. > >There are some editorial work that needs to be done, but the utility is >clear and ties together with the traffic class label work in MMUSIC. > >One noted change that was discussed is the P-type value. Previously, it was >AUTH_APP and now the document shows AUTH_APP in some places and APP_TC in >others. I would prefer to leave AUTH_APP as it was. The application string >containing the GUID make it clear the nature of this policy object. > >Paul > > > -----Original Message----- > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > > Rolf Winter > > Sent: Tuesday, September 11, 2012 11:33 AM > > To: tsvwg@ietf.org > > Subject: [tsvwg] review(er)s for and/or comments on draft-polk-tsvwg-rsvp- > > app-id-vv-profiles > > > > WG, > > > > draft-polk-tsvwg-rsvp-app-id-vv-profiles has been presented at the last > > meeting and we decided to defer the question of whether we'll make this a > > WG draft or not after we received comments from the list. If you would > > like to volunteer to review the draft we'd like to hear from you. Also, if > > already read the draft, we would like to hear your comments/opinion on the > > document (in particular whether you support the document to become a WG > > item or not). > > > > Please read the draft! > > > > Best, > > > > The chairs > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London > > W3 6BL | Registered in England 2832014 > > From Karen.Nielsen@tieto.com Mon Sep 24 11:12: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 835ED1F040A for ; Mon, 24 Sep 2012 11:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 v2MSmADItcjA for ; Mon, 24 Sep 2012 11:12:08 -0700 (PDT) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by ietfa.amsl.com (Postfix) with ESMTP id 00E7C1F0381 for ; Mon, 24 Sep 2012 11:12:07 -0700 (PDT) X-AuditID: 83cfa824-b7f2c6d0000009fa-c8-5060a276b231 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb05.tieto.com (SMTP Mailer) with SMTP id FA.81.02554.672A0605; Mon, 24 Sep 2012 21:12:06 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.121]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Mon, 24 Sep 2012 21:12:06 +0300 From: To: Date: Mon, 24 Sep 2012 21:12:04 +0300 Thread-Topic: NR-SACK in draft-tuexen-tsvwg-sctp-mulitpath-sctp-05.txt Thread-Index: Ac2agBorNtbO3HqpSSqWhUXWGdXnoA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF340E42AED0874C81947E18863DE77B2554B8D092EXMB03eutieto_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsXSfL5DS7dsUUKAwcrVShbH3txlc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxq4NW9kKfiZWfD/5lrGB8UlEFyMHh4SAicTsNTZdjJxAppjE hXvr2boYuTiEBFYxSnxr/8UK4UxhlPj3fyczSBWbgLzE3L2r2EGaRQREJLp36IOEWQRUJW6+ /ccIYgsLOEpseHEDzBYRcJN40nyLBcLWk3jUd4ENpJVXwEfi59sikDAj0N7vp9YwgdjMAuIS t57MZ4K4R0BiyZ7zzBC2qMTLx/9YIepFJe60r2eEqM+XaNn+ng3E5hUQlDg58wnLBEahWUhG zUJSNgtJGURcT+LG1ClsELa2xLKFr5khbF2JGf8OsSCLL2BkX8XIn5qUZGCqV5KZWpKvl5yf u4kRHAMrVHYwnn0gdYhRgINRiYf3RmtCgBBrYllxZe4hRkkOJiVR3t0LgEJ8SfkplRmJxRnx RaU5qcWHGCU4mJVEeK90AeV4UxIrq1KL8mFS0hwsSuK8u6YCpQTSE0tSs1NTC1KLYLIyHBxK ErwlC4GygkWp6akVaZk5JQhpJg5OkOE8QMO1QWp4iwsSc4sz0yHypxgVpcR5XUASAiCJjNI8 uF5YinrFKA70ijCvKUgVDzC9wXW/AhrMBDSYf08cyOCSRISUVANjrtEXcYkoqZANfMIL2dSP H5h++23Z07JtLv2s/uoPNxnPdT97m+NtiVYax7JzrhFTX4fvUiiNvbh1Ual4lpHLr/SSv537 Bbts4v06Ohzl82XvZVic4utY/yTHbVqv1E4+cYbG+dtyzpj7/5k6Q3HjAYbQGw5rrCNZ3x0R nFjxh7tg06LP+dZKLMUZiYZazEXFiQAXAKWtLAMAAA== Subject: [tsvwg] NR-SACK in draft-tuexen-tsvwg-sctp-mulitpath-sctp-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: Mon, 24 Sep 2012 18:12:10 -0000 --_000_CF340E42AED0874C81947E18863DE77B2554B8D092EXMB03eutieto_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The NR-SACK work seems now to be fully incorporated in the "CMT-SCTP" draft draft-tuexen-tsvwg-sctp-mulitpath-sctp-05.txt. I fully support both the NR-SACK and the CMT-SCTP work, but given that the NR-SACK mechanism, like, e.g., the potentially failed mechanism, is equally= relevant for non-CMT SCTP, then I wonder what the motivation is for incorporating the NR-SACK work int= o draft-tuexen-tsvwg-sctp-mulitpath-sctp-05.txt. Is it because it is believed that NR-SACK only is significant for CMT-SCTP = ? - or is it so that the "CMT-draft" generally will include mechanisms relevant also for a = non-CMT SCTP ? In the latter case then I think that this should be made more explicit in t= he draft - e.g., by noting which of the mechanisms that equally well apply to non-CMT SCTP. I recognize that also other mechanisms of the CMT-SCTP draft, like CuCv2, at least from a "far-fetched (?)" theoretical standpoint, have relevance fo= r a non CMT-SCTP implementation (for temporary transmission concurrency during path changes and/or retransmissions). But I should still think that the NR-SACK mechanism stand out as a generic = "core" SCTP mechanism opposed to CuCv2 - ? Thanks. BR, Karen ***************************************************************************= ************** Karen Egede Nielsen Software Architect, Ph.D. Tieto Denmark A/S IP Solutions, R&D Services =C5have Parkvej 27, 2nd, 8260 Viby J, DK-Denmark Direct Phone / Mobile +45 25134336 E-mail: karen.nielsen@tieto.com ***************************************************************************= ************** www.tieto.com Please note: The information contained in this message may be legally privi= leged and confidential and protected from disclosure. If the reader of this= message is not the intended recipient, you are hereby notified that any un= authorised use, distribution or copying of this communication is strictly p= rohibited. If you have received this communication in error, please notify = us immediately by replying to the message and deleting it from your compute= r. Thank You. --_000_CF340E42AED0874C81947E18863DE77B2554B8D092EXMB03eutieto_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

=

 

The NR-SACK work seems = now to be fully incorporated in the

̶= 0;CMT-SCTP” draft draft-tuexen-tsvwg-sctp-mulitpath-sctp-05.txt.=

 

I full= y support both the NR-SACK and the CMT-SCTP work, but given that the

NR-SACK mechanism, like, e.g., the potentially f= ailed mechanism, is equally relevant for non-CMT SCTP,

then I wonder what the motivation is for incorporating the NR-= SACK work into

draft-tuexen-tsvwg-sctp-mu= litpath-sctp-05.txt.

 

Is it because it is believed that NR-SACK only is signi= ficant for CMT-SCTP ? - or is it so

that t= he “CMT-draft” generally will include mechanisms relevant also = for a non-CMT SCTP ?

 

In the latter case then I think that this should be mad= e more explicit in the draft – e.g., by

noting which of the mechanisms that equally well apply to non-CMT SCTP.=

 

I= recognize that also other mechanisms of the CMT-SCTP draft, like CuCv2,

at least from a “far-fetched (?)̶= 1; theoretical standpoint, have relevance for

a non CMT-SCTP implementation (for temporary transmission concurrency =

during path changes and/or retransmission= s).

But I should still think that the NR-= SACK mechanism stand out as a generic “core” SCTP mechanism

opposed to CuCv2 - ?

 

Thanks.<= /p>

 

BR, Karen=

 

 <= /o:p>

 

*******************= **********************************************************************=

Karen Egede Nielsen

=

Sof= tware Architect, Ph.D.

 

Tieto Denmark A/S

IP Solutions, R&am= p;D Services

=C5have Parkvej 27, 2nd, 8260 Viby= J, DK-Denmark

Direct Phone / Mobile +45 251= 34336

E-mail: karen.nielsen@tieto.com

*****************************************************= ************************************

www.tie= to.com=A0

 

Please = note: The information contained in this message may be legally privileged a= nd confidential and protected from disclosure. If the reader of this messag= e is not the intended recipient, you are hereby notified that any unauthori= sed use, distribution or copying of this communication is strictly prohibit= ed. If you have received this communication in error, please notify us imme= diately by replying to the message and deleting it from your computer. Thank You.

 

&nbs= p;

= --_000_CF340E42AED0874C81947E18863DE77B2554B8D092EXMB03eutieto_-- From Karen.Nielsen@tieto.com Tue Sep 25 00:01:59 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 D89D821F8927; Tue, 25 Sep 2012 00:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, 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 3GGwuRRo2WTv; Tue, 25 Sep 2012 00:01:58 -0700 (PDT) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by ietfa.amsl.com (Postfix) with ESMTP id 8057921F890D; Tue, 25 Sep 2012 00:01:57 -0700 (PDT) X-AuditID: 83cfa824-b7f2c6d0000009fa-fb-506156e36c14 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb05.tieto.com (SMTP Mailer) with SMTP id F0.06.02554.3E651605; Tue, 25 Sep 2012 10:01:55 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.121]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Tue, 25 Sep 2012 10:01:54 +0300 From: To: Date: Tue, 25 Sep 2012 10:01:53 +0300 Thread-Topic: rtorestart applicable for SCTP ? Thread-Index: Ac2a66T5VBzC+ClCTlufoA0AU1T12A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF340E42AED0874C81947E18863DE77B2554B8D17BEXMB03eutieto_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGKsWRmVeSWpSXmKPExsXSfL5DS/dxWGKAweGvehafV15gtdh2cj6T xbE3d9kcmD2WLPnJ5PH3QitbAFMUl01Kak5mWWqRvl0CV8bZW3cZC1amVGxuvMzSwHg0qouR k0NCwETi9f83jBC2mMSFe+vZuhi5OIQEVjFK3Hy8nBnCmcIoce3VBFaQKjYBeYm5e1exg9gi AuISa+c/BOrg4GAWUJVY/ywWJMwCZHad38AEYgsLaEr8b1zNBFGuJ3G5ZwEzjL31/RuwMbwC PhJtzSvYQGxGoCO+n1oDVs8MNP7Wk/lMEMcJSCzZc54ZwhaVePn4HytEvajEnfb1jBD1+RLT lsxhhpgpKHFy5hOWCYzCs5CMmoWkbBaSMoi4nsSNqVPYIGxtiWULXzND2LoSM/4dYkEWX8DI voqRPzUpycBUryQztSRfLzk/dxMjOHpWqOxgPPtA6hCjAAejEg/vjdaEACHWxLLiytxDjJIc TEqivGxBiQFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHh3ywDleFMSK6tSi/JhUtIcLErivLum Ak0SSE8sSc1OTS1ILYLJynBwKEnwJoQCNQoWpaanVqRl5pQgpJk4OEGG8wANjwap4S0uSMwt zkyHyJ9iVJQS510KkhAASWSU5sH1wpLbK0ZxoFeEeWtBqniAiRGu+xXQYCagwfx74kAGlyQi pKQaGDV+v3DeUz835ewro3nLjtvVNxjLb7u3b5fpv/woC9XNFlKtfde36ajo7/uc4X7l3Nsr vxMrP82Lmn5upZTzGftvbfncv2ozNSaL/O7mPTf/j9K82R/lWy68Om1ovq7p4SaZhJv1rP9L c4yPFuyVEWK0Uy7TDBBX4Dq/caFHUo1R4w7PDSf99JRYijMSDbWYi4oTAXx+sCtJAwAA Cc: tcpm@ietf.org, tsvwg@ietf.org Subject: [tsvwg] rtorestart applicable for SCTP ? 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, 25 Sep 2012 07:02:00 -0000 --_000_CF340E42AED0874C81947E18863DE77B2554B8D17BEXMB03eutieto_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This comment is related to draft-hurtig-tcpm-rtorestart-02. The work seems to assume that SCTP T3 handling is as in TCP, which it is no= t. By prescription SCTP should already implement "almost" the mechanism descri= bed in the draft as indeed it is prescribed to: Section 6.3.2: R3) Whenever a SACK is received that acknowledges the DATA chunk with the earliest outstanding TSN for that address, restart the T3-rtx timer for that address with its current RTO (if there is still outstanding data on that address). The difference in between the Rtorestart draft and existing SCTP prescripti= on then seems to be that SCTP does it always not only under special circumstances - ? The latter perhaps then should be questioned - in particular if STCP, as TC= P, is to start using larger initial CWNDs. BR, Karen PS: I have not followed discussions on the work, draft-hurtig-tcpm-rtorestart-02, in the past, so my comment may already have been discussed. If so than I apologize in advance ! ***************************************************************************= ************** Karen Egede Nielsen Software Architect, Ph.D. Tieto Denmark A/S IP Solutions, R&D Services =C5have Parkvej 27, 2nd, 8260 Viby J, DK-Denmark Direct Phone / Mobile +45 25134336 E-mail: karen.nielsen@tieto.com ***************************************************************************= ************** www.tieto.com Please note: The information contained in this message may be legally privi= leged and confidential and protected from disclosure. If the reader of this= message is not the intended recipient, you are hereby notified that any un= authorised use, distribution or copying of this communication is strictly p= rohibited. If you have received this communication in error, please notify = us immediately by replying to the message and deleting it from your compute= r. Thank You. --_000_CF340E42AED0874C81947E18863DE77B2554B8D17BEXMB03eutieto_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

=

 

This comment is related= to draft-hurtig-tcpm-rtorestart-02.

=  

The work seems to assume that SCTP T3 ha= ndling is as in TCP, which it is not.

By p= rescription SCTP should already implement “almost” the mechanis= m described in the draft as indeed

it is = prescribed to:

 

Section 6.3.2:

<= o:p> 

=A0=A0 R3)=A0 Whenever a SACK is received th= at acknowledges the DATA chunk

=A0=A0=A0=A0=A0=A0= =A0 with the earliest outstanding TSN for that address, restart the<= o:p>

=A0=A0=A0=A0=A0=A0=A0 T3-rtx timer for that addres= s with its current RTO (if there is

=A0=A0=A0=A0= =A0=A0=A0 still outstanding data on that address).

 

=  

The difference in be= tween the Rtorestart draft and existing SCTP prescription then seems to be = that SCTP does it always not

= only under special circumstances - ?

 

The latter per= haps then should be questioned – in particular if STCP, as TCP, is to= start using larger initial CWNDs.

 

BR, Karen

 

&nb= sp;

PS: =A0I have not followed discussions on t= he work,

draft-hurtig-tcpm-rtorestart-02, = in the past, so my comment

may already hav= e been discussed. If so than I apologize in advance !

=

 

 

 

******************************= ***********************************************************

Karen Egede Nielsen

Software Archi= tect, Ph.D.

 

Tiet= o Denmark A/S

IP Solutions, R&D Service= s

=C5have Parkvej 27, 2nd, 8260 Viby J, DK-Denm= ark

Direct Phone / Mobile +45 25134336<= /o:p>

E-mail: karen.nielsen@tieto.com

****************************************************************= *************************

www.tieto.com=A0=

 

Please note: The i= nformation contained in this message may be legally privileged and confiden= tial and protected from disclosure. If the reader of this message is not th= e intended recipient, you are hereby notified that any unauthorised use, di= stribution or copying of this communication is strictly prohibited. If you = have received this communication in error, please notify us immediately by = replying to the message and deleting it from your computer. <= span lang=3DDA style=3D'font-size:7.5pt;font-family:"Arial","sans-serif"'>T= hank You.

 

 

= --_000_CF340E42AED0874C81947E18863DE77B2554B8D17BEXMB03eutieto_-- From Karen.Nielsen@tieto.com Tue Sep 25 08:55: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 CC6BB21F8809; Tue, 25 Sep 2012 08:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.372, 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 m9x23DeJjdnu; Tue, 25 Sep 2012 08:55:15 -0700 (PDT) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by ietfa.amsl.com (Postfix) with ESMTP id EB8EF21F879C; Tue, 25 Sep 2012 08:55:10 -0700 (PDT) X-AuditID: 83cfa824-b7f2c6d0000009fa-92-5061d3ddb671 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb05.tieto.com (SMTP Mailer) with SMTP id 1C.2E.02554.DD3D1605; Tue, 25 Sep 2012 18:55:09 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.121]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Tue, 25 Sep 2012 18:55:09 +0300 From: To: Date: Tue, 25 Sep 2012 18:55:04 +0300 Thread-Topic: rtorestart applicable for SCTP ? Thread-Index: Ac2a66T5VBzC+ClCTlufoA0AU1T12AASlqSw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF340E42AED0874C81947E18863DE77B2554B8D4B2EXMB03eutieto_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNKsWRmVeSWpSXmKPExsXSfL5DS/fu5cQAg7Z9qhafV15gtdh2cj6T xbE3d9kcmD2WLPnJ5PH3QitbAFMUl01Kak5mWWqRvl0CV8bNiX4FH0orTjSsYG1gPJ/VxcjJ ISFgInH/7x9mCFtM4sK99WwgtpDAKkaJO+eCuhi5gOwpjBKfpn0ES7AJyEvM3buKHcQWERCX WDv/IVCcg4NZQFVi/bNYkDALkLmp9wUjiC0soCtx49kcqHI9ics9C5ghbCOJKxNmMoHYvAI+ Em3/ulkg9vpIXFo4jwVkJKeAr8Tzn2BjGIFO+35qDVg5M9DWW0/mM0GcLCCxZM95qPNFJV4+ /scKUS8qcad9PSNEfb7E3I272CBWCUqcnPmEZQKj6Cwko2YhKZuFpAwiridxY+oUNghbW2LZ wtfMELauxIx/h1iQxRcwsq9i5E9NSjIw1SvJTC3J10vOz93ECI6zFSo7GM8+kDrEKMDBqMTD e6M1IUCINbGsuDL3EKMkB5OSKG/5kcQAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8sseAcrwp iZVVqUX5MClpDhYlcd5dU4EmCaQnlqRmp6YWpBbBZGU4OJQkeFddAmoULEpNT61Iy8wpQUgz cXCCDOcBGr4bpIa3uCAxtzgzHSJ/ilFRSpz3CEhCACSRUZoH1wtLg68YxYFeEeZdDlLFA0yh cN2vgAYzAQ3m3xMHMrgkESEl1cDI/EM4UXuayknju/1ZIZFZVuIOB7fL6Dkm8n/94ZraV8Es NTHTR2IBZ2eToVPZgtoogZwlP1la0ycK9e9n7bf/4J623r78yqP1N55s+80348xUBql7bvJr 7mS9z6mwf+2221ft6dI7RjtfBb23b1l/zneWqqpXf/HruodPeBpkJnjdfVBh+0yJpTgj0VCL uag4EQBn+RP1XgMAAA== Cc: tcpm@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] rtorestart applicable for SCTP ? 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, 25 Sep 2012 15:55:17 -0000 --_000_CF340E42AED0874C81947E18863DE77B2554B8D4B2EXMB03eutieto_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Please disregard the email below. TCP and SCTP indeed do share the issue. BR, Karen From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Kar= en.Nielsen@tieto.com Sent: 25. september 2012 09:02 To: per.hurtig@kau.se Cc: tcpm@ietf.org; tsvwg@ietf.org Subject: [tcpm] rtorestart applicable for SCTP ? Hi, This comment is related to draft-hurtig-tcpm-rtorestart-02. The work seems to assume that SCTP T3 handling is as in TCP, which it is no= t. By prescription SCTP should already implement "almost" the mechanism descri= bed in the draft as indeed it is prescribed to: Section 6.3.2: R3) Whenever a SACK is received that acknowledges the DATA chunk with the earliest outstanding TSN for that address, restart the T3-rtx timer for that address with its current RTO (if there is still outstanding data on that address). The difference in between the Rtorestart draft and existing SCTP prescripti= on then seems to be that SCTP does it always not only under special circumstances - ? The latter perhaps then should be questioned - in particular if STCP, as TC= P, is to start using larger initial CWNDs. BR, Karen PS: I have not followed discussions on the work, draft-hurtig-tcpm-rtorestart-02, in the past, so my comment may already have been discussed. If so than I apologize in advance ! ***************************************************************************= ************** Karen Egede Nielsen Software Architect, Ph.D. Tieto Denmark A/S IP Solutions, R&D Services =C5have Parkvej 27, 2nd, 8260 Viby J, DK-Denmark Direct Phone / Mobile +45 25134336 E-mail: karen.nielsen@tieto.com ***************************************************************************= ************** www.tieto.com Please note: The information contained in this message may be legally privi= leged and confidential and protected from disclosure. If the reader of this= message is not the intended recipient, you are hereby notified that any un= authorised use, distribution or copying of this communication is strictly p= rohibited. If you have received this communication in error, please notify = us immediately by replying to the message and deleting it from your compute= r. Thank You. --_000_CF340E42AED0874C81947E18863DE77B2554B8D4B2EXMB03eutieto_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

Please disregard the email below.

<= p class=3DMsoNormal>TCP and SCTP indeed do share the issue.=

 

BR, Karen

=  

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> tcpm-bou= nces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Karen.Niel= sen@tieto.com
Sent: 25. september 2012 09:02
To: per.hu= rtig@kau.se
Cc: tcpm@ietf.org; tsvwg@ietf.org
Subject: = [tcpm] rtorestart applicable for SCTP ?

 

Hi,

 

This comment is rela= ted to draft-hurtig-tcpm-rtorestart-02.

 

The work seems to assume that SCTP T3= handling is as in TCP, which it is not.

B= y prescription SCTP should already implement “almost” the mecha= nism described in the draft as indeed

it = is prescribed to:

 =

Section 6.3.2:

   R3)  Whenever a SACK is= received that acknowledges the DATA chunk

 &= nbsp;      with the earliest outstanding TS= N for that address, restart the

   =      T3-rtx timer for that address with its current RTO= (if there is

      =   still outstanding data on that address).

 

 

The difference in between= the Rtorestart draft and existing SCTP prescription then seems to be that = SCTP does it always not

only = under special circumstances - ?

<= span lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Arial","sans-serif= "'> 

The latter perhaps = then should be questioned – in particular if STCP, as TCP, is to star= t using larger initial CWNDs.

 

BR, Karen=

 

 <= /o:p>

PS:  I have not followed discussions on th= e work,

draft-hurtig-tcpm-rtorestart-02, i= n the past, so my comment

may already have= been discussed. If so than I apologize in advance !

<= p class=3DMsoNormal> 

 =

 

*******************************= **********************************************************

Karen Egede Nielsen

Software Archit= ect, Ph.D.

 

Tieto= Denmark A/S

IP Solutions, R&D Services=

=C5have Parkvej 27, 2nd, 8260 Viby J, DK-Denma= rk

Direct Phone / Mobile +45 25134336

E-mail: karen.nielsen@tieto.com

=

*****************************************************************= ************************

www.tieto.com =

 

Please note: The i= nformation contained in this message may be legally privileged and confiden= tial and protected from disclosure. If the reader of this message is not th= e intended recipient, you are hereby notified that any unauthorised use, di= stribution or copying of this communication is strictly prohibited. If you = have received this communication in error, please notify us immediately by = replying to the message and deleting it from your computer. <= span lang=3DDA style=3D'font-size:7.5pt;font-family:"Arial","sans-serif"'>T= hank You.

 

 

= --_000_CF340E42AED0874C81947E18863DE77B2554B8D4B2EXMB03eutieto_--