From gorry@erg.abdn.ac.uk Fri Jul 1 00:52:32 2011 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 C677721F8851 for ; Fri, 1 Jul 2011 00:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 JlFf-9wrKnU3 for ; Fri, 1 Jul 2011 00:52:32 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 062B421F884F for ; Fri, 1 Jul 2011 00:52:30 -0700 (PDT) Received: from don.erg.abdn.ac.uk (don.erg.abdn.ac.uk [139.133.204.83]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p617qQwe028430 for ; Fri, 1 Jul 2011 08:52:26 +0100 (BST) Date: Fri, 1 Jul 2011 08:52:26 +0100 (BST) From: Gorry Fairhurst To: tsvwg@ietf.org Subject: TSVWG Adoption of draft-polk-tsvwg-intserv-multiple-tspec Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk 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, 01 Jul 2011 07:52:32 -0000 This email confirms the adoption of the above draft by TSVWG as a work item. Authors please prepare a draft -00 working group ID including the comments received during the WG adoption call. New name: draft-ietf-tsvwg-intserv-multiple-tspec This document received postive support by the WG, and noissues were noted about its suitability for adoption. A set of reviewers have been be identified who will provide feedback duing the WG/IETF process. Best wishes, Gorry Fairhurst (tsvwg Chair) From jmpolk@cisco.com Fri Jul 1 12:50:23 2011 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 E136C9E8046 for ; Fri, 1 Jul 2011 12:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Hxadwrob1OvG for ; Fri, 1 Jul 2011 12:50:23 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 66CD79E8042 for ; Fri, 1 Jul 2011 12:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2565; q=dns/txt; s=iport; t=1309549823; x=1310759423; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=Q8xRf4fc7hvt1tgvfXwvy5TS6Del5bNi9aDMfLr3NL8=; b=O7AjMVFU5nQCNCun1dq5C5rDsqWtZFuHIigL32srK6+PxXWkRxMRQDWg PgoBiAdQTW3+BpedvO5i8rhfpg9tWy8HGyJ8eVq1uDAlZCXdgQL7d+29I npn9Z5btDhvhtBQa0mIvamcOBYsdgIPqsMucVk/O9UCKs697t8tjeqtBU E=; X-IronPort-AV: E=Sophos;i="4.65,460,1304294400"; d="scan'208";a="390257963" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 01 Jul 2011 19:50:23 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p61JoMn3031990; Fri, 1 Jul 2011 19:50:22 GMT Message-Id: <201107011950.p61JoMn3031990@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 Jul 2011 14:50:21 -0500 To: tsvwg From: "James M. Polk" Subject: Re: New 48 hour LC on draft-ietf-tsvwg-sctpsocket In-Reply-To: <7.1.0.9.2.20110628221739.05d46a10@cisco.com> References: <7.1.0.9.2.20110628221739.05d46a10@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: gorry@erg.abdn.ac.uk, "James M. Polk" 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, 01 Jul 2011 19:50:24 -0000 TSVWG Having received no comments one way or the other,=20 the chairs call (that silence as) WG acceptance=20 of the changes, therefore this mini-LC is=20 concluded and the draft will progress towards the IESG as its next step. James & Gorry TSVWG Chairs At 10:30 PM 6/28/2011, James M. Polk wrote: >TSVWG > >Michael T=FCxen discovered a few bugs when=20 >implementing this SCTP Socket API against -29 of=20 >this draft. The chairs are issuing a VERY SHORT 48 hour WGLC (details= below). > >Here is the complete list (including the issues earlier reported): > >(NOTE: the "I" below is from Michael) > >(1) The list in section 8 for the socket options supported by= sctp_opt_info() > is outdated. It should be updated to be consistent with the current= doc. > I consider this purely editorial. >(2) The description of SCTP_LOCAL_AUTH_CHUNKS is missing a statement= regarding > the special assoc ids. It should be added. > I consider this purely editorial. >(3) It should be made clear in section 8.1.20 that the sctp_data_io_event > is deprecated. > I consider this purely editorial. >(4) For all socket options supporting an=20 >association ID, only the special value > of SCTP_FUTURE_ASSOC might make sense with=20 > getsockopt(). SCTP_ALL_ASSOC and > SCTP_CURRENT_ASSOC do not make sense. This should be stated= explicitly. > I consider this purely editorial. >(5) Change > struct sctp_authinfo { > uint16_t auth_keyid; > } > to > struct sctp_authinfo { > uint16_t auth_keynumber; > } > to make naming consistent in the document. > I consider this purely editorial. >(6) The SCTP_PEER_ADDR_PARAMS socket option supports SCTP_FUTURE_ASSOCS. > This is not stated correctly in the ID. > I consider this purely editorial. >(7) The description of sctp_sendv() is missing the constant= SCTP_SENDV_NOINFO. > This is an omission and should be added. > I don't consider this to be a technically change. >(8) A socket option for setting/getting the default SCTP_PRINFO. This was > forgotten. > I don't consider this to be a technically change. > >TSVWG now has 48 hours to let the chairs know if=20 >they see any problems with the proposed status=20 >or fixes stated to any open issue listed above.=20 >This is a VERY short LC, ending Thursday at 11pm EDT (2300 East Coast US= Time). > >If you have issues, make sure the chairs hear you in the next 48 hours. > >James & Gorry >TSVWG chairs From dreibh@iem.uni-due.de Sat Jul 2 12:31:05 2011 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 34D33228014 for ; Sat, 2 Jul 2011 12:31:05 -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 xq8t1rNVko2e for ; Sat, 2 Jul 2011 12:31:04 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id 04748228011 for ; Sat, 2 Jul 2011 12:31:03 -0700 (PDT) Received: from lupo.localnet (p5086D166.dip.t-dialin.net [80.134.209.102]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id p62JUx1D016371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 2 Jul 2011 21:31:01 +0200 From: Thomas Dreibholz Organization: University of Duisburg-Essen, Institute for Experimental Mathematics To: tsvwg@ietf.org Subject: Call for Papers: PAMS 2012 -- 2nd International Workshop on Protocols and Applications with Multi-Homing Support Date: Sun, 3 Jul 2011 07:30:56 +1200 User-Agent: KMail/1.13.6 (Linux/3.0.0-rc5dreibholz; KDE/4.6.4; x86_64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201107030730.58872.dreibh@iem.uni-due.de> 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 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, 02 Jul 2011 19:31:05 -0000 CALL FOR PAPERS 2nd International Workshop on Protocols and Applications with Multi-Homing= =20 Support (PAMS 2012) In conjunction with the 26th IEEE International Conference on Advanced=20 Information Networkingand Applications (AINA 2012) =46ukuoka, Japan, March 26-29, 2012 http://tdrwww.iem.uni-due.de/pams2012.html The intent of our workshop is to bring together people from research and industry, in order to provide a discussion forum for state-of-the-art topics related to multi-homing on Network, Transport, Session and Application Laye= rs. The PAMS workshop will include full-paper sessions as well as a poster sess= ion (with short presentations) to introduce preliminary ideas as well as work in progress. Workshops proceedings will be published by the IEEE CS Conference Publishing 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 * 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 * Security of Multi-Homed Systems * Application Deployment and Support for Legacy Applications * Cross-Layer Optimization for Multi-Homed Systems * Multi-Homing in the Context of Future Internet GENERAL CHAIRS: * Thomas Dreibholz, University of Duisburg-Essen, Germany * Martin Becke, University of Duisburg-Essen, Germany PROGRAM CHAIRS: * Michael T=FCxen, M=FCnster University of Applied Sciences, Germany * Erwin P. Rathgeb, University of Duisburg-Essen, Germany PROGRAM COMMITTEE * Hakim Adhari, University of Duisburg-Essen, Germany * Nicola Altan, Cetekom, Germany * Paul Amer, University of Delaware, U.S.A. * Anna Brunstr=F6m, Karlstad University, Sweden * Glenford Mapp, Middlesex University, United Kingdom * Michio Honda, Keio University, Japan * Seok J. Koh, Kyungpook National University, Korea * Preethi Natarajan, Cisco, U.S.A. * Brad Penoff, University of British Columbia, Canada * Irene R=FCngeler, M=FCnster University of Applied Sciences, Germany * Robin Seggelmann, M=FCnster University of Applied Sciences, Germany * Esbold Unurkhaan, Mongolian University of Science and Technology,=20 Mongolia * Alan Wagner, University of British Columbia, Canada * Michael Welzl, University of Oslo, Norway IMPORTANT DATES * Paper Submission Deadline: October 01, 2011 * Author Notification: December 01, 2011 * Camera-Ready Paper Submission: January 06, 2012 CONTACT =46or further information, please contact: * Thomas Dreibholz (dreibh AT iem.uni-due.de) * Martin Becke (martin.becke AT uni-due.de) WEBSITE http://tdrwww.iem.uni-due.de/pams2012.html From karagian@cs.utwente.nl Sun Jul 3 00:40:59 2011 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 EE46221F8763; Sun, 3 Jul 2011 00:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.085 X-Spam-Level: X-Spam-Status: No, score=-0.085 tagged_above=-999 required=5 tests=[AWL=0.419, 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 pMn0FOb4NHJb; Sun, 3 Jul 2011 00:40:59 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4B55721F874C; Sun, 3 Jul 2011 00:40:59 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p637dLnh021160; Sun, 3 Jul 2011 09:39:21 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sun, 03 Jul 2011 07:40:57 +0000 To: "Steven Blake" , jmpolk@cisco.com, gorry@erg.abdn.ac.uk Subject: agenda slot for Aggregated RSVP over PCN Date: Sun, 03 Jul 2011 07:40:57 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Sun, 03 Jul 2011 09:39:32 +0200 (MEST) Cc: "pcn@ietf.org" , tsvwg@ietf.org 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, 03 Jul 2011 07:41:00 -0000 Hi Steve, Hi Gorry, Hi James Please note that before tomorrow's deadline, I will submit the following draft, which I would also like to present during the pcn and tsvwg meetings. Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 and IPv6 Reservations over PCN domains draft-karagiannis-pcn-tsvwg-RSVP-PCN-00 It will be great if I could get for each of the meetings (PCN and tsvwg) a 20 minutes agenda slot. Best regards, Georgios From karagian@cs.utwente.nl Sun Jul 3 10:25:01 2011 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 BA1F321F86BC; Sun, 3 Jul 2011 10:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.155 X-Spam-Level: X-Spam-Status: No, score=-0.155 tagged_above=-999 required=5 tests=[AWL=0.349, 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 kj0cu6wekc2H; Sun, 3 Jul 2011 10:25:01 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0013121F86BA; Sun, 3 Jul 2011 10:25:00 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p63HNQ7j021355; Sun, 3 Jul 2011 19:23:26 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sun, 03 Jul 2011 17:25:02 +0000 To: "pcn@ietf.org" , "tsvwg@ietf.org" Subject: uploaded draft-karagiannis-pcn-tsvwg-rsvp-pcn-00 Date: Sun, 03 Jul 2011 17:25:02 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Sun, 03 Jul 2011 19:23:37 +0200 (MEST) 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, 03 Jul 2011 17:25:01 -0000 Hi all, I have just uploaded draft-karagiannis-pcn-tsvwg-rsvp-pcn-00, see: http://www.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-00.txt Filename: draft-karagiannis-pcn-tsvwg-rsvp-pcn Revision: 00 Title: Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains Creation date: 2011-07-04 WG ID: Individual Submission Number of pages: 19 Abstract: This document specifies the extensions to the Aggregated RSVP [RFC3175] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. Comments are welcome! It will be great if I could get for each of the meetings (pcn and tsvwg) a 20 minutes agenda slot to present this draft! Best regards, Georgios On 7/3/2011, "Georgios Karagiannis" wrote: >Hi Steve, Hi Gorry, Hi James > >Please note that before tomorrow's deadline, I will submit the following >draft, which I would also like to present during the pcn and tsvwg >meetings. > >Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 and > IPv6 Reservations over PCN domains > draft-karagiannis-pcn-tsvwg-RSVP-PCN-00 > >It will be great if I could get for each of the meetings (PCN and tsvwg) >a 20 minutes agenda slot. > >Best regards, >Georgios From internet-drafts@ietf.org Sun Jul 3 14:54:20 2011 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 EB65811E80CA; Sun, 3 Jul 2011 14:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 j4Zvw3qNk3rB; Sun, 3 Jul 2011 14:54:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464C611E80AE; Sun, 3 Jul 2011 14:54:20 -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 Subject: I-D Action: draft-ietf-tsvwg-intserv-multiple-tspec-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110703215420.16174.78701.idtracker@ietfa.amsl.com> Date: Sun, 03 Jul 2011 14:54:20 -0700 Cc: tsvwg@ietf.org 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, 03 Jul 2011 21:54:21 -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 = Group of the IETF. Title : Integrated Services (IntServ) Extension to Allow Signali= ng of Multiple Traffic Specifications and Multiple Flow Specifications in R= SVPv1 Author(s) : James Polk Subha Dhesikan Filename : draft-ietf-tsvwg-intserv-multiple-tspec-00.txt Pages : 26 Date : 2011-07-03 This document defines extensions to Integrated Services (IntServ) allowing multiple traffic specifications and multiple flow specifications to be conveyed in the same Resource Reservation Protocol (RSVPv1) reservation message exchange. This ability helps optimize an agreeable bandwidth through a network between endpoints in a single round trip. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-intserv-multiple-tspec= -00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-intserv-multiple-tspec-= 00.txt From jmpolk@cisco.com Sun Jul 3 17:17:23 2011 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 22D981F0C6F for ; Sun, 3 Jul 2011 17:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.47 X-Spam-Level: X-Spam-Status: No, score=-110.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 IHiLv+stJHDC for ; Sun, 3 Jul 2011 17:17:22 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACBB1F0C6E for ; Sun, 3 Jul 2011 17:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2413; q=dns/txt; s=iport; t=1309738642; x=1310948242; h=message-id:date:to:from:subject:cc:mime-version; bh=1UjIdFpsL1dyE8dk1gV4dwMamjOeuq93lLU6nwf/sWs=; b=dSsG8KGlOCawQFi3l61t5aIRiYLglbtxG9qEdjLTGKbc0i5HLetwJ9f4 ZoEq7mO29cTtW7vWcjjRmjgP6BYUtgDn/+nOd9e7Hp51EPKptt9pYQeaW 5trIW/mYLI9HP6Bf6pKMgloUTpPQn9I4159L/JW1r42n5sq9vm2xD81Gm o=; X-IronPort-AV: E=Sophos;i="4.65,469,1304294400"; d="scan'208";a="360233271" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-5.cisco.com with ESMTP; 04 Jul 2011 00:17:22 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p640HLc0031104; Mon, 4 Jul 2011 00:17:21 GMT Message-Id: <201107040017.p640HLc0031104@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 03 Jul 2011 19:17:20 -0500 To: tsvwg From: "James M. Polk" Subject: draft-ietf-tsvwg-intserv-multiple-tspec-00 submitted Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 04 Jul 2011 00:17:23 -0000 TSVWG (with my individual hat on) We'd like to draw your attention to the newest WG item within TSVWG. The authors made only a couple of individual modifications from the individual version that was approved as a WG item: - clarified how this extension also extends RFC 4495 (RSVP Bandwidth Reduction), and - added some text to the security considerations section The top item has to do with good network hygiene - correcting as soon as possible when too much BW was reserved (that is no longer needed) within part of a reservation setup. The latter item was directly from a review comment. Both of these we thought we low hanging fruit, so we put them in this version. Any further changes needs WG approval in our opinion. Comments are encouraged and/or requested. James & Subha >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the Transport Area Working >Group Working Group of the IETF. > > Title : Integrated Services (IntServ) Extension > to Allow Signaling of Multiple Traffic Specifications and Multiple > Flow Specifications in RSVPv1 > Author(s) : James Polk > Subha Dhesikan > Filename : draft-ietf-tsvwg-intserv-multiple-tspec-00.txt > Pages : 26 > Date : 2011-07-03 > > This document defines extensions to Integrated Services (IntServ) > allowing multiple traffic specifications and multiple flow > specifications to be conveyed in the same Resource Reservation > Protocol (RSVPv1) reservation message exchange. This ability helps > optimize an agreeable bandwidth through a network between endpoints > in a single round trip. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-intserv-multiple-tspec-00.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-intserv-multiple-tspec-00.txt >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From lberger@labn.net Wed Jul 6 11:27:21 2011 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 AB18921F896E for ; Wed, 6 Jul 2011 11:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.113 X-Spam-Level: X-Spam-Status: No, score=-102.113 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 yprb0PW8xZLd for ; Wed, 6 Jul 2011 11:27:20 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 9071121F87AF for ; Wed, 6 Jul 2011 11:27:20 -0700 (PDT) Received: (qmail 32248 invoked by uid 0); 6 Jul 2011 18:27:19 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 6 Jul 2011 18:27:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=uOL4XxjDoj5tZDWexYkhvMEQgy3H8wxw8M+lBbxEX7MQ0VkGXVtqpAOEiZccqmf+pUudrr4TLBvxhY7wO59DWcF5q6gcNKi5hHj7MZv3H28mnQv3+Ccavpu/WKIq//w2; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1QeWoh-0003i9-IP; Wed, 06 Jul 2011 12:27:19 -0600 Message-ID: <4E14A909.4090900@labn.net> Date: Wed, 06 Jul 2011 14:27:21 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "James M. Polk" Subject: Re: draft-ietf-tsvwg-intserv-multiple-tspec-00 submitted References: <201107040017.p640HLc0031104@mtv-core-1.cisco.com> In-Reply-To: <201107040017.p640HLc0031104@mtv-core-1.cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: tsvwg 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, 06 Jul 2011 18:27:21 -0000 James, Since you ask... I thought this would be a good time to revive our discussion from March. As a reminder, here is the salient part of the discussion: On 3/18/2011 5:04 PM, James M. Polk wrote: >> > At 05:46 PM 3/17/2011, Lou Berger wrote: ... >> >1) a real nit: >> >I suspect that the RBNF is broken, and >> >[MULTI_FLOWSPEC] should be [ ] . > yep, sorry - this is obvious > >> > (You might want to add a reference to 5511 too.) > probably > > >> >2) I could see this as a more generally applicable problem, in >> >particular it could apply to the non-IntServ class types supported by >> >RSVP (TSPEC/FLOWSPEC). What do you think about having the MULT_xxSPEC >> >objects being defined solely on the RSVP level (perhaps using >> >subobjects) rather than as defined now which is a change to RSVP and >> >IntServ? > Hadn't thought about this before. We'll think about how this would > work and if there are any gotchas. Have you had any further thoughts? I think this would have the real benefit that it can apply to all flowspec types. Lou On 7/3/2011 8:17 PM, James M. Polk wrote: > TSVWG > > (with my individual hat on) > > We'd like to draw your attention to the newest WG item within TSVWG. > > The authors made only a couple of individual modifications from the > individual version that was approved as a WG item: > > - clarified how this extension also extends RFC 4495 (RSVP Bandwidth > Reduction), and > - added some text to the security considerations section > > The top item has to do with good network hygiene - correcting as soon > as possible when too much BW was reserved (that is no longer needed) > within part of a reservation setup. The latter item was directly from > a review comment. > > Both of these we thought we low hanging fruit, so we put them in this > version. Any further changes needs WG approval in our opinion. > > Comments are encouraged and/or requested. > > James & Subha > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Transport Area Working >> Group Working Group of the IETF. >> >> Title : Integrated Services (IntServ) Extension >> to Allow Signaling of Multiple Traffic Specifications and Multiple >> Flow Specifications in RSVPv1 >> Author(s) : James Polk >> Subha Dhesikan >> Filename : draft-ietf-tsvwg-intserv-multiple-tspec-00.txt >> Pages : 26 >> Date : 2011-07-03 >> >> This document defines extensions to Integrated Services (IntServ) >> allowing multiple traffic specifications and multiple flow >> specifications to be conveyed in the same Resource Reservation >> Protocol (RSVPv1) reservation message exchange. This ability helps >> optimize an agreeable bandwidth through a network between endpoints >> in a single round trip. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-intserv-multiple-tspec-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-intserv-multiple-tspec-00.txt >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > From yoshifumi.nishida@gmail.com Thu Jul 7 01:05:47 2011 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 CC12921F8872 for ; Thu, 7 Jul 2011 01:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 JeHRES3dlam2 for ; Thu, 7 Jul 2011 01:05:47 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4021621F8792 for ; Thu, 7 Jul 2011 01:05:47 -0700 (PDT) Received: by iwn39 with SMTP id 39so747873iwn.31 for ; Thu, 07 Jul 2011 01:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lWoz3WEhHIP7zd4Rx0JFX4m8WlB+7ufrzqHEzLvgQAQ=; b=EUkxlAC/20Jy+lUUpcETbNFuxb+yeLn5q5gJ0QbRWYqjkxOkzsqZp1vkVvR2nXqNYW 6+ttegsz2QG4Qi0w5wkHhAh4bptrpuxaZ1o3/IMJdJi8kw7C/x9GU/NrsyCsFBh9pFuA EW9JLOS85Vk0ZUnaJkalz6FiYj65ZDHAGtGps= MIME-Version: 1.0 Received: by 10.231.60.73 with SMTP id o9mr504056ibh.33.1310025946699; Thu, 07 Jul 2011 01:05:46 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.199.12 with HTTP; Thu, 7 Jul 2011 01:05:46 -0700 (PDT) In-Reply-To: <20110706215123.5292.76380.idtracker@ietfa.amsl.com> References: <20110706215123.5292.76380.idtracker@ietfa.amsl.com> Date: Thu, 7 Jul 2011 01:05:46 -0700 X-Google-Sender-Auth: y8aNk9J2YS1Ujxnv4kw3Z8DS56o Message-ID: Subject: Re: I-D Action: draft-nishida-tsvwg-sctp-failover-03.txt From: Yoshifumi Nishida To: tsvwg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Preethi Natarajan 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, 07 Jul 2011 08:05:47 -0000 Hello folks, We've just submitted the new version of sctp failover draft in order to keep the doc alive. Please give us feedbacks to proceed. We'll really appreciate your comments. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/7/6 : > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Quick Failover Algorithm in SC= TP > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Yoshifumi Nishida > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Preethi Natarajan > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-nishida-tsvwg-sctp-failove= r-03.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 15 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-07-06 > > =A0 One of the major advantages in SCTP is supporting multi-homing > =A0 communication. =A0If a multi-homed end-point has redundant network > =A0 connections, SCTP sessions can have a good chance to survive from > =A0 network failures by migrating inactive network to active one. > =A0 However, if we follow the SCTP standard, there can be significant > =A0 delay for the network migration. =A0During this migration period, SCT= P > =A0 cannot transmit much data to the destination. =A0This issue drastical= ly > =A0 impairs the usability of SCTP in some situations. =A0This memo > =A0 describes the issue of SCTP failover mechanism and discuss its > =A0 solutions which require minimal modification to the current standard. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nishida-tsvwg-sctp-failover-03.= txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-nishida-tsvwg-sctp-failover-03.t= xt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From touch@isi.edu Thu Jul 7 10:29:23 2011 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 4650E21F87F8 for ; Thu, 7 Jul 2011 10:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.774 X-Spam-Level: X-Spam-Status: No, score=-105.774 tagged_above=-999 required=5 tests=[AWL=0.825, BAYES_00=-2.599, 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 76s2GRsgOS2D for ; Thu, 7 Jul 2011 10:29:22 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id CFC6E21F8811 for ; Thu, 7 Jul 2011 10:29:22 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p67HSmZm013769 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 7 Jul 2011 10:28:48 -0700 (PDT) Message-ID: <4E15ECD0.1020602@isi.edu> Date: Thu, 07 Jul 2011 10:28:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Scott O. Bradner" Subject: Re: draft-ietf-tsvwg-source-quench: SHOULD NOT vs. MUST NOT References: <4E0168C8.6020709@gont.com.ar> <6E42136B-111D-45BA-BD01-3B2E7FE6CC77@harvard.edu> <50A7BE87-94A5-4165-B00E-E7E59C02DCC0@harvard.edu> In-Reply-To: <50A7BE87-94A5-4165-B00E-E7E59C02DCC0@harvard.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Fernando Gont , tsvwg 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, 07 Jul 2011 17:29:23 -0000 Why isn't it: SHOULD NOT send MUST be ignored on receipt The latter is much more important, isn't it? Joe On 6/22/2011 6:20 AM, Scott O. Bradner wrote: > if one wanted to be anal one could say that "new implementations MUST NOT...." but > I expect just saying MUST NOT wold be understood to apply to software created after > the RFC was published > > Scott > > On Jun 22, 2011, at 8:54 AM, Scott Brim wrote: > >> For example, if you're allowing for existing implementations. > From william.d.ivancic@nasa.gov Thu Jul 7 10:30:44 2011 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 5C0DE21F8802 for ; Thu, 7 Jul 2011 10:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.714 X-Spam-Level: X-Spam-Status: No, score=-5.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 Lbs2I-LxltBY for ; Thu, 7 Jul 2011 10:30:43 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by ietfa.amsl.com (Postfix) with ESMTP id 9719721F87D9 for ; Thu, 7 Jul 2011 10:30:38 -0700 (PDT) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 2224D2607C5; Thu, 7 Jul 2011 12:30:38 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt04.ndc.nasa.gov (8.14.4/8.14.4) with ESMTP id p67HUbO7018043; Thu, 7 Jul 2011 12:30:37 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Thu, 7 Jul 2011 12:30:37 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "tsvwg@ietf.org" Date: Thu, 7 Jul 2011 12:30:36 -0500 Subject: Saratoga reliable transport protocol Thread-Topic: Saratoga reliable transport protocol Thread-Index: Acw8y5WK4od8fxHoQMmSfTYpsYyBLQ== Message-ID: <772E9AAA-532C-422D-B693-5CE7137B5ED0@nasa.gov> 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_772E9AAA532C422DB6935CE7137B5ED0nasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-07_07:2011-07-07, 2011-07-07, 1970-01-01 signatures=0 Cc: Lloyd Wood 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, 07 Jul 2011 17:30:44 -0000 --_000_772E9AAA532C422DB6935CE7137B5ED0nasagov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A small group has been working on implementing version 1 of the Saratoga tr= ansport protocol. I will be giving a 10 minute synopsis at the 81 IETF (cu= rrently it looks like that will be Friday morning.) Saratoga was originally developed to transfer remote-sensing imagery effici= ently from a low-Earth-orbiting satellite constellation, but is useful for = many other scenarios, including ad-hoc peer-to-peer communications, delay-t= olerant networking, and grid computing. Saratoga Version 1 has hooks in pla= ce to accommodate file transfer, streaming, and bundling. http://tools.ietf.org/html/draft-wood-tsvwg-saratoga-09 We currently are working implementations in PERL, C and C++. Charles Smith= (Commonwealth Scientific and Industrial Research Organization) has also be= en working on a wireshark plugin. One interesting area that is being consider for deployment of Saratoga is = for ground-based space sensors that need to move hugh data sets fast. Implementations will likely be in FPGAs. See: PAPER Lloyd Wood, Charles Smith, Wesley Eddy, William D. Ivancic, Chris Jackson: = "Taking Saratoga from Space-Based Ground Sensors to Ground-Based Space Sens= ors," 2011 IEEE Aerospace Conference, Big Sky Montana, March 5 - 12, 2011 = file size 374 Kbyte http://roland.grc.nasa.gov/~ivancic/papers_presentations/2011/z04_0201.pdf PRESENTATION (PDF) file size 2.3 Mbyt= e http://roland.grc.nasa.gov/~ivancic/papers_presentations/2011/IEEE%20Aeros= pace%202011%20Saratoga%20Space%20to%20Ground.pdf --_000_772E9AAA532C422DB6935CE7137B5ED0nasagov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A small group has been working on implementin= g version 1 of the Saratoga transport protocol.  I will be giving a 10= minute synopsis at the 81 IETF (currently it looks like that will be Frida= y morning.)

Saratoga was originally d= eveloped to transfer remote-sensing imagery efficiently from a low-Earth-or= biting satellite constellation, but is useful for many other scenarios, in= cluding ad-hoc peer-to-peer communications, delay-tolerant networking, and= grid computing. Saratoga Version 1 has hooks in place to accommodate file= transfer, streaming, and bundling.


We currently are wor= king implementations in PERL, C and C++.  Charles Smith (Commonwealth Scientific a= nd Industrial Research Organization) has
One interesting area that is being consider for deployment of=  Saratoga is for ground-based space sensors that need to move hugh da= ta sets fast. 
 Implementations will likely be in FPGAs. &nb= sp;See:
PAPER
Lloyd Wood, Charles Smith, Wesley Eddy, William D. = Ivancic, Chris Jackson: "Taking Saratoga from Space-Based Ground Sensors to Ground-Based Space Sens= ors," 2011 IEEE Aerospace Conference, Big Sky Montana, March 5 - 12, 2011  f= ile size 374 Kbyte


= --_000_772E9AAA532C422DB6935CE7137B5ED0nasagov_-- From L.Wood@surrey.ac.uk Thu Jul 7 10:55:49 2011 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 AEFE81F0C70 for ; Thu, 7 Jul 2011 10:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 vEo+xUEONRVY for ; Thu, 7 Jul 2011 10:55:48 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id D41FC1F0C6E for ; Thu, 7 Jul 2011 10:55:47 -0700 (PDT) Received: from [195.245.230.131:46910] by server-3.bemta-3.messagelabs.com id 34/BB-27875-223F51E4; Thu, 07 Jul 2011 17:55:46 +0000 X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-2.tower-78.messagelabs.com!1310061345!73647593!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [131.227.200.43] Received: (qmail 13950 invoked from network); 7 Jul 2011 17:55:46 -0000 Received: from unknown (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-2.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 7 Jul 2011 17:55:46 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.151]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Thu, 7 Jul 2011 18:55:45 +0100 From: To: Date: Thu, 7 Jul 2011 18:55:45 +0100 Subject: Re: Saratoga reliable transport protocol Thread-Topic: Saratoga reliable transport protocol Thread-Index: Acw8zxiH80s74CjETkOgVyGMgkz7Yg== Message-ID: <2AE17516-E958-4F79-966B-F9FB1BB24A78@surrey.ac.uk> References: <772E9AAA-532C-422D-B693-5CE7137B5ED0@nasa.gov> In-Reply-To: <772E9AAA-532C-422D-B693-5CE7137B5ED0@nasa.gov> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org, L.Wood@surrey.ac.uk 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, 07 Jul 2011 17:55:49 -0000 As Will mentions, we have multiple separate implementations of this Saratog= a protocol specified in this draft, and we've tested for interoperability. We'd like to take this draft forward to experimental status, and believe th= at tsvwg is the best place to do that. Further information on Saratoga (draft, papers, presentations, etc.) is ava= ilable at: http://personal.ee.surrey.ac.uk/Personal/L.Wood/dtn/saratoga thanks, Lloyd Wood http://sat-net.com/L.Wood/CCSR On 7 Jul 2011, at 18:30, Ivancic, William D. (GRC-RHN0) wrote: > A small group has been working on implementing version 1 of the Saratoga = transport protocol. I will be giving a 10 minute synopsis at the 81 IETF (= currently it looks like that will be Friday morning.) >=20 > Saratoga was originally developed to transfer remote-sensing imagery eff= iciently from a low-Earth-orbiting satellite constellation, but is useful f= or many other scenarios, including ad-hoc peer-to-peer communications, de= lay-tolerant networking, and grid computing. Saratoga Version 1 has hooks = in place to accommodate file transfer, streaming, and bundling. >=20 > http://tools.ietf.org/html/draft-wood-tsvwg-saratoga-09 >=20 > We currently are working implementations in PERL, C and C++. Charles Smi= th (Commonwealth Scientific and Industrial Research Organization) has also = been working on a wireshark plugin. =20 >=20 > One interesting area that is being consider for deployment of Saratoga i= s for ground-based space sensors that need to move hugh data sets fast.=20 > Implementations will likely be in FPGAs. See: > PAPER > Lloyd Wood, Charles Smith, Wesley Eddy, William D. Ivancic, Chris Jackson= : "Taking Saratoga from Space-Based Ground Sensors to Ground-Based Space Se= nsors," 2011 IEEE Aerospace Conference, Big Sky Montana, March 5 - 12, 2011= file size 374 Kbyte > http://roland.grc.nasa.gov/~ivancic/papers_presentations/2011/z04_0201.pd= f > PRESENTATION > (PDF) file size 2.3 Mbyte > http://roland.grc.nasa.gov/~ivancic/papers_presentations/2011/IEEE%20Aer= ospace%202011%20Saratoga%20Space%20to%20Ground.pdf >=20 From jmpolk@cisco.com Fri Jul 8 14:15:16 2011 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 8FFCB21F8CA2 for ; Fri, 8 Jul 2011 14:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.276 X-Spam-Level: X-Spam-Status: No, score=-105.276 tagged_above=-999 required=5 tests=[AWL=-2.677, 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 amPNdx+XtSKF for ; Fri, 8 Jul 2011 14:15:15 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A80C821F8C99 for ; Fri, 8 Jul 2011 14:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=768; q=dns/txt; s=iport; t=1310159715; x=1311369315; h=message-id:date:to:from:subject:mime-version; bh=72O9s+RFaAzMPC97VWsccVsojnsTazNWaHUQeDdRc3c=; b=WTc8CRS6eBN+EAGcnD55B4bQeHto3d+thq2NuKXDNuJoTyLB9bPRb1bG 14JbzDmGWmjoc/090lZnL7/5nt5gwSHDcjg32EocS4cP07eOveY4JBQhd Yjd91j/l1Cu/TFfQ/A9ULQxfXp6VfbKMT4o8P/79E7VIXFG99GsbJf7RC g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAIdyF06rRDoH/2dsb2JhbABUmBqPNHeqV4EinV6GOASHS5ti X-IronPort-AV: E=Sophos;i="4.65,500,1304294400"; d="scan'208";a="1190004" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-7.cisco.com with ESMTP; 08 Jul 2011 21:15:15 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p68LFEQc004904 for ; Fri, 8 Jul 2011 21:15:14 GMT Message-Id: <201107082115.p68LFEQc004904@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 08 Jul 2011 16:15:13 -0500 To: tsvwg From: "James M. Polk" Subject: TSVWG Session in Quebec is on Friday morning Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 08 Jul 2011 21:15:16 -0000 TSVWG Here's the schedule we've been given for IETF81 FRIDAY, July 29, 2011 0800-1100 IETF Registration - 2000 A 0800-0900 Continental Breakfast - 2000 BC 0900-1130 Morning Session I 2103 INT ancp Access Node Control Protocol WG 208 AB INT lwig Light-Weight Implementation Guidance WG 2101 IRTF VNRG Virtual Networks Research Group 205 ABC OPS armd Address Resolution for Massive numbers of hosts in the Data center WG 206 A RAI mmusic Multiparty Multimedia Session Control WG 202 RAI p2psip Peer-to-Peer Session Initiation Protocol WG 204 B SEC abfab Application Bridging for Federated Access Beyond web WG 206 B TSV tsvwg Transport Area Working Group WG James & Gorry TSVWG chairs From jmpolk@cisco.com Fri Jul 8 14:25:57 2011 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 2900221F8CEC for ; Fri, 8 Jul 2011 14:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.085 X-Spam-Level: X-Spam-Status: No, score=-105.085 tagged_above=-999 required=5 tests=[AWL=-2.486, 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 NnNNsLJyu96p for ; Fri, 8 Jul 2011 14:25:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 851F421F8CE5 for ; Fri, 8 Jul 2011 14:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=986; q=dns/txt; s=iport; t=1310160356; x=1311369956; h=message-id:date:to:from:subject:mime-version; bh=CbtV64oXPexzz0tMpVFN/ivmN5wlOgfaSDR71cGksA8=; b=Y4TOinMC0wCaq4I7MplilIeILXBjE3ou7PlZmnGkshBtip32kXOo/x63 +H0miLXCAsdCe2od6AUKJhmKZSjFm+Yry+HI97Tc9ssWAMaznxqEkeSTC 2c4TgNMZalq5Ggd0w6NKJyTLm8B41kHGri0L5o3gLT4SSGaVDBGpqDtqP w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJd1F06rRDoJ/2dsb2JhbABUp053qkiBIp1ehjgEh0ubYg X-IronPort-AV: E=Sophos;i="4.65,500,1304294400"; d="scan'208";a="1192428" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-5.cisco.com with ESMTP; 08 Jul 2011 21:25:56 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p68LPtxo001301 for ; Fri, 8 Jul 2011 21:25:55 GMT Message-Id: <201107082125.p68LPtxo001301@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 08 Jul 2011 16:25:54 -0500 To: tsvwg From: "James M. Polk" Subject: Rough (i.e., pre-draft) agenda items Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 08 Jul 2011 21:25:57 -0000 TSVWG I have a list of items that folks have asked to present. I don't know if I have a complete list though, so I ask that each of you wanting to present, formally request a slot (include name of presenter, time wanted, and ID filename). What I currently have ===================== Chair's agenda and stuff draft-ietf-natsupp-tsvwg draft-ietf-tsvwg-intserv-multiple-tspec draft-ietf-tsvwg-sctpstrrst draft-briscoe-tsvwg-ecn-encap-guidelines draft-touch-tsvwg-port-use draft-wood-tsvwg-saratoga draft-tuexen-tsvwg-sctp-sack-immediately draft-polk-tsvwg-rsvp-app-id-vv-profiles Those I'm not sure about ======================== draft-ietf-6man-udpzero draft-nishida-tsvwg-sctp-failover draft-tuexen-tsvwg-sctp-multipath-00 draft-tuexen-sctp-udp-encaps-04 draft-stewart-tsvwg-sctp-nonce draft-lefaucheur-tsvwg-rsvp-multiple-preemption draft-prehnal-tsvwg-rsp Let me know soon, as draft agendas are due next Wednesday the 13th. James TSVWG chair From Michael.Tuexen@lurchi.franken.de Sun Jul 10 08:50:45 2011 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 913B421F8740 for ; Sun, 10 Jul 2011 08:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.127 X-Spam-Level: X-Spam-Status: No, score=-0.127 tagged_above=-999 required=5 tests=[AWL=-2.172, BAYES_00=-2.599, FRT_STOCK2=3.988, MIME_8BIT_HEADER=0.3, SARE_SUB_6CONS_WORD=0.356] 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 qUI0FNpPGR99 for ; Sun, 10 Jul 2011 08:50:44 -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 0D6D621F866A for ; Sun, 10 Jul 2011 08:50:42 -0700 (PDT) Received: from [192.168.1.195] (p508FBB54.dip.t-dialin.net [80.143.187.84]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 15B961C0C0BCA; Sun, 10 Jul 2011 17:50:40 +0200 (CEST) Subject: Re: Review of draft-ietf-tsvwg-sctp-strrst-09.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <53A68C67A0118048A3E3F2C0827667EF5EB59C@XMB-AMS-202.cisco.com> Date: Sun, 10 Jul 2011 17:50:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53A68C67A0118048A3E3F2C0827667EF5EB59C@XMB-AMS-202.cisco.com> To: Gavin Shearer (gasheare) X-Mailer: Apple Mail (2.1084) Cc: tsvwg@ietf.org 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, 10 Jul 2011 15:50:45 -0000 Hi Gavin, thank you very much for your comments. Please see my corresponding answers in-line. Best regards Michael On Mar 29, 2011, at 1:05 PM, Gavin Shearer (gasheare) wrote: > Hi, >=20 > I have been reviewing the draft RFC: >=20 > Stream Control Transmission Protocol (SCTP) Stream Reconfiguration > draft-ietf-tsvwg-sctp-strrst-09.txt >=20 > I think the RFC is useful, especially the option to add more outgoing > streams, which is used in "IPFIX Export per SCTP Stream" > (draft-ietf-ipfix-export-per-sctp-stream-08)i, so I believe the ID > should progress. However, I do have some review comments, though most > of them are document text suggestions, and I think with the few = changes > I have suggested, that the information to implementors is quite clear. >=20 > One area I am questioning is why there needs to be a feature to reset > both SSN and TSN, but if that is needed by others, then I will accept = it > as part of this draft. >=20 > Cheers, Gavin Shearer >=20 >=20 >=20 > The following are my comments and suggestions on: >=20 > My comments are marked below with #### GSS. I have included > some context of the document to aid locating where the comments = relates. > I have some general comments first. >=20 > What is the purpose of the TSN/SSN reset? What do you gain from > allowing the TSNs to also be reset considering that they are not set = to > a specific value in the first place, and when changed the way it > "SHOULD" > be changed does not allow much control of the values the TSNs are > changed > to? It also adds more complexity as you have to be concerned whether = the >=20 > the TSN's of recent chunks before the change may be muddled with new > chunks after the change if the "SHOULD" suggestions on values are not > followed.=20 Please see the discussion on the mailing list. >=20 > As the new STREAM_RESET chunk is for more than just resetting streams > (i.e. > adding extra outgoing streams), should it be named STREAM_RECONFIG > instead of STREAM_RESET? > Other similar changes in line with this are suggested below: > Stream Reset Response Parameter -> > Stream Reconfig Response Parameter > Stream Reset Request Sequence Number -> > Stream Reconfig Request Sequence Number > Stream Reset Response Sequence Number -> > Stream Reconfig Response Sequence Number > Stream Reset Chunk[s] -> > Stream Reconfig Chunk[s] > Stream Reset Timer -> > Stream Reconfig Timer > reset request parameter -> > reconfig request parameter >=20 > For consistency should decide on STREAM_RESET or STREAM RESET when > discussing > the chunk (it also uses Stream Reset ...). I already did some renaming like you suggested for revision 10. So this is already done. >=20 > For the Sockets API, what should happen if the timer is already = running > when a request is received? Should the request be failed (and so a > failure > event needs specified) or should the request be queued? The corresponding setsockopt() will fail. I've added: If a call to setsockopt() is used to issue a Re-configuration request while the Re-configuration timer is running, setsockopt() will return -1 and error is set to EALREADY. >=20 >=20 >=20 > 3.1. STREAM RESET Chunk > . > . > . > Note that each STREAM RESET chunk holds at least one parameter and = at > most two parameters. Only the following combinations are allowed: >=20 > 1. Outgoing SSN Reset Request Parameter. >=20 > 2. Incoming SSN Reset Request Parameter. >=20 > 3. Outgoing SSN Reset Request Parameter, Incoming SSN Reset Request > Parameter. >=20 > 4. SSN/TSN Reset Request Parameter. >=20 > 5. Add Outgoing Streams Request Parameter. >=20 > 6. Stream Reset Response Parameter. >=20 > 7. Stream Reset Response Parameter, Outgoing SSN Reset Request > Parameter. >=20 > 8. Stream Reset Response Parameter, Stream Reset Response = Parameter. >=20 > #### GSS: Under what situation do you expect there to be 2 response > #### GSS: parameters? For example if you receive two request parameters listed as case 3. > . > . > . > 4.1. Outgoing SSN Reset Request Parameter >=20 > This parameter is used by the sender to request the reset of some or > all outgoing streams. >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Parameter Type =3D 0x000d | Parameter Length =3D 16 + 2 * N = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Stream Reset Request Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Stream Reset Response Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sender's Last Assigned TSN | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Stream Number 1 (optional) | Stream Number 2 (optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / ...... / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Stream Number N-1 (optional) | Stream Number N (optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Parameter Type: 2 bytes (unsigned integer) > This field holds the IANA defined parameter type for Stream Reset >=20 > #### GSS: Change "Stream Reset Request Parameter" to > #### GSS: "Outgoing SSN Reset Request Parameter" Done. >=20 > Request Parameter. The suggested value of this field for IANA is > 0x000d. >=20 > Parameter Length: 2 bytes (unsigned integer) > This field holds the length in bytes of the parameter; the value > MUST be 16 + 2 * N. >=20 > Stream Reset Request Sequence Number: 4 bytes (unsigned integer) > This field is used to identify the request. It is a = monotonically > increasing number that is initialized to the same value as the > Initial TSN number. It is increased by 1 whenever sending a new > Stream Reset Request parameter. >=20 > #### GSS: Change "Stream Reset Request parameter" to "request > parameter", > #### GSS: as also used when adding additional streams, and there is = also > #### GSS: no specific parameter named "Stream Reset Request" This was already done, when doing the renaming. It now reads: It is increased by 1 whenever sending a new Re-configuration Request = parameter. >=20 > . > . > . >=20 >=20 > 4.2. Incoming SSN Reset Request Parameter >=20 > This parameter is used by the sender to request that the peer resets > some or all of its outgoing streams. >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Parameter Type =3D 0x000e | Parameter Length =3D 8 + 2 * N = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Stream Reset Request Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Stream Number 1 (optional) | Stream Number 2 (optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / ...... / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Stream Number N-1 (optional) | Stream Number N (optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Parameter Type: 2 bytes (unsigned integer) > This field holds the IANA defined parameter type for Stream Reset >=20 > #### GSS: Change "Stream Reset Request Parameter" to > #### GSS: "Incoming SSN Reset Request Parameter" Already done. >=20 > Request Parameter. The suggested value of this field for IANA is > 0x000e. >=20 > Parameter Length: 2 bytes (unsigned integer) > This field holds the length in bytes of the parameter; the value > MUST be 8 + 2 * N. >=20 > Stream Reset Request Sequence Number: 4 bytes (unsigned integer) > This field is used to identify the request. It is a = monotonically > increasing number that is initialized to the same value as the > Initial TSN number. It is increased by 1 whenever sending a new > Stream Reset Request parameter. >=20 > #### GSS: Change "Stream Reset Request parameter" to "request > parameter", > #### GSS: as also used when adding additional streams, and there is = also > #### GSS: no specific parameter named "Stream Reset Request" Already done. >=20 > Stream Number 1..N: 2 bytes (unsigned integer) > This optional field, if included, is used to indicate specific > streams that are to be reset. If no streams are listed, then all > streams are to be reset. >=20 > This parameter can appear in a STREAM RESET chunk. This parameter > MUST NOT appear in any other chunk type. >=20 > 4.3. SSN/TSN Reset Request Parameter >=20 > This parameter is used by the sender to request a reset of the TSN > and SSN numbering of all streams. >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Parameter Type =3D 0x000f | Parameter Length =3D 8 = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Stream Reset Request Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Parameter Type: 2 bytes (unsigned integer) > This field holds the IANA defined parameter type for Stream Reset >=20 > #### GSS: Change "Stream Reset Request Parameter" to > #### GSS: "SSN/TSN Reset Request Parameter" Already done. >=20 > Request Parameter. The suggested value of this field for IANA is > 0x000f. >=20 > Parameter Length: 2 bytes (unsigned integer) > This field holds the length in bytes of the parameter; the value > MUST be 8. >=20 > Stream Reset Request Sequence Number: 4 bytes (unsigned integer) > This field is used to identify the request. It is a = monotonically > increasing number that is initialized to the same value as the > Initial TSN number. It is increased by 1 whenever sending a new > Stream Reset Request parameter. >=20 > #### GSS: Change "Stream Reset Request parameter" to "request > parameter", > #### GSS: as also used when adding additional streams, and there is = also > #### GSS: no specific parameter named "Stream Reset Request" Already done. >=20 > This parameter can appear in a STREAM RESET chunk. This parameter > MUST NOT appear in any other chunk type. >=20 > 4.4. Stream Reset Response Parameter >=20 > This parameter is used by the receiver of a stream reset request > parameter to respond to the stream reset request. >=20 > #### GSS: As also used for adding additional streams change to: > #### GSS: "This parameter is used by the receiver of a request = parameter > #### GSS: to respond to the request." It now uses Re-configuration Request parameter. > . > . > . > Sender's next TSN: 4 bytes (unsigned integer) > This field holds the TSN the sender of the Response will use to >=20 > #### GSS: lower case "R" in response Done. >=20 >=20 > 4.5. Add Outgoing Streams Request Parameter >=20 > This parameter is used by the sender to request that an additional > number of outgoing streams (i.e. the receiver's incoming streams) be > added to the association. >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Parameter Type =3D 0x0011 | Parameter Length =3D 12 = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Stream Reset Request Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Number of new streams | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Parameter Type: 2 bytes (unsigned integer) > This field holds the IANA defined parameter type for the Add > Streams Parameter. The suggested value of this field for IANA is >=20 > #### GSS: Change "Add Streams Parameter" to > #### GSS: "Add Outgoing Streams Request Parameter" Done. >=20 > 0x0011. >=20 > Parameter Length: 2 bytes (unsigned integer) > This field holds the length in bytes of the parameter; the value > MUST be 12. >=20 > Stream Reset Request Sequence Number: 4 bytes (unsigned integer) > This field is used to identify the request. It is a = monotonically > increasing number that is initialized to the same value as the > Initial TSN number. It is increased by 1 whenever sending a new > Stream Reset Request parameter. >=20 > #### GSS: Change "Stream Reset Request parameter" to "request > parameter", > #### GSS: as also used when adding additional streams, and there is = also > #### GSS: no specific parameter named "Stream Reset Request" It reads now It is increased by 1 whenever sending a new Re-configuration Request = parameter. > . > . > . >=20 > 5. Procedures >=20 > This section defines the procedures used by both the sender and > receiver of a stream reset. We also give various example stream > reset scenarios. >=20 > #### GSS: As it gives more than reset, maybe change to talk about > handling of > #### GSS: the chunks, e.g.: > #### GSS: This section defines the procedures used by both the sender > and > #### GSS: receiver of a STREAMS_RESET chunk. >=20 > #### GSS: I don't think this section gives example scenarios (they are > in > #### GSS: Appendix A), so remove the line: "We also give various = example > #### GSS: stream reset scenarios". Yes, it reads now: This section defines the procedures used by both the sender and receiver of a RE-CONFIG chunk. Various examples of re-configuration scenarios are given in . >=20 > One important thing to remember about SCTP streams is that they are > uni-directional and there is no coorespondance between outgoing and >=20 > #### GSS: Typo: coorespondance -> correspondance Fixed. >=20 > incoming streams. The procedures outlined in this section are > designed so that the incoming side will always reset their stream > sequence number first before the outgoing side which means the = stream > reset request must always originate from the outgoing side. These > two issues have important ramifications upon how an SCTP endpoint > might request that its incoming streams be reset. In effect it must > ask the peer to start an outgoing reset proceedure and once that >=20 > #### GSS: Typo: proceedure -> procedure Fixed. >=20 > request is acknowledged let the peer actually control the reset > operation. >=20 > 5.1. Sender Side Procedures >=20 > This section describes the procedures related to the sending of > Stream Reset Chunks. A Stream Reset Chunk is composed of one or two > Type Length Value (TLV) parameters. >=20 > 5.1.1. Sender Side Procedures for the Stream Reset Chunk >=20 > This SCTP extension uses the Supported Extensions Parameter defined > in [RFC5061] for negotiating the support for it. >=20 > An SCTP endpoint supporting this extension MUST include the chunk > type of the STREAM_RESET chunk in the Supported Extensions Parameter > in either the INIT or INIT-ACK. Before sending a Stream Reset Chunk > the sender MUST ensure that the peer advertised support for the > stream reset extension. If the chunk type of the STREAM_RESET chunk > does not appear in the supported extensions list of chunks, then the > sender MUST NOT send any stream reset request to the peer, and any > request by the application for such service SHOULD be responded to > with an appropriate error indicating the peer SCTP stack does not > support the stream reset extension. >=20 > After packaging the Stream Reset Chunk and sending it to the peer = the > sender MUST start a 'Stream Reset Timer' if the STREAM RESET chunk > contains at least one request parameter. If it contains no request > parameter, the Stream Reset Timer MUST NOT be started. This timer >=20 > #### GSS: Typo: parameter -> parameters Fixed >=20 > MUST use the same value as SCTP's Data transmission timer (i.e. the > RTO timer) and MUST use exponential backoff doubling the value at > every expiration. If the timer expires, besides doubling the value, > the sender MUST retransmit the Stream Reset Chunk, increment the > appropriate error counts (both for the association and the > destination), and perform threshold management possibly destroying > the association if SCTP retransmission thresholds are exceeded. >=20 > 5.1.2. Sender Side Procedures for the Outgoing SSN Reset Request > Parameter >=20 > When an SCTP sender wants to reset the SSNs of some or all outgoing > streams it can send an Outgoing SSN Reset Request Parameter provided > that the Stream Reset Timer is not running. The following steps = must > be followed: >=20 > A1: The sender MUST stop assigning new SSNs to new user data > provided by the upper layer for the affected streams and queue > it. This is because it is not known whether the receiver of = the > request will accept or deny it and moreover, a lost request > might cause an out-of-sequence error in a stream that the > receiver is not yet prepared to handle. >=20 > #### GSS: What happens to user data already assigned SSNs, or do we > assume > #### GSS: that they are only assigned just before sending? If we do = not Yes, assigning SSN must be done before sending, since the SSN field is part of the DATA chunk. > #### GSS: assume this, should it say that the request can only be sent > #### GSS: out after all data with assigned SSNs have been sent? >=20 > #### GSS: Also should it emphasize that transmission of data must be > suspended > #### GSS: until a response is received for the request? I think that is clear. Without assigning the SSN, you can't put it on the wire. >=20 > . > . > . >=20 > 5.1.3. Sender Side Procedures for the Incoming SSN Reset Request > Parameter >=20 > . > . > . >=20 > When sending a Incoming SSN Reset Request their is a potential that >=20 > #### GSS: Typos: a -> an, their -> there Fixed. >=20 > the peer has just reset or is in the process of resetting the same > streams via an Outgoing SSN Reset Request. This collision scenario > is discussed in Section 5.2.3. >=20 > 5.1.4. Sender Side Procedures for the SSN/TSN Reset Request Parameter >=20 > When an SCTP sender wants to reset the SSNs and TSNs it can send an > SSN/TSN Reset Request Parameter provided that the Stream Reset Timer > is not running. The following steps must be followed: >=20 > C1: The sender MUST assign the next stream reset request sequence > number and put it into the Stream Reset Request Sequence Number > field of the SSN/TSN Reset Request Parameter. After assigning > it the next stream reset request sequence number MUST be > incremented by 1. >=20 > C2: The sender MUST queue any user data suspending any new > transmissions and TSN assignment until the reset procedure is >=20 > #### GSS: change "TSN" to "TSN and SSN" >=20 > finished by the peer either acknowledging or denying the > request. >=20 > #### GSS: What happens to data already assigned TSN and/or SSNs but = have > #### GSS: but have not been sent, or do we assume that they are only > #### GSS: assigned just before sending? If we do not Only user messages sent after the application has requested the SSN/TSN reset are affected. So only these need to be queued. > #### GSS: assume this, should it say that the request can only be sent > #### GSS: out after all data with assigned TSNs and SSNs have been = sent? I added: The sender has either no outstanding TSNs or considers all outstanding TSNs abondoned. >=20 > C3: The SSN/TSN Reset Request Parameter MUST be put into a STREAM > RESET Chunk. There MUST NOT be any other parameter in this > chunk. >=20 > C4: The STREAM RESET Chunk MUST be sent following the rules given = in > Section 5.1.1. >=20 > Only one SSN/TSN Reset Request SHOULD be sent within 30 seconds, > which is considered a maximum segment lifetime, the IP MSL. >=20 > 5.1.5. Sender Side Procedures for the Stream Reset Response Parameter >=20 > When an implementation receives a reset request parameter it must > respond with a Stream Reset Response Parameter in the following > manner: >=20 > D1: The Stream Reset Request Sequence number of the incoming = request > MUST be copied to the Stream Reset Response Sequence Number > field of the Stream Reset Response Parameter. >=20 > D2: The result of the processing of the incoming request according > to Table 3 MUST be placed in the Result field of the Stream > Reset Response Parameter. >=20 > D3: If the incoming request is an SSN/TSN reset request, the > Sender's next TSN field MUST be filled with the next TSN the > sender of this Stream Reset Response Parameter will assign. = For >=20 > #### GSS: should D3 also mention the SHOULD in G2? No: It MUST be filled. However, the suggested value SHOULD be the one given in G2. >=20 > other requests the Sender's next TSN field, which is optional, > MUST NOT be used. >=20 > . > . > . >=20 > 5.2.2. Receiver Side Procedures for the Outgoing SSN Reset Request > Parameter > . > . > . > E6: The STREAM RESET chunk MUST be sent after the incoming STREAM > RESET chunk is processed completely. >=20 > #### GSS Should it say about sending "Denied" if not supporting the > change, > #### GSS similar to 5.2.3 I took the sentence out of 5.2.3, since there is a generic statement in 5.2.1. >=20 > 5.2.3. Receiver Side Procedures for the Incoming SSN Reset Request > Parameter >=20 > In the case that the endpoint is willing to perform a stream reset > the following steps must be followed: >=20 > F1: An Outgoing SSN Reset Request Parameter MUST be put into an > STREAM RESET chunk according to Section 5.1.2. >=20 > F2: The STREAM RESET chunk MUST be sent after the incoming STREAM > RESET chunk is processed completely. >=20 > If the endpoint is un-willing to perform the stream reset it MUST > send a Stream Reset Response Parameter with the appropriate error = set > to "Denied". >=20 > When a peer endpoint requests a Incoming SSN Reset Request it is >=20 > #### GSS: Typo: a -> an Fixed. >=20 > possible that the local endpoint has just sent an Outgoing SSN Reset > Request on the same stream and has not yet received a response. In >=20 > #### GSS: stream -> association? Fixed. >=20 > such a case the local endpoint MUST do the following: >=20 > 1) If the stream reset overlaps the outstanding request completely >=20 > #### GSS: make clearer which is which? e.g. > #### GSS: "If the just sent Outgoing SSN Reset Request Parameter > completely=20 > #### GSS: overlaps the received Incoming SSN Reset Request Parameter > ..." Fixed. >=20 > respond to the requestor with a acknowledgment indicating that >=20 > #### GSS: Typo: a -> an Fixed. >=20 > there was 'Nothing to do'. >=20 > 2) Otherwise process the stream reset request normally responding to > the requestor with a acknowledgment. >=20 > #### GSS: Typo: a -> an Fixed. > . > . > . >=20 > 5.2.4. Receiver Side Procedures for the SSN/TSN Reset Request = Parameter >=20 > In the case that the endpoint is willing to perform an SSN/TSN reset > the following steps must be followed: >=20 > G1: Compute an appropriate value for the Receiver's next TSN, the > TSN the peer should use to send the next DATA chunk. The value > SHOULD be the smallest TSN not acknowledged by the receiver of > the request plus 2^31. >=20 > G2: Compute an appropriate value for the local endpoint's next TSN, > i.e. the receiver of the SSN/TSN reset chunk next TSN to be > assigned. The value SHOULD be the highest TSN sent by the > receiver of the request plus 1. >=20 > #### GSS: Is this recommended value not the value the other size would > #### GSS: normally expect at the TSN? If other values are allowed, are > #### GSS: there recommendations, e.g. add 2^31 We recommend the value given. It is the next expected TSN. >=20 From internet-drafts@ietf.org Sun Jul 10 13:10:07 2011 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 715CF21F861E; Sun, 10 Jul 2011 13:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356, 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 I3EsfAuwZgaN; Sun, 10 Jul 2011 13:10:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED25721F8650; Sun, 10 Jul 2011 13:10:06 -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 Subject: I-D Action: draft-ietf-tsvwg-sctp-strrst-11.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110710200951.24019.52568.idtracker@ietfa.amsl.com> Date: Sun, 10 Jul 2011 13:09:51 -0700 Cc: tsvwg@ietf.org 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, 10 Jul 2011 20:10:07 -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 = Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Stream Recon= figuration Author(s) : Randall R. Stewart Michael Tuexen Peter Lei Filename : draft-ietf-tsvwg-sctp-strrst-11.txt Pages : 33 Date : 2011-07-10 Many applications that use SCTP want the ability to "reset" a = stream. The intention of resetting a stream is to set the numbering sequence of the stream back to 'zero' with a corresponding notification t= o the upper layer that this has been performed. The applications that want this feature want it so that they can "re-use" streams for dif= ferent purposes but still utilize the stream sequence number so that the application can track the message flows. Thus, without this feature, a new use of an old stream would result in message numbers greater than expected unless there is a protocol mechanism to "reset the streams back to zero". This document also includes methods for resetting the transport sequence numbers, adding additional streams and resetting all stream sequence numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-11.txt From karagian@cs.utwente.nl Mon Jul 11 07:35:20 2011 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 CB32021F8C58; Mon, 11 Jul 2011 07:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[AWL=0.614, 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 1XKh3DthVJ0m; Mon, 11 Jul 2011 07:35:20 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 282FE21F8C56; Mon, 11 Jul 2011 07:35:19 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p6BEXaOg018737; Mon, 11 Jul 2011 16:33:36 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 11 Jul 2011 14:35:22 +0000 To: "tsvwg@ietf.org" , "pcn@ietf.org" Subject: uploaded Generic Aggregation RSVP over PCN (v01) Date: Mon, 11 Jul 2011 14:35:22 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <20110711142038.25971.69732.idtracker@ietfa.amsl.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 11 Jul 2011 16:33:45 +0200 (MEST) Cc: "anuragb@cisco.com" 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, 11 Jul 2011 14:35:20 -0000 Hi all, I have just uploaded draft-karagiannis-pcn-tsvwg-rsvp-pcn-01, see: http://www.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt 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 main changes of this version compared to the previous version is that the aggregation is mainly based on the Generic Aggregation RSVP (RFC4860], instead of being based on the Agggation RSVP (RFC3175}. Comments are welcome! This draft is relevant for both WGs, PCN and tsvwg. I would therefore very much like to also get an tsvwg agenda slot (of 15 minutes)! Best regards, Georgios From karagian@cs.utwente.nl Mon Jul 11 07:42:41 2011 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 9ED0E21F8C8F for ; Mon, 11 Jul 2011 07:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.087 X-Spam-Level: X-Spam-Status: No, score=0.087 tagged_above=-999 required=5 tests=[AWL=0.591, 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 1vEZALlFvEaJ for ; Mon, 11 Jul 2011 07:42:41 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id EB49C21F8C8E for ; Mon, 11 Jul 2011 07:42:40 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p6BEewRt019859; Mon, 11 Jul 2011 16:40:58 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 11 Jul 2011 14:42:44 +0000 To: "James M. Polk" , "tsvwg" Subject: Re: Rough (i.e., pre-draft) agenda items Date: Mon, 11 Jul 2011 14:42:43 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <201107082125.p68LPtxo001301@mtv-core-4.cisco.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 11 Jul 2011 16:41:07 +0200 (MEST) 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, 11 Jul 2011 14:42:41 -0000 Hi James, I have just uploaded draft-karagiannis-pcn-tsvwg-rsvp-pcn-01, see: http://www.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt 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. This draft is relevant for both pcn and tsvwg! I would therefore very much like to also get an tsvwg agenda slot (of 15 minutes)! Best regards, Georgios On 7/8/2011, "James M. Polk" wrote: >TSVWG > >I have a list of items that folks have asked to present. I don't know >if I have a complete list though, so I ask that each of you wanting >to present, formally request a slot (include name of presenter, time >wanted, and ID filename). > >What I currently have >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Chair's agenda and stuff >draft-ietf-natsupp-tsvwg >draft-ietf-tsvwg-intserv-multiple-tspec >draft-ietf-tsvwg-sctpstrrst >draft-briscoe-tsvwg-ecn-encap-guidelines >draft-touch-tsvwg-port-use >draft-wood-tsvwg-saratoga >draft-tuexen-tsvwg-sctp-sack-immediately >draft-polk-tsvwg-rsvp-app-id-vv-profiles > > >Those I'm not sure about >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >draft-ietf-6man-udpzero >draft-nishida-tsvwg-sctp-failover >draft-tuexen-tsvwg-sctp-multipath-00 >draft-tuexen-sctp-udp-encaps-04 >draft-stewart-tsvwg-sctp-nonce >draft-lefaucheur-tsvwg-rsvp-multiple-preemption >draft-prehnal-tsvwg-rsp > >Let me know soon, as draft agendas are due next Wednesday the 13th. > >James >TSVWG chair From magnus.westerlund@ericsson.com Wed Jul 13 09:08:27 2011 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 644B911E8127 for ; Wed, 13 Jul 2011 09:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.517 X-Spam-Level: X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, 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 9KjsNAAtO8i2 for ; Wed, 13 Jul 2011 09:08:26 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA7811E80A8 for ; Wed, 13 Jul 2011 09:08:26 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-24-4e1dc2f9034e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3D.8A.20773.9F2CD1E4; Wed, 13 Jul 2011 18:08:25 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Wed, 13 Jul 2011 18:08:24 +0200 Message-ID: <4E1DC2F1.2050102@ericsson.com> Date: Wed, 13 Jul 2011 18:08:17 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: Rough (i.e., pre-draft) agenda items References: <201107082125.p68LPtxo001301@mtv-core-4.cisco.com> In-Reply-To: <201107082125.p68LPtxo001301@mtv-core-4.cisco.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== 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, 13 Jul 2011 16:08:27 -0000 On 2011-07-08 23:25, James M. Polk wrote: > > Those I'm not sure about > ======================== > draft-ietf-6man-udpzero We don't need any presentation time for this draft. Its status is as follows. We authors judge it ready for WG last call. It is currently awaiting that the draft actually making the changes to RFC 2460 (IPv6 spec) is in good enough shape for a joint WG last call. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From iesg-secretary@ietf.org Mon Jul 18 06:29:27 2011 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 9A28621F8BD5; Mon, 18 Jul 2011 06:29:27 -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 HT3dv8pESlaF; Mon, 18 Jul 2011 06:29:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A06621F862F; Mon, 18 Jul 2011 06:29:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Applicability of Keying Methods for RSVP Security) to Informational RFC X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110718132927.32159.56752.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2011 06:29:27 -0700 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 13:29:27 -0000 The IESG has received a request from the Transport Area Working Group (tsvwg) to consider the following document: - 'Applicability of Keying Methods for RSVP Security' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity protection of RSVP neighbors. This requires messages to be cryptographically protected using a shared secret between participating nodes. This document compares group keying for RSVP with per neighbor or per interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. The document also discusses applicability of encrypting RSVP messages. The Responsible AD notes that the IPR declaration terms seem to apply to standards-track documents, but not necessarily to an Informational document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-security-groupkeying/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-security-groupkeying/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/988/ From wangdanhua@huawei.com Wed Jun 29 20:06:50 2011 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 2709711E80A3; Wed, 29 Jun 2011 20:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 3GS1B546BE37; Wed, 29 Jun 2011 20:06:48 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id DA0C711E8083; Wed, 29 Jun 2011 20:06:47 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNL007VF1XR0Z@szxga05-in.huawei.com>; Thu, 30 Jun 2011 11:05:52 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNL003EW1XR1X@szxga05-in.huawei.com>; Thu, 30 Jun 2011 11:05:51 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml202-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACE21556; Thu, 30 Jun 2011 11:05:43 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 30 Jun 2011 11:05:33 +0800 Received: from SZXEML504-MBX.china.huawei.com ([169.254.8.3]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Thu, 30 Jun 2011 11:05:42 +0800 From: wangdanhua Subject: Looking forward to your comments: Survey and Gap Analysis for Policies and Dynamic Information Migration in Data Center X-Originating-IP: [10.138.41.96] To: "opsawg@ietf.org" , "tsvwg@ietf.org" , "dispatch@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_BSfEl/DYdM2SDEFKzFNi0w)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Looking forward to your comments: Survey and Gap Analysis for Policies and Dynamic Information Migration in Data Center Thread-index: AcwvxII6NIOr4KEqT7e/9oY69KijZAAA/D3AAGJst3ABYAr98A== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 20 Jul 2011 07:22:36 -0700 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: , Date: Thu, 30 Jun 2011 03:06:50 -0000 X-Original-Date: Thu, 30 Jun 2011 03:04:45 +0000 X-List-Received-Date: Thu, 30 Jun 2011 03:06:50 -0000 --Boundary_(ID_BSfEl/DYdM2SDEFKzFNi0w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Hi all, A few days ago, we sent a draft considering "policies and dynamic informati= on migration in DC" to OPSAWG, the draft ID is "draft-gu-opsa-policies-migr= ation-00" and its URL is http://datatracker.ietf.org/doc/draft-gu-opsa-poli= cies-migration/ . Based on this problem statement draft as well as the disc= ussion at the 80th IETF conference, we also performed a gap analysis betwee= n dynamic information migration (DIM) requirements and the most related IET= F works. We sent a gap analysis draft to the OPSAWG, here is the URL http:= //datatracker.ietf.org/doc/draft-wang-opsawg-policies-migration-gap-analysi= s/ . Following is the abstract of this draft. We sincerely hope that you wo= uld give your valuable comment or options if you are interest in this draft= . With the virtualization of Data Center, the number of VM explodes. VM can p= lay different roles in Data Center, such as end-host, server, firewall, and= so on. Also, VM can be migrated to any places within Data Center, even to = another Data Center. Since running services shouldn't be significantly inte= rrupted while VM migrates, VM related policies and dynamic information gene= rated by any devices must be transferred to destination devices during a pr= oper short period. [I.D-gu-opsa-policies-migration-00] has introduced more = detail problem statement and corresponding considerations. We wish we could= benefit from existing work to realize accurate dynamic information migrati= on (DIM). Therefore, we engaged in the investigation of related IETF works= right after general requirements of DIM are defined. Since the solution f= or DIM has not been decided yet, and the author can envision several kinds = of solution, e.g. centralized or distributed. It's unrealistic to enumerat= e all the related works for an uncertain solution. So, in this draft, only= the most related IETF work, MIDCOM protocol, has been evaluated to find ou= t whether it can fully support DIM or which characteristics can be reused i= n DIM. The author would like analyze other related IETF works when the WG m= ake further decision on DIM solution. Following a short description of general DIM requirements, this draft prese= nts a brief survey of MIDCOM protocol, and then lists the gap between MIDCO= M and DIM requirements. The final section presents possible working scope = on the topic of DIM in IETF. Best Regards Danhua Wang HuaWei Technology Co. Ltd. Nanjing, China --Boundary_(ID_BSfEl/DYdM2SDEFKzFNi0w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all,

 

A few days ago, we sent a draft considering “policies and dynamic information migration in DC” to OPSAWG, the draft ID is “draft-gu-opsa-policies-migration-00” and its URL is http://datatracker.ietf.org/doc/draft-gu-opsa-policies-migration/ . Based on this problem statement draft as well as the discussion at the 80th IETF conference, we also performed a gap analysis between dynamic information migration (DIM) requirements and the most related IETF works. We sent a gap analysis draft to the OPSAWG, here is the URL  http://datatracker.ietf.org/doc/draft-wang-opsawg-policies-migration-gap-analysis/ . Following is the abstract of this draft. We sincerely hope that you would give your valuable comment or options if you are interest in this draft.

 

With the virtualization of Data Center, the number of VM explodes. VM can play different roles in Data Center, such as end-host, server, firewall, and so on. Also, VM can be migrated to any places within Data Center, even to another Data Center. Since running services shouldn't be significantly interrupted while VM migrates, VM related policies and dynamic information generated by any devices must be transferred to destination devices during a proper short period. [I.D-gu-opsa-policies-migration-00] has introduced more detail problem statement and corresponding considerations. We wish we could benefit from existing work to realize accurate dynamic information migration (DIM).  Therefore, we engaged in the investigation of related IETF works right after general requirements of DIM are defined.  Since the solution for DIM has not been decided yet, and the author can envision several kinds of solution, e.g. centralized or distributed.  It's unrealistic to enumerate all the related works for an uncertain solution.  So, in this draft, only the most related IETF work, MIDCOM protocol, has been evaluated to find out whether it can fully support DIM or which characteristics can be reused in DIM. The author would like analyze other related IETF works when the WG make further decision on DIM solution.

 

Following a short description of general DIM requirements, this draft presents a brief survey of MIDCOM protocol, and then lists the gap between MIDCOM and DIM requirements.  The final section presents possible working scope on the topic of DIM in IETF.

 

 

Best Regards

Danhua Wang

HuaWei Technology Co. Ltd.

Nanjing, China

--Boundary_(ID_BSfEl/DYdM2SDEFKzFNi0w)-- From karagian@cs.utwente.nl Thu Jul 21 13:35:49 2011 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 5D28B21F8876; Thu, 21 Jul 2011 13:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.038 X-Spam-Level: X-Spam-Status: No, score=0.038 tagged_above=-999 required=5 tests=[AWL=0.542, 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 BP+5brg1WN56; Thu, 21 Jul 2011 13:35:48 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 535FC21F886A; Thu, 21 Jul 2011 13:35:48 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p6LKXq3V011782; Thu, 21 Jul 2011 22:33:52 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 21 Jul 2011 20:35:53 +0000 To: "tsvwg@ietf.org" , "pcn@ietf.org" Subject: soliciting comments for "Generic aggregation RSVP over PCN" draft Date: Thu, 21 Jul 2011 20:35:53 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 21 Jul 2011 22:34:01 +0200 (MEST) 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, 21 Jul 2011 20:35:49 -0000 Hi all, You might know that the following draft has been submitted to the PCN WG and the tsvwg: http://www.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt We solicit comments on this draft from the members of PCN WG and tsvwg, since this draft might be relevant for both WGs. Below we are providing some information regarding the motivation of writing this draft and the additions to RFC 4860 and the PCN edge behaviour drafts, specified in this draft: Motivation (problem statement): ------------- o) All PCN charter items are fulfilled, except: Submit Encoding and Transport of PCN from the Domain Egress to the Ingress to the IESG for consideration as a Proposed Standard RFC: o) Pairs of PCN-ingress-node and PCN-egress-node use ingress-egress-aggregates (IEA): collection of PCN-packets from all PCN-flows that travel in one direction between a specific pair of PCN-boundary-nodes: =3D> Need a signaling protocol to transport PCN information from PCN-egress-node to PCN-ingress-node that is able to maintain ingress-egress-aggregate between each pair of PCN-ingress-node and PCN-egress-node Possible IETF QoS signaling protocols to solve the above problem: ----------------------------------- o) Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC 5979) o) Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175) o) Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC4860) All can be used, but for time being we selected RFC 4860 due to: o) possible deployment interest o) Supports RFC 3175 and additonal features such as: *) support of multiple IEAs from same pair of PCN edge nodes *) support of bandwidth reduction for individual flows (RFC 4495) Some augmentations needed for RFC 4860, see below: ---------------------------------------------------- o) Four new (2 for CL and 2 for SM) objects specified to include PCN information to be transported from PCN-egress-node to PCN-ingress-node o) Each Aggregator and Deaggregator support policies to initiate and maintain for each combination of a PCN-boundary-node and all other PCN-boundary-nodes of the same PCN domain one RSVP SESSION for generic aggregated reservations *) RSVP SESSION for generic aggregated reservations can match to one or more than one ingress-egress-aggregates. o) For each supported IEA, PCN-egress-node, periodically (end of each PCN measurement interval) generates Aggregated Resv messages and include new PCN object and send it to associated PCN-ingress-node o) PCN-interior-nodes are not using E2E RSVP or Generic Aggregated RSVP messages, but treated as normal packets. o) E2E RSVP session admission in PCN-domain: *) Each Aggregator support policies and PCN functionalities to admit or reject an incoming e2e RSVP Path message (in RFC4086 this is done by Deaggregator) and send a PathErr towards the sender. o) E2E RSVP flow termination in PCN-domain: *) Each Aggregator support policies and PCN functionalities to support the initiation of termination of one or more active E2E RSVP sessions and/or to reduce the bandwidth of one or more active individual existing RSVP sessions, in order to solve congestion in PCN-domain *) Same mechanisms for terminating or reducing bandwidth of an e2e RSVP session can be followed as specified in [RFC4495] Some augmentations might be needed for PCN CL and SM edge behavior drafts, see below: ---------------------------------------------------- In order to use all the advanced features of the Generic aggregation RSVP, minor augmentations on the CL and SM edge behavior drafts might be needed: Considered that PCN-ingress-node collocated with Decision point o) More than one IEAs between the same pair of PCN edge nodes should be supported, each of them using a different PHB-ID value o) When IEA supported by a PCN-ingress-node is in PCN-admission state, then based on a local policy, the requesting e2e RSVP session should be either rejected or should be mapped to another IEA that is NOT in PCN-admission-state o) When for an IEA supported by a PCN-ingress-node incoming traffic needs to be reduced (to reduce congestion in PCN-domain), then based on a local policy and for same IEA, select a number of e2e RSVP sessions: either to be terminated and/or to reduce the reserved bandwidth of e2e RSVP sessions, in order to decrease total incoming amount of incoming traffic associated with IEA by amount of traffic to be terminated Best regards, Georgios From david.black@emc.com Fri Jul 22 08:20:10 2011 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 98D4221F8B04; Fri, 22 Jul 2011 08:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 sqBHNO4DpATr; Fri, 22 Jul 2011 08:20:07 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 69E8921F8AFB; Fri, 22 Jul 2011 08:20:07 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p6MFJuJ4014340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jul 2011 11:19:57 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Fri, 22 Jul 2011 11:19:47 -0400 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p6MFJkMv029113; Fri, 22 Jul 2011 11:19:46 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Fri, 22 Jul 2011 11:19:45 -0400 From: To: , , , Date: Fri, 22 Jul 2011 11:19:45 -0400 Subject: RE: Looking forward to your comments: Survey and Gap Analysis for Policies and Dynamic Information Migration in Data Center Thread-Topic: Looking forward to your comments: Survey and Gap Analysis for Policies and Dynamic Information Migration in Data Center Thread-Index: AcwvxII6NIOr4KEqT7e/9oY69KijZAAA/D3AAGJst3ABYAr98ARo4rlA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058948BC34@MX14A.corp.emc.com> 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_7C4DFCE962635144B8FAE8CA11D0BF1E058948BC34MX14Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 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, 22 Jul 2011 15:20:10 -0000 --_000_7C4DFCE962635144B8FAE8CA11D0BF1E058948BC34MX14Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft-gu-opsa-policies-migration-00 is not completely clear to me. The= network diagrams, starting with Figure 1, do not indicate the L2 vs. L3 ne= twork boundaries (e.g., what's the scope of the VLANs mentioned in Section = 3.1), and the function of the "Gateway" at the top of the diagrams is not d= escribed. This is a concern, as if there's no L2 connectivity through the = Gateway across the two sides of the diagram, the left-to-right VM migration= use case shown in Figure 1 can be problematic, because all of the VM's L2 = connectivity breaks (e.g., ARP cache entries contain unreachable L2 address= es). Section 3.2 refers to a "proxy" - what is it and where is it in the n= etwork diagrams? That said, I believe that the ACL and related firewall state transfer probl= ems exist, but I'm concerned that other problems (e.g., DHCP state) may be = artifacts of unclear assumptions about network architecture that may not be= reasonable. For DHCP in particular, a few well-placed DHCP proxies may so= lve the problem, but the network diagrams are sufficiently unclear that I c= an't figure out where to locate the proxies. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.black@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of w= angdanhua Sent: Wednesday, June 29, 2011 11:05 PM To: opsawg@ietf.org; tsvwg@ietf.org; dispatch@ietf.org Subject: Looking forward to your comments: Survey and Gap Analysis for Poli= cies and Dynamic Information Migration in Data Center Hi all, A few days ago, we sent a draft considering "policies and dynamic informati= on migration in DC" to OPSAWG, the draft ID is "draft-gu-opsa-policies-migr= ation-00" and its URL is http://datatracker.ietf.org/doc/draft-gu-opsa-poli= cies-migration/ . Based on this problem statement draft as well as the disc= ussion at the 80th IETF conference, we also performed a gap analysis betwee= n dynamic information migration (DIM) requirements and the most related IET= F works. We sent a gap analysis draft to the OPSAWG, here is the URL http:= //datatracker.ietf.org/doc/draft-wang-opsawg-policies-migration-gap-analysi= s/ . Following is the abstract of this draft. We sincerely hope that you wo= uld give your valuable comment or options if you are interest in this draft= . With the virtualization of Data Center, the number of VM explodes. VM can p= lay different roles in Data Center, such as end-host, server, firewall, and= so on. Also, VM can be migrated to any places within Data Center, even to = another Data Center. Since running services shouldn't be significantly inte= rrupted while VM migrates, VM related policies and dynamic information gene= rated by any devices must be transferred to destination devices during a pr= oper short period. [I.D-gu-opsa-policies-migration-00] has introduced more = detail problem statement and corresponding considerations. We wish we could= benefit from existing work to realize accurate dynamic information migrati= on (DIM). Therefore, we engaged in the investigation of related IETF works= right after general requirements of DIM are defined. Since the solution f= or DIM has not been decided yet, and the author can envision several kinds = of solution, e.g. centralized or distributed. It's unrealistic to enumerat= e all the related works for an uncertain solution. So, in this draft, only= the most related IETF work, MIDCOM protocol, has been evaluated to find ou= t whether it can fully support DIM or which characteristics can be reused i= n DIM. The author would like analyze other related IETF works when the WG m= ake further decision on DIM solution. Following a short description of general DIM requirements, this draft prese= nts a brief survey of MIDCOM protocol, and then lists the gap between MIDCO= M and DIM requirements. The final section presents possible working scope = on the topic of DIM in IETF. Best Regards Danhua Wang HuaWei Technology Co. Ltd. Nanjing, China --_000_7C4DFCE962635144B8FAE8CA11D0BF1E058948BC34MX14Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The draft-gu-opsa-policies-migration-00 is not complete= ly clear to me.  The network diagrams, starting with Figure 1, do not = indicate the L2 vs. L3 network boundaries (e.g., what’s the scope of = the VLANs mentioned in Section 3.1), and the function of the “Gateway= ” at the top of the diagrams is not described.  This is a concer= n, as if there’s no L2 connectivity through the Gateway across the tw= o sides of the diagram, the left-to-right VM migration use case shown in Fi= gure 1 can be problematic, because all of the VM’s L2 connectivity br= eaks (e.g., ARP cache entries contain unreachable L2 addresses).  Sect= ion 3.2 refers to a “proxy” – what is it and where is it = in the network diagrams?

 <= /o:p>

That said, I believe that the ACL and rela= ted firewall state transfer problems exist, but I’m concerned that ot= her problems (e.g., DHCP state) may be artifacts of unclear assumptions abo= ut network architecture that may not be reasonable.  For DHCP in parti= cular, a few well-placed DHCP proxies may solve the problem, but the networ= k diagrams are sufficiently unclear that I can’t figure out where to = locate the proxies.

 

T= hanks,
--David
----------------------------------------------------David L. Black, Distinguished Engineer
EMC Corporation, 176 South St.,= Hopkinton, MA  01748
+1 (508) 293-7953    &nbs= p;        FAX: +1 (508) 293-7786
davi= d.black@emc.com        Mobile: +1 (978) = 394-7754
----------------------------------------------------

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: = tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of = wangdanhua
Sent: Wednesday, June 29, 2011 11:05 PM
To: = opsawg@ietf.org; tsvwg@ietf.org; dispatch@ietf.org
Subject: Looki= ng forward to your comments: Survey and Gap Analysis for Policies and Dynam= ic Information Migration in Data Center

 =

Hi all,

&nb= sp;

A few days ago, we sent a draft considering “policies and dyn= amic information migration in DC” to OPSAWG, the draft ID is “d= raft-gu-opsa-policies-migration-00” and its URL is http://datatracker.ietf.org/doc/draft-gu-opsa-policie= s-migration/ . Based on this problem statement draft as well as the dis= cussion at the 80th IETF conference, we also performed a gap analysis betwe= en dynamic information migration (DIM) requirements and the most related IE= TF works. We sent a gap analysis draft to the OPSAWG, here is the URL  http://datatracke= r.ietf.org/doc/draft-wang-opsawg-policies-migration-gap-analysis/ . Fol= lowing is the abstract of this draft. We sincerely hope that you would give= your valuable comment or options if you are interest in this draft.

 

With the virtualization of Data Center, the= number of VM explodes. VM can play different roles in Data Center, such as= end-host, server, firewall, and so on. Also, VM can be migrated to any pla= ces within Data Center, even to another Data Center. Since running services= shouldn't be significantly interrupted while VM migrates, VM related polic= ies and dynamic information generated by any devices must be transferred to= destination devices during a proper short period. [I.D-gu-opsa-policies-mi= gration-00] has introduced more detail problem statement and corresponding = considerations. We wish we could benefit from existing work to realize accu= rate dynamic information migration (DIM).  Therefore, we engaged in th= e investigation of related IETF works right after general requirements of D= IM are defined.  Since the solution for DIM has not been decided yet, = and the author can envision several kinds of solution, e.g. centralized or = distributed.  It's unrealistic to enumerate all the related works for = an uncertain solution.  So, in this draft, only the most related IETF = work, MIDCOM protocol, has been evaluated to find out whether it can fully = support DIM or which characteristics can be reused in DIM. The author would= like analyze other related IETF works when the WG make further decision on= DIM solution.

 

Following a short description of general DIM requirements, this dra= ft presents a brief survey of MIDCOM protocol, and then lists the gap betwe= en MIDCOM and DIM requirements.  The final section presents possible w= orking scope on the topic of DIM in IETF.

 

 <= /p>

Best Regards

= Danh= ua Wang

HuaWei Technology Co. Ltd.<= /o:p>

Nanjing,= China

= --_000_7C4DFCE962635144B8FAE8CA11D0BF1E058948BC34MX14Acorpemcc_-- From gorry@erg.abdn.ac.uk Sat Jul 23 02:45:12 2011 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 E801321F8922 for ; Sat, 23 Jul 2011 02:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 rbWpMOnVzFyQ for ; Sat, 23 Jul 2011 02:45:12 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 022CE21F865E for ; Sat, 23 Jul 2011 02:45:10 -0700 (PDT) Received: from Gorry.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p6N9j6Nh018338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 23 Jul 2011 10:45:07 +0100 (BST) Message-ID: <4E2A9822.6020201@erg.abdn.ac.uk> Date: Sat, 23 Jul 2011 10:45:06 +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:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: tsvwg WG Subject: IPR discussion: draft-ietf-tsvwg-rsvp-security-groupkeying References: <94007F3F05A24CF0AAFA916B42F93E69@davidPC> In-Reply-To: <94007F3F05A24CF0AAFA916B42F93E69@davidPC> X-Forwarded-Message-Id: <94007F3F05A24CF0AAFA916B42F93E69@davidPC> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk 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, 23 Jul 2011 09:45:13 -0000 The draft above is now in Last Call, and there needs to now be a discussion within TSVWG relating to the acceptability of the IPR terms for this document. There is an IPR statement filed: ID # 988 "Cisco's Statement about IPR claimed in draft-ietf-tsvwg-rsvp-security-groupkeying-01.txt" This seems to provide RAND terms for compliance to a standard, but this I-D is not being submitted as a standards-track document. The terms in the IPR declaration do not seem to provide non-assert status for implementing an Informational document. Please can the WG discuss this? * Specifically, do other options exist that would not introduce this IPR dependence? * Have these options been explored? * What does the WG recommend? (We can discuss this further in the WG meeting next week). Best wishes, Gorry Fairhurst TSVWG Chair From adrian@olddog.co.uk Sat Jul 23 07:31:43 2011 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 5DC1421F8726 for ; Sat, 23 Jul 2011 07:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 nmdgloTgqB+L for ; Sat, 23 Jul 2011 07:31:43 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAE821F865B for ; Sat, 23 Jul 2011 07:31:37 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p6NEVUJw019526; Sat, 23 Jul 2011 15:31:30 +0100 Received: from 950129200 ([216.226.38.2]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p6NEVRNJ019515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 Jul 2011 15:31:29 +0100 From: "Adrian Farrel" To: , "'tsvwg WG'" References: <94007F3F05A24CF0AAFA916B42F93E69@davidPC> <4E2A9822.6020201@erg.abdn.ac.uk> In-Reply-To: <4E2A9822.6020201@erg.abdn.ac.uk> Subject: RE: IPR discussion: draft-ietf-tsvwg-rsvp-security-groupkeying Date: Sat, 23 Jul 2011 10:31:21 +0100 Message-ID: <009b01cc491b$49f66190$dde324b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKDQnBiBMo+ceFkt6wNJTrXgCuR7wHch4k2k3zJ8UA= Content-Language: en-gb X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 14:31:43 -0000 Thanks Gorry, For those too tired to follow the links, the disclosure is at http://datatracker.ietf.org/ipr/988/ Personally (no hats being worn - consequent risk of sunstroke) I find the text of the disclosure a little disappointing. As you point out, the reference to "inclusion in a standard" is unclear both for this Informational document, and for any Standards Track document. What if I implement a PS or DS? I also find the lack of references for the "one or more pending unpublished patent applications" unfortunate. The vagueness is such that it might even be the case that it some feature (such as IPSec) that is covered rather than group keying. This leads me to say that I am unable to assess whether it would be harmful to proceed with this document in the light of the disclosure. But I would observe that this is an informational document that does not make any changes to the base protocols. That is, the presence of this document will not require implementations to conform to it. Thus, it is probably safe to proceed with its publication. Adrian > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Gorry Fairhurst > Sent: 23 July 2011 10:45 > To: tsvwg WG > Subject: IPR discussion: draft-ietf-tsvwg-rsvp-security-groupkeying > > > The draft above is now in Last Call, and there needs to now be a > discussion within TSVWG relating to the acceptability of the IPR terms > for this document. > > There is an IPR statement filed: > ID # 988 "Cisco's Statement about IPR claimed in > draft-ietf-tsvwg-rsvp-security-groupkeying-01.txt" > > This seems to provide RAND terms for compliance to a standard, but this > I-D is not being submitted as a standards-track document. The terms in > the IPR declaration do not seem to provide non-assert status for > implementing an Informational document. Please can the WG discuss this? > > * Specifically, do other options exist that would not introduce this IPR > dependence? > > * Have these options been explored? > > * What does the WG recommend? (We can discuss this further in the WG > meeting next week). > > Best wishes, > > Gorry Fairhurst > > TSVWG Chair From ietfc@btconnect.com Sat Jul 23 13:00:53 2011 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 53CAB21F8B53 for ; Sat, 23 Jul 2011 13:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 m8dj3JDQOJ3j for ; Sat, 23 Jul 2011 13:00:52 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by ietfa.amsl.com (Postfix) with ESMTP id EE3F821F8696 for ; Sat, 23 Jul 2011 13:00:51 -0700 (PDT) Received: from host86-174-254-236.range86-174.btcentralplus.com (HELO pc6) ([86.174.254.236]) by c2bthomr10.btconnect.com with SMTP id DUD19806; Sat, 23 Jul 2011 21:00:08 +0100 (BST) Message-ID: <024b01cc496a$53ee7800$4001a8c0@gateway.2wire.net> From: "t.petch" To: , "tsvwg WG" References: <94007F3F05A24CF0AAFA916B42F93E69@davidPC> <4E2A9822.6020201@erg.abdn.ac.uk> Subject: Re: IPR discussion: draft-ietf-tsvwg-rsvp-security-groupkeying Date: Sat, 23 Jul 2011 20:57:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4E2B2848.002C, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.7.23.183914:17:7.586, ip=86.174.254.236, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_1600_1699, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0208.4E2B286A.00A9,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false 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, 23 Jul 2011 20:00:53 -0000 ---- Original Message ----- From: "Gorry Fairhurst" To: "tsvwg WG" Sent: Saturday, July 23, 2011 11:45 AM > > The draft above is now in Last Call, and there needs to now be a > discussion within TSVWG relating to the acceptability of the IPR terms > for this document. > > There is an IPR statement filed: > ID # 988 "Cisco's Statement about IPR claimed in > draft-ietf-tsvwg-rsvp-security-groupkeying-01.txt" > > This seems to provide RAND terms for compliance to a standard, but this > I-D is not being submitted as a standards-track document. The terms in > the IPR declaration do not seem to provide non-assert status for > implementing an Informational document. Please can the WG discuss this? I think that you are reading too much into the IPR claim, which is probably written by a lawyer whose use of terms means what (s)he wants them to mean and has no relationship to their usage by other people such as the IETF. I suggest that the editors of this I-D contact the e-mail addresses in the IPR claim and ask for clarification as the meaning of the word 'standard', whether the term is being using in the IETF sense, and so excluding BCP, Experimental etc of whether it is being used in another sense and so, for example, encompassing any document that the IETF produces as part of the RFC series. Tom Petch > > * Specifically, do other options exist that would not introduce this IPR > dependence? > > * Have these options been explored? > > * What does the WG recommend? (We can discuss this further in the WG > meeting next week). > > Best wishes, > > Gorry Fairhurst > > TSVWG Chair From gorry@erg.abdn.ac.uk Sun Jul 24 11:53:23 2011 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 249F221F8A57 for ; Sun, 24 Jul 2011 11:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.924 X-Spam-Level: X-Spam-Status: No, score=-101.924 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 1HV+3IZlqp+H for ; Sun, 24 Jul 2011 11:53:22 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB0221F893C for ; Sun, 24 Jul 2011 11:53:21 -0700 (PDT) Received: from Gorry.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p6OIqxJE013289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 24 Jul 2011 19:53:01 +0100 (BST) Message-ID: <4E2B1B3A.6060201@erg.abdn.ac.uk> Date: Sat, 23 Jul 2011 20:04:26 +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:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Bob Briscoe , Jukka Manner , tsvwg WG Subject: draft-ietf-tsvwg-byte-pkt-congest -04 (second review) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk 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: Sun, 24 Jul 2011 18:53:23 -0000 I've read this draft again, and have the following additional comments (some of which overlap the comments I sent on 29/03/2011, please can you revise the I-D and issue a revision -05 that includes your responses to these sets of comments and any others that you have received. best wishes, Gorry NiTs: " Fortunately all the RED implementers who responded to our survey (Section 4.2.4) have not followed the earlier advice to use byte-mode drop, so the consensus this memo argues for seems to already exist in implementations." - I mentioned before that the survey was not performed by the IETF, and therefore this should be rephrased so that it can't be interpreted as IETF thought. It could for instance be sufficient to say something like "A survey described in section 4.2.4 concluded..." - It was suggested at the IETF TSVWG meeting in Prague that the survey could be placed in an appendix to clarify that this was a welcome contribution from the authors, rather than an IETF-lead activity. Style: I'd personally prefer "most TCP implementations" to "most TCPs" "But, as we design new congestion controls, we should build in scaling with packet size rather than assuming we should follow TCP's example." - This seems like a "hidden" recommendation. I assume here this is meant to be a statement from the IETF TSVWG, so could the document say that the current recommendation is ... Section 2,1 Corollaries - first in list doe snot have quotes, the second does. Please clarify the term "admin";-) Allowance for packet size is only appropriate when the transport responds to congestion ^ - is it better to insert "the time" before when, so we can see that this does not mean a type of transport that responds (all should). "it is strongly RECOMMENDED that it SHOULD" - this is an inappropriate form of wording, I think the IETF consensus is that "vendors SHOULD". "ever, our survey of" ^^^ - again, recommend the editors change the wording to directly refer to the survey in section XXX. " it seems we can deprecate byte-mode drop" - "it is expected that byte mode drop can be depecrated ..." "as proportionate to the size in octets of the missing or marked packet." - could be useful to add "(bytes)" given that the document speaks a lot about bytes v. packets. Section 3 reads: " In this section, we evaluate the topic of packet vs. byte based congestion notifications and motivate the recommendations given in this document." - I think the section is informative and *ALL* the recommendations are in section 2, if this is correct, it would be really helpful to the reader to be told this. " No matter how convenient it is, we SHOULD NOT hack the network solely to allow for omissions from the design of one transport protocol, even if it is as predominant as TCP." - This doesn't seem to be a standard-stack IETF recommendation. Is the capitilisation correct? To whom is the advice directed to? "the bit rate the RED queue aims to pass to the line will be 750Kbit the bit rate the RED queue aims to pass to the line will be 750Kbit for the flow of larger packet but 990Kbit" - Is this a volume - Kbit or is this a rate - per second? 4.1.2 " because interference increases with the rate at which bits are" - not quite, the effect of interference and/or noise is larger as the rate of transmission increases... The actual interference (if any) does not change. "Turning to our more formal survey (Table 2)," - should probably be rephrased. " We have established that Linux does not implement RED with packet size drop bias, although we have not investigated a wider range of open source code." " This claim seems hard to substantiate, if you refer to a specific release, or say at the time of writing that your survey showed..., it seems hard to make conclusive claims in this space. "Finally, we repeat that RED's byte mode drop SHOULD be disabled, but active queue management such as RED SHOULD be enabled wherever possible" - This repetition of the standards language at the end of section 4 seems necessary, the document could simply have referred back to section 2 for the RFC2119 text. " (BT) has widely deployed RED, but many tail-drop queues are there are bound to still exist, particularly in access network equipment and " - It seems like too many "are"s. "security and policability." ^^^^^^^^^^^^ - is this the intended word? From internet-drafts@ietf.org Mon Jul 25 06:43:40 2011 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 ABFA421F8ABB; Mon, 25 Jul 2011 06:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 KihXwPc++0Ri; Mon, 25 Jul 2011 06:43:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F34A21F8879; Mon, 25 Jul 2011 06:43:40 -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 Subject: I-D Action: draft-ietf-tsvwg-sctp-udp-encaps-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.56 Message-ID: <20110725134340.9168.6327.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2011 06:43:40 -0700 Cc: tsvwg@ietf.org 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, 25 Jul 2011 13:43:40 -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 = Group of the IETF. Title : UDP Encapsulation of SCTP Packets Author(s) : Michael Tuexen Randall R. Stewart Filename : draft-ietf-tsvwg-sctp-udp-encaps-00.txt Pages : 8 Date : 2011-07-25 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-udp-encaps-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-udp-encaps-00.txt From gorry@erg.abdn.ac.uk Tue Jul 26 10:24:47 2011 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 7DBAC21F8BA6 for ; Tue, 26 Jul 2011 10:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.244 X-Spam-Level: X-Spam-Status: No, score=-102.244 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_6CONS_WORD=0.356, 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 f5JgQr0HGxzE for ; Tue, 26 Jul 2011 10:24:47 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id A5B2A21F8B66 for ; Tue, 26 Jul 2011 10:24:45 -0700 (PDT) Received: from ra-gorry.erg.abdn.ac.uk ([IPv6:2001:df8:0:16:5ab0:35ff:fe7b:b828]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p6QHObgS029272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 26 Jul 2011 18:24:38 +0100 (BST) Message-ID: <4E2EF856.3080206@erg.abdn.ac.uk> Date: Tue, 26 Jul 2011 13:24:38 -0400 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:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: tsvwg WG Subject: Progressing: draft-ietf-tsvwg-sctp-strrst-11.txt References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk 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: Tue, 26 Jul 2011 17:24:47 -0000 Concerning stream reset, the last meeting's minutes said: "There appears to be consensus emerging, there needs to be discussion on whether it is viable to have one in-band mechanism. To resolve this, the WG needs to decide, but there needs to be only one mechanism," A wee while ago, I think Randy sent an email request to TSV to ask for suggestions on how a complete in-band mechanism would work. Looking back at the archive, I could not find an answer. Can someone please let me know if they have thought on this, or point me to a contribution - either one of these will help me prepare for Friday's meeting. It would be good to conclude this now people have had time to reflect on whether any issues discovered or new proposals exist. Gorry TSVWG Co-Chair From jmpolk@cisco.com Tue Jul 26 23:01:36 2011 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 CD97721F8782 for ; Tue, 26 Jul 2011 23:01:36 -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 DK-v0n23q+7r for ; Tue, 26 Jul 2011 23:01:36 -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 D902F21F8781 for ; Tue, 26 Jul 2011 23:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=5112; q=dns/txt; s=iport; t=1311746496; x=1312956096; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=UxO5d2aG8iWMtkeGV4XWIcWp39f70CB3x3JwGUlWIgs=; b=gdWeASQ4Jc2go/Lk4wHq7dVK3Gne6HFX+CrNQvtxbb9dOvwEhLYB9yKZ TvlSatubUJHLyzZ8Sh0Qti6EYfhMReRkIkTfIpDaB8oUp7w9vAfo3MJz6 45WP8P+KLvIhDbRjAiZKYbp7gDtZJ+oyi12N9jUNbcK2a5l2XXioz8mbJ 8=; X-IronPort-AV: E=Sophos;i="4.67,274,1309737600"; d="scan'208";a="6800775" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 27 Jul 2011 06:01:35 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-vpn-client-10-89-7-202.cisco.com [10.89.7.202]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6R61Y1U002314; Wed, 27 Jul 2011 06:01:34 GMT Message-Id: <201107270601.p6R61Y1U002314@rcdn-core2-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Jul 2011 01:01:32 -0500 To: Lou Berger , "James M. Polk" From: "James M. Polk" Subject: Re: draft-ietf-tsvwg-intserv-multiple-tspec-00 submitted In-Reply-To: <4E14A909.4090900@labn.net> References: <201107040017.p640HLc0031104@mtv-core-1.cisco.com> <4E14A909.4090900@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: tsvwg 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, 27 Jul 2011 06:01:36 -0000 At 01:27 PM 7/6/2011, Lou Berger wrote: >James, > Since you ask... > >I thought this would be a good time to revive our discussion from March. > As a reminder, here is the salient part of the discussion: > >On 3/18/2011 5:04 PM, James M. Polk wrote: > >> > At 05:46 PM 3/17/2011, Lou Berger wrote: >... > >> >1) a real nit: > >> >I suspect that the RBNF is broken, and > >> >[MULTI_FLOWSPEC] should be [ ] . > > yep, sorry - this is obvious > > > >> > (You might want to add a reference to 5511 too.) > > probably > > > > > >> >2) I could see this as a more generally applicable problem, in > >> >particular it could apply to the non-IntServ class types supported by > >> >RSVP (TSPEC/FLOWSPEC). What do you think about having the MULT_xxSPEC > >> >objects being defined solely on the RSVP level (perhaps using > >> >subobjects) rather than as defined now which is a change to RSVP and > >> >IntServ? > > Hadn't thought about this before. We'll think about how this would > > work and if there are any gotchas. > >Have you had any further thoughts? I think this would have the real >benefit that it can apply to all flowspec types. Lou I've been pondering this since you first sent it. I can't find anyone that thinks this is a bad idea, but I also haven't found anyone that thinks this is a no-brainer either. I mean, the same logic will be needed because the same steps are needed to replace whatever is in the new MULTI_xxSPEC Object you propose. I do have a concern - and that has to do with what to do with the existing MULTI_TSPEC text that has to go somewhere. I mean, is it within this same new draft that creates the MULTI_xxSPEC Object, or are they separate drafts, in which the MULTI_TSPEC is the first offering (in its own draft) for what goes into the MULTI_xxSPEC Object (framework)? We also have an individual draft about a MULTI_PREEMPTION_PRI Object that extends RFC 3181 just as the MULTI_TSPEC extends 2210 (where the TSPEC is defined). Is that to be in another draft, or just one bigger draft since we know it's coming? I'm thinking about the structure of the Object too, and I'm not sure about it. I plan on having this be the basis for what I talk about Friday during the MULTI_TSPEC preso slot. Do others have comments and/or inputs to this idea? James >Lou > >On 7/3/2011 8:17 PM, James M. Polk wrote: > > TSVWG > > > > (with my individual hat on) > > > > We'd like to draw your attention to the newest WG item within TSVWG. > > > > The authors made only a couple of individual modifications from the > > individual version that was approved as a WG item: > > > > - clarified how this extension also extends RFC 4495 (RSVP Bandwidth > > Reduction), and > > - added some text to the security considerations section > > > > The top item has to do with good network hygiene - correcting as soon > > as possible when too much BW was reserved (that is no longer needed) > > within part of a reservation setup. The latter item was directly from > > a review comment. > > > > Both of these we thought we low hanging fruit, so we put them in this > > version. Any further changes needs WG approval in our opinion. > > > > Comments are encouraged and/or requested. > > > > James & Subha > > > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. This draft is a work item of the Transport Area Working > >> Group Working Group of the IETF. > >> > >> Title : Integrated Services (IntServ) Extension > >> to Allow Signaling of Multiple Traffic Specifications and Multiple > >> Flow Specifications in RSVPv1 > >> Author(s) : James Polk > >> Subha Dhesikan > >> Filename : draft-ietf-tsvwg-intserv-multiple-tspec-00.txt > >> Pages : 26 > >> Date : 2011-07-03 > >> > >> This document defines extensions to Integrated Services (IntServ) > >> allowing multiple traffic specifications and multiple flow > >> specifications to be conveyed in the same Resource Reservation > >> Protocol (RSVPv1) reservation message exchange. This ability helps > >> optimize an agreeable bandwidth through a network between endpoints > >> in a single round trip. > >> > >> > >> A URL for this Internet-Draft is: > >> > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-intserv-multiple-tspec-00.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> This Internet-Draft can be retrieved at: > >> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-intserv-multiple-tspec-00.txt > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > From fernando.gont.netbook.win@gmail.com Wed Jul 27 09:44:51 2011 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 92F9D21F8A1A for ; Wed, 27 Jul 2011 09:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.407 X-Spam-Level: X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 xEcnRBmoxdYS for ; Wed, 27 Jul 2011 09:44:51 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 100A321F899F for ; Wed, 27 Jul 2011 09:44:50 -0700 (PDT) Received: by gwb20 with SMTP id 20so1436404gwb.31 for ; Wed, 27 Jul 2011 09:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=3MUcJ3p3tUaPSnr0XfB2iK235fAXsZ0xvNaUQS3Wt+o=; b=Cxf1paC0RkCg/56b+jg30rwW6J5EL6q9TIOkFlVRnnzlZR3zIjT2b7bOXZNtFcHo/5 nzBn41qENrcxFt/MCdVjtHx+U4XnrGWCRpFHUs0LnW/c5oFx4dqll7ScOL9bFKBqxz8F kZfsxMkC4xxnxz70R0XJ3DyuC2IrKs82eS41g= Received: by 10.101.191.6 with SMTP id t6mr21098anp.62.1311785089963; Wed, 27 Jul 2011 09:44:49 -0700 (PDT) Received: from [192.168.123.103] ([190.48.244.208]) by mx.google.com with ESMTPS id j3sm37156anm.47.2011.07.27.09.44.47 (version=SSLv3 cipher=OTHER); Wed, 27 Jul 2011 09:44:49 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E30407A.8030309@gont.com.ar> Date: Wed, 27 Jul 2011 13:44:42 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [tsvwg] #15: draft-ietf-tsvwg-source-quench References: <060.bbabb66384b3d4ace6f432b8cdab1dd4@trac.tools.ietf.org> In-Reply-To: <060.bbabb66384b3d4ace6f432b8cdab1dd4@trac.tools.ietf.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, "Scott O. Bradner" 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, 27 Jul 2011 16:44:51 -0000 Gorry, On 07/27/2011 01:06 PM, tsvwg issue tracker wrote: > #15: draft-ietf-tsvwg-source-quench > > There are RFC2119 words that need to be explained and the possible > exception conditions need to be explained. There are no exception conditions. The wg argued in favour of "SHOULD" (rather than MUST) assuming that since supporting ICMP SQ does not result in interoperability problems, a "MUST" was too strong. However, as noted by Scott Bradner, this is incorrect. There are no exception conditions, and hence we should be using "MUST NOT" rather than "SHOULD NOT". Thoughts? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Wed Jul 27 15:00:26 2011 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 BD3C25E8002; Wed, 27 Jul 2011 15:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, MANGLED_MARKET=2.3, 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 FXmVQb6QTQS2; Wed, 27 Jul 2011 15:00:26 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 5628C5E8001; Wed, 27 Jul 2011 15:00:26 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p6RLxd24000317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Jul 2011 14:59:39 -0700 (PDT) Message-ID: <4E308A4B.4090702@isi.edu> Date: Wed, 27 Jul 2011 14:59:39 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mark Handley Subject: Re: [saag] Fwd: fyi: tcpcrypt draft References: <4DC6C56D.6040709@ieca.com> <20110727184256.GA3690@shorty> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: saag@ietf.org, tsvwg 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, 27 Jul 2011 22:00:26 -0000 Hi, Mark (et al.), I'm cc-ing this to the TSVWG mailing list for the benefit of those attending TSVAREA, where the presentation will occur tomorrow AM. Since this is the second IETF transport presentation (the first was in TCPM at IETF 80), I hope this presentation will clarify how the current tcpcrypt code uses the existing TCP option space. In specific, it appears to use *two* unassigned TCP option codepoints (69 and 70), rather than experimental codepoints (and, IMO, it should use the latter instead). I hope the presentation this time will address the plans to correct the currently deployed code to appropriately use the experimental codepoints. Joe From jmpolk@cisco.com Wed Jul 27 18:22:06 2011 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 E05E911E80B9 for ; Wed, 27 Jul 2011 18:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.914 X-Spam-Level: X-Spam-Status: No, score=-103.914 tagged_above=-999 required=5 tests=[AWL=-1.315, 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 KuA9PM717rPu for ; Wed, 27 Jul 2011 18:22:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCCC11E8084 for ; Wed, 27 Jul 2011 18:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=857; q=dns/txt; s=iport; t=1311816126; x=1313025726; h=message-id:date:to:from:subject:mime-version; bh=z/JIxpn/vGQAxvV4kWpNlk9Sc/QnkgyHXJXbgWSUUxM=; b=hwIUdS19+Y2yjuKA9em5jqiJy49p2xPZ0RvV3i38P44cf6XRzqnjlxHN pwYpQdWbz/T8dknQXW/7bRzTc1AXkDAv7DtC6It/dgdBSxD4wE/c1AGu9 tmC+5fY9BJmzU4eCCxWd4lP/2QIIuGExn5CanRqLfbvWllOWXzS6b4VWF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKW4ME6rRDoH/2dsb2JhbABPASkCXkYkBlIkGqcmd4kAomuBI55PhkAEh1ecHg X-IronPort-AV: E=Sophos;i="4.67,279,1309737600"; d="scan'208";a="7204440" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-6.cisco.com with ESMTP; 28 Jul 2011 01:22:05 +0000 Received: from jmpolk-wxp01.cisco.com ([10.89.10.211]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6S1M4bN002501 for ; Thu, 28 Jul 2011 01:22:05 GMT Message-Id: <201107280122.p6S1M4bN002501@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Jul 2011 20:22:03 -0500 To: tsvwg From: "James M. Polk" Subject: New info about the TSVWG session on Friday morning Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 28 Jul 2011 01:22:07 -0000 TSVWG We need volunteers for Jabber scribe and *TWO* note takers. PLEASE volunteer before I just pick someone, say, - the first and last person in the room or - the two quietest people before the meeting or - the two I like the least in the room... ;-) or a combination of the above. We have a more complete agenda now http://www.ietf.org/proceedings/81/agenda/tsvwg.txt though there are a couple of IDs that may or may not be presented (they are identified on the agenda). Let the agenda bashing begin... We have 161 minutes of presentations - IF THE PRESENTERS DON'T RUN OVER - and only a 150 minute meeting slot. Something has to give, and the chairs haven't decided what yet. Now, it would be nice if every presenter merely took 1 minute less of time. This would be ideal. See you on Friday James & Gorry From touch@isi.edu Thu Jul 28 09:52:22 2011 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 4EB6B21F8AE1 for ; Thu, 28 Jul 2011 09:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.377 X-Spam-Level: X-Spam-Status: No, score=-103.377 tagged_above=-999 required=5 tests=[AWL=-0.778, 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 Yk6cNtdiDF7O for ; Thu, 28 Jul 2011 09:52:21 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 58A3621F89CC for ; Thu, 28 Jul 2011 09:52:21 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p6SGpk6V004309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Jul 2011 09:51:49 -0700 (PDT) Message-ID: <4E3193A2.8010707@isi.edu> Date: Thu, 28 Jul 2011 09:51:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: tsvwg Subject: Fwd: New Version Notification for draft-touch-tsvwg-port-use-01.txt References: <20110728164745.10957.89135.idtracker@ietfa.amsl.com> In-Reply-To: <20110728164745.10957.89135.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110728164745.10957.89135.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu 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, 28 Jul 2011 16:52:22 -0000 FYI. This update includes a few additional bullet points gleaned from emails over the past few months, but remains largely an outline placeholder until the WG decides whether to make it a WG item or not. Joe -------- Original Message -------- Subject: New Version Notification for draft-touch-tsvwg-port-use-01.txt Date: Thu, 28 Jul 2011 09:47:45 -0700 From: internet-drafts@ietf.org To: touch@isi.edu CC: touch@isi.edu A new version of I-D, draft-touch-tsvwg-port-use-01.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Filename: draft-touch-tsvwg-port-use Revision: 01 Title: Recommendations for Transport Port Uses Creation date: 2011-07-28 WG ID: Individual Submission Number of pages: 10 Abstract: This document provides recommendations to application and service designers on how to use the transport protocol port number space to help in its preservation. **NOTE THAT THIS CURRENT VERSION IS LARGELY AN OUTLINE OF ISSUES**. The IETF Secretariat From mark.j.handley@gmail.com Thu Jul 28 10:16:09 2011 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 587F511E80D0; Thu, 28 Jul 2011 10:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Utx5QxOqH4VP; Thu, 28 Jul 2011 10:16:08 -0700 (PDT) Received: from mail-gw0-f43.google.com (mail-gw0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id B92B811E8078; Thu, 28 Jul 2011 10:16:08 -0700 (PDT) Received: by gwm11 with SMTP id 11so3434453gwm.16 for ; Thu, 28 Jul 2011 10:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=jqav7fPVens+K7dQ+SrYaw+6JvZOfaq7cDgSUPF8WDw=; b=dyup/B6pIlr7Lq3lWDmMh0EBD2yeSe8hUK/hC5p11l2HoTIIwjB3fAiPo35c5unHdE a0NAehAeBuHGkj7ebcJHHyFZjwsCDjAOZZEGbJ4Fc9aDBin4K3NB9s1shVcMV4KC4GQV yUiMq/dwaxkFB/2u6iyzEyxtDQQoUaz3EtFbE= Received: by 10.236.115.230 with SMTP id e66mr334317yhh.28.1311873368258; Thu, 28 Jul 2011 10:16:08 -0700 (PDT) MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.236.102.166 with HTTP; Thu, 28 Jul 2011 10:15:48 -0700 (PDT) In-Reply-To: <4E308A4B.4090702@isi.edu> References: <4DC6C56D.6040709@ieca.com> <20110727184256.GA3690@shorty> <4E308A4B.4090702@isi.edu> From: Mark Handley Date: Thu, 28 Jul 2011 13:15:48 -0400 X-Google-Sender-Auth: o57SNIWC6PTa_G54AutTByJkM8Q Message-ID: Subject: Re: [saag] Fwd: fyi: tcpcrypt draft To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: tcpcrypt@scs.stanford.edu, saag@ietf.org, tsvwg 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, 28 Jul 2011 17:16:09 -0000 On 27 July 2011 17:59, Joe Touch wrote: > Since this is the second IETF transport presentation (the first was in TCPM > at IETF 80), I hope this presentation will clarify how the current tcpcrypt > code uses the existing TCP option space. > > In specific, it appears to use *two* unassigned TCP option codepoints (69 > and 70), rather than experimental codepoints (and, IMO, it should use the > latter instead). Hi Joe, You're correct that our code is currently using two unassigned codepoints, and we should not be doing so. I've looked into what we should do, and the problem is that there are deployed products using the two experimental options. We don't wish them to interfere with our experiments, nor do we wish to interfere with their experiments. But using unassigned ports is bad too. I've talked with Wes and David, and we're working on figuring out the least bad solution. Wes will raise the issue with the IESG, and we'll implement whatever they decide is best. - Mark From touch@isi.edu Thu Jul 28 11:05:18 2011 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 BB0A811E80E9; Thu, 28 Jul 2011 11:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.356 X-Spam-Level: X-Spam-Status: No, score=-105.356 tagged_above=-999 required=5 tests=[AWL=1.243, BAYES_00=-2.599, 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 oDYOteDPPCuk; Thu, 28 Jul 2011 11:05:18 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4181911E807B; Thu, 28 Jul 2011 11:05:18 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p6SI4dR6017376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Jul 2011 11:04:39 -0700 (PDT) Message-ID: <4E31A4B7.6010900@isi.edu> Date: Thu, 28 Jul 2011 11:04:39 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mark Handley Subject: Re: [saag] Fwd: fyi: tcpcrypt draft References: <4DC6C56D.6040709@ieca.com> <20110727184256.GA3690@shorty> <4E308A4B.4090702@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpcrypt@scs.stanford.edu, saag@ietf.org, tsvwg 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, 28 Jul 2011 18:05:18 -0000 On 7/28/2011 10:15 AM, Mark Handley wrote: > On 27 July 2011 17:59, Joe Touch wrote: >> Since this is the second IETF transport presentation (the first was in TCPM >> at IETF 80), I hope this presentation will clarify how the current tcpcrypt >> code uses the existing TCP option space. >> >> In specific, it appears to use *two* unassigned TCP option codepoints (69 >> and 70), rather than experimental codepoints (and, IMO, it should use the >> latter instead). > > Hi Joe, > > You're correct that our code is currently using two unassigned > codepoints, and we should not be doing so. I've looked into what we > should do, and the problem is that there are deployed products using > the two experimental options. We don't wish them to interfere with > our experiments, nor do we wish to interfere with their experiments. Hi, Mark, It's hard to understand how these could interfere, since experiments are not supposed to be widely deployed. The only interference would be if theirs were widely deployed *and* yours were too, which means you're both using those codepoints inappropriately. > But using unassigned ports is bad too. I've talked with Wes and > David, and we're working on figuring out the least bad solution. Wes > will raise the issue with the IESG, and we'll implement whatever they > decide is best. AOK. It'd be useful to note this in your talk, IMO. Thanks, Joe From ananth@cisco.com Thu Jul 28 11:41:53 2011 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 864535E801B; Thu, 28 Jul 2011 11:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=-3.425, 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 HmhxHxDzxswO; Thu, 28 Jul 2011 11:41:52 -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 B20F15E801A; Thu, 28 Jul 2011 11:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=2157; q=dns/txt; s=iport; t=1311878513; x=1313088113; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=j3m8ZFQYIFJkxo4Zy66jOTOW0fSqOoI+V5g5V2BG8E8=; b=WLlCeMCEBYlI60nZTZREiPM9Q30b2YYf+LCYekHOSGeTMNgO5tmsdU57 ylJeJPovf8c57XhW1nqvJkpjIf4psv2Q1VogIp9Eow7v5KHeII3BqrY3S 2j9YRzGSbDJ6FYs1hdwz2Vspjz8yrPg5QuG5klnpQdJAupQO/1EnoThe5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUAANmsMU6rRDoH/2dsb2JhbAA0AQEBAQMUASEKRQwFAgEJEQQBAQEKBiMBBgETOw4IAQEDAgEWDBQHl2uPT3etdJ4/hWJfBIdZkDCLHVc X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="scan'208";a="7491411" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-9.cisco.com with ESMTP; 28 Jul 2011 18:41:51 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6SIfmKL006187; Thu, 28 Jul 2011 18:41:51 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 11:41:46 -0700 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 Subject: RE: [saag] Fwd: fyi: tcpcrypt draft Date: Thu, 28 Jul 2011 11:41:45 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580D482D56@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4E31A4B7.6010900@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Fwd: fyi: tcpcrypt draft Thread-Index: AcxNUPlP6zUQn3zuSZWdt6KFh754WQABKVbg References: <4DC6C56D.6040709@ieca.com><20110727184256.GA3690@shorty><4E308A4B.4090702@isi.edu> <4E31A4B7.6010900@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , "Mark Handley" X-OriginalArrivalTime: 28 Jul 2011 18:41:46.0252 (UTC) FILETIME=[00C7C4C0:01CC4D56] Cc: tcpcrypt@scs.stanford.edu, saag@ietf.org, tsvwg 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, 28 Jul 2011 18:41:53 -0000 Is there any consideration to allocate more code points for TCP experimental usage? With the increasing number of experimental TCP drafts (some of which uses TCP options), it would be useful thing to extend the experimental TCP option space. Wondering whether this has been brought up before? -Anantha > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf > Of Joe Touch > Sent: Thursday, July 28, 2011 11:05 AM > To: Mark Handley > Cc: tcpcrypt@scs.stanford.edu; saag@ietf.org; tsvwg > Subject: Re: [saag] Fwd: fyi: tcpcrypt draft >=20 >=20 >=20 > On 7/28/2011 10:15 AM, Mark Handley wrote: > > On 27 July 2011 17:59, Joe Touch wrote: > >> Since this is the second IETF transport presentation (the first was > in TCPM > >> at IETF 80), I hope this presentation will clarify how the current > tcpcrypt > >> code uses the existing TCP option space. > >> > >> In specific, it appears to use *two* unassigned TCP option > codepoints (69 > >> and 70), rather than experimental codepoints (and, IMO, it should > use the > >> latter instead). > > > > Hi Joe, > > > > You're correct that our code is currently using two unassigned > > codepoints, and we should not be doing so. I've looked into what we > > should do, and the problem is that there are deployed products using > > the two experimental options. We don't wish them to interfere with > > our experiments, nor do we wish to interfere with their experiments. >=20 > Hi, Mark, >=20 > It's hard to understand how these could interfere, since experiments > are > not supposed to be widely deployed. The only interference would be if > theirs were widely deployed *and* yours were too, which means you're > both using those codepoints inappropriately. >=20 > > But using unassigned ports is bad too. I've talked with Wes and > > David, and we're working on figuring out the least bad solution. Wes > > will raise the issue with the IESG, and we'll implement whatever they > > decide is best. >=20 > AOK. It'd be useful to note this in your talk, IMO. >=20 > Thanks, >=20 > Joe From touch@isi.edu Thu Jul 28 11:52:54 2011 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 92CFC11E80E0; Thu, 28 Jul 2011 11:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.389 X-Spam-Level: X-Spam-Status: No, score=-103.389 tagged_above=-999 required=5 tests=[AWL=-0.790, 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 M8bNmGx-Zuyu; Thu, 28 Jul 2011 11:52:54 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 3F17A5E801D; Thu, 28 Jul 2011 11:52:50 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p6SIqJxL026804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Jul 2011 11:52:19 -0700 (PDT) Message-ID: <4E31AFE3.8090706@isi.edu> Date: Thu, 28 Jul 2011 11:52:19 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [saag] Fwd: fyi: tcpcrypt draft References: <4DC6C56D.6040709@ieca.com><20110727184256.GA3690@shorty><4E308A4B.4090702@isi.edu> <4E31A4B7.6010900@isi.edu> <0C53DCFB700D144284A584F54711EC580D482D56@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580D482D56@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpcrypt@scs.stanford.edu, saag@ietf.org, Mark Handley , tsvwg 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, 28 Jul 2011 18:52:54 -0000 Hi, Anantha, On 7/28/2011 11:41 AM, Anantha Ramaiah (ananth) wrote: > Is there any consideration to allocate more code points for TCP > experimental usage? With the increasing number of experimental TCP > drafts (some of which uses TCP options), it would be useful thing to > extend the experimental TCP option space. Wondering whether this has > been brought up before? It has. In principle, the entire space can be used of the code is *ensured* to never leave the lab; these codepoints were assigned for safety. IMO, nobody should EVER use an experimental codepoint without including a nonce that can be used to identify their use of that codepoint; that would prevent interference if (when) accidental deployment occurs. Systems that intend to be widely deployed should get assigned codepoints, period. I personally think that posting code on a website for public use that includes experimental codepoints MUST NOT be tolerated (yes, that means that tcpcrypt code *needs* be taken down until this is resolved). Joe >> -----Original Message----- >> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf >> Of Joe Touch >> Sent: Thursday, July 28, 2011 11:05 AM >> To: Mark Handley >> Cc: tcpcrypt@scs.stanford.edu; saag@ietf.org; tsvwg >> Subject: Re: [saag] Fwd: fyi: tcpcrypt draft >> >> >> >> On 7/28/2011 10:15 AM, Mark Handley wrote: >>> On 27 July 2011 17:59, Joe Touch wrote: >>>> Since this is the second IETF transport presentation (the first was >> in TCPM >>>> at IETF 80), I hope this presentation will clarify how the current >> tcpcrypt >>>> code uses the existing TCP option space. >>>> >>>> In specific, it appears to use *two* unassigned TCP option >> codepoints (69 >>>> and 70), rather than experimental codepoints (and, IMO, it should >> use the >>>> latter instead). >>> >>> Hi Joe, >>> >>> You're correct that our code is currently using two unassigned >>> codepoints, and we should not be doing so. I've looked into what we >>> should do, and the problem is that there are deployed products using >>> the two experimental options. We don't wish them to interfere with >>> our experiments, nor do we wish to interfere with their experiments. >> >> Hi, Mark, >> >> It's hard to understand how these could interfere, since experiments >> are >> not supposed to be widely deployed. The only interference would be if >> theirs were widely deployed *and* yours were too, which means you're >> both using those codepoints inappropriately. >> >>> But using unassigned ports is bad too. I've talked with Wes and >>> David, and we're working on figuring out the least bad solution. > Wes >>> will raise the issue with the IESG, and we'll implement whatever > they >>> decide is best. >> >> AOK. It'd be useful to note this in your talk, IMO. >> >> Thanks, >> >> Joe From gorry@erg.abdn.ac.uk Thu Jul 28 12:46:24 2011 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 08D9E11E8113 for ; Thu, 28 Jul 2011 12:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 IHZR1wzVE4wX for ; Thu, 28 Jul 2011 12:46:23 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC8311E80F0 for ; Thu, 28 Jul 2011 12:46:22 -0700 (PDT) Received: from ra-gorry.erg.abdn.ac.uk ([IPv6:2001:df8:0:16:5ab0:35ff:fe7b:b828]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p6SJkFgx015306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 28 Jul 2011 20:46:16 +0100 (BST) Message-ID: <4E31BC88.1090406@erg.abdn.ac.uk> Date: Thu, 28 Jul 2011 15:46:16 -0400 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:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: tsvwg WG Subject: TSVWG presenters at IETF-81, Friday 9:00am Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk 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: Thu, 28 Jul 2011 19:46:24 -0000 If you think you have an Agenda slot please read the rest: 1) Please do provide copies of your slides as soon as possible. We need the slides in advance of the meeting to let remote participants upload them. 2) We do not currently have a spare PC - so if you are presenting, please be ready to bring your computer to the front to connect to the projector. Thanks Gorry and James. P.S. If anyone would be willing to volunteer a computer to connect for the whole of the session that would be great!!! Do send an email to the chairs! From jmpolk@cisco.com Thu Jul 28 22:00:03 2011 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 4C52721F886A for ; Thu, 28 Jul 2011 22:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.866 X-Spam-Level: X-Spam-Status: No, score=-103.866 tagged_above=-999 required=5 tests=[AWL=-1.267, 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 sYjduNC033GS for ; Thu, 28 Jul 2011 22:00:02 -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 5D97E21F8867 for ; Thu, 28 Jul 2011 22:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=116; q=dns/txt; s=iport; t=1311915602; x=1313125202; h=message-id:date:to:from:subject:mime-version; bh=pHAoD5PqdStJs9q4+Mjml/5KkBiu+uGbZ8AlfDhQT8c=; b=JHtMWGMgabiRQEANmg0PGap9Xp1b2ARRPDnHfSzueq/Z/CSIXRTgdGQY eW652srzjcjPrP2VtDSDXp0Xk+lZMpzo/bN/UwlALlUj36LNKD7AyU/74 7VnP08yk56Y+GzDsfhHXwDk0SdivV1D/9FgoJO5LFDSl3Kh/AaAjY+ecS c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANE8Mk6rRDoI/2dsb2JhbAAyHwEpAl5GJAZSJBqnOHeIdgqhEIEjnkGGQQSHWpwh X-IronPort-AV: E=Sophos;i="4.67,286,1309737600"; d="scan'208";a="7648745" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jul 2011 05:00:01 +0000 Received: from jmpolk-wxp01.cisco.com ([10.89.13.203]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6T500x6001964 for ; Fri, 29 Jul 2011 05:00:00 GMT Message-Id: <201107290500.p6T500x6001964@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Jul 2011 23:59:58 -0500 To: tsvwg From: "James M. Polk" Subject: Slightly updated TSVWG agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 29 Jul 2011 05:00:03 -0000 Please see a slightly updated agenda here http://www.ietf.org/proceedings/81/agenda/tsvwg.txt James & Gorry From randall@lakerest.net Fri Jul 29 05:27:58 2011 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 5972021F88A5 for ; Fri, 29 Jul 2011 05:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, SARE_SUB_6CONS_WORD=0.356] 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 XkrDH4x61sNm for ; Fri, 29 Jul 2011 05:27:57 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by ietfa.amsl.com (Postfix) with ESMTP id D809C21F87BC for ; Fri, 29 Jul 2011 05:27:56 -0700 (PDT) Received: from dhcp-578f.meeting.ietf.org (dhcp-578f.meeting.ietf.org [130.129.87.143]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id p6TCRo7t080538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Jul 2011 08:27:51 -0400 (EDT) (envelope-from randall@lakerest.net) Subject: Re: I-D Action: draft-ietf-tsvwg-sctp-strrst-10.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Randy Stewart X-Priority: 3 In-Reply-To: <008e01cc3666$1b8d2220$4001a8c0@gateway.2wire.net> Date: Fri, 29 Jul 2011 08:27:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <193C0C0D-EA43-4C64-943A-600D0400525F@lakerest.net> References: <20110626102951.11992.17163.idtracker@ietfa.amsl.com> <008e01cc3666$1b8d2220$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1084) Cc: =?iso-8859-1?Q?Michael_T=FCxen?= , tsvwg list 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, 29 Jul 2011 12:27:58 -0000 Tom: Ok after sitting with Michael here, in the TSVWG meeting room, I see = what happened here... you did not see my "else" clause or it was not clear = enough. So to make it more clear I have changed the text to be as follows: Otherwise process the Incoming SSN Reset Request Parameter normally = responding to the peer with an acknowledgment. Note that this case includes the = situation where some of the streams requested overlap with the jsut sent Outgoing SSN = Reset Request.=20 Even in such a situation the Incoming SSN Reset MUST be processed = normally even though this means that (if the endpoint elects to do the stream reset) = streams that are already at SSN 0, will be reset a subsequent time. On Jun 29, 2011, at 10:08 AM, t.petch wrote: > There are still some quirks of spelling, some old, some new, and I = think that > the race And as to the "quirks" of spelling.. could you please be more specific.. = or as Scott would say... "send text"! Thanks R > condition is still not wholy covered in 5.2.3. I am thinking of a = case where > the > Incoming SSN Reset Request Parameter specifies eg streams 2 and 3 = while the > Outgoing > SSN Reset Request Parameter specifies eg streams 1 and 2. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Michael T=FCxen" > To: "Randy Stewart" > Cc: "tsvwg list" > Sent: Sunday, June 26, 2011 1:11 PM > Subject: Re: I-D Action: draft-ietf-tsvwg-sctp-strrst-10.txt >=20 >=20 > On Jun 26, 2011, at 12:55 PM, Randy Stewart wrote: >=20 >> This submission has all the previous comment .. not to many I think.. > These issues are not yet resolved, but on my ToDo list: > * Address Geavins comments. > * Add incoming streams request parameters. >=20 > These were the points brought up during LC, which I know hoe to = address. > And the out-of-band vs. in-band discussion, which is still open. >=20 > Best regards > Michael >>=20 >> It was about to expire so I thought it best to update (especially = since >> my affiliation has changed ;-) >>=20 >> Still unresolved is the out-of-band vs in-band idea... again >> I don't see how you do this totally inband.. >>=20 >> R >> On Jun 26, 2011, at 6:29 AM, Internet-Drafts@ietf.org wrote: >>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Transport Area Working = Group > Working Group of the IETF. >>>=20 >>> Title : Stream Control Transmission Protocol (SCTP) Stream > Reconfiguration >>> Author(s) : Randall R. Stewart >>> Peter Lei >>> Michael Tuexen >>> Filename : draft-ietf-tsvwg-sctp-strrst-10.txt >>> Pages : 31 >>> Date : 2011-06-26 >>>=20 >>> Many applications that use SCTP want the ability to = "reset" a > stream. >>> The intention of resetting a stream is to set the numbering sequence >>> of the stream back to 'zero' with a corresponding = notification to > the >>> upper layer that this has been performed. The applications that = want >>> this feature want it so that they can "re-use" streams for > different >>> purposes but still utilize the stream sequence number so that the >>> application can track the message flows. Thus, without this = feature, >>> a new use of an old stream would result in message numbers greater >>> than expected unless there is a protocol mechanism to "reset = the >>> streams back to zero". This document also includes methods for >>> resetting the transport sequence numbers, adding additional streams >>> and resetting all stream sequence numbers. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-10.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> This Internet-Draft can be retrieved at: >>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-10.txt >>>=20 >>=20 >> ----- >> Randall Stewart >> randall@lakerest.net >>=20 >>=20 >>=20 >>=20 >>=20 >=20 ----- Randall Stewart randall@lakerest.net From fred@cisco.com Sat Jul 30 21:35:49 2011 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 1381311E8079 for ; Sat, 30 Jul 2011 21:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.009 X-Spam-Level: X-Spam-Status: No, score=-103.009 tagged_above=-999 required=5 tests=[AWL=-0.410, 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 pzpKtjIeyvuZ for ; Sat, 30 Jul 2011 21:35: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 9B6AF21F86EA for ; Sat, 30 Jul 2011 21:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=8926; q=dns/txt; s=iport; t=1312086947; x=1313296547; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=FqLiZiR7lcyYs/lj6EatWMJD4bV7k/njta2ieLpdnzk=; b=bzXrjvUfUa1HeGf0ghNH+ZV4xnwHoDTeLmFf/FeJLLUr+L/KREqk5n3d BhgYllxYw0KlydszYV3zgh7yd8HeZA82Fd0j4rgvouInDmA6qJ+Lfged0 LDHF+TgTEpcpadOk6AaiXVGr0BvQjLG+luN2BqZ1aoSctF5EcZ9oP8X4T 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAODaNE6rRDoJ/2dsb2JhbABBp2R3gUABAQEBAgESASc6BQULCxgVGVcGLAmHSqFxAZ0ugzeCLF8Eh1qLIYUHi30 X-IronPort-AV: E=Sophos;i="4.67,294,1309737600"; d="scan'208";a="8147330" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2011 04:35:46 +0000 Received: from Freds-Computer.local (sjc-vpn6-30.cisco.com [10.21.120.30]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6V4Zj1t020385; Sun, 31 Jul 2011 04:35:45 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sat, 30 Jul 2011 21:35:45 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Sat, 30 Jul 2011 21:35:45 -0700 Subject: Re: Review draft-ietf-tsvwg-byte-pkt-congest-04 ? Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <201107290734.p6T7Ymk1025025@bagheera.jungle.bt.co.uk> Date: Sat, 30 Jul 2011 21:35:35 -0700 Message-Id: <36A3BFC5-889D-4470-88BE-36D6E8758AF5@cisco.com> References: <201107290734.p6T7Ymk1025025@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: tsvwg list 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, 31 Jul 2011 04:35:49 -0000 On Jul 28, 2011, at 11:14 PM, Bob Briscoe wrote: > Would you be willing to review this, now it is well-baked? >=20 > It had wide review earlier in its life, but only 2 or 3 reviews since = we reorganised it to make it easier to read (hopefully). Sure Bob. > Abstract >=20 > This memo concerns dropping or marking packets using active queue > management (AQM) such as random early detection (RED) or pre- > congestion notification (PCN). This sentence seems to mix apples and orangutans. RED is an AQM = procedure, meaning that it decides by some mechanism what packets to do = something to with a view to active queue management. The structure of = the sentence would suggest that PCN is also an AQM procedure. I'll argue = that either the AQM procedure uses dropping and/or PCN for signaling or = the drop/mark mechanism uses AQM to decide what do affect and the = signaling procedure to comminicate. While they both (RED/AQM and PCN, as = well as dropping) merit mention in the abstract, I wouldn't put them = parallel in the sentence. You can't really say "I think I'll turn off = RED and turn on PCN". > We give three strong recommendations: > (1) packet size should be taken into account when transports read > 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. Wow. Before I go into the draft itself, let me comment on how I have = historically come down on Van and Sally's debate here.=20 If one is dropping traffic to signal congestion, the only loss that TCP = or SCTP is cognizant of in that sense is the loss of data packets. = Dropping a SYN, SYN-ACK, INIT, or whatever prevents a session from = opening, dropping a FIN/RST/etc prevents it from closing, and dropping = an ACK delays a signal releasing state in the transport and potentially = triggering new transmissions. None of those have anything to do with the = congestion window. Hence, if I could understand TCP traffic in the place = that queues are managed (which I often cannot - the data is encrypted, = or I'm on another card that simply doesn't have that visibility) I would = restrict congestion-management signals in the form of loss to data = segments. Ditto if someone is marking TCP/SCTP traffic; ECN depends on a signal = returning on data packets, and as a result is primarily implemented (by = TCP) in data packets. One could argue that I could learn CE from an Ack = or whatever, but I'm not sure why I would bother, as communicating it = back requires saving it somewhere as opposed to simply including it in a = reply I'm going to send anyway. The question of doing it on bytes vs packets was never, to my knowledge, = about preventing the loss of small packets. It was about working = effectively with TCP's congestion control mechanisms and managing router = resources. Van wanted us to integrate packet depth because router = resources were measured in buffers, which are the same size regardless = of how much data they contain (in some implementations), and Sally = wanted it on bytes because that was a reasonable heuristic for = identifying data segments, which interact better with TCP's mechanisms.=20= Having for 30+ years worked on equipment that was able to chain = relatively small buffers to store a larger message, Van's argument has = always seemed incomplete to me, and Sally's makes sense mechanistically. = So I have generally come down on the side of bytes... But, whatever. On to your document... I have dropped your entire document into my mail window. Text I don't = have a problem with I will simply hack out, copying back text I have = questions about. I assume that you can find it in the document by the = markers I leave behind or by common search functions. I'm not going to = say "[snip]"... > 1. Introduction > When notifying congestion, the problem of how (and whether) to take ^...the participants in a session of the onset of... > packet sizes into account has exercised the minds of researchers = and > practitioners for as long as active queue management (AQM) has been > discussed. Indeed, one reason AQM was originally introduced was to > reduce the lock-out effects that small packets can have on large > packets in drop-tail queues. True, but I'll note that large packets can have a lock-out effect on = small packets as well. RFCs 896 and 970, at least, worried about small = packets not because there were so many of them, but because they implied = the presence of additional IP and TCP headers and as a result relatively = inefficient use of the line. > The byte vs. packet dilemma arises at three stages in the = congestion > notification process: >=20 > Measuring congestion: When the congested resource decides locally = to > measure how congested it is, should the queue measure its length > in bytes or packets? >=20 > Encoding congestion notification into the wire protocol: When the > congested network resource decides whether to notify the level = of > congestion by dropping or marking a particular packet, should = its > decision depend on the byte-size of the particular packet being > dropped or marked? >=20 > Decoding congestion notification from the wire protocol: When the > transport interprets the notification in order to decide how = much > to respond to congestion, should it take into account the byte- > size of each missing or marked packet? >=20 > Consensus has emerged over the years concerning the first stage: > whether queues are measured in bytes or packets, termed byte-mode > queue measurement or packet-mode queue measurement. This memo > records this consensus in the RFC Series. In summary the choice > solely depends on whether the resource is congested by bytes or > packets. If you're recording a consensus for posterity, I think it needs to be = more clearly stated. Do you mean "the consensus is that both choices are = viable; the implementor or operator should choose to measure whatever is = congesting his links"? I personally don't hear a clear statement here = about (1). > The controversy is mainly around the last two stages: whether to > allow for the size of the specific packet notifying congestion i) > when the network encodes or ii) when the transport decodes the > congestion notification. ... > The primary purpose of this memo is to build a definitive consensus > against deliberate preferential treatment for small packets in AQM > algorithms and to record this advice within the RFC series. It > recommends that (1) packet size should be taken into account when > transports read congestion indications, (2) not when network > equipment writes them. I have read the rest of the paper, but let me stop here and make some = generalizations. First, I expected to find some data or pointers to data. There are in = fact some pointers to other documents. The vast majority of the = statements in the document that might be supported by data appear to say = "80% of those we might have expected to respond didn't, but..." or = something like that. I'd be a lot happier with statements of the form = "we ran a test..." or "we were able to construct a proof that the = mathematics tells us..." Second, I disagree with the argument about a "perverse favoring of small = packets". At least in implementations I'm familiar with, the policy = isn't "drop only large packets"; it's "make the drop probability of a = packet proportional to the ratio of its size to the bit rate of the = link". If all packets are 9000 bytes and you're on an STM-4 link, the = drop probability of a packet is proportional to (8*9000)/622000000. If = all packets are 64 bytes, the drop probability of any given packet is = proportional to (8*64)/622000000, which is smaller, but there are = 9000/64 times as many to choose from. Any given bit on the wire has the = same probability of being contained in a packet that got lost. On the = other hand, if packets are variable in size and you're keying off packet = depth, a bit on the wire that is contained in a small packet has a much = greater proportional probability of being tagged than one in a large = packet. I don't see that one is incented to send small packets; if the = probability that a given bit gets lost is the same regardless of size, = it seems to me that it takes size out of the discussion. I'll go back and read the paper again a couple of times before = commenting further.=