From ananth@cisco.com Fri Apr 1 01:05:43 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C5E028C0E9 for ; Fri, 1 Apr 2011 01:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.32 X-Spam-Level: X-Spam-Status: No, score=-11.32 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCUX1eKeUUk9 for ; Fri, 1 Apr 2011 01:05:40 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 27CC63A6B25 for ; Fri, 1 Apr 2011 01:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=2836; q=dns/txt; s=iport; t=1301645240; x=1302854840; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=WIvTgqrm/sPu4V1zPfHJJsqJEKALvmwBk6n5Sy4WxYs=; b=VXPtrF3Xg5dxGbyA0cDOW8X01mCKf2YoUPuruz1bvGbTtj8O4fk059Ck InCc0t2STUDmXDTbRiWU6TllqujI9kNx2iqaNKBJDLdgnWkpHaeqKz5jl G7ctm6Ts+1kXwAwJJMh+YiaU5+LUv6lkzT2iM6pshE2dcFT87Y8DIdWKt 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAAmHlU2rRDoJ/2dsb2JhbACYHo09d6Q8nDmFawSFRIs2gyo X-IronPort-AV: E=Sophos;i="4.63,281,1299456000"; d="scan'208";a="287176699" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 01 Apr 2011 08:07:20 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3187KRd008210; Fri, 1 Apr 2011 08:07:20 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); Fri, 1 Apr 2011 01:07:19 -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: Content for deprecating source-quench Date: Fri, 1 Apr 2011 01:07:17 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580C56D2DE@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Content for deprecating source-quench Thread-Index: Acvvyw7W0u55yJ/YSryUi2oT0pG8ygAdjXuA References: <201103310733.p2V7XfNH022948@bagheera.jungle.bt.co.uk><4D94730E.8050104@gont.com.ar><201103311647.p2VGld01025257@bagheera.jungle.bt.co.uk> From: "Anantha Ramaiah (ananth)" To: "Fernando Gont" , "Bob Briscoe" X-OriginalArrivalTime: 01 Apr 2011 08:07:19.0929 (UTC) FILETIME=[D2BD5690:01CBF043] X-Mailman-Approved-At: Fri, 01 Apr 2011 01:25:04 -0700 Cc: tsvwg IETF list , draft-ietf-tsvwg-source-quench@tools.ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:05:43 -0000 Fernando, > -----Original Message----- > From: fernando.gont.netbook@gmail.com > [mailto:fernando.gont.netbook@gmail.com] On Behalf Of Fernando Gont > Sent: Thursday, March 31, 2011 10:43 AM > To: Bob Briscoe > Cc: Anantha Ramaiah (ananth); tsvwg IETF list; draft-ietf-tsvwg-source- > quench@tools.ietf.org; fernando@gont.com.ar > Subject: Re: Content for deprecating source-quench >=20 > On Thu, Mar 31, 2011 at 1:47 PM, Bob Briscoe > wrote: > > > > Personally I think, if an RFC is going to deprecate something, it > needs to > > say why. >=20 > I fully agree. The current doc is what it is because at the time the > idea of formally deprecating ICMP SQ originated, folks argued that a > kinda a single page document would do. That's it. But I do agree with > your view. >=20 >=20 > > Referencing an email archive is a bad idea. >=20 > Yes. I just asked which option would make you happier. :-) Unless > somebody yells, I'll incorporate this in the current Section 2 of the > I-D. Well, I would do both. i.e, add some text which enumerates the reasons of deprecating SQ. Also add the reference. That said, I did briefly go through the email archive pointed by Bob, but I am afraid I don't necessarily agree with some of the assertions that email has made :- a) "IPsec and tunneling" :- how different is it for any other for any other ICMP message. For example ICMP PTB messages? Also, it needs to be noted that most stacks do check the sanity of incoming ICMP messages (as described by RFC 5927). So the robustness worries can be alleviated with such checks. b) "ICMP packet creation is normally (always) implemented on the ingress interface of a router. Congestion is detected on the egress, where it is too late, and too expensive wrt. critical processing time, to trigger the creation of an ICMP packet, without hugely re-working the implementation architecture of most routers." This is again not true, even when you are forwarding to the outgoing link, you need to check with the MTU and if it needs fragmentation and DF bit is on, an ICMP PTB message would get sent. So the SQ case is no different where you can consult the outgoing link properties (queues, QOS etc.,) and generate the ICMP back. (it can be ingress or egress feature or both) There are other reasons which seem to point to some other RFC etc., but I haven't had a chance to read them, so, at a first glance the reasons of deprecating seem dubious or atleast this falls into the category of "what might have been valid 15 years back, is no longer true, things have changed" I am not saying that SQ should not be be deprecated, but this it time to probably dig up history, validate it and share the results in the document. -Anantha >=20 > Thanks! > Fernando From bob.briscoe@bt.com Fri Apr 1 02:23:37 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D17A3A67AB for ; Fri, 1 Apr 2011 02:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8NNsDncGw23 for ; Fri, 1 Apr 2011 02:23:36 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 97B023A6774 for ; Fri, 1 Apr 2011 02:23:36 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 10:25:16 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 10:25:16 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1301649914666; Fri, 1 Apr 2011 10:25:14 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.193.101]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p319PCIP028431; Fri, 1 Apr 2011 10:25:12 +0100 Message-Id: <201104010925.p319PCIP028431@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 Apr 2011 10:25:12 +0100 To: "Anantha Ramaiah (ananth)" From: Bob Briscoe Subject: RE: Content for deprecating source-quench In-Reply-To: <0C53DCFB700D144284A584F54711EC580C56D2DE@xmb-sjc-21c.amer. cisco.com> References: <201103310733.p2V7XfNH022948@bagheera.jungle.bt.co.uk> <4D94730E.8050104@gont.com.ar> <201103311647.p2VGld01025257@bagheera.jungle.bt.co.uk> <0C53DCFB700D144284A584F54711EC580C56D2DE@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 01 Apr 2011 09:25:16.0202 (UTC) FILETIME=[B603F8A0:01CBF04E] Cc: draft-ietf-tsvwg-source-quench@tools.ietf.org, Fernando Gont , tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:23:37 -0000 Anantha, At 09:07 01/04/2011, Anantha Ramaiah (ananth) wrote: >Fernando, > > > -----Original Message----- > > From: fernando.gont.netbook@gmail.com > > [mailto:fernando.gont.netbook@gmail.com] On Behalf Of Fernando Gont > > Sent: Thursday, March 31, 2011 10:43 AM > > To: Bob Briscoe > > Cc: Anantha Ramaiah (ananth); tsvwg IETF list; >draft-ietf-tsvwg-source- > > quench@tools.ietf.org; fernando@gont.com.ar > > Subject: Re: Content for deprecating source-quench > > > > On Thu, Mar 31, 2011 at 1:47 PM, Bob Briscoe > > wrote: snip >That said, I did briefly go through the email archive pointed by Bob, >but I am afraid I don't necessarily agree with some of the assertions >that email has made :- > >a) "IPsec and tunneling" :- how different is it for any other for any >other ICMP message. For example ICMP PTB messages? > >Also, it needs to be noted that most stacks do check the sanity of >incoming ICMP messages (as described by RFC 5927). So the robustness >worries can be alleviated with such checks. The difference is that for some ICMP messages it's not a show-stopper if they can't get back. But for congestion control "most stacks" isn't good enough. >b) "ICMP packet creation is normally (always) implemented on the ingress >interface of a router. Congestion is detected on the egress, where it is >too late, and too expensive wrt. critical processing time, to trigger >the creation of an ICMP packet, without hugely re-working the >implementation architecture of most routers." > >This is again not true, even when you are forwarding to the outgoing >link, you need to check with the MTU and if it needs fragmentation and >DF bit is on, an ICMP PTB message would get sent. So the SQ case is no >different where you can consult the outgoing link properties (queues, >QOS etc.,) and generate the ICMP back. (it can be ingress or egress >feature or both) > >There are other reasons which seem to point to some other RFC etc., but >I haven't had a chance to read them, so, at a first glance the reasons >of deprecating seem dubious or atleast this falls into the category of >"what might have been valid 15 years back, is no longer true, things >have changed" > >I am not saying that SQ should not be be deprecated, but this it time to >probably dig up history, validate it and share the results in the >document. I agree - I posted that list in 2006, as a copy and paste from a tech note I had written in 2000, which in turn was based (in some cases) on info Jon gave me which could have been based on reasons valid even earlier. They certainly should not just be forwarded from /dev/history to /dev/standards-track without going through /dev/brain. Bob >-Anantha > > > > Thanks! > > Fernando ________________________________________________________________ Bob Briscoe, BT Innovate & Design From ka-cheong.poon@oracle.com Sun Apr 3 22:39:13 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 901343A68C8 for ; Sun, 3 Apr 2011 22:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.031 X-Spam-Level: X-Spam-Status: No, score=-6.031 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4KkX00Y1mbw for ; Sun, 3 Apr 2011 22:39:11 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 4D9033A67EF for ; Sun, 3 Apr 2011 22:39:10 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p345eo7x011515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 4 Apr 2011 05:40:52 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p345eofu023162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 Apr 2011 05:40:50 GMT Received: from abhmt008.oracle.com (abhmt008.oracle.com [141.146.116.17]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p345endf016955 for ; Mon, 4 Apr 2011 00:40:49 -0500 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 03 Apr 2011 22:40:49 -0700 Message-ID: <4D9959DE.60507@oracle.com> Date: Mon, 04 Apr 2011 13:40:46 +0800 From: Kacheong Poon User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.15) Gecko/20110304 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: tsvwg Subject: Re: New Version Notification for draft-stewart-tsvwg-reconfuse-sctp-00 References: <20110329152523.C5C753A6927@core3.amsl.com> <663F18AA-9878-4A5F-856D-AB1CCEE0D955@lakerest.net> <4D9443E2.6050208@oracle.com> <88B43C20-C843-4B51-81B4-B34548CB7C89@lakerest.net> In-Reply-To: <88B43C20-C843-4B51-81B4-B34548CB7C89@lakerest.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4D9959E2.0159:SCFSTAT5015188,ss=1,fgs=0 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 05:39:14 -0000 On 03/31/11 07:36 PM, Randy Stewart wrote: > Here I think we must agree to disagree and from the list I think > you are alone here. Most everyone else is supportive of the idea of > reseting a stream as well as adding. I will let the chairs of course > be the judge of consensus... I think this needs to be put in perspective. What I've heard so far is that app writers using SCTP does not think that having SSN reset is a problem. If I am an app writer and you ask me this question whether having SSN reset in SCTP is a problem from app writing point of view, my answer will also be "there is no problem." But this is TSVWG, we must also check the proposal from the transport layer point of view. This is what I think is lacking in the discussion so far. And this is definitely lacking in the current draft. The only point raised from the transport layer point of view I've read is from Tom Petch. It is about "unknotting" some network problem. And this is still being discussed. > I think the big question is the in-band/out-ofband one. The > rest of the stuff I think has rough consensus (but of course thats > my opinion). > > The big question for the in-band proponents is can we come up with an > alternative mechanism that adds a stream that is NOT out-of-band. If so > then I think its a possible option.. However if you still must implement > two mechanism's then I think an out-of-band mechanism is the best approach > (only one method ;-D) If this is one supporting argument that TSN/SSN reset should be bundled with stream addition in the same draft, I'd say that it is then better for us to create an in-band mechanism for stream addition. Michael mentioned some difficulties. But I guess we can work on how to solve them. Brian Bidulock may already have some ideas. > Hmm.. that would be an interesting approach and an alternative. But the > only down side is applications like Sigtran which if I remember Michael told > me change a RESTART event into a DISCONNECT/CONNECT.. which is the whole thing > you are trying to avoid... Isn't this an app issue again? The app can be changed to adapt to it. And if a backward compatibility is the number one priority, I guess we can still have a simpler mechanism utilizing existing mechanism since both sides of the SCTP stack are being changed anyway. For example (without much thinking), a "restart recovery" flag can be added to the INIT chunk to notify the other side that this is a failure recovery so that the other side will not send up a normal restart notification to the app. An app can use a new option to choose to be notified about this type of "restart recovery" event. There are many simple possibilities if the stack needs to be changed. > It would also be a bit heavier weight to do of course... but it is possible... Why? If you count the number of messages exchanged in your example, I think it is more than the normal association set-up handshake, right? -- K. Poon. ka-cheong.poon@oracle.com From ka-cheong.poon@oracle.com Sun Apr 3 22:49:09 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64313A68E6 for ; Sun, 3 Apr 2011 22:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.575 X-Spam-Level: X-Spam-Status: No, score=-5.575 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLm7rzQ2bvcb for ; Sun, 3 Apr 2011 22:49:07 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 0EBDF3A67EF for ; Sun, 3 Apr 2011 22:49:07 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p345omKa026952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 4 Apr 2011 05:50:49 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p345olnu016174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 Apr 2011 05:50:47 GMT Received: from abhmt010.oracle.com (abhmt010.oracle.com [141.146.116.19]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p345okWe007467 for ; Mon, 4 Apr 2011 00:50:47 -0500 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 03 Apr 2011 22:50:46 -0700 Message-ID: <4D995C34.7080408@oracle.com> Date: Mon, 04 Apr 2011 13:50:44 +0800 From: Kacheong Poon Organization: Oracle Corporation User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.15) Gecko/20110304 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: wglc FOR draft-ietf-tsvwg-sctp-strrst-09 started References: <201102080311.p183BpvU025288@sj-core-2.cisco.com><4D86D500.80807@oracle.com> <4D9060A9.5080703@oracle.com> <022701cbed32$d21db0e0$4001a8c0@gateway.2wire.net> <4D92B02E.8020609@oracle.com> <02b001cbeec9$539e1fa0$4001a8c0@gateway.2wire.net> <4D94496B.8030402@oracle.com> <011401cbef91$b22bc360$4001a8c0@gateway.2wire.net> <4D94814D.5080906@oracle.com> <007301cbefb5$f15e4fc0$4001a8c0@gateway.2wire.net> In-Reply-To: <007301cbefb5$f15e4fc0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt358.oracle.com [141.146.40.158] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4D995C38.000C:SCFSTAT5015188,ss=1,fgs=0 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 05:49:10 -0000 On 03/31/11 11:11 PM, t.petch wrote: > No, reset is what I have in mind, but the IETF is a bit short > of transport layer protocols with which to illustrate my point:-( > so these are (more or less) application layer doing a similar job. > For example, how many of the BGP restarts (with consequent > ripple effects throughout the Internet) prior to Graceful > Restart were caused by TCP problems which a proper > TCP reset (not the current 'kill the connection') would have > obviated? I do not know of any research into that issue > but if you look at BGP prior to Graceful Restart, then when > anything went wrong, it more or less had to take the connection > down and begin all over again with ripple effects etc. So a TCP reset > of the kind proposed for SCTP could have been quite beneficial. > (Usual caveat about my lack of familiarity with the deployed > use of SCTP). Can you be more specific about the TCP issue above? If I am not mistaken, the BGP graceful restart is because the other side has restarted, maybe because of an app crash. This is not about TCP getting out of sync, which I think is what your idea of a TCP "reset" may be useful. It is an issue above the transport layer. So I am not sure a transport layer "reset" can help. > Remember too that the SCTP association may have underlying state > as part of security which may be expensive or time consuming > to re-establish which would be unnecessary if all the problem is > is with SSN/TSN, which is also part of the SCTP state. (I think > that implementation error is the most likely cause of getting knotted, > as I put it, not an attack, although the latter cannot be ruled out). I am not aware of any special state which the SCTP stack needs to keep. Can you give some examples? I agree that TSN/SSN can get out of sync if there is a bug in the stack or because of an attack. But under these situations, it is actually better to tear down the association. Besides the reason that the same problem can happen again, there may already be data loss/corruption of the original association. It is better to notify the app that something bad happens. -- K. Poon. ka-cheong.poon@oracle.com From randall@lakerest.net Mon Apr 4 03:56:24 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1760A3A6971 for ; Mon, 4 Apr 2011 03:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKSf12wrQkJn for ; Mon, 4 Apr 2011 03:56:23 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by core3.amsl.com (Postfix) with ESMTP id 407B43A696A for ; Mon, 4 Apr 2011 03:56:21 -0700 (PDT) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id p34Aw1VM068125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Apr 2011 06:58:02 -0400 (EDT) (envelope-from randall@lakerest.net) Subject: Re: New Version Notification for draft-stewart-tsvwg-reconfuse-sctp-00 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Randy Stewart In-Reply-To: <4D9959DE.60507@oracle.com> Date: Mon, 4 Apr 2011 06:58:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110329152523.C5C753A6927@core3.amsl.com> <663F18AA-9878-4A5F-856D-AB1CCEE0D955@lakerest.net> <4D9443E2.6050208@oracle.com> <88B43C20-C843-4B51-81B4-B34548CB7C89@lakerest.net> <4D9959DE.60507@oracle.com> To: Kacheong Poon X-Mailer: Apple Mail (2.1084) Cc: tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 10:56:24 -0000 On Apr 4, 2011, at 1:40 AM, Kacheong Poon wrote: > On 03/31/11 07:36 PM, Randy Stewart wrote: >=20 >> Here I think we must agree to disagree and from the list I think >> you are alone here. Most everyone else is supportive of the idea of >> reseting a stream as well as adding. I will let the chairs of course >> be the judge of consensus... >=20 >=20 > I think this needs to be put in perspective. What I've heard > so far is that app writers using SCTP does not think that > having SSN reset is a problem. If I am an app writer and you > ask me this question whether having SSN reset in SCTP is a problem > from app writing point of view, my answer will also be "there is > no problem." But this is TSVWG, we must also check the proposal > from the transport layer point of view. This is what I think > is lacking in the discussion so far. And this is definitely > lacking in the current draft. The only point raised from the > transport layer point of view I've read is from Tom Petch. It > is about "unknotting" some network problem. And this is still > being discussed. Kahceong, we know you are against this.. thats ok.. I understand.. not sure why.. because I don't see it as a bad thing, neither do others who have commented.. >=20 >=20 >> I think the big question is the in-band/out-ofband one. The >> rest of the stuff I think has rough consensus (but of course thats >> my opinion). >>=20 >> The big question for the in-band proponents is can we come up with an >> alternative mechanism that adds a stream that is NOT out-of-band. If = so >> then I think its a possible option.. However if you still must = implement >> two mechanism's then I think an out-of-band mechanism is the best = approach >> (only one method ;-D) >=20 >=20 > If this is one supporting argument that TSN/SSN reset should be > bundled with stream addition in the same draft, I'd say that it > is then better for us to create an in-band mechanism for stream > addition. Michael mentioned some difficulties. But I guess we > can work on how to solve them. Brian Bidulock may already have > some ideas. I am gladly waiting for Brian to put out a proposal.. as you say he may have an idea on how 1) Stream Reset 2) Add 3) Delete and 4) Compete reset Can be put in-band. I don't know what it would be since the Add seems to me to be an out-of-band thing.. I can see how 1 and 2 and even 4 can be made to be in-band.. I am sure if Brian has a method he will post it... and then if=20 we decide its a good idea then we can change the draft... after all it is a wg draft...=20 >=20 >=20 >> Hmm.. that would be an interesting approach and an alternative. But = the >> only down side is applications like Sigtran which if I remember = Michael told >> me change a RESTART event into a DISCONNECT/CONNECT.. which is the = whole thing >> you are trying to avoid... >=20 >=20 > Isn't this an app issue again? The app can be changed to adapt > to it. And if a backward compatibility is the number one > priority, I guess we can still have a simpler mechanism utilizing > existing mechanism since both sides of the SCTP stack are being > changed anyway. For example (without much thinking), a "restart > recovery" flag can be added to the INIT chunk to notify the other > side that this is a failure recovery so that the other side will > not send up a normal restart notification to the app. An app > can use a new option to choose to be notified about this type of > "restart recovery" event. There are many simple possibilities if > the stack needs to be changed. Hmm.. I am not quite sure how you add flags to the restart to indicate you are restarting. The whole idea of the restart is the transport does NOT know. I.e. the machine rebooted and there is no state left.. it just sent an INIT. The only side that knows it is a restart is the side that had the original connection that was restarted. The NAT draft by its nature has to turn that feature off. >=20 >=20 >> It would also be a bit heavier weight to do of course... but it is = possible... >=20 >=20 > Why? If you count the number of messages exchanged in your > example, I think it is more than the normal association set-up > handshake, right? A 4 way handshake instead a simple Reset/Ack. Add to that the cost of generating a cookie (with MD5 or SHA-1 signature) and then unpacking it ... and I consider that far heavier than a simple request/ack. R >=20 >=20 > --=20 >=20 > K. Poon. > ka-cheong.poon@oracle.com >=20 ----- Randall Stewart randall@lakerest.net From ietfc@btconnect.com Mon Apr 4 10:30:28 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06BDF3A6A09 for ; Mon, 4 Apr 2011 10:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, SARE_MILLIONSOF=0.315, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSg-ZP1NvfNI for ; Mon, 4 Apr 2011 10:30:26 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by core3.amsl.com (Postfix) with ESMTP id 327B53A6A05 for ; Mon, 4 Apr 2011 10:30:25 -0700 (PDT) Received: from host217-44-145-1.range217-44.btcentralplus.com (HELO pc6) ([217.44.145.1]) by c2beaomr06.btconnect.com with SMTP id CPA21998; Mon, 04 Apr 2011 18:31:43 +0100 (BST) Message-ID: <017701cbf2e5$b2991300$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Kacheong Poon" , References: <201102080311.p183BpvU025288@sj-core-2.cisco.com><4D86D500.80807@oracle.com><4D9060A9.5080703@oracle.com><022701cbed32$d21db0e0$4001a8c0@gateway.2wire.net><4D92B02E.8020609@oracle.com><02b001cbeec9$539e1fa0$4001a8c0@gateway.2wire.net><4D94496B.8030402@oracle.com><011401cbef91$b22bc360$4001a8c0@gateway.2wire.net><4D94814D.5080906@oracle.com><007301cbefb5$f15e4fc0$4001a8c0@gateway.2wire.net> <4D995C34.7080408@oracle.com> Subject: Re: wglc FOR draft-ietf-tsvwg-sctp-strrst-09 started Date: Mon, 4 Apr 2011 18:30:52 +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.0A0B0301.4D9A007F.0023, actions=TAG X-Junkmail-Premium-Raw: score=26/50, refid=2.7.2:2011.4.2.222122:17:26.894, ip=217.44.145.1, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __URI_NO_WWW, __URI_NO_PATH, BODY_SIZE_5000_5999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, __URI_NS, SXL_IP_DYNAMIC[1.145.44.217.fur], RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=26/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4D9A0081.01F0,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.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 17:30:28 -0000 Kacheong One last time; we are not communicating, I suspect because we have different experiences and may be we will never have enough of them to communicate. You want 'why', protocol details, and to me they are an irrelevance, I should not be trying to persuade you with them. I see almost everything deficient in the ability to perform partial resets which makes the cost of a failure much higher than it need be so any additional such function - eg in SCTP - is automatically a good thing; end of story. My (frequent) experience is of two systems separated by a (wide area) network (by definition erratic and unreliable even before malicious interventions are taken into account), getting out of synch, with only way to recover a full restart when much is lost that need not have been had there been a partial restart, a reset or various flavours of reset. So adding that to SCTP is obviously a good idea; end of story. I am sure the Microsoft knew that a well designed and well implemented system would not need partial resets; millions of users know better (blue screens of death, power on resets anyone?) and so Windows has steadily gained partial restarts, preserving the 'state' (eg database) that has been built up over days or weeks of running (I suspect that application designers, meanwhile, have got an awful lot smarter at checkpointing and restarting). My experience is that (almost) every piece of software, (almost) every protocol could be improved by more partial restarts, resets. When I am a user of a system and it hangs, and I ring the help desk it is usually 'have you rebooted the system?' 'no, that would cost me at least half an hour's work to reinstate where I am' 'you must reboot before we investigate further' 'sigh' You look at protocols I have pointed you to and you do not understand. Perhaps RFC3478 is the easiest. It concerns an MPLS router and routers can work or fail. Wrong, they can part work and part fail. This RFC addresses the case where the router is forwarding millions of pps at light speed using a FIB built up over days or weeks.Then something goes wrong with the signalling such that LDP no longer works and so needs restarting so that the FIB can go on being updated. Why? an irrelevance - could be a bug in the SNMP code, could be an obscure never thought of race condition, ... - all irrelevant. The important thing is to preserve the forwarding while restarting the LDP part. I expect there are or will be comparable applications with SCTP, one part slowly building up an 'operational database' that another part uses. If an application designer chose a single association for both parts, well they might soon learn to use separate associations so that a lock up on the former does require destruction of the latter. Adding a partial reset to SCTP would stop that hassle. Good idea; end of story. Of course, when a system locks up repeatedly, as happened for me as a user in the early hours of each Thursday morning in February, then the help desk, or the support behind them, notices, investigates and puts in a cure or prevention. In the meantime, the partial resets that on that occasion were available saved me and others work. What was the problem? I am curious but ultimately, I don't know, don't care, cannot afford to make it my responsibility; end of story. Tom Petch ----- Original Message ----- From: "Kacheong Poon" To: Sent: Monday, April 04, 2011 7:50 AM Subject: Re: wglc FOR draft-ietf-tsvwg-sctp-strrst-09 started > On 03/31/11 11:11 PM, t.petch wrote: > > > No, reset is what I have in mind, but the IETF is a bit short > > of transport layer protocols with which to illustrate my point:-( > > so these are (more or less) application layer doing a similar job. > > For example, how many of the BGP restarts (with consequent > > ripple effects throughout the Internet) prior to Graceful > > Restart were caused by TCP problems which a proper > > TCP reset (not the current 'kill the connection') would have > > obviated? I do not know of any research into that issue > > but if you look at BGP prior to Graceful Restart, then when > > anything went wrong, it more or less had to take the connection > > down and begin all over again with ripple effects etc. So a TCP reset > > of the kind proposed for SCTP could have been quite beneficial. > > (Usual caveat about my lack of familiarity with the deployed > > use of SCTP). > > Can you be more specific about the TCP issue above? If > I am not mistaken, the BGP graceful restart is because the > other side has restarted, maybe because of an app crash. > This is not about TCP getting out of sync, which I think is > what your idea of a TCP "reset" may be useful. It is an > issue above the transport layer. So I am not sure a > transport layer "reset" can help. > > > Remember too that the SCTP association may have underlying state > > as part of security which may be expensive or time consuming > > to re-establish which would be unnecessary if all the problem is > > is with SSN/TSN, which is also part of the SCTP state. (I think > > that implementation error is the most likely cause of getting knotted, > > as I put it, not an attack, although the latter cannot be ruled out). > > I am not aware of any special state which the SCTP stack > needs to keep. Can you give some examples? I agree that > TSN/SSN can get out of sync if there is a bug in the stack > or because of an attack. But under these situations, it > is actually better to tear down the association. Besides > the reason that the same problem can happen again, there > may already be data loss/corruption of the original > association. It is better to notify the app that something > bad happens. > > > > > -- > > K. Poon. > ka-cheong.poon@oracle.com From ka-cheong.poon@oracle.com Wed Apr 6 20:12:22 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE2363A69E8 for ; Wed, 6 Apr 2011 20:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.055 X-Spam-Level: X-Spam-Status: No, score=-6.055 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blpSsQm+Nnh9 for ; Wed, 6 Apr 2011 20:12:22 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 1030A3A6784 for ; Wed, 6 Apr 2011 20:12:21 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p373E5da000880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 7 Apr 2011 03:14:06 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p373E4Gu023620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Apr 2011 03:14:04 GMT Received: from abhmt015.oracle.com (abhmt015.oracle.com [141.146.116.24]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p373E3uI009113 for ; Wed, 6 Apr 2011 22:14:03 -0500 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 Apr 2011 20:14:03 -0700 Message-ID: <4D9D2BF5.9050908@oracle.com> Date: Thu, 07 Apr 2011 11:13:57 +0800 From: Kacheong Poon Organization: Oracle Corporation User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.15) Gecko/20110304 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: tsvwg Subject: Re: New Version Notification for draft-stewart-tsvwg-reconfuse-sctp-00 References: <20110329152523.C5C753A6927@core3.amsl.com> <663F18AA-9878-4A5F-856D-AB1CCEE0D955@lakerest.net> <4D9443E2.6050208@oracle.com> <88B43C20-C843-4B51-81B4-B34548CB7C89@lakerest.net> <4D9959DE.60507@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4D9D2BFC.01B6:SCFSTAT5015188,ss=1,fgs=0 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 03:12:22 -0000 On 04/ 4/11 06:58 PM, Randy Stewart wrote: > Kahceong, we know you are against this.. thats ok.. I understand.. not > sure why.. because I don't see it as a bad thing, neither do > others who have commented.. I have been very clear why I have reservation on the proposal. IMHO it is a wrong design choice to make the transport layer fatter just for the sake of app layer protocol which does not really *need* the functionality. And as I repeatedly pointed out, we *MUST* look at it from the transport layer perspective, not purely from the app point of view as described in the current draft. And so far for all the example usage given, the app layer can do the job just as well. As Michael noted, it can be done in many ways. So it is unclear to me why the authors keep pushing this idea of TSN/SSN reset. AFAICT, there is no app layer protocol requesting SSN/TSN reset in IETF. At best, there are some "thought" experiments which *may* utilize it although it *isn't necessary*. And it is unfortunate that folks with transport protocol design experience have not jumped in to comment more, either for or against the idea. We only have one sided comment which is from app layer. IMHO, this is not a good sign to move forward as there is not enough discussion from more than one point of view. It is also unclear to me why SSN/TSN must be bundled with stream addition. It don't see that there is any technical reason. Is there any? >>> Hmm.. that would be an interesting approach and an alternative. But the >>> only down side is applications like Sigtran which if I remember Michael told >>> me change a RESTART event into a DISCONNECT/CONNECT.. which is the whole thing >>> you are trying to avoid... >> >> >> Isn't this an app issue again? The app can be changed to adapt >> to it. And if a backward compatibility is the number one >> priority, I guess we can still have a simpler mechanism utilizing >> existing mechanism since both sides of the SCTP stack are being >> changed anyway. For example (without much thinking), a "restart >> recovery" flag can be added to the INIT chunk to notify the other >> side that this is a failure recovery so that the other side will >> not send up a normal restart notification to the app. An app >> can use a new option to choose to be notified about this type of >> "restart recovery" event. There are many simple possibilities if >> the stack needs to be changed. > > > Hmm.. I am not quite sure how you add flags to the restart to indicate > you are restarting. The whole idea of the restart is the transport > does NOT know. I.e. the machine rebooted and there is no state > left.. it just sent an INIT. The only side that knows it is a > restart is the side that had the original connection that was > restarted. The NAT draft by its nature has to turn that > feature off. This is the example in your new draft, a failover situation. So the side sending the INIT know that it is a "recovery restart" otherwise it is not a failover situation... >>> It would also be a bit heavier weight to do of course... but it is possible... >> >> >> Why? If you count the number of messages exchanged in your >> example, I think it is more than the normal association set-up >> handshake, right? > > A 4 way handshake instead a simple Reset/Ack. Add to that the > cost of generating a cookie (with MD5 or SHA-1 signature) and then > unpacking it ... and I consider that far heavier than a simple > request/ack. In your example, there is the address reconfiguration and that authentication option is enabled which actually require more processing than a simple restart. My comment is strictly based on the your new draft. -- K. Poon. ka-cheong.poon@oracle.com From Internet-Drafts@ietf.org Fri Apr 8 11:45:02 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ECE63A69B4; Fri, 8 Apr 2011 11:45:02 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGCq9+3+hKDY; Fri, 8 Apr 2011 11:45:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94D633A69F4; Fri, 8 Apr 2011 11:45:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-tsvwg-sctpsocket-28.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.16 Message-ID: <20110408184501.10831.60590.idtracker@localhost> Date: Fri, 08 Apr 2011 11:45:01 -0700 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 18:45:02 -0000 --NextPart 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 : Sockets API Extensions for Stream Control Transmission Protocol (SCTP) Author(s) : R. Stewart, et al. Filename : draft-ietf-tsvwg-sctpsocket-28.txt Pages : 111 Date : 2011-04-08 This document describes a mapping of the Stream Control Transmission Protocol (SCTP) into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features and a consolidated error and event notification scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-28.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctpsocket-28.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-08113632.I-D@ietf.org> --NextPart-- From gorry@erg.abdn.ac.uk Mon Apr 18 08:46:46 2011 Return-Path: X-Original-To: tsvwg@ietfc.amsl.com Delivered-To: tsvwg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1036CE080D for ; Mon, 18 Apr 2011 08:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEw0ETYcy4Sw for ; Mon, 18 Apr 2011 08:46:44 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfc.amsl.com (Postfix) with ESMTP id 4EAD6E0806 for ; Mon, 18 Apr 2011 08:46:43 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk ([IPv6:2001:630:241:207:21f:5bff:fe38:7354]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p3IFkaDA010771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Apr 2011 16:46:36 +0100 (BST) Message-ID: <4DAC5CDD.7090506@erg.abdn.ac.uk> Date: Mon, 18 Apr 2011 16:46:37 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: tsvwg WG Subject: Fwd: TSV Notes from IETF-80 (draft) and TSVWG Current Status 18-Apr-2011 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: Mon, 18 Apr 2011 15:46:46 -0000 I uploaded draft notes for TSVWG, please check for corrections: http://www.ietf.org/proceedings/80/minutes/tsvwg.txt Below is a draft post-meeting status report. Best wishes, Gorry +++++++++++++++++++++++++ RFC Published: draft-ietf-tsvwg-admitted-realtime-dscp-07 (RFC 5865) draft-ietf-tsvwg-rsvp-proxy-approaches-09 (RFC 5945) draft-ietf-tsvwg-rsvp-proxy-proto-11 (RFC 5946) draft-ietf-tsvwg-rsvp-l3vpn-07 (RFC 6016) draft-ietf-tsvwg-ecn-tunnel-10 (RFC6040) draft-ietf-tsvwg-port-randomization (RFC 6056) draft-ietf-tsvwg-sctp-chunk-flags (RFC 6096) draft-ietf-tsvwg-dtls-for-sctp (RFC 6083) --- IDs in RFC Editor Queue: draft-ietf-tsvwg-emergency-rsvp-15 (MISREF) Norm. ref to router alert draft (in the INT-area WG, now in WGLC) draft-ietf-tsvwg-iana-ports New revision 25 Oct 2010. This will require a multi-working group LC. draft-ietf-tsvwg-iana-ports-08 was WGL'ed 30-10-2010 WGLC ended Friday, 26th November 2010 New version -09 02/12/2010. Discussion on list during Dec 2010. AD review received 21/12/2010. Proto Write-up sent 19/01/2011. Revised document text agreed, and document sent for publication. Gorry is Shepherd. ------------------------------------------------------------------- IDs in IESG processing: draft-ietf-tsvwg-rsvp-security-groupkeying WGLC of previous version completed. SECDIR review comments received, and updated as version -05. Short WGLC to confirm new text ended August 11th 2010. New version (-09) 22-10-2010. Proto write-up sent 14/12/2010. Publication requested. James is Shepherd. DUE: AD to review. ------------------------------------------------------------------- WG Drafts with Chairs: draft-ietf-tsvwg-sctpsocket New Rev -25, 07/01/2011. WGLC complete. James is Shepherd. DUE: Proto Write-up by Shepherd (James) draft-ietf-tsvwg-sctp-strrst Dependency on this for IPFIX document with RFC-Ed. Benoit Claise to review for IPFIX New revision (-08) 25 Oct 2010. Text on race-condition to be updated before WGLC. New text to address this in revision 04/01/2011. WGLC in progress. James is Shepherd. DUE: WG Chairs to evaluate result of WGLC (17-Mar-2011) ------------------------------------------------------------------- WG Drafts: draft-ietf-tsvwg-source-quench (Replaced: draft-gont-tsvwg-source-quench-01.txt) IETF-79 suggested there was interest in this topic. Comments to list in 2010 from: Fred Baker, Antonio DeSimone, James Polk, Gorry Fairhurst, Andrew Yourtchenko, and others. WG agreed the draft should be a work item. More motivation needed to justify the SHOULD cases. DUE: New revision expected DUE: Reviewers need to volunteer for LC Please comment on list. draft-ietf-tsvwg-byte-pkt-congest New editor added Jul 2010. New revision 25 Oct 2010. DUE: Update needed before deciding if ready for WGLC. DUE: Reviewers need to volunteer for LC Please comment on list. draft-ietf-tsvwg-natsupp-tsvwg (Replaced: draft-stewart-natsupp-tsvw) Dependency from BEHAVE WG. Adopted as a work item 21 Sept 2010 (Gorry). WG -00, 29/11/2010 uploaded as: draft-ietf-natsupp-tsvwg DUE: New revision need. draft-ietf-tsvwg-sctp-udp-encap (Replaced: draft-tuexen-sctp-udp-encap) Lars sent a note as AD agreeing to progress this work. Work to be coordinated with DCCP work on encaps. Adopted as a work item 21 Sept 2010 (Gorry). DUE: New revision need. ------------------------------------------------------------------- WG action required: draft-polk-tsvwg-intserv-multiple-tspec WG interest in this topic recorded at IETF-78. Charter update would be needed to progress this work. 5 Reviews needed to determine energy/technical direction. Version -05 (presented in Beijing, IETF-79) Version -06 (presented in Prague, IETF-80) RSVP directorate was consulted. 2 reviews from RSVP-DIR received (Bruce Davie, ?). 2 additional reviews promised (Ken Carlberg, Francois LeF). WG needs to assess if the new draft should be a work item. Chairs approached AD to examine if the Charter can be updated. DUE: Awaiting response from AD (and then call needed to list). draft-ietf-6man-udpzero was: draft-fairhurst-tsvwg-6man-udpzero Draft was adopted by 6man, please discuss on the 6man list. A WGLC of this draft is expected in 6MAN WG. related draft: draft-ietf-6man-udpchecksums-00 Expected to start WGLC in April 2011. This draft will be LC'ed in TSVWG also. ------------------------------------------------------------------- The following have received recent discussion at TSVWG meetings or on the list. Inclusion in the list below does not indicate support for these specific drafts and other contributions are also warmly welcomed. draft-stewart-tsvwg-sctpecn-00 Partially replaces (draft-stewart-tsvwg-sctp-nonce) IETF-78 suggested there was interest in this topic. Please comment to list. Revised draft to be uploaded with new name. - The draft needs to be updated for multihoming (IETF-80) WG needs to assess if the new draft should be a work item. draft-briscoe-tsvwg-ecn-encap-guidelines -00 Presented in Prague, IETF-80. WG needs to assess if the new draft should be a work item. Please comment on list. DUE: Chairs to check liaison status with other SDOs. draft-touch-tsvwg-port-use-00 - Intended to be advice to protocol designers needing a port. 5 people have looked at this document, Prague IETF-80 WG needs to assess if the new draft should be a work item. Please comment on list. DUE: Chairs to discuss with TSV and APPs ADs. draft-nishida-tsvwg-sctp-failover -00 Presented in Prague, IETF-80. - understood to not conflict with draft-tuexen-tsvwg-sctp-multipath Please comment to list. draft-tuexen-tsvwg-sctp-multipath -00 Presented in Prague, IETF-80. - understood to not conflict with draft-nishida-tsvwg-sctp-failover Please comment to list. WG chair note: Above two drafts should be read together. ------------------------------------------------------------------- draft-polk-tsvwg-rsvp-app-id-vv-profiles -01 Presented in Beijing, IETF-79. -02 was submitted 14-Mar-2011 WG needs to assess if the new draft should be a work item. Please comment on list. draft-lefaucheur-tsvwg-rsvp-multiple-preemption RSVP directorate to be consulted. - Reviewers: Bruce Davie (awaiting other reviews) Please comment to list. draft-wing-tsvwg-happy-eyeballs-sctp Please comment to list. draft-tuexen-tsvwg-sctp-sack-immediately Please comment to list. draft-lei-tsvwg-sctp-compr-requirements-profile Please comment to list. draft-wei-tsvwg-nested-header-compression Please comment to list. ------------------------------------------------------------------- Related non-WG items: draft-narayanan-tsvwg-rsvp-resource-sharing Authors to take this draft to CCAMP WG. draft-ietf-behave-sctpnat-03.txt BEHAVE WG item linked to SCTP encapsulation work. ------------------------------------------------------------------ Other news: RSVP Directorate (formed in May 2010) Charter to be updated. ------------------------------------------------------------------ From ietfdbh@comcast.net Tue Apr 19 14:22:04 2011 Return-Path: X-Original-To: tsvwg@ietfc.amsl.com Delivered-To: tsvwg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E47B9E086D for ; Tue, 19 Apr 2011 14:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zr0kW4LA+6KT for ; Tue, 19 Apr 2011 14:22:03 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfc.amsl.com (Postfix) with ESMTP id 89741E08B2 for ; Tue, 19 Apr 2011 14:22:01 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta03.westchester.pa.mail.comcast.net with comcast id ZZK71g0050EZKEL53ZN18S; Tue, 19 Apr 2011 21:22:01 +0000 Received: from davidPC ([67.189.235.106]) by omta01.westchester.pa.mail.comcast.net with comcast id ZZN01g0152JQnJT3MZN1Ln; Tue, 19 Apr 2011 21:22:01 +0000 From: "David Harrington" To: , Subject: AD review: draft-ietf-tsvwg-rsvp-security-groupkeying-09 Date: Tue, 19 Apr 2011 17:21:50 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16776 Thread-index: Acv+18wptvljEK1ITqGvJbPzSX0YDQ== X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 21:22:05 -0000 Hi, I have performed an AD review of this document. Overall, I found the content of this document well written, but have a few concerns. I believe these should be fairly easy to resolve. -- Technical and Process concerns: 1) section 2 last paragraph "... the RSVP router that receives the Path message will be able to authenticate it successfully using the group key." It is important to be consistent in specifying what is being authenticated. Here "it" appears to refer to a message. Earlier text in section 2 says "If a group key is used, the authentication granularity becomes group membership of devices, not (individual) peer authentication between devices", which seems to indicate a device (or peer) is being authenticated (or a group of devices). 2) I am concerned with the number of "should" and "should not" recommendations, using non-RFC2119 keywords in an Informational document. This feels like you are trying to define a standard or BCP without using the standards track process. I think the usage of "should" should be eliminated from an Informational document. 3) Has the WG explicitly discussed acceptability of the IPR terms related to this document? The RAND terms apply for compliance to the standard, but this is not being submitted as a standards-track document. As noted in 2), there are a number of shoulds in this Informational document. The terms in the IPR declaration do not seem to provide non-assert status for implementing an Informational document. Has the WG discussed this? Comments (mainly suggestions for improving the text): 1) The text is made much harder to read because there are a bunch of unnecesary lead-in phrases. You do not need a lead-in phrase for most sentences. Sentences that start with "Note that" generally don't need the "Note that". Sentences that start with "This implies that" generally don't need the "This implies that". Sentences that start with "We observe that" generally don't need the "We observe that". Sentences that start with "As observed in the security considerations section of RFCXXXX," generally don't need the introductory lead-in, just a simple reference after the stated content. These superfluous phrases obscure the real content of the text. 2) [I-D.weis-gdoi-mac-tek] is referenced informationally. I generally prefer to avoid referencing IDs; they are an unstable thing to reference, and can delay document publication. 3) The next-to-last paragraph of section2 (starting with "This means that") could benefit from rephrasing. The first sentence seems to belong to the preceding paragraph (the challenge), while the rest of this paragraph is about the impact of handshakes. I think the paragraph could be more succinct: OLD: Section 4.3 of [RFC2747] states that "... the receiver MAY initiate an integrity handshake with the sender." We note that if this handshake is taking place, it can be used to determine the identity of the next RSVP hop. In this case, non-RSVP hops can be traversed also using per interface or per neighbor keys. NEW: Section 4.3 of [RFC2747] states that "... the receiver MAY initiate an integrity handshake with the sender." Non-RSVP hops can be traversed more easily using per interface or per neighbor keys if an integrity handshake is used to determine the identity of the next RSVP hop. (The ease is impacted; are the security properties impacted at all?) 4) section 3.1 defines "security domain". I think the definition is not clear and unambiguous. I think if you are going to define a term, it should not be buried in the fourth sentence of a paragraph. Put it in a terminology section, and make sure it is clear and unambiguous. If the term is already clearly defined in another document, please reference the normative document. 5) please ask the RFC editor whether they would prefer that "per interface" and "per neighbor" be hyphenated. 6) "per interface" should be "Per interface" when it starts a sentence. 7) please run id-nits and correct the problems it finds. I ran it and it complains about copyright year, lack of an RFC2119 reference, and the IPR disclaimer. Some complaints are caused by crossing a year-end during processing and are easy fixes. 8) I found section 3.1 a bit confusing on first read. The problem is the repetition using different words: "However, when the interface is multipoint, all RSVP speakers on a given subnet have to share the same key in this model. This makes it unsuitable for deployment scenarios where nodes from different security domains are present on a subnet" and "As mentioned above, per interface keys are only applicable when all the nodes reachable on the specific interface belong to the same security domain." and "Again, interface level keys can be deployed safely only when all the reachable neighbors on the interface belong to the same security domain." What happens if interpretatiosn of the wording differ because your wording differs? State it once clearly, so you don't have to keep repeating it in different language. 9) s/We observe that, alternatively, in some environments, // 10) The sentence starting "Group keying may allow" might be better as the start of the next paragraph. 11) section 5.2 OLD: In its Security Considerations section, [RFC4875] points out that RSVP message integrity mechanisms for hop- by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE signaling. Suggested: RSVP message integrity mechanisms for hop- by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE signaling (see [RFC4875] Security Considerations). 12) s/In turn, we observe that the analyses in this document of keying methods apply equally to P2MP RSVP-TE for the hop-by-hop signaling. /analyses in this document apply to P2MP RSVP-TE hop-by-hop signaling./ But after cutting away the excess words, does this sentence actually say anything? Is it the analyses in this document that apply to P2MP signalling, or is it the RSVP integrity mechanism that applies? Or are you saying that the analysis of keying methods for RSVP apply to the keying for P2MP signalling? 13) "We note that the observation in Section 3.1 of this document about use of group keying for protection of non-hop-by-hop messages apply to protection of non-hop-by-hop signaling for LSP Hierarchy and P2MP RSVP- TE." What does this sentence actually say? Please be clear and unambiguous in your wording. Let me see if I can understand what you are trying to say here. a) section 3.1 discusses per-interface and per-neighbor keying, not group keying. and doesn't even mention non-hop-by-hop messages. b) If I assume you meant 3.2, not 3.1, then I find that 3.2 says "As discussed in Section 2, group keying can be used in the presence of non-RSVP hops." So to understand 5.2, I should read 3.2, which says I should read section 2. and the message is ... "group keying can simplify protection of non-hop-by-hop signaling for LSP Hierarchy and P2MP RSVP- TE." Is that what you are trying to say? 14) please expand all acronyms on first usage. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From Internet-Drafts@ietf.org Sat Apr 23 09:30:02 2011 Return-Path: X-Original-To: tsvwg@ietfc.amsl.com Delivered-To: tsvwg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9F669E0716; Sat, 23 Apr 2011 09:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.972 X-Spam-Level: X-Spam-Status: No, score=-102.972 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vn01z+i8Xvwx; Sat, 23 Apr 2011 09:30:01 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E69D5E06CD; Sat, 23 Apr 2011 09:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-tsvwg-sctpsocket-29.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110423163001.18273.76542.idtracker@ietfc.amsl.com> Date: Sat, 23 Apr 2011 09:30:01 -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: Sat, 23 Apr 2011 16:30:02 -0000 --NextPart 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 : Sockets API Extensions for Stream Control Transmission Protocol (SCTP) Author(s) : R. Stewart, et al. Filename : draft-ietf-tsvwg-sctpsocket-29.txt Pages : 111 Date : 2011-04-23 This document describes a mapping of the Stream Control Transmission Protocol (SCTP) into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features and a consolidated error and event notification scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-29.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctpsocket-29.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-23091739.I-D@ietf.org> --NextPart--