From mailnull@www1.ietf.org Sat Feb 1 18:05:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17243 for ; Sat, 1 Feb 2003 18:05:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h11N9vG11518 for tsvwg-archive@odin.ietf.org; Sat, 1 Feb 2003 18:09:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11N9MJ11504; Sat, 1 Feb 2003 18:09:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VI3AJ09338 for ; Fri, 31 Jan 2003 13:03:10 -0500 Received: from viefep11-int.chello.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13938; Fri, 31 Jan 2003 12:59:00 -0500 (EST) Received: from work ([80.109.142.58]) by viefep11-int.chello.at (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with SMTP id <20030131180233.YPZ16768.viefep11-int.chello.at@work>; Fri, 31 Jan 2003 19:02:33 +0100 From: "Michael Welzl" To: , "Michael Welzl" Cc: , Date: Fri, 31 Jan 2003 19:02:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <77897.1044035500@aardvark.icir.org> Content-Transfer-Encoding: 8bit Subject: [Tsvwg] AW: [dccp] DCCP and UDP Lite Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Mark, I agree that the 4 bits would be worth it. What I meant is: if this is a sensible thing to include in DCCP (which I think), it's about time for UDP Lite to move on. Or, otherwise, it should be removed (which I don't think). Anyhow, I thought it would be worth pointing out that this feature connects DCCP to UDP Lite... I wasn't aware that it was in fact inspired by UDP Lite. Cheers, Michael > -----Ursprüngliche Nachricht----- > Von: mjh@icir.org [mailto:mjh@icir.org] > Gesendet: Freitag, 31. Jänner 2003 18:52 > An: Michael Welzl > Cc: dccp@ietf.org; tsvwg@ietf.org > Betreff: Re: [dccp] DCCP and UDP Lite > > > > >Hi everybody, > > > >I just noticed the following sentences in the DCCP specification > >(page 11, section 5.1, "checksum length"): > > > >"The checksum length field specifies what parts of the packet > >are covered by the checksum field. The checksum always covers > >at least the DCCP header, DCCP options, and a pseudoheader taken > >from the network-layer header (see below). If the checksum > >length field is zero, that is all the checksum covers." > > > > > >The functionality of setting the checksum length field > >to zero closely resembles the capability of UDP Lite to > >receive erroneous payload packets and deliver them to the > >application. > > > > > >I would say that: > > > >EITHER: > > > >- a comment should be included that states that erroneous > > payload MUST NOT be delivered to the applications and may > > only be used for congestion control purposes (or, possibly > > better, the sentence about values other than 0 or 15 being > > experimental should be changed to "values other than 15"). > > > >OR: > > > >- UDP Lite should be accepted upon acceptance of DCCP. > > > > > >This has nothing to do with personal preference - it's just > >similar functionality that caused a lot of discussions in > >the case of UDP Lite ... > > It's not just similar - it was entirely inspired by UDP Lite. We're > still rather undecided as to whether this is a useful function. It > can easily be removed if there's pushback, but so far the comments > we've received have mostly been in favour. > > It's clearly not a dangerous thing for a transport to allow this. > It's just rather pointless unless there are link-layers that might > take advantage of it, and applications that can make use of it. > > In our case it comes down to whether we have a better use for those > four bits. Currently we think it's worth spending those 4 bits in > this way, given that the unreliable applications DCCP is primarily > intended to support are the sort of applications that might be able to > use this functionality. > > - Mark _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Feb 3 12:23:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13987 for ; Mon, 3 Feb 2003 12:23:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13HS7j06747 for tsvwg-archive@odin.ietf.org; Mon, 3 Feb 2003 12:28:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13HRNJ06682; Mon, 3 Feb 2003 12:27:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13HPjJ06505 for ; Mon, 3 Feb 2003 12:25:45 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13907 for ; Mon, 3 Feb 2003 12:20:06 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h13HNeim000530 for ; Mon, 3 Feb 2003 11:23:41 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E3EA59C.8090407@stewart.chicago.il.us> Date: Mon, 03 Feb 2003 11:23:40 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: TSV WG list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] SCTP implementors guide comments... Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi: I have two comments (there may be more later on :>) on the implementors guide (I am reviewing notes and attempting to get it updated for the next rev :-0) 1) In the current pass the wording in 2.14.2 the new wording for 7.2.1 changes it so that "the cwnd of the transport address MUST be adjusted to 2*MTU." I feel this is a bit to strong... for a couple of reasons: a) In some networks (ones I have been playing wish) you do tend to get a spike in the RTO which have little to do with congestion. In such a case I think it a bit extreme to take away all of the cwnd... especially the networks I am working with that take a long time to ramp back up. b) I don't see the same restriction in TCP. Now, what I think is this MUST should be a SHOULD... since SHOULD means unless you have a really really really good reason you should follow this... MUST seems way to strong for me. 2) I am incorporating Armando's text clearification (stated a while back) for section 2.8 (regarding sack gap ack blocks). I see no follow up and his clearification makes sense :> Thats all for now :> R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 4 12:24:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29151 for ; Tue, 4 Feb 2003 12:24:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14HUA910782 for tsvwg-archive@odin.ietf.org; Tue, 4 Feb 2003 12:30:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14HThJ10744; Tue, 4 Feb 2003 12:29:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14HSOJ10699 for ; Tue, 4 Feb 2003 12:28:24 -0500 Received: from web8201.mail.in.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29131 for ; Tue, 4 Feb 2003 12:22:19 -0500 (EST) Message-ID: <20030204172556.37294.qmail@web8201.mail.in.yahoo.com> Received: from [210.214.67.112] by web8201.mail.in.yahoo.com via HTTP; Tue, 04 Feb 2003 17:25:56 GMT Date: Tue, 4 Feb 2003 17:25:56 +0000 (GMT) From: =?iso-8859-1?q?amit=20somani?= To: lksctp developers , tsvwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Tsvwg] Problem regarding two connections Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello everyone, i am a student from Pune Institute od Computer technology and i am doing a project of sending SS7 signals over IP. for this i am using SCTP as transport layer protocol. i am using linux kernel 2.5.55 for the same. the problem is that when i open a socket using SCTP and send some data, the data is sent successfully but when i close this connection and try to open another connection only INIT and INIT_ACK messeges are exchanged and no data can be sent. the system doesn't give any error but the data is not received. So can anyone please help me solve this problem. waiting for reply. Regards Amit ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 5 00:03:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15811 for ; Wed, 5 Feb 2003 00:03:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1559Jo17942 for tsvwg-archive@odin.ietf.org; Wed, 5 Feb 2003 00:09:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1558gJ17926; Wed, 5 Feb 2003 00:08:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1557RJ17868 for ; Wed, 5 Feb 2003 00:07:27 -0500 Received: from x86unx3.comp.nus.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15762 for ; Wed, 5 Feb 2003 00:01:07 -0500 (EST) Received: from e500b.comp.nus.edu.sg (e500b.comp.nus.edu.sg [137.132.90.26]) by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with SMTP id NAA21329; Wed, 5 Feb 2003 13:04:43 +0800 (GMT-8) Received: from sf3.comp.nus.edu.sg(137.132.90.55) by e500b.comp.nus.edu.sg via csmap id 10291; Wed, 05 Feb 2003 12:57:21 +0800 (SGT) Received: from localhost (venka@localhost) by sf3.comp.nus.edu.sg (8.8.5/8.8.5) with ESMTP id NAA04448; Wed, 5 Feb 2003 13:04:43 +0800 (GMT-8) Date: Wed, 5 Feb 2003 13:04:42 +0800 (GMT-8) From: Venkatesh S Obanaik To: =?iso-8859-1?q?amit=20somani?= cc: lksctp developers , tsvwg@ietf.org Subject: Re: [Tsvwg] Problem regarding two connections In-Reply-To: <20030204172556.37294.qmail@web8201.mail.in.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , 2.5.X is a development version of the kernel meant for kernel developers. Always use a stable kernel version (all the even numbered versions are stable versions of the kernel ..like 2.0.X, 2.2.X, 2.4.X ) http://www.kernel.org/ the latest stable version is 2.4.20 Regards, Venkatesh On Tue, 4 Feb 2003, [iso-8859-1] amit somani wrote: > Hello everyone, > > i am a student from Pune Institute od Computer > technology and i am doing a project of sending SS7 > signals over IP. for this i am using SCTP as transport > layer protocol. i am using linux kernel 2.5.55 for the > same. the problem is that when i open a socket using > SCTP and send some data, the data is sent successfully > but when i close this connection and try to open > another connection only INIT and INIT_ACK messeges are > exchanged and no data can be sent. the system doesn't > give any error but the data is not received. So can > anyone please help me solve this problem. > > waiting for reply. > Regards > Amit > > ________________________________________________________________________ > Missed your favourite TV serial last night? Try the new, Yahoo! TV. > visit http://in.tv.yahoo.com > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 5 04:35:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15284 for ; Wed, 5 Feb 2003 04:35:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h159er410141 for tsvwg-archive@odin.ietf.org; Wed, 5 Feb 2003 04:40:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h159eTJ10129; Wed, 5 Feb 2003 04:40:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h159dIJ10065 for ; Wed, 5 Feb 2003 04:39:18 -0500 Received: from irmgard.exp-math.uni-essen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15248 for ; Wed, 5 Feb 2003 04:32:53 -0500 (EST) Received: from gina.exp-math.uni-essen.de (gina.exp-math.uni-essen.de [132.252.150.131]) by irmgard.exp-math.uni-essen.de (8.12.2/8.12.2) with ESMTP id h159aT1n040414; Wed, 5 Feb 2003 10:36:29 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Andreas Jungmaier Organization: University of Essen To: Venkatesh S Obanaik , amit somani Subject: Re: [Tsvwg] Problem regarding two connections Date: Wed, 5 Feb 2003 10:36:31 +0100 User-Agent: KMail/1.4.3 Cc: lksctp developers , tsvwg@ietf.org References: In-Reply-To: MIME-Version: 1.0 Message-Id: <200302051036.38120.ajung@exp-math.uni-essen.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h159dIJ10066 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Venkatesh, I think you are missing a point here: the lksctp is only integral part of the linux kernel since some 2.5. version. This means it has been integrated into the mainstream developers kernels. So, if you want up-to-date kernel level SCTP, you *need* to use a recent 2.5. kernel. Also, please note that implementation dependent questions should be discussed on the SCTP-IMP list, which is at To subscribe, send a message to with the following text in the body: subscribe sctp-impl Best regards, Andreas On Wednesday 05 February 2003 06:04, Venkatesh S Obanaik wrote: > 2.5.X is a development version of the kernel > meant for kernel developers. > > Always use a stable kernel version > (all the even numbered versions are stable versions of > the kernel ..like 2.0.X, 2.2.X, 2.4.X ) > > http://www.kernel.org/ > the latest stable version is 2.4.20 > > Regards, > Venkatesh > > On Tue, 4 Feb 2003, [iso-8859-1] amit somani wrote: > > Hello everyone, > > > > i am a student from Pune Institute od Computer > > technology and i am doing a project of sending SS7 > > signals over IP. for this i am using SCTP as transport > > layer protocol. i am using linux kernel 2.5.55 for the > > same. the problem is that when i open a socket using > > SCTP and send some data, the data is sent successfully > > but when i close this connection and try to open > > another connection only INIT and INIT_ACK messeges are > > exchanged and no data can be sent. the system doesn't > > give any error but the data is not received. So can > > anyone please help me solve this problem. > > > > waiting for reply. > > Regards > > Amit > > > > ________________________________________________________________________ > > Missed your favourite TV serial last night? Try the new, Yahoo! TV. > > visit http://in.tv.yahoo.com > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg - -- - --------------------------------------------------------------------------- Dipl.-Ing. Andreas Jungmaier | Stop sending E-POSTCARDS ! Computer Networking Technology Group | Send E-MAILS -- Use PGP ! University of Essen | http://www.exp-math.uni-essen.de/~ajung | http://www.gnupg.org My PGP Key-ID: D3824AC0 | http://wwwkeys.pgp.net - --------------------------------------------------------------------------- My PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 - --------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+QNskXAsLBNOCSsARAhhzAJ4lRZpYXfMbBGAgn439RcGz5M11SQCg9nIC U7cTxpBOsuPmfcGNbgnyINY= =NOCY -----END PGP SIGNATURE----- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 5 09:28:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26501 for ; Wed, 5 Feb 2003 09:28:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15EYjm28513 for tsvwg-archive@odin.ietf.org; Wed, 5 Feb 2003 09:34:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15EYNJ28486; Wed, 5 Feb 2003 09:34:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15EXAJ28440 for ; Wed, 5 Feb 2003 09:33:10 -0500 Received: from e32.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26440 for ; Wed, 5 Feb 2003 09:26:40 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h15ETwM2040978; Wed, 5 Feb 2003 09:29:59 -0500 Received: from us.ibm.com ([9.53.216.106]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h15ETvEg021190; Wed, 5 Feb 2003 07:29:58 -0700 Message-ID: <3E411F8A.3030609@us.ibm.com> Date: Wed, 05 Feb 2003 08:28:26 -0600 From: Jon Grimm Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Venkatesh S Obanaik , amit somani CC: Andreas Jungmaier , lksctp developers , tsvwg@ietf.org Subject: Re: [Tsvwg] Problem regarding two connections References: <200302051036.38120.ajung@exp-math.uni-essen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yes, Andreas is quite correct here that lksctp is integrated into the 2.5 branch of Linux. Amit's request for assistance was inappropriately addressed to the tsvwg and will be addressed over on the lksctp-developer's list, as I've already mailed Amit. Sorry for the intrusion into tswvg-land, Jon Grimm Andreas Jungmaier wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Venkatesh, > > I think you are missing a point here: > the lksctp is only integral part of the linux kernel since some > 2.5. version. This means it has been integrated into the mainstream > developers kernels. So, if you want up-to-date kernel level SCTP, > you *need* to use a recent 2.5. kernel. > > Also, please note that implementation dependent questions should > be discussed on the SCTP-IMP list, which is at > > > To subscribe, send a message to with the > following text in the body: > > subscribe sctp-impl > > Best regards, > Andreas > > On Wednesday 05 February 2003 06:04, Venkatesh S Obanaik wrote: > >> 2.5.X is a development version of the kernel >>meant for kernel developers. >> >>Always use a stable kernel version >>(all the even numbered versions are stable versions of >>the kernel ..like 2.0.X, 2.2.X, 2.4.X ) >> >>http://www.kernel.org/ >>the latest stable version is 2.4.20 >> >>Regards, >>Venkatesh >> >>On Tue, 4 Feb 2003, [iso-8859-1] amit somani wrote: >> >>>Hello everyone, >>> >>>i am a student from Pune Institute od Computer >>>technology and i am doing a project of sending SS7 >>>signals over IP. for this i am using SCTP as transport >>>layer protocol. i am using linux kernel 2.5.55 for the >>>same. the problem is that when i open a socket using >>>SCTP and send some data, the data is sent successfully >>>but when i close this connection and try to open >>>another connection only INIT and INIT_ACK messeges are >>>exchanged and no data can be sent. the system doesn't >>>give any error but the data is not received. So can >>>anyone please help me solve this problem. >>> >>>waiting for reply. >>> Regards >>> Amit >>> >>>________________________________________________________________________ >>>Missed your favourite TV serial last night? Try the new, Yahoo! TV. >>> visit http://in.tv.yahoo.com >>>_______________________________________________ >>>tsvwg mailing list >>>tsvwg@ietf.org >>>https://www1.ietf.org/mailman/listinfo/tsvwg >> >>_______________________________________________ >>tsvwg mailing list >>tsvwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/tsvwg > > > - -- > - --------------------------------------------------------------------------- > Dipl.-Ing. Andreas Jungmaier | Stop sending E-POSTCARDS ! > Computer Networking Technology Group | Send E-MAILS -- Use PGP ! > University of Essen | > http://www.exp-math.uni-essen.de/~ajung | http://www.gnupg.org > My PGP Key-ID: D3824AC0 | http://wwwkeys.pgp.net > - --------------------------------------------------------------------------- > My PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 > - --------------------------------------------------------------------------- > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE+QNskXAsLBNOCSsARAhhzAJ4lRZpYXfMbBGAgn439RcGz5M11SQCg9nIC > U7cTxpBOsuPmfcGNbgnyINY= > =NOCY > -----END PGP SIGNATURE----- > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 5 23:19:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21965 for ; Wed, 5 Feb 2003 23:19:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h164Q3Y20105 for tsvwg-archive@odin.ietf.org; Wed, 5 Feb 2003 23:26:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h164Pjp20094; Wed, 5 Feb 2003 23:25:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h164OKp20055 for ; Wed, 5 Feb 2003 23:24:20 -0500 Received: from web8201.mail.in.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21832 for ; Wed, 5 Feb 2003 23:17:33 -0500 (EST) Message-ID: <20030206042110.3645.qmail@web8201.mail.in.yahoo.com> Received: from [210.214.67.124] by web8201.mail.in.yahoo.com via HTTP; Thu, 06 Feb 2003 04:21:10 GMT Date: Thu, 6 Feb 2003 04:21:10 +0000 (GMT) From: =?iso-8859-1?q?amit=20somani?= To: tsvwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Tsvwg] sorry Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hello everyone at tsvwg! sorry for the query sent to u all. it was just a mistake as lksctp & tsvwg mailing lists r consecutive in my address book. sorry again. i`ll take care such things will not happen in future. amit. ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Feb 6 10:31:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22248 for ; Thu, 6 Feb 2003 10:31:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16FbhX08614 for tsvwg-archive@odin.ietf.org; Thu, 6 Feb 2003 10:37:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16FbMp08468; Thu, 6 Feb 2003 10:37:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16FaDp07778 for ; Thu, 6 Feb 2003 10:36:13 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22067 for ; Thu, 6 Feb 2003 10:29:12 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h16FWnKV021332 for ; Thu, 6 Feb 2003 16:32:49 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DW0DPQGK; Thu, 6 Feb 2003 16:32:49 +0100 Received: from res0010384da36.eed.ericsson.se (dhcp5-197 [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id QAA28503 for ; Thu, 6 Feb 2003 16:32:48 +0100 (MET) Message-Id: <5.1.0.14.0.20030206163100.0277d668@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Feb 2003 16:32:37 +0100 To: tsvwg@ietf.org From: Reiner Ludwig Subject: Fwd: [Tsvwg] draft-ietf-tsvwg-tcp-eifel-response-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , this is just a friendly reminder asking for feedback on draft-ietf-tsvwg-tcp-eifel-response-02.txt. Otherwise, the ADs might think that everybody is happy with the document :-) ///Reiner >X-Sender: eedrel@mailhost.eed.ericsson.se >X-Mailer: QUALCOMM Windows Eudora Version 5.1 >Date: Mon, 09 Dec 2002 14:51:27 +0100 >To: tsvwg@ietf.org >From: Reiner Ludwig >Subject: [Tsvwg] draft-ietf-tsvwg-tcp-eifel-response-02.txt >Sender: tsvwg-admin@ietf.org >X-BeenThere: tsvwg@ietf.org >X-Mailman-Version: 2.0.12 >List-Unsubscribe: , > >List-Id: Transport Area Working Group >List-Post: >List-Help: >List-Subscribe: , > > >Hi, > >I have now also submitted a new revision of the Eifel Response algorithm >for TCP. It should be online shortly. > > From our side this document should be ready for WG last call to publish > it as an experimental RFC. > >Despite many discussion during IETF meetings and private e-mail exchange, >there has been little feedback on the mailing list. This could either mean >that everybody is happy with the document (unlikely :-), or that people >haven't given the doc a serious review. In case of the latter, it would be >great if some of you took the time, and let us know what you think. > >///Reiner > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Feb 6 11:29:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24765 for ; Thu, 6 Feb 2003 11:29:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16GZZw12715 for tsvwg-archive@odin.ietf.org; Thu, 6 Feb 2003 11:35:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16GZEp12686; Thu, 6 Feb 2003 11:35:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16GYGp12625 for ; Thu, 6 Feb 2003 11:34:16 -0500 Received: from MAIL.cynetanetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24657 for ; Thu, 6 Feb 2003 11:27:13 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C2CDFD.1CECC5B5" Date: Thu, 6 Feb 2003 10:30:51 -0600 Message-ID: <9255B6CD76A88943A3062F7D4E6432F543BAE2@mail.cynetanetworks.com> X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-ietf-ops-mib-review-guidelines-00.txt Thread-Index: AcLN/NZghyHLiRF4TACStN+arUIOOAAAA0hw From: "Spencer Dawkins" To: "Tsvwg Mailing List (E-mail)" Cc: Subject: [Tsvwg] FW: I-D ACTION:draft-ietf-ops-mib-review-guidelines-00.txt Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2CDFD.1CECC5B5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For those who are working through the TCP Extended Statistics MIB, this = is timely and (at least to me!) helpful... Spencer > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Thursday, February 06, 2003 9:37 AM > To: wgchairs@ietf.org > Subject: FW: I-D ACTION:draft-ietf-ops-mib-review-guidelines-00.txt >=20 >=20 > WG chairs, >=20 > The MIB doctor/reviewers team is working on a document > that guides us in reviwing MIB related documents. >=20 > The idea here is twofold: >=20 > - Try to come to a consistent review of different MIB > documents, even if done by different MIB doctors. > Of course there are always personal flavors and > subsjective comments... but with such a document, > we should at least not bother people with inconsistent > comments on various MIB and SMIv2 aspects. >=20 > - Serve as a guideline for MIB document editors/authors > and WG chairs when developing such MIB documents. > Taking into account these guidelines, the review process > may go much faster and so your document can get approved > faster as a result. >=20 > Hopefully this helps us with the process of MIB reviews. >=20 > This is an initial version, so we are not 100% in sync yet, > and various IETF people may have their own opinions on it > as well. So if you (or your WG members) have any comments, > feel free to send them to me, or send them to > mibs@ops.ietf.org, where all the MIB doctors/reviewers > can read it. >=20 > Thanks, > Bert Wijnen > co-AD for the OPS area, specifically Network Management >=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: donderdag 6 februari 2003 15:30 > Subject: I-D ACTION:draft-ietf-ops-mib-review-guidelines-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Operations & Management Open=20 > Area Working Group of the IETF. >=20 > Title : Guidelines for MIB Authors and Reviewers > Author(s) : C. Heard > Filename : draft-ietf-ops-mib-review-guidelines-00.txt > Pages : 39 > Date : 2003-2-5 >=20 > This memo provides guidelines for authors and reviewers of IETF > specifications containing MIB modules. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review- guidelines-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the = message. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ops-mib-review-guidelines-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ops-mib-review-guidelines-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C2CDFD.1CECC5B5 Content-Type: message/rfc822 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C2CDF1.2C123B80" Subject: Date: Thu, 6 Feb 2003 09:05:23 -0600 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: This is a multi-part message in MIME format. ------_=_NextPart_002_01C2CDF1.2C123B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------_=_NextPart_002_01C2CDF1.2C123B80 Content-Type: application/octet-stream; name="ATT15310" Content-Description: ATT15310 Content-Disposition: attachment; filename="ATT15310" Content-Transfer-Encoding: base64 Q29udGVudC10eXBlOiBtZXNzYWdlL2V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDAzLTItNTE0MDI0Ny5JLURAaWV0Zi5vcmc+DQoNCkVO Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9wcy1taWItcmV2 aWV3LWd1aWRlbGluZXMtMDAudHh0DQo= ------_=_NextPart_002_01C2CDF1.2C123B80 Content-Type: application/octet-stream; name="ATT104069.TXT" Content-Description: ATT104069.TXT Content-Disposition: attachment; filename="ATT104069.TXT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBtZXNzYWdlL2V4dGVybmFsLWJvZHk7DQoJc2l0ZT0iaW50ZXJuZXQtZHJh ZnRzIjsNCglkaXI9ImRyYWZ0LWlldGYtb3BzLW1pYi1yZXZpZXctZ3VpZGVsaW5lcy0wMC50eHQi Ow0KCW1vZGU9ImZ0cC5pZXRmLm9yZyI7DQoJYWNjZXNzLXR5cGU9ImFub24tZnRwIg0KDQo= ------_=_NextPart_002_01C2CDF1.2C123B80-- ------_=_NextPart_001_01C2CDFD.1CECC5B5-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Feb 7 05:24:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04043 for ; Fri, 7 Feb 2003 05:24:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17AV9w23533 for tsvwg-archive@odin.ietf.org; Fri, 7 Feb 2003 05:31:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17AUnp23502; Fri, 7 Feb 2003 05:30:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17ATop23467 for ; Fri, 7 Feb 2003 05:29:50 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04010 for ; Fri, 7 Feb 2003 05:22:25 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h17AOv206360 for ; Fri, 7 Feb 2003 12:24:57 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Feb 2003 12:26:03 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Feb 2003 12:26:03 +0200 Received: from there (sarolaht@sahaja.research.nokia.com [172.21.40.118]) by mgw.research.nokia.com (8.9.3/8.9.3) with SMTP id MAA16576; Fri, 7 Feb 2003 12:26:03 +0200 (EET) Message-Id: <200302071026.MAA16576@mgw.research.nokia.com> X-Authentication-Warning: mgw.research.nokia.com: Host sarolaht@sahaja.research.nokia.com [172.21.40.118] claimed to be there Content-Type: text/plain; charset="iso-8859-1" From: Pasi Sarolahti Organization: Nokia Research Center To: "ext Reiner Ludwig" , tsvwg@ietf.org Subject: Re: [Tsvwg] draft-ietf-tsvwg-tcp-eifel-response-02.txt Date: Fri, 7 Feb 2003 12:26:02 +0200 X-Mailer: KMail [version 1.3.2] References: <5.1.0.14.0.20030206163100.0277d668@mailhost.eed.ericsson.se> In-Reply-To: <5.1.0.14.0.20030206163100.0277d668@mailhost.eed.ericsson.se> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Feb 2003 10:26:03.0383 (UTC) FILETIME=[50F96070:01C2CE93] Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, On Thursday 06 February 2003 17:32, ext Reiner Ludwig wrote: > this is just a friendly reminder asking for feedback on > draft-ietf-tsvwg-tcp-eifel-response-02.txt. In my earlier mail in December I was suggesting that the Introduction and the beginning of Section 2.1 would be reworded to be independent of the detection mechanism used. Now the text is written specifically for the Eifel detection, but I don't see any reason why the response could not be applied with DSACK or F-RTO or some other detection method, or what do you think? ...which reminds me that I would still like to take steps forward with draft-sarolahti-tsvwg-tcp-frto-03.txt. So, I'm again kindly asking for opinions on having the draft to be a tsvwg work item. - Pasi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Feb 8 13:22:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27107 for ; Sat, 8 Feb 2003 13:22:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h18IULO02614 for tsvwg-archive@odin.ietf.org; Sat, 8 Feb 2003 13:30:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h18IU0p02603; Sat, 8 Feb 2003 13:30:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h18ISIp02560 for ; Sat, 8 Feb 2003 13:28:18 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27070 for ; Sat, 8 Feb 2003 13:20:15 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 20C039D9D; Sat, 8 Feb 2003 13:23:56 -0500 (EST) Received: from ren.eecis.udel.edu (ren.eecis.udel.edu [128.4.40.13]) by mail.eecis.udel.edu (Postfix) with ESMTP id 6EA739D9C; Sat, 8 Feb 2003 13:23:53 -0500 (EST) Date: Sat, 8 Feb 2003 13:23:53 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Qiaobing Xie Cc: , , Subject: Re: [Tsvwg] queries on draft-ietf-tsvwg-sctpimpguide-05.txt In-Reply-To: <3E2F3B12.EE694111@Motorola.com> Message-ID: X-Spam-Status: No, hits=-103.0 required=6.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE,USER_IN_WHITELIST version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Qiaobing, Sorry for the late reply, but no I do not have any such information. SCTP's Congestion Window Validation algorithm is based on the one for TCP presented in RFC2861. As long as the connection is not application-limited, the algorithm should not be of concern in high bandwidth*delay pipes. Otherwise, I am not aware of any work which shows a cwnd validation algorithm which works optimally for idle or application-limited connections. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 On Wed, 22 Jan 2003, Qiaobing Xie wrote: > Hi, Armando, > > "Armando L. Caro Jr." wrote: > .... > > > Originally, Max.Burst was applied only in the case of a SACK > > > acknowledging fast retransmitted DATA Chunks. However, Max.Burst is > > > now used always. Note that this is a modification to the general > > > congestion control algorithm. > > > > Yes, this change was made to avoid bursts at any time. Max.Burst was left > > as a parameter, because we don't really know what an acceptable burst > > is... 4 was a reasonable number chosen earlier, so we stuck with it. > > Do you have a reference to any analysis/discussion on the impact of this change to > the data throughput over a long, fat SCTP connection? (or similar analysis for > long fat TCP connections). _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Feb 8 13:27:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27209 for ; Sat, 8 Feb 2003 13:27:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h18IZQ502795 for tsvwg-archive@odin.ietf.org; Sat, 8 Feb 2003 13:35:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h18IZ4p02785; Sat, 8 Feb 2003 13:35:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h18IYqp02752 for ; Sat, 8 Feb 2003 13:34:52 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27191 for ; Sat, 8 Feb 2003 13:26:50 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 3D37C9D9C; Sat, 8 Feb 2003 13:30:30 -0500 (EST) Received: from ren.eecis.udel.edu (ren.eecis.udel.edu [128.4.40.13]) by mail.eecis.udel.edu (Postfix) with ESMTP id 009529D97; Sat, 8 Feb 2003 13:30:29 -0500 (EST) Date: Sat, 8 Feb 2003 13:30:28 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Qiaobing Xie Cc: , , Subject: Re: [Tsvwg] queries on draft-ietf-tsvwg-sctpimpguide-05.txt In-Reply-To: Message-ID: X-Spam-Status: No, hits=-103.0 required=6.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE,USER_IN_WHITELIST version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , oops... I meant to say... On Sat, 8 Feb 2003, Armando L. Caro Jr. wrote: > Qiaobing, > > Sorry for the late reply, but no I do not have any such information. > SCTP's Congestion Window Validation algorithm is based on the one for TCP > presented in RFC2861. As long as the connection is not > application-limited, the algorithm should not be of concern in high > bandwidth*delay pipes. Otherwise, I am not aware of any work which shows a > cwnd validation algorithm which works optimally for idle or > application-limited connections over high bandwidth*delay pipes. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 11 00:08:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08862 for ; Tue, 11 Feb 2003 00:08:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B5HFj07878 for tsvwg-archive@odin.ietf.org; Tue, 11 Feb 2003 00:17:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B5Glp07846; Tue, 11 Feb 2003 00:16:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B5FKp07816 for ; Tue, 11 Feb 2003 00:15:20 -0500 Received: from pop-4.dnv.wideopenwest.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08805 for ; Tue, 11 Feb 2003 00:06:04 -0500 (EST) Received: from thoth.ir.bbn.com (d53-203-209.clv.wideopenwest.com [64.53.209.203]) by pop-4.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h1B5Dij03519; Mon, 10 Feb 2003 23:13:44 -0600 Received: from thoth.ir.bbn.com (localhost [127.0.0.1]) by thoth.ir.bbn.com (8.12.6/8.12.6) with ESMTP id h1B5B1ht040836; Tue, 11 Feb 2003 00:11:01 -0500 (EST) (envelope-from mallman@thoth.ir.bbn.com) Message-Id: <200302110511.h1B5B1ht040836@thoth.ir.bbn.com> To: tsvwg@ietf.org Cc: "Bob Dimond" , "Ethan Blanton" From: Mark Allman Reply-To: mallman@grc.nasa.gov Organization: BBN Technologies/NASA GRC Song-of-the-Day: Paradise City Date: Tue, 11 Feb 2003 00:11:01 -0500 Subject: [Tsvwg] new draft on mitigating effects of reordering Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Folks- Ethan Blanton, Bob Dimond and I have just submitted the following Internet-Draft: Ethan Blanton, Robert Dimond, Mark Allman. Practices for TCP Senders in the Face of Segment Reordering, February 2003. Internet-Draft draft-blanton-tcp-reordering-00.txt (work in progress). http://roland.grc.nasa.gov/~mallman/papers/draft-blanton-tcp-reordering-00.txt The i-d should pop out in the usual places in a couple of days. Until then you can slurp it at the URL above. The background.... At the last IETF meeting I gave quick status on draft-blanton-dsack-use-02.txt -- which outlines how to use DSACK information to reliably detect spurious retransmits. The question then was "who cares? I can't do anything anyway". And, that is true. Hence the above i-d (which is really a large update to an old, outdated and expired i-d). The above i-d does not specify how to decide when you have retransmitted needlessly. That is left to other i-ds (our DSACK version or eifel or frto or ...). The above i-d specifies what you can do with your congestion control state (basically undo bogus changes) and a few different mitigations for changing the fast retransmit trigger so that you prevent future needless retransmits. It's -00 and we're sure it is rough around the edges. But, we'd appreciate any comments folks might have on it. Thanks! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 11 01:45:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11324 for ; Tue, 11 Feb 2003 01:45:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B6sJk12845 for tsvwg-archive@odin.ietf.org; Tue, 11 Feb 2003 01:54:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B6rBp12797; Tue, 11 Feb 2003 01:53:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B6qEp12736 for ; Tue, 11 Feb 2003 01:52:14 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11264 for ; Tue, 11 Feb 2003 01:42:56 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:5TtESTVuu0OP1UBt7YUABbJSCWD8jR8k@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1B6kdD22133 for ; Mon, 10 Feb 2003 23:46:39 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1B6kdE18221 for tsvwg@ietf.org; Mon, 10 Feb 2003 23:46:39 -0700 Date: Mon, 10 Feb 2003 23:46:39 -0700 From: "Brian F. G. Bidulock" To: tsvwg@ietf.org Message-ID: <20030210234639.A17851@openss7.org> Reply-To: bidulock@openss7.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Subject: [Tsvwg] SCTP IG - Status Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, What's the status on the SCTP IG? AFAIK the document has been stable for some time and contains no outstanding issues. Is it time to advance the draft to RFC status? --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 11 05:39:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26294 for ; Tue, 11 Feb 2003 05:39:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BAlpt03901 for tsvwg-archive@odin.ietf.org; Tue, 11 Feb 2003 05:47:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BAlTp03882; Tue, 11 Feb 2003 05:47:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BAkRp03842 for ; Tue, 11 Feb 2003 05:46:27 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26239 for ; Tue, 11 Feb 2003 05:37:05 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:o/1knD4TXukc7WXiJxdWOYzeCVBCjhkq@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1BAemD25578; Tue, 11 Feb 2003 03:40:48 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1BAelk16468; Tue, 11 Feb 2003 03:40:47 -0700 Date: Tue, 11 Feb 2003 03:40:47 -0700 From: "Brian F. G. Bidulock" To: Tuexen Michael Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP IG - Status Message-ID: <20030211034047.A16399@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from michael.tuexen@siemens.com on Tue, Feb 11, 2003 at 11:00:23AM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Michael, What would it take to move SCTP to DS? --brian On Tue, 11 Feb 2003, Tuexen Michael wrote: > Brian, > > the SCTP IG will never become an RFC as far as I know. > It is the 'delta' which will be applied to RFC 2960 when > SCTP is moved from PS to DS or PS again. > > Best regards > Michael > > Michael Tuexen Tel.: +49 89 722 47210 > Siemens AG Fax: +49 89 722 48212 > ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: Tuesday, February 11, 2003 7:47 AM > > To: tsvwg@ietf.org > > Subject: [Tsvwg] SCTP IG - Status > > > > > > Hi, > > > > What's the status on the SCTP IG? AFAIK the document has been stable > > for some time and contains no outstanding issues. > > > > Is it time to advance the draft to RFC status? > > > > --brian > > > > -- > > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > > ¦ Therefore all progress depends on the ¦ > > ¦ unreasonable man. -- George Bernard Shaw ¦ > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 11 07:41:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01757 for ; Tue, 11 Feb 2003 07:41:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BCo1711610 for tsvwg-archive@odin.ietf.org; Tue, 11 Feb 2003 07:50:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BCnVp11591; Tue, 11 Feb 2003 07:49:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BCmCp11544 for ; Tue, 11 Feb 2003 07:48:12 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01661 for ; Tue, 11 Feb 2003 07:38:47 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1BCdTYq002091; Tue, 11 Feb 2003 06:39:30 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E48EF01.9080502@stewart.chicago.il.us> Date: Tue, 11 Feb 2003 06:39:29 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: TSV WG list , SCTP Implementors Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] A question of Un-Ordered SCTP Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all: In working with the RDDP adaption for SCTP one of the things my co-authors and I have discussed is the 16bit SSN number when sending a "unordered" message. I have thought on this pro's/con's and would like to hear your feedback... Currently the sender of a Unordered data chunk sets the SSN to 0 and the receiver of the Unordered data chunk ignores the contents of the field.. What has been discussed is, "could we instead allow the ULP to specify a value to be set in the SSN and sent in that field with the receiving SCTP to continue to ignore the value but instead pass it, as is, to the ULP" Now, the more I have thought on this the more I think that it is rather harmless for the following reasons: a) Currently receivers are ignoring the SSN, they have to be otherwise they could not process the unordered data properly. b) The sending side API is pretty much in place for this since the send_rcv_info structure (in the socket api) includes the SSN which currently on sending is ignored. c) It seems to me that these 16 bits are just wasted bandwidth and with minor changes to most implementations it would allow useage of these bits in other situations besides RDDP.. So what do all think of the idea? Good? Bad? Thanks R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 11 08:24:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04022 for ; Tue, 11 Feb 2003 08:24:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BDXSC14473 for tsvwg-archive@odin.ietf.org; Tue, 11 Feb 2003 08:33:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BDX6p14459; Tue, 11 Feb 2003 08:33:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BDWnp14431 for ; Tue, 11 Feb 2003 08:32:49 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03997 for ; Tue, 11 Feb 2003 08:23:22 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:ki4D626Scye5ygHzfu/tP+eIKYZa54/n@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1BDMgD28282; Tue, 11 Feb 2003 06:22:42 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1BDMgn06558; Tue, 11 Feb 2003 06:22:42 -0700 Date: Tue, 11 Feb 2003 06:22:42 -0700 From: "Brian F. G. Bidulock" To: Randall Stewart Cc: TSV WG list , SCTP Implementors Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030211062242.A5719@openss7.org> Reply-To: bidulock@openss7.org References: <3E48EF01.9080502@stewart.chicago.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E48EF01.9080502@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Tue, Feb 11, 2003 at 06:39:29AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Randall, Bits inside of chunk headers should be used by SCTP and not by the ULP. The DATA chunk payload is for use by the ULP. If the use of these bits was to be interpreted by SCTP, I would say ok. But because they would be transparent to SCTP, muddling user data and SCTP protocol bits in the header of a DATA chunk is not very clean. User headers transparent to SCTP should be in the data payload. My $0.02 --brian On Tue, 11 Feb 2003, Randall Stewart wrote: > Hi all: > > In working with the RDDP adaption for SCTP one of the things > my co-authors and I have discussed is the 16bit SSN number when > sending a "unordered" message. > > I have thought on this pro's/con's and would like to hear > your feedback... > > Currently the sender of a Unordered data chunk sets the > SSN to 0 and the receiver of the Unordered data chunk ignores > the contents of the field.. > > What has been discussed is, "could we instead allow the > ULP to specify a value to be set in the SSN and sent > in that field with the receiving SCTP to continue to ignore the > value but instead pass it, as is, to the ULP" > > Now, the more I have thought on this the more I think that > it is rather harmless for the following reasons: > > a) Currently receivers are ignoring the SSN, they have to > be otherwise they could not process the unordered data > properly. > > b) The sending side API is pretty much in place for this > since the send_rcv_info structure (in the socket api) includes > the SSN which currently on sending is ignored. > > c) It seems to me that these 16 bits are just wasted bandwidth > and with minor changes to most implementations it would allow > useage of these bits in other situations besides RDDP.. > > > So what do all think of the idea? Good? Bad? > > > Thanks > > R > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 11 09:59:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07244 for ; Tue, 11 Feb 2003 09:59:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BF8V420991 for tsvwg-archive@odin.ietf.org; Tue, 11 Feb 2003 10:08:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BF7jp20930; Tue, 11 Feb 2003 10:07:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BF6Dp20202 for ; Tue, 11 Feb 2003 10:06:13 -0500 Received: from thebe.your-site.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07106 for ; Tue, 11 Feb 2003 09:56:47 -0500 (EST) From: cait@asomi.com Received: from asomi.com (unknown [140.186.45.27]) by thebe.your-site.com (Postfix) with ESMTP id A374B2450AA; Tue, 11 Feb 2003 10:00:29 -0500 (EST) Received: from 64.144.5.25 (SquirrelMail authenticated user cait@asomi.com) by webmail with HTTP; Tue, 11 Feb 2003 10:00:29 -0500 (EST) Message-ID: <50677.64.144.5.25.1044975629.squirrel@webmail> Date: Tue, 11 Feb 2003 10:00:29 -0500 (EST) Subject: Re: [Tsvwg] A question of Un-Ordered SCTP To: In-Reply-To: <20030211062242.A5719@openss7.org> References: <3E48EF01.9080502@stewart.chicago.il.us> <20030211062242.A5719@openss7.org> X-Priority: 3 Importance: Normal Cc: X-Mailer: SquirrelMail (version 1.2.9) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > Randall, > > Bits inside of chunk headers should be used by SCTP and not > by the ULP. The DATA chunk payload is for use by the ULP. > > If the use of these bits was to be interpreted by SCTP, I > would say ok. But because they would be transparent to > SCTP, muddling user data and SCTP protocol bits in the > header of a DATA chunk is not very clean. User headers > transparent to SCTP should be in the data payload. > > My $0.02 > > --brian > Understood. That is the rationale for placing the sequence number in the Data Chunk (which is the alternate proposal). The gotcha is that these two bytes have *exactly* the same semantics as the SSN would have had for ordered delivery. The RDDP draft requires that all packets be unordered, but would prefer to know what the per-stream order was. It allows earlier detection of when each stream is fully delivered. The basic options are to rely solely on the cumulative TSN ack point, which can result in head-of-line blocking, use/abuse the "meaningless" SSN field within the SCTP header, or duplicate its functionality within the Data Chunk. I suspect there are other ULPs that would benefit from per-stream ordering information when otherwise sending only unordered chunks. If so, it makes sense to use the header for this purpose. But if this is truly unique to RDDP then I agree with your position that ULP data belongs inside the Data Chunks. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 11 11:26:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10145 for ; Tue, 11 Feb 2003 11:26:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BGZ9P25913 for tsvwg-archive@odin.ietf.org; Tue, 11 Feb 2003 11:35:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGYop25890; Tue, 11 Feb 2003 11:34:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGWnp25793 for ; Tue, 11 Feb 2003 11:32:49 -0500 Received: from emulex.emulex.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10048 for ; Tue, 11 Feb 2003 11:23:20 -0500 (EST) Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id IAA25153; Tue, 11 Feb 2003 08:23:11 -0800 (PST) Received: by xbl.ma.emulex.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Feb 2003 11:23:10 -0500 Message-ID: <3356669BBE90C448AD4645C843E2BF289B8FEA@xbl.ma.emulex.com> From: "Williams, Jim" To: "'Randall Stewart'" , TSV WG list , SCTP Implementors Subject: RE: [Tsvwg] A question of Un-Ordered SCTP Date: Tue, 11 Feb 2003 11:23:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > -----Original Message----- > From: Randall Stewart [mailto:randall@stewart.chicago.il.us] > Sent: Tuesday, February 11, 2003 7:39 AM > To: TSV WG list; SCTP Implementors > Subject: [Tsvwg] A question of Un-Ordered SCTP > > > Hi all: > > In working with the RDDP adaption for SCTP one of the things > my co-authors and I have discussed is the 16bit SSN number when > sending a "unordered" message. > > I have thought on this pro's/con's and would like to hear > your feedback... > > Currently the sender of a Unordered data chunk sets the > SSN to 0 and the receiver of the Unordered data chunk ignores > the contents of the field.. For SCTP to provide unordered but sequenced delivery seems like a useful and constructive feature. This would require that a sequence number (rather than zero) is placed in SSN on transmit, and and passed to application on receive. This is exactly what RDDP requires, and seems like a general mechanism that would have uses beyond RDDP. The problem, is that it would be a change to SCTP, and RDDP if it relied on this feature would not work with implementations of SCTP that did not support it. However it is a rather trivial change to implementations that could be adopted quite quickly. On balance, I would support this change to SCTP provided there is sentiment that this would be useful beyond just RDDP. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 11 11:33:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10516 for ; Tue, 11 Feb 2003 11:33:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BGgdl27033 for tsvwg-archive@odin.ietf.org; Tue, 11 Feb 2003 11:42:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGgKp27023; Tue, 11 Feb 2003 11:42:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGfhp26989 for ; Tue, 11 Feb 2003 11:41:43 -0500 Received: from thebe.your-site.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10464 for ; Tue, 11 Feb 2003 11:32:15 -0500 (EST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 3CEC3244AF0; Tue, 11 Feb 2003 11:35:57 -0500 (EST) Date: Tue, 11 Feb 2003 10:37:05 -0600 From: Caitlin Bestler Subject: RE: [Tsvwg] A question of Un-Ordered SCTP To: tsvwg@ietf.org Cc: Tuexen Michael X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 2/11/03, Tuexen Michael wrote: >Dear all, > >does this mean that you want two sequence spaces per >stream: one for the 'ordered' user data and one for the >unordered user data? > The RDDP/SCTP adaptation only uses unordered delivery, so that question did not really arise. But if you were to generalize the problem, I believe the answer would be yes. The SSN for ordered delivery would be unchanged. The addition would be providing "advisory ordering" for unordered delivery. The general characteristic is that the receiving ULP wants the data in whatever order it arrives, but wants to know what the original order was. In addition to RDDP, RTP over UDP is another example of an application that wants to be aware of the original ordering, even while accepting the data out-of-order. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 11 15:05:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17136 for ; Tue, 11 Feb 2003 15:05:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BKEBb08805 for tsvwg-archive@odin.ietf.org; Tue, 11 Feb 2003 15:14:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BKDZp08767; Tue, 11 Feb 2003 15:13:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BKC9p08701 for ; Tue, 11 Feb 2003 15:12:09 -0500 Received: from ilsa.franken.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17114 for ; Tue, 11 Feb 2003 15:02:35 -0500 (EST) Received: from lurchi.franken.de (p50801AC3.dip.t-dialin.net [80.128.26.195]) by ilsa.franken.de (Postfix) with ESMTP id 04794245D0; Tue, 11 Feb 2003 21:04:43 +0100 (CET) Date: Tue, 11 Feb 2003 21:01:40 +0100 Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: tsvwg@ietf.org, Tuexen Michael To: Caitlin Bestler From: Michael Tuexen In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Caitlin, thank you very much for the clarification. I do not like the idea to pass the SSN transparently from the ULP to the ULP. But having two sequence spaces is OK for me. This means that the SSN at the sending side is controlled by the SCTP and given to the ULP at the receiving side. This would be a clean solution. So I voting for have two separate number spaces for user data. Since the one for ordered delivery exists already in RFC 2960, this only means that a new one is introduced for the unordered delivery user data. Best regards Michael On Tuesday, Feb 11, 2003, at 17:37 Europe/Berlin, Caitlin Bestler wrote: > On 2/11/03, Tuexen Michael wrote: > >> Dear all, >> >> does this mean that you want two sequence spaces per >> stream: one for the 'ordered' user data and one for the >> unordered user data? >> > The RDDP/SCTP adaptation only uses unordered delivery, so > that question did not really arise. > > But if you were to generalize the problem, I believe the > answer would be yes. > > The SSN for ordered delivery would be unchanged. The > addition would be providing "advisory ordering" for > unordered delivery. The general characteristic is that > the receiving ULP wants the data in whatever order it > arrives, but wants to know what the original order was. > > In addition to RDDP, RTP over UDP is another example of > an application that wants to be aware of the original > ordering, even while accepting the data out-of-order. > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 11 17:01:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19759 for ; Tue, 11 Feb 2003 17:01:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BMAth16427 for tsvwg-archive@odin.ietf.org; Tue, 11 Feb 2003 17:10:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BMAKp16372; Tue, 11 Feb 2003 17:10:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BA6tp01354 for ; Tue, 11 Feb 2003 05:06:55 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25308 for ; Tue, 11 Feb 2003 04:57:34 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA21320; Tue, 11 Feb 2003 11:01:13 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA10598; Tue, 11 Feb 2003 11:01:14 +0100 (MET) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id <1468H968>; Tue, 11 Feb 2003 11:00:25 +0100 Message-ID: From: Tuexen Michael To: "'bidulock@openss7.org'" , tsvwg@ietf.org Subject: RE: [Tsvwg] SCTP IG - Status Date: Tue, 11 Feb 2003 11:00:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1BA6tp01355 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Brian, the SCTP IG will never become an RFC as far as I know. It is the 'delta' which will be applied to RFC 2960 when SCTP is moved from PS to DS or PS again. Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Tuesday, February 11, 2003 7:47 AM > To: tsvwg@ietf.org > Subject: [Tsvwg] SCTP IG - Status > > > Hi, > > What's the status on the SCTP IG? AFAIK the document has been stable > for some time and contains no outstanding issues. > > Is it time to advance the draft to RFC status? > > --brian > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 11 17:01:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19773 for ; Tue, 11 Feb 2003 17:01:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BMAx916444 for tsvwg-archive@odin.ietf.org; Tue, 11 Feb 2003 17:10:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BMAWp16392; Tue, 11 Feb 2003 17:10:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBVnp06368 for ; Tue, 11 Feb 2003 06:31:49 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27636 for ; Tue, 11 Feb 2003 06:22:26 -0500 (EST) Received: from blues.mchh.siemens.de ([139.21.204.206]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA16476; Tue, 11 Feb 2003 12:26:07 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA22100; Tue, 11 Feb 2003 12:25:42 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2656.59) id ; Tue, 11 Feb 2003 12:25:17 +0100 Message-ID: From: Tuexen Michael To: "'bidulock@openss7.org'" , Tuexen Michael Cc: tsvwg@ietf.org Subject: RE: [Tsvwg] SCTP IG - Status Date: Tue, 11 Feb 2003 12:25:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1BBVnp06369 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Brian, I'm not sure, but I think it should be initiated by the ADs. Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Tuesday, February 11, 2003 11:41 AM > To: Tuexen Michael > Cc: tsvwg@ietf.org > Subject: Re: [Tsvwg] SCTP IG - Status > > > Michael, > > What would it take to move SCTP to DS? > > --brian > > On Tue, 11 Feb 2003, Tuexen Michael wrote: > > > Brian, > > > > the SCTP IG will never become an RFC as far as I know. > > It is the 'delta' which will be applied to RFC 2960 when > > SCTP is moved from PS to DS or PS again. > > > > Best regards > > Michael > > > > Michael Tuexen Tel.: +49 89 722 47210 > > Siemens AG Fax: +49 89 722 48212 > > ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > > > > > -----Original Message----- > > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > > Sent: Tuesday, February 11, 2003 7:47 AM > > > To: tsvwg@ietf.org > > > Subject: [Tsvwg] SCTP IG - Status > > > > > > > > > Hi, > > > > > > What's the status on the SCTP IG? AFAIK the document has > been stable > > > for some time and contains no outstanding issues. > > > > > > Is it time to advance the draft to RFC status? > > > > > > --brian > > > > > > -- > > > Brian F. G. Bidulock ¦ The reasonable man adapts > himself to the ¦ > > > bidulock@openss7.org ¦ world; the unreasonable one > persists in ¦ > > > http://www.openss7.org/ ¦ trying to adapt the world to > himself. ¦ > > > ¦ Therefore all progress > depends on the ¦ > > > ¦ unreasonable man. -- George > Bernard Shaw ¦ > > > _______________________________________________ > > > tsvwg mailing list > > > tsvwg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/tsvwg > > > > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 11 17:01:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19776 for ; Tue, 11 Feb 2003 17:01:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BMAxq16457 for tsvwg-archive@odin.ietf.org; Tue, 11 Feb 2003 17:10:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BMAXp16407; Tue, 11 Feb 2003 17:10:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BFwXp23726 for ; Tue, 11 Feb 2003 10:58:33 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08875 for ; Tue, 11 Feb 2003 10:49:05 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA12924; Tue, 11 Feb 2003 16:52:44 +0100 (MET) Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA06423; Tue, 11 Feb 2003 16:52:43 +0100 (MET) Received: by MCHH248E with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Feb 2003 16:51:53 +0100 Message-ID: From: Tuexen Michael To: "'cait@asomi.com'" , bidulock@openss7.org Cc: tsvwg@ietf.org Subject: RE: [Tsvwg] A question of Un-Ordered SCTP Date: Tue, 11 Feb 2003 16:51:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Dear all, does this mean that you want two sequence spaces per stream: one for the 'ordered' user data and one for the unordered user data? Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > -----Original Message----- > From: cait@asomi.com [mailto:cait@asomi.com] > Sent: Tuesday, February 11, 2003 4:00 PM > To: bidulock@openss7.org > Cc: tsvwg@ietf.org > Subject: Re: [Tsvwg] A question of Un-Ordered SCTP > > > > Randall, > > > > Bits inside of chunk headers should be used by SCTP and not > > by the ULP. The DATA chunk payload is for use by the ULP. > > > > If the use of these bits was to be interpreted by SCTP, I > > would say ok. But because they would be transparent to > > SCTP, muddling user data and SCTP protocol bits in the > > header of a DATA chunk is not very clean. User headers > > transparent to SCTP should be in the data payload. > > > > My $0.02 > > > > --brian > > > Understood. That is the rationale for placing the sequence number > in the Data Chunk (which is the alternate proposal). > > The gotcha is that these two bytes have *exactly* the same semantics > as the SSN would have had for ordered delivery. The RDDP > draft requires > that all packets be unordered, but would prefer to know what > the per-stream > order was. It allows earlier detection of when each stream is fully > delivered. > > The basic options are to rely solely on the cumulative TSN ack point, > which can result in head-of-line blocking, use/abuse the "meaningless" > SSN field within the SCTP header, or duplicate its > functionality within > the Data Chunk. > > I suspect there are other ULPs that would benefit from > per-stream ordering > information when otherwise sending only unordered chunks. If > so, it makes > sense to use the header for this purpose. But if this is > truly unique to > RDDP then > I agree with your position that ULP data belongs inside the > Data Chunks. > > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 11 18:08:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21229 for ; Tue, 11 Feb 2003 18:08:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BNHAs20183 for tsvwg-archive@odin.ietf.org; Tue, 11 Feb 2003 18:17:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BNGap20127; Tue, 11 Feb 2003 18:16:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BNBpp19960 for ; Tue, 11 Feb 2003 18:11:51 -0500 Received: from thebe.your-site.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21113 for ; Tue, 11 Feb 2003 18:02:15 -0500 (EST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 382342449A0; Tue, 11 Feb 2003 18:05:57 -0500 (EST) Date: Tue, 11 Feb 2003 17:07:06 -0600 From: Caitlin Bestler Subject: RE: [Tsvwg] A question of Un-Ordered SCTP To: Tuexen Michael , tsvwg@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 2/11/03, Tuexen Michael wrote: >Dear all, > >does this mean that you want two sequence spaces per >stream: one for the 'ordered' user data and one for the >unordered user data? > RDDP only requires a single sequence space, which is used solely for unordered data. That would also suffice for the other applications that I am aware of that could benefit from unordered delivery of sequenced data chunks. So the question would be, which would have the least impact on existing implementations: Recognizing the concept of an "unordered stream", where *all* data chunks must be sent unordered, but the SSN is handled as though they were ordered. Tracking an additional "USSN" per stream. The second option seems more natural, but the first one has the benefit of being implementable in terms of current data structures with only the definition of a single bit per stream. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 11 18:37:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21899 for ; Tue, 11 Feb 2003 18:37:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BNkM921928 for tsvwg-archive@odin.ietf.org; Tue, 11 Feb 2003 18:46:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BNk6p21891; Tue, 11 Feb 2003 18:46:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BNjGp21850 for ; Tue, 11 Feb 2003 18:45:16 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21879 for ; Tue, 11 Feb 2003 18:35:38 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1BNd6u6002321; Tue, 11 Feb 2003 17:39:06 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E49899A.6010809@stewart.chicago.il.us> Date: Tue, 11 Feb 2003 17:39:06 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Tuexen CC: Caitlin Bestler , tsvwg@ietf.org, Tuexen Michael Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Michael: This seems like a valid method.. it gets around Brian's objection (which was a good point) and yet still provides the application with a hint about what the assigned sequence order was on the unordered messages... R Michael Tuexen wrote: > Caitlin, > > thank you very much for the clarification. > > I do not like the idea to pass the SSN transparently from the ULP to the > ULP. > But having two sequence spaces is OK for me. This means that the SSN at the > sending side is controlled by the SCTP and given to the ULP at the > receiving side. > > This would be a clean solution. So I voting for have two separate number > spaces > for user data. Since the one for ordered delivery exists already in RFC > 2960, this > only means that a new one is introduced for the unordered delivery user > data. > > Best regards > Michael > > On Tuesday, Feb 11, 2003, at 17:37 Europe/Berlin, Caitlin Bestler wrote: > >> On 2/11/03, Tuexen Michael wrote: >> >>> Dear all, >>> >>> does this mean that you want two sequence spaces per >>> stream: one for the 'ordered' user data and one for the >>> unordered user data? >>> >> The RDDP/SCTP adaptation only uses unordered delivery, so >> that question did not really arise. >> >> But if you were to generalize the problem, I believe the >> answer would be yes. >> >> The SSN for ordered delivery would be unchanged. The >> addition would be providing "advisory ordering" for >> unordered delivery. The general characteristic is that >> the receiving ULP wants the data in whatever order it >> arrives, but wants to know what the original order was. >> >> In addition to RDDP, RTP over UDP is another example of >> an application that wants to be aware of the original >> ordering, even while accepting the data out-of-order. >> >> Caitlin Bestler >> http://asomi.com/CaitlinBestler/ >> _______________________________________________ >> tsvwg mailing list >> tsvwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/tsvwg >> > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 11 19:50:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23268 for ; Tue, 11 Feb 2003 19:50:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1C0xsi25559 for tsvwg-archive@odin.ietf.org; Tue, 11 Feb 2003 19:59:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C0xWp25534; Tue, 11 Feb 2003 19:59:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C0wKp25451 for ; Tue, 11 Feb 2003 19:58:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23212; Tue, 11 Feb 2003 19:48:39 -0500 (EST) Message-Id: <200302120048.TAA23212@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , tsvwg@ietf.org From: The IESG Date: Tue, 11 Feb 2003 19:48:39 -0500 Subject: [Tsvwg] Protocol Action: A Conservative SACK-based Loss Recovery Algorithm for TCP to Proposed Standard Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'A Conservative SACK-based Loss Recovery Algorithm for TCP' as a Proposed Standard. This document is the product of the Transport Area Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. Technical Summary This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification RFC2581, but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. Working Group Summary The working group supported publishing of this document. Protocol Quality This document was reviewed for the IESG by Allison Mankin and Scott Bradner. RFC Editor Note: Please replace the following paragraph in section 2: For the purposes of this specification we define a ``duplicate acknowledgment'' as an acknowledgment (ACK) whose cumulative ACK number is equal to the current value of HighACK, as described in [RFC2581]. with For the purposes of this specification we define a ``duplicate acknowledgment'' as a segment that arrives with no data and an acknowledgment (ACK) number that is equal to the current value of HighACK, as described in [RFC2581]. also - please add the IPR notices from Sec 10.4(A) and 10.4(B) before the author's addresses _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 11 21:13:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24960 for ; Tue, 11 Feb 2003 21:13:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1C2MxK30578 for tsvwg-archive@odin.ietf.org; Tue, 11 Feb 2003 21:22:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C2Mdp30557; Tue, 11 Feb 2003 21:22:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C2Lhp30536 for ; Tue, 11 Feb 2003 21:21:43 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24936; Tue, 11 Feb 2003 21:12:00 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:nkteuQ4IYqcrgn/w5At224D1D1Drd8Mo@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1C2FiD07777; Tue, 11 Feb 2003 19:15:44 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1C2FhU16862; Tue, 11 Feb 2003 19:15:43 -0700 Date: Tue, 11 Feb 2003 19:15:43 -0700 From: "Brian F. G. Bidulock" To: Randall Stewart Cc: Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org, Tuexen Michael , sigtran@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030211191543.A14481@openss7.org> Reply-To: bidulock@openss7.org Mail-Followup-To: Randall Stewart , Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org, Tuexen Michael , sigtran@ietf.org References: <3E49899A.6010809@stewart.chicago.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E49899A.6010809@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Tue, Feb 11, 2003 at 05:39:06PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Randall, I agree to having SCTP set the sequence number and, as you said in your first note, SCTP passing the sequence number to the ULP on the receiving side is already done for ordered traffic. Some even pass the zero now. I suppose that SCTP would set this sequence number when it is given the data for delivery at the sending ULP and the sequence would represent the order that the data was presented to SCTP by the ULP at the sending side. I think it would be good to see the requirement that the sequence number begin at 1 and be monotonically increasing in the saem fashion as ordered streams. That way RDDP and other applications could perform their own reordering at the receiver. I think it would be a good thing to have SCTP set this value. In fact, I can see another application for this feature. M2PA (SIGTRAN protocol) needs in some circumstances to send data unordered with the hope of expedited delivery (does not want control information stuck behind large amounts of data in an ordered stream), however, the order of processing of the expedited control information is important. This facility would permit M2PA to send such information unordered to expedite it and the receiver could perform the reordering itself. Up until now, the only solution was to place a sequence number in with the control information. Could we perhaps add a section to the SCTP IG. "Problem statement: the sender wishes to send unordered data but the receive needs to know the original order of sending..." or some such. It should be quite simple to add the feature to existing SCTP implementations. --brian On Tue, 11 Feb 2003, Randall Stewart wrote: > Michael: > > This seems like a valid method.. it gets around Brian's objection > (which was a good point) and yet still provides the application with > a hint about what the assigned sequence order was on the unordered > messages... > > R > > Michael Tuexen wrote: > > Caitlin, > > > > thank you very much for the clarification. > > > > I do not like the idea to pass the SSN transparently from the ULP to the > > ULP. > > But having two sequence spaces is OK for me. This means that the SSN at the > > sending side is controlled by the SCTP and given to the ULP at the > > receiving side. > > > > This would be a clean solution. So I voting for have two separate number > > spaces > > for user data. Since the one for ordered delivery exists already in RFC > > 2960, this > > only means that a new one is introduced for the unordered delivery user > > data. > > > > Best regards > > Michael > > > > On Tuesday, Feb 11, 2003, at 17:37 Europe/Berlin, Caitlin Bestler wrote: > > > >> On 2/11/03, Tuexen Michael wrote: > >> > >>> Dear all, > >>> > >>> does this mean that you want two sequence spaces per > >>> stream: one for the 'ordered' user data and one for the > >>> unordered user data? > >>> > >> The RDDP/SCTP adaptation only uses unordered delivery, so > >> that question did not really arise. > >> > >> But if you were to generalize the problem, I believe the > >> answer would be yes. > >> > >> The SSN for ordered delivery would be unchanged. The > >> addition would be providing "advisory ordering" for > >> unordered delivery. The general characteristic is that > >> the receiving ULP wants the data in whatever order it > >> arrives, but wants to know what the original order was. > >> > >> In addition to RDDP, RTP over UDP is another example of > >> an application that wants to be aware of the original > >> ordering, even while accepting the data out-of-order. > >> > >> Caitlin Bestler > >> http://asomi.com/CaitlinBestler/ > >> _______________________________________________ > >> tsvwg mailing list > >> tsvwg@ietf.org > >> https://www1.ietf.org/mailman/listinfo/tsvwg > >> > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg > > > > > > > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 11 22:45:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27362 for ; Tue, 11 Feb 2003 22:45:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1C3spY02997 for tsvwg-archive@odin.ietf.org; Tue, 11 Feb 2003 22:54:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C3sSp02974; Tue, 11 Feb 2003 22:54:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C3rTp02936 for ; Tue, 11 Feb 2003 22:53:29 -0500 Received: from thebe.your-site.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27299 for ; Tue, 11 Feb 2003 22:43:48 -0500 (EST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id E7730244F41; Tue, 11 Feb 2003 22:47:28 -0500 (EST) Date: Tue, 11 Feb 2003 21:48:38 -0600 From: Caitlin Bestler Subject: Re: [Tsvwg] A question of Un-Ordered SCTP To: bidulock@openss7.org, tsvwg@ietf.org X-Priority: 3 In-Reply-To: <20030211191543.A14481@openss7.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 2/11/03, Brian F. G. Bidulock wrote: > >I think it would be good to see the requirement that the >sequence number begin at 1 and be monotonically increasing >in the saem fashion as ordered streams. > Excellent suggestion. A value of 0 is a tip-off that the sender does not have the unordered sequencing feature. When the receiver spots U-SSNs of 0, it knows that the best it can do to infer sequence is to check the TSNs (which will do sequence, but provides no clues as to whether the entire stream has been delivered until the cumulative ack point catches up). Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 12 00:42:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29441 for ; Wed, 12 Feb 2003 00:42:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1C5q3q09158 for tsvwg-archive@odin.ietf.org; Wed, 12 Feb 2003 00:52:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C5pdp09148; Wed, 12 Feb 2003 00:51:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C5oTp09113 for ; Wed, 12 Feb 2003 00:50:29 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29421 for ; Wed, 12 Feb 2003 00:40:43 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:/Lc8N8J02RwAHYJSdQVFRNI94IPivI6w@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1C5iRD10600; Tue, 11 Feb 2003 22:44:27 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1C5iQV11904; Tue, 11 Feb 2003 22:44:26 -0700 Date: Tue, 11 Feb 2003 22:44:26 -0700 From: "Brian F. G. Bidulock" To: Caitlin Bestler Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030211224426.A11748@openss7.org> Reply-To: bidulock@openss7.org References: <20030211191543.A14481@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cait@asomi.com on Tue, Feb 11, 2003 at 09:48:38PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Caitlin, Bonus! --brian On Tue, 11 Feb 2003, Caitlin Bestler wrote: > On 2/11/03, Brian F. G. Bidulock wrote: > > > > > >I think it would be good to see the requirement that the > >sequence number begin at 1 and be monotonically increasing > >in the saem fashion as ordered streams. > > > Excellent suggestion. A value of 0 is a tip-off that the > sender does not have the unordered sequencing feature. > > When the receiver spots U-SSNs of 0, it knows that the best > it can do to infer sequence is to check the TSNs (which will > do sequence, but provides no clues as to whether the entire > stream has been delivered until the cumulative ack point > catches up). > > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 12 04:42:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27477 for ; Wed, 12 Feb 2003 04:42:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1C9q7501051 for tsvwg-archive@odin.ietf.org; Wed, 12 Feb 2003 04:52:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C9pNp01016; Wed, 12 Feb 2003 04:51:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C9o1p00956 for ; Wed, 12 Feb 2003 04:50:01 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27415 for ; Wed, 12 Feb 2003 04:40:12 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:Utx7iX4CG0eF7kyxJGr3JxJeX+T6Af2y@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1C9htD14052; Wed, 12 Feb 2003 02:43:55 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1C9hs309298; Wed, 12 Feb 2003 02:43:54 -0700 Date: Wed, 12 Feb 2003 02:43:54 -0700 From: "Brian F. G. Bidulock" To: Tuexen Michael Cc: Randall Stewart , Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030212024354.B6927@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from michael.tuexen@siemens.com on Wed, Feb 12, 2003 at 09:39:41AM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Michael, Tuexen Michael wrote: (Wed, 12 Feb 2003 09:39:41) > > > > I think it would be good to see the requirement that the sequence > > number begin at 1 and be monotonically increasing in the saem fashion > > as ordered streams. > > > I would prefer that the two sequence spaces are handled the same > way. Thus both start with SSN=0. That would make it impossible to distinguish between SCTP's supporting the feature and SCTP's not supporting the feature on the first message in a stream. Leaving '0' for unordered packets of unspecified transmission order has some value for backwards compatibility and interoperability. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 12 06:32:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29380 for ; Wed, 12 Feb 2003 06:32:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CBfq007734 for tsvwg-archive@odin.ietf.org; Wed, 12 Feb 2003 06:41:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CBfWp07724; Wed, 12 Feb 2003 06:41:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CBe2p07649 for ; Wed, 12 Feb 2003 06:40:02 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29341 for ; Wed, 12 Feb 2003 06:30:10 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:1/RDGNTLN4L3aqYya1PghpP1tRxtlOE8@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1CBXrD16193; Wed, 12 Feb 2003 04:33:53 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1CBXrl24486; Wed, 12 Feb 2003 04:33:53 -0700 Date: Wed, 12 Feb 2003 04:33:53 -0700 From: "Brian F. G. Bidulock" To: Tuexen Michael Cc: Randall Stewart , Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030212043353.C16495@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from michael.tuexen@siemens.com on Wed, Feb 12, 2003 at 12:26:13PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Michael, I disagree. Adding an new INIT/INIT ACK procedure to start counting at 0 instead of 1 seems excessive to me. --brian On Wed, 12 Feb 2003, Tuexen Michael wrote: > Brian, > > I understand your point, but I think it is clearer to > define a new parameter of length 8 bytes to be included > in the INIT / INIT-ACK which indicates that this feature used. > Like in the case of PR-SCTP. This make the stuff explicit > and introduces almost no additional complexity. > > Best regards > Michael > > Michael Tuexen Tel.: +49 89 722 47210 > Siemens AG Fax: +49 89 722 48212 > ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: Wednesday, February 12, 2003 10:44 AM > > To: Tuexen Michael > > Cc: Randall Stewart; Michael Tuexen; Caitlin Bestler; tsvwg@ietf.org > > Subject: Re: [Tsvwg] A question of Un-Ordered SCTP > > > > > > Michael, > > > > Tuexen Michael wrote: > > (Wed, 12 Feb 2003 09:39:41) > > > > > > > > I think it would be good to see the requirement that the sequence > > > > number begin at 1 and be monotonically increasing in the > > saem fashion > > > > as ordered streams. > > > > > > > I would prefer that the two sequence spaces are handled the same > > > way. Thus both start with SSN=0. > > > > That would make it impossible to distinguish between SCTP's supporting > > the feature and SCTP's not supporting the feature on the first message > > in a stream. > > > > Leaving '0' for unordered packets of unspecified transmission > > order has > > some value for backwards compatibility and interoperability. > > > > --brian > > > > -- > > Brian F. G. Bidulock > > bidulock@openss7.org > > http://www.openss7.org/ > > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 12 06:59:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29885 for ; Wed, 12 Feb 2003 06:59:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CC8hv09263 for tsvwg-archive@odin.ietf.org; Wed, 12 Feb 2003 07:08:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CC8Jp09208; Wed, 12 Feb 2003 07:08:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CC5Qp08426 for ; Wed, 12 Feb 2003 07:05:26 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29823; Wed, 12 Feb 2003 06:55:32 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1CBwtu6003525; Wed, 12 Feb 2003 05:58:56 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E4A36FF.8050205@stewart.chicago.il.us> Date: Wed, 12 Feb 2003 05:58:55 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org, Michael Tuexen CC: Caitlin Bestler , tsvwg@ietf.org, Tuexen Michael , sigtran@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: <3E49899A.6010809@stewart.chicago.il.us> <20030211191543.A14481@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brian/Michael: I do like the idea of keeping things the same (aka same methodology)... this is good. It is also neat to be able to tell the difference between an implementation that supports this feature and one that does not. But there are positives and negatives, I think, to each idea... A) For using a TLV, (as Michael suggests) we really need to put this into a seperate draft.. when I do think one could easily fit this into the IG as Brian as suggested. B) montonically increasing numbers would eventually wrap when the SSN hit FFFF back to 0... thus the application would need to have some sort of state to track if the peer supported the feature. It seems to me it is only the first message that arrives that benefits from the start at 0. If the application assumes a "not supported", then by starting the SSN at 1 the app can flip the flag from "not supported" to "supported" on the arrival of the first message. If the application instead set its flag to "supported" the first message would not tell this information and instead it would only be upon the second arriving message that the app could make the flag determination... causing either a delay in delivery of the first message (yuck) or just toss it up and wait. More importantly, I am wondering, if the implementation does NOT support this, what will the app do? Change its message structure? If so it will need to have some clues (as the initiator) that its implementation does not support the feature .. possibly a HAVE_SCTP_UNORDERED_SSN in sctp.h... but the problem is you would not know about the other guy until its first unordered message arrives. So if you have to send the first message what do you do? if HAVE_SCTP_UNORDERED_SSN is 0.. no problem.. you send a message that has the imbedded sequence number.. but what do you send when HAVE_SCTP_UNRODERED_SSN is set to 1? If you send the imbedded sequence in the message anyway whats the point of this little trick? The second message (which you may have to send before knowing receiving a unordered msg from the peer) would still have this, and maybe the third etc... Hmm.. the more I think on this the more it becomes clear that you must know ahead of time i.e. when the association comes up to "do the right thing".... which goes back to Michaels idea of a TLV. I have been wondering for quite some time now if we don't just need a TLV in the INIT/INIT-ACK that indicate features in general... something like a bit mask or byte array indicating each feature... addip delip prsctp setprimary unordered-assigns-sequences etc.. Maybe this is a better way to go.. and we could write a short draft dictating this bit/byte TLV... code as a 0x80 class.. that way old implementations will throw it away... (we really don't care if they don't understand it)... I have been avoiding this.. but it might be the best approach.. Then again, I guess it could also be put in addip or prsctp since it would effect them as well :> Then one could put the other change in the IG and thus have a very easy change that is in the IG and a minor update to either addip or prsctp... What do you all think? R Brian F. G. Bidulock wrote: > Randall, > > I agree to having SCTP set the sequence number and, as you said in > your first note, SCTP passing the sequence number to the ULP on > the receiving side is already done for ordered traffic. Some even > pass the zero now. > > I suppose that SCTP would set this sequence number when it is given > the data for delivery at the sending ULP and the sequence would represent > the order that the data was presented to SCTP by the ULP at the sending > side. > > I think it would be good to see the requirement that the sequence > number begin at 1 and be monotonically increasing in the saem fashion > as ordered streams. > > That way RDDP and other applications could perform their own reordering > at the receiver. I think it would be a good thing to have SCTP set > this value. > > In fact, I can see another application for this feature. M2PA > (SIGTRAN protocol) needs in some circumstances to send data unordered > with the hope of expedited delivery (does not want control information > stuck behind large amounts of data in an ordered stream), however, the > order of processing of the expedited control information is important. > > This facility would permit M2PA to send such information unordered > to expedite it and the receiver could perform the reordering itself. > Up until now, the only solution was to place a sequence number in with > the control information. > > Could we perhaps add a section to the SCTP IG. "Problem statement: > the sender wishes to send unordered data but the receive needs to know > the original order of sending..." or some such. > > It should be quite simple to add the feature to existing SCTP > implementations. > > --brian > > > On Tue, 11 Feb 2003, Randall Stewart wrote: > > >>Michael: >> >>This seems like a valid method.. it gets around Brian's objection >>(which was a good point) and yet still provides the application with >>a hint about what the assigned sequence order was on the unordered >>messages... >> >>R >> >>Michael Tuexen wrote: >> >>>Caitlin, >>> >>>thank you very much for the clarification. >>> >>>I do not like the idea to pass the SSN transparently from the ULP to the >>>ULP. >>>But having two sequence spaces is OK for me. This means that the SSN at the >>>sending side is controlled by the SCTP and given to the ULP at the >>>receiving side. >>> >>>This would be a clean solution. So I voting for have two separate number >>>spaces >>>for user data. Since the one for ordered delivery exists already in RFC >>>2960, this >>>only means that a new one is introduced for the unordered delivery user >>>data. >>> >>>Best regards >>>Michael >>> >>>On Tuesday, Feb 11, 2003, at 17:37 Europe/Berlin, Caitlin Bestler wrote: >>> >>> >>>>On 2/11/03, Tuexen Michael wrote: >>>> >>>> >>>>>Dear all, >>>>> >>>>>does this mean that you want two sequence spaces per >>>>>stream: one for the 'ordered' user data and one for the >>>>>unordered user data? >>>>> >>>> >>>>The RDDP/SCTP adaptation only uses unordered delivery, so >>>>that question did not really arise. >>>> >>>>But if you were to generalize the problem, I believe the >>>>answer would be yes. >>>> >>>>The SSN for ordered delivery would be unchanged. The >>>>addition would be providing "advisory ordering" for >>>>unordered delivery. The general characteristic is that >>>>the receiving ULP wants the data in whatever order it >>>>arrives, but wants to know what the original order was. >>>> >>>>In addition to RDDP, RTP over UDP is another example of >>>>an application that wants to be aware of the original >>>>ordering, even while accepting the data out-of-order. >>>> >>>>Caitlin Bestler >>>>http://asomi.com/CaitlinBestler/ >>>>_______________________________________________ >>>>tsvwg mailing list >>>>tsvwg@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/tsvwg >>>> >>> >>>_______________________________________________ >>>tsvwg mailing list >>>tsvwg@ietf.org >>>https://www1.ietf.org/mailman/listinfo/tsvwg >>> >>> >> >> >>-- >>Randall R. Stewart >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) >> >>_______________________________________________ >>tsvwg mailing list >>tsvwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 12 07:15:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00184 for ; Wed, 12 Feb 2003 07:15:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CCOYX09957 for tsvwg-archive@odin.ietf.org; Wed, 12 Feb 2003 07:24:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCOAp09911; Wed, 12 Feb 2003 07:24:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCNHp09869 for ; Wed, 12 Feb 2003 07:23:17 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00144; Wed, 12 Feb 2003 07:13:21 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA15542; Wed, 12 Feb 2003 13:17:02 +0100 (MET) Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA10951; Wed, 12 Feb 2003 13:17:03 +0100 (MET) Received: by MCHH248E with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Feb 2003 13:16:13 +0100 Message-ID: From: Schwarzbauer Hanns Juergen To: "'Randall Stewart'" Cc: tsvwg@ietf.org, sigtran@ietf.org Subject: AW: [Sigtran] Re: [Tsvwg] A question of Un-Ordered SCTP Date: Wed, 12 Feb 2003 13:15:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1CCNHp09870 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Randy, I definitely would appreciate such a possibility, but not based on a bit map. Using only one bit per feature would narrow limits on the number of features that could be supported. greetings HannsJuergen > -----Ursprüngliche Nachricht----- > Von: Randall Stewart [mailto:randall@stewart.chicago.il.us] > Gesendet: Mittwoch, 12. Februar 2003 12:59 > An: bidulock@openss7.org; Michael Tuexen > Cc: Caitlin Bestler; tsvwg@ietf.org; Tuexen Michael; sigtran@ietf.org > Betreff: [Sigtran] Re: [Tsvwg] A question of Un-Ordered SCTP > > > Brian/Michael: > > I do like the idea of keeping things the same (aka same > methodology)... this is good. > > It is also neat to be able to tell the difference between > an implementation that supports this feature and one that > does not. But there are positives and negatives, I think, > to each idea... > > A) For using a TLV, (as Michael suggests) > we really need to put this into a seperate > draft.. when I do think one could easily fit > this into the IG as Brian as suggested. > > B) montonically increasing numbers would eventually > wrap when the SSN hit FFFF back to 0... thus > the application would need to have some sort > of state to track if the peer supported the > feature. > > It seems to me it is only the first message that > arrives that benefits from the start at 0. If the > application assumes a "not supported", then by > starting the SSN at 1 the app can flip the flag > from "not supported" to "supported" on the arrival > of the first message. > > If the application instead set its flag to "supported" > the first message would not tell this information and > instead it would only be upon the second arriving message > that the app could make the flag determination... causing > either a delay in delivery of the first message (yuck) or > just toss it up and wait. > > More importantly, I am wondering, if the implementation does > NOT support this, what will the app do? Change its > message structure? If so it will need to have some clues > (as the initiator) that its implementation does not > support the feature .. possibly a HAVE_SCTP_UNORDERED_SSN > in sctp.h... but the problem is you would not know about > the other guy until its first unordered message arrives. > So if you have to send the first message what do you do? > > if HAVE_SCTP_UNORDERED_SSN is 0.. no problem.. you > send a message that has the imbedded sequence number.. but > what do you send when HAVE_SCTP_UNRODERED_SSN is set to 1? > > If you send the imbedded sequence in the message anyway whats > the point of this little trick? The second message (which you > may have to send before knowing receiving a unordered > msg from the peer) would still have this, and maybe the third > etc... > > Hmm.. the more I think on this the more it becomes clear that > you must know ahead of time i.e. when the association comes > up to "do the right thing".... which goes back to Michaels > idea of a TLV. > > I have been wondering for quite some time now if we don't > just need a TLV in the INIT/INIT-ACK that indicate features > in general... something like a bit mask or byte array indicating > each feature... > > addip > delip > prsctp > setprimary > unordered-assigns-sequences > > etc.. > > Maybe this is a better way to go.. and we could write a short > draft dictating this bit/byte TLV... code as a 0x80 class.. that > way old implementations will throw it away... (we really don't > care if they don't understand it)... > > I have been avoiding this.. but it might be the best approach.. > > Then again, I guess it could also be put in addip or prsctp since > it would effect them as well :> Then one could put the > other change in the IG and thus have a very easy change that > is in the IG and a minor update to either addip or prsctp... > > > What do you all think? > > R > > Brian F. G. Bidulock wrote: > > Randall, > > > > I agree to having SCTP set the sequence number and, as you said in > > your first note, SCTP passing the sequence number to the ULP on > > the receiving side is already done for ordered traffic. Some even > > pass the zero now. > > > > I suppose that SCTP would set this sequence number when it is given > > the data for delivery at the sending ULP and the sequence > would represent > > the order that the data was presented to SCTP by the ULP at > the sending > > side. > > > > I think it would be good to see the requirement that the sequence > > number begin at 1 and be monotonically increasing in the > saem fashion > > as ordered streams. > > > > That way RDDP and other applications could perform their > own reordering > > at the receiver. I think it would be a good thing to have SCTP set > > this value. > > > > In fact, I can see another application for this feature. M2PA > > (SIGTRAN protocol) needs in some circumstances to send data > unordered > > with the hope of expedited delivery (does not want control > information > > stuck behind large amounts of data in an ordered stream), > however, the > > order of processing of the expedited control information is > important. > > > > This facility would permit M2PA to send such information unordered > > to expedite it and the receiver could perform the reordering itself. > > Up until now, the only solution was to place a sequence > number in with > > the control information. > > > > Could we perhaps add a section to the SCTP IG. "Problem statement: > > the sender wishes to send unordered data but the receive > needs to know > > the original order of sending..." or some such. > > > > It should be quite simple to add the feature to existing SCTP > > implementations. > > > > --brian > > > > > > On Tue, 11 Feb 2003, Randall Stewart wrote: > > > > > >>Michael: > >> > >>This seems like a valid method.. it gets around Brian's objection > >>(which was a good point) and yet still provides the application with > >>a hint about what the assigned sequence order was on the unordered > >>messages... > >> > >>R > >> > >>Michael Tuexen wrote: > >> > >>>Caitlin, > >>> > >>>thank you very much for the clarification. > >>> > >>>I do not like the idea to pass the SSN transparently from > the ULP to the > >>>ULP. > >>>But having two sequence spaces is OK for me. This means > that the SSN at the > >>>sending side is controlled by the SCTP and given to the ULP at the > >>>receiving side. > >>> > >>>This would be a clean solution. So I voting for have two > separate number > >>>spaces > >>>for user data. Since the one for ordered delivery exists > already in RFC > >>>2960, this > >>>only means that a new one is introduced for the unordered > delivery user > >>>data. > >>> > >>>Best regards > >>>Michael > >>> > >>>On Tuesday, Feb 11, 2003, at 17:37 Europe/Berlin, Caitlin > Bestler wrote: > >>> > >>> > >>>>On 2/11/03, Tuexen Michael wrote: > >>>> > >>>> > >>>>>Dear all, > >>>>> > >>>>>does this mean that you want two sequence spaces per > >>>>>stream: one for the 'ordered' user data and one for the > >>>>>unordered user data? > >>>>> > >>>> > >>>>The RDDP/SCTP adaptation only uses unordered delivery, so > >>>>that question did not really arise. > >>>> > >>>>But if you were to generalize the problem, I believe the > >>>>answer would be yes. > >>>> > >>>>The SSN for ordered delivery would be unchanged. The > >>>>addition would be providing "advisory ordering" for > >>>>unordered delivery. The general characteristic is that > >>>>the receiving ULP wants the data in whatever order it > >>>>arrives, but wants to know what the original order was. > >>>> > >>>>In addition to RDDP, RTP over UDP is another example of > >>>>an application that wants to be aware of the original > >>>>ordering, even while accepting the data out-of-order. > >>>> > >>>>Caitlin Bestler > >>>>http://asomi.com/CaitlinBestler/ > >>>>_______________________________________________ > >>>>tsvwg mailing list > >>>>tsvwg@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/tsvwg > >>>> > >>> > >>>_______________________________________________ > >>>tsvwg mailing list > >>>tsvwg@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/tsvwg > >>> > >>> > >> > >> > >>-- > >>Randall R. Stewart > >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) > >> > >>_______________________________________________ > >>tsvwg mailing list > >>tsvwg@ietf.org > >>https://www1.ietf.org/mailman/listinfo/tsvwg > > > > > > > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 12 07:20:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00381 for ; Wed, 12 Feb 2003 07:20:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CCTdJ10298 for tsvwg-archive@odin.ietf.org; Wed, 12 Feb 2003 07:29:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCT3p10208; Wed, 12 Feb 2003 07:29:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCSZp10173 for ; Wed, 12 Feb 2003 07:28:35 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00328; Wed, 12 Feb 2003 07:18:39 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:nrPNu/O+or2jPCcjvFc2Il/njb1X0mo3@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1CCMND16850; Wed, 12 Feb 2003 05:22:23 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1CCMNv30963; Wed, 12 Feb 2003 05:22:23 -0700 Date: Wed, 12 Feb 2003 05:22:23 -0700 From: "Brian F. G. Bidulock" To: Randall Stewart Cc: Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org, Tuexen Michael , sigtran@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030212052223.A29464@openss7.org> Reply-To: bidulock@openss7.org Mail-Followup-To: Randall Stewart , Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org, Tuexen Michael , sigtran@ietf.org References: <3E49899A.6010809@stewart.chicago.il.us> <20030211191543.A14481@openss7.org> <3E4A36FF.8050205@stewart.chicago.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E4A36FF.8050205@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Wed, Feb 12, 2003 at 05:58:55AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Randall, For the M2PA application, I think that reserving '0' for unordered messages for which the order of sending is unimportant is still a good idea. So the number space from 1 to 0xffff indicates importance of order. '0' indicates no importance of order. As in M2PA's case, a sender could mix both on the same stream. There then becomes three different types of messages: 1) Unordered messages for which the order of sending is unimportant (U-bit SSN=0), 2) unordered messages for which the order of sending is important (U-bit SSN!=0), and 3) ordered messages for which the order of sending is important (~U-bit). And this also handles compatibility because previous unordered messages fall into category (1) by nature of the fact that SSN==0. But starting counting at 1, you get rid of the ability to indicate that the order of sending is unimportant and force the receiving ULP to handle ordering of all received unordered data. So, in short, start counting at 1, regardless of whether there is an indicator in the INIT/INIT-ACK. --brian Randall Stewart wrote: (Wed, 12 Feb 2003 05:58:55) > Brian/Michael: > > I do like the idea of keeping things the same (aka same > methodology)... this is good. > > It is also neat to be able to tell the difference between > an implementation that supports this feature and one that > does not. But there are positives and negatives, I think, > to each idea... > > A) For using a TLV, (as Michael suggests) > we really need to put this into a seperate > draft.. when I do think one could easily fit > this into the IG as Brian as suggested. > > B) montonically increasing numbers would eventually > wrap when the SSN hit FFFF back to 0... thus > the application would need to have some sort > of state to track if the peer supported the > feature. > > It seems to me it is only the first message that > arrives that benefits from the start at 0. If the > application assumes a "not supported", then by > starting the SSN at 1 the app can flip the flag > from "not supported" to "supported" on the arrival > of the first message. > > If the application instead set its flag to "supported" > the first message would not tell this information and > instead it would only be upon the second arriving message > that the app could make the flag determination... causing > either a delay in delivery of the first message (yuck) or > just toss it up and wait. > > More importantly, I am wondering, if the implementation does > NOT support this, what will the app do? Change its > message structure? If so it will need to have some clues > (as the initiator) that its implementation does not > support the feature .. possibly a HAVE_SCTP_UNORDERED_SSN > in sctp.h... but the problem is you would not know about > the other guy until its first unordered message arrives. > So if you have to send the first message what do you do? > > if HAVE_SCTP_UNORDERED_SSN is 0.. no problem.. you > send a message that has the imbedded sequence number.. but > what do you send when HAVE_SCTP_UNRODERED_SSN is set to 1? > > If you send the imbedded sequence in the message anyway whats > the point of this little trick? The second message (which you > may have to send before knowing receiving a unordered > msg from the peer) would still have this, and maybe the third > etc... > > Hmm.. the more I think on this the more it becomes clear that > you must know ahead of time i.e. when the association comes > up to "do the right thing".... which goes back to Michaels > idea of a TLV. > > I have been wondering for quite some time now if we don't > just need a TLV in the INIT/INIT-ACK that indicate features > in general... something like a bit mask or byte array indicating > each feature... > > addip > delip > prsctp > setprimary > unordered-assigns-sequences > > etc.. > > Maybe this is a better way to go.. and we could write a short > draft dictating this bit/byte TLV... code as a 0x80 class.. that > way old implementations will throw it away... (we really don't > care if they don't understand it)... > > I have been avoiding this.. but it might be the best approach.. > > Then again, I guess it could also be put in addip or prsctp since > it would effect them as well :> Then one could put the > other change in the IG and thus have a very easy change that > is in the IG and a minor update to either addip or prsctp... > > > What do you all think? > > R > > Brian F. G. Bidulock wrote: > > Randall, > > > > I agree to having SCTP set the sequence number and, as you said in > > your first note, SCTP passing the sequence number to the ULP on > > the receiving side is already done for ordered traffic. Some even > > pass the zero now. > > > > I suppose that SCTP would set this sequence number when it is given > > the data for delivery at the sending ULP and the sequence would represent > > the order that the data was presented to SCTP by the ULP at the sending > > side. > > > > I think it would be good to see the requirement that the sequence > > number begin at 1 and be monotonically increasing in the saem fashion > > as ordered streams. > > > > That way RDDP and other applications could perform their own reordering > > at the receiver. I think it would be a good thing to have SCTP set > > this value. > > > > In fact, I can see another application for this feature. M2PA > > (SIGTRAN protocol) needs in some circumstances to send data unordered > > with the hope of expedited delivery (does not want control information > > stuck behind large amounts of data in an ordered stream), however, the > > order of processing of the expedited control information is important. > > > > This facility would permit M2PA to send such information unordered > > to expedite it and the receiver could perform the reordering itself. > > Up until now, the only solution was to place a sequence number in with > > the control information. > > > > Could we perhaps add a section to the SCTP IG. "Problem statement: > > the sender wishes to send unordered data but the receive needs to know > > the original order of sending..." or some such. > > > > It should be quite simple to add the feature to existing SCTP > > implementations. > > > > --brian > > > > > > On Tue, 11 Feb 2003, Randall Stewart wrote: > > > > > >>Michael: > >> > >>This seems like a valid method.. it gets around Brian's objection > >>(which was a good point) and yet still provides the application with > >>a hint about what the assigned sequence order was on the unordered > >>messages... > >> > >>R > >> > >>Michael Tuexen wrote: > >> > >>>Caitlin, > >>> > >>>thank you very much for the clarification. > >>> > >>>I do not like the idea to pass the SSN transparently from the ULP to the > >>>ULP. > >>>But having two sequence spaces is OK for me. This means that the SSN at the > >>>sending side is controlled by the SCTP and given to the ULP at the > >>>receiving side. > >>> > >>>This would be a clean solution. So I voting for have two separate number > >>>spaces > >>>for user data. Since the one for ordered delivery exists already in RFC > >>>2960, this > >>>only means that a new one is introduced for the unordered delivery user > >>>data. > >>> > >>>Best regards > >>>Michael > >>> > >>>On Tuesday, Feb 11, 2003, at 17:37 Europe/Berlin, Caitlin Bestler wrote: > >>> > >>> > >>>>On 2/11/03, Tuexen Michael wrote: > >>>> > >>>> > >>>>>Dear all, > >>>>> > >>>>>does this mean that you want two sequence spaces per > >>>>>stream: one for the 'ordered' user data and one for the > >>>>>unordered user data? > >>>>> > >>>> > >>>>The RDDP/SCTP adaptation only uses unordered delivery, so > >>>>that question did not really arise. > >>>> > >>>>But if you were to generalize the problem, I believe the > >>>>answer would be yes. > >>>> > >>>>The SSN for ordered delivery would be unchanged. The > >>>>addition would be providing "advisory ordering" for > >>>>unordered delivery. The general characteristic is that > >>>>the receiving ULP wants the data in whatever order it > >>>>arrives, but wants to know what the original order was. > >>>> > >>>>In addition to RDDP, RTP over UDP is another example of > >>>>an application that wants to be aware of the original > >>>>ordering, even while accepting the data out-of-order. > >>>> > >>>>Caitlin Bestler > >>>>http://asomi.com/CaitlinBestler/ > >>>>_______________________________________________ > >>>>tsvwg mailing list > >>>>tsvwg@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/tsvwg > >>>> > >>> > >>>_______________________________________________ > >>>tsvwg mailing list > >>>tsvwg@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/tsvwg > >>> > >>> > >> > >> > >>-- > >>Randall R. Stewart > >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) > >> > >>_______________________________________________ > >>tsvwg mailing list > >>tsvwg@ietf.org > >>https://www1.ietf.org/mailman/listinfo/tsvwg > > > > > > > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 12 07:20:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00398 for ; Wed, 12 Feb 2003 07:20:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CCTnI10311 for tsvwg-archive@odin.ietf.org; Wed, 12 Feb 2003 07:29:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCTBp10254; Wed, 12 Feb 2003 07:29:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCSmp10187 for ; Wed, 12 Feb 2003 07:28:48 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00335; Wed, 12 Feb 2003 07:18:53 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1CCMau6003573; Wed, 12 Feb 2003 06:22:37 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E4A3C8C.6030805@stewart.chicago.il.us> Date: Wed, 12 Feb 2003 06:22:36 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Schwarzbauer Hanns Juergen CC: tsvwg@ietf.org, sigtran@ietf.org Subject: Re: AW: [Sigtran] Re: [Tsvwg] A question of Un-Ordered SCTP References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hanns: Yes.. I knew you would feel that way and thats why I said bit mask or byte array :> I do like Michaels proposal.. R Schwarzbauer Hanns Juergen wrote: > Randy, > > I definitely would appreciate such a possibility, but not based on a bit map. > Using only one bit per feature would narrow limits on the number of features that could be supported. > > greetings > > HannsJuergen > > >>-----Ursprüngliche Nachricht----- >>Von: Randall Stewart [mailto:randall@stewart.chicago.il.us] >>Gesendet: Mittwoch, 12. Februar 2003 12:59 >>An: bidulock@openss7.org; Michael Tuexen >>Cc: Caitlin Bestler; tsvwg@ietf.org; Tuexen Michael; sigtran@ietf.org >>Betreff: [Sigtran] Re: [Tsvwg] A question of Un-Ordered SCTP >> >> >>Brian/Michael: >> >>I do like the idea of keeping things the same (aka same >>methodology)... this is good. >> >>It is also neat to be able to tell the difference between >>an implementation that supports this feature and one that >>does not. But there are positives and negatives, I think, >>to each idea... >> >>A) For using a TLV, (as Michael suggests) >> we really need to put this into a seperate >> draft.. when I do think one could easily fit >> this into the IG as Brian as suggested. >> >>B) montonically increasing numbers would eventually >> wrap when the SSN hit FFFF back to 0... thus >> the application would need to have some sort >> of state to track if the peer supported the >> feature. >> >>It seems to me it is only the first message that >>arrives that benefits from the start at 0. If the >>application assumes a "not supported", then by >>starting the SSN at 1 the app can flip the flag >>from "not supported" to "supported" on the arrival >>of the first message. >> >>If the application instead set its flag to "supported" >>the first message would not tell this information and >>instead it would only be upon the second arriving message >>that the app could make the flag determination... causing >>either a delay in delivery of the first message (yuck) or >>just toss it up and wait. >> >>More importantly, I am wondering, if the implementation does >>NOT support this, what will the app do? Change its >>message structure? If so it will need to have some clues >>(as the initiator) that its implementation does not >>support the feature .. possibly a HAVE_SCTP_UNORDERED_SSN >>in sctp.h... but the problem is you would not know about >>the other guy until its first unordered message arrives. >>So if you have to send the first message what do you do? >> >>if HAVE_SCTP_UNORDERED_SSN is 0.. no problem.. you >>send a message that has the imbedded sequence number.. but >>what do you send when HAVE_SCTP_UNRODERED_SSN is set to 1? >> >>If you send the imbedded sequence in the message anyway whats >>the point of this little trick? The second message (which you >>may have to send before knowing receiving a unordered >>msg from the peer) would still have this, and maybe the third >>etc... >> >>Hmm.. the more I think on this the more it becomes clear that >>you must know ahead of time i.e. when the association comes >>up to "do the right thing".... which goes back to Michaels >>idea of a TLV. >> >>I have been wondering for quite some time now if we don't >>just need a TLV in the INIT/INIT-ACK that indicate features >>in general... something like a bit mask or byte array indicating >>each feature... >> >>addip >>delip >>prsctp >>setprimary >>unordered-assigns-sequences >> >>etc.. >> >>Maybe this is a better way to go.. and we could write a short >>draft dictating this bit/byte TLV... code as a 0x80 class.. that >>way old implementations will throw it away... (we really don't >>care if they don't understand it)... >> >>I have been avoiding this.. but it might be the best approach.. >> >>Then again, I guess it could also be put in addip or prsctp since >>it would effect them as well :> Then one could put the >>other change in the IG and thus have a very easy change that >>is in the IG and a minor update to either addip or prsctp... >> >> >>What do you all think? >> >>R >> >>Brian F. G. Bidulock wrote: >> >>>Randall, >>> >>>I agree to having SCTP set the sequence number and, as you said in >>>your first note, SCTP passing the sequence number to the ULP on >>>the receiving side is already done for ordered traffic. Some even >>>pass the zero now. >>> >>>I suppose that SCTP would set this sequence number when it is given >>>the data for delivery at the sending ULP and the sequence >> >>would represent >> >>>the order that the data was presented to SCTP by the ULP at >> >>the sending >> >>>side. >>> >>>I think it would be good to see the requirement that the sequence >>>number begin at 1 and be monotonically increasing in the >> >>saem fashion >> >>>as ordered streams. >>> >>>That way RDDP and other applications could perform their >> >>own reordering >> >>>at the receiver. I think it would be a good thing to have SCTP set >>>this value. >>> >>>In fact, I can see another application for this feature. M2PA >>>(SIGTRAN protocol) needs in some circumstances to send data >> >>unordered >> >>>with the hope of expedited delivery (does not want control >> >>information >> >>>stuck behind large amounts of data in an ordered stream), >> >>however, the >> >>>order of processing of the expedited control information is >> >>important. >> >>>This facility would permit M2PA to send such information unordered >>>to expedite it and the receiver could perform the reordering itself. >>>Up until now, the only solution was to place a sequence >> >>number in with >> >>>the control information. >>> >>>Could we perhaps add a section to the SCTP IG. "Problem statement: >>>the sender wishes to send unordered data but the receive >> >>needs to know >> >>>the original order of sending..." or some such. >>> >>>It should be quite simple to add the feature to existing SCTP >>>implementations. >>> >>>--brian >>> >>> >>>On Tue, 11 Feb 2003, Randall Stewart wrote: >>> >>> >>> >>>>Michael: >>>> >>>>This seems like a valid method.. it gets around Brian's objection >>>>(which was a good point) and yet still provides the application with >>>>a hint about what the assigned sequence order was on the unordered >>>>messages... >>>> >>>>R >>>> >>>>Michael Tuexen wrote: >>>> >>>> >>>>>Caitlin, >>>>> >>>>>thank you very much for the clarification. >>>>> >>>>>I do not like the idea to pass the SSN transparently from >>>> >>the ULP to the >> >>>>>ULP. >>>>>But having two sequence spaces is OK for me. This means >>>> >>that the SSN at the >> >>>>>sending side is controlled by the SCTP and given to the ULP at the >>>>>receiving side. >>>>> >>>>>This would be a clean solution. So I voting for have two >>>> >>separate number >> >>>>>spaces >>>>>for user data. Since the one for ordered delivery exists >>>> >>already in RFC >> >>>>>2960, this >>>>>only means that a new one is introduced for the unordered >>>> >>delivery user >> >>>>>data. >>>>> >>>>>Best regards >>>>>Michael >>>>> >>>>>On Tuesday, Feb 11, 2003, at 17:37 Europe/Berlin, Caitlin >>>> >>Bestler wrote: >> >>>>> >>>>>>On 2/11/03, Tuexen Michael wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Dear all, >>>>>>> >>>>>>>does this mean that you want two sequence spaces per >>>>>>>stream: one for the 'ordered' user data and one for the >>>>>>>unordered user data? >>>>>>> >>>>>> >>>>>>The RDDP/SCTP adaptation only uses unordered delivery, so >>>>>>that question did not really arise. >>>>>> >>>>>>But if you were to generalize the problem, I believe the >>>>>>answer would be yes. >>>>>> >>>>>>The SSN for ordered delivery would be unchanged. The >>>>>>addition would be providing "advisory ordering" for >>>>>>unordered delivery. The general characteristic is that >>>>>>the receiving ULP wants the data in whatever order it >>>>>>arrives, but wants to know what the original order was. >>>>>> >>>>>>In addition to RDDP, RTP over UDP is another example of >>>>>>an application that wants to be aware of the original >>>>>>ordering, even while accepting the data out-of-order. >>>>>> >>>>>>Caitlin Bestler >>>>>>http://asomi.com/CaitlinBestler/ >>>>>>_______________________________________________ >>>>>>tsvwg mailing list >>>>>>tsvwg@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/tsvwg >>>>>> >>>>> >>>>>_______________________________________________ >>>>>tsvwg mailing list >>>>>tsvwg@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/tsvwg >>>>> >>>>> >>>> >>>> >>>>-- >>>>Randall R. Stewart >>>>randall@stewart.chicago.il.us 815-342-5222 (cell phone) >>>> >>>>_______________________________________________ >>>>tsvwg mailing list >>>>tsvwg@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/tsvwg >>> >>> >> >>-- >>Randall R. Stewart >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) >> >>_______________________________________________ >>Sigtran mailing list >>Sigtran@ietf.org >>https://www1.ietf.org/mailman/listinfo/sigtran >> > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 12 07:23:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00486 for ; Wed, 12 Feb 2003 07:22:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CCWMK10533 for tsvwg-archive@odin.ietf.org; Wed, 12 Feb 2003 07:32:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCW6p10493; Wed, 12 Feb 2003 07:32:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCVdp10442 for ; Wed, 12 Feb 2003 07:31:39 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00437; Wed, 12 Feb 2003 07:21:44 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1CCPQu6003585; Wed, 12 Feb 2003 06:25:27 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E4A3D36.4030401@stewart.chicago.il.us> Date: Wed, 12 Feb 2003 06:25:26 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuexen Michael CC: bidulock@openss7.org, Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org, sigtran@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This looks good.. but would it be better to make the FEATURE_ID 16 bits.. .. my reasoning is that cookies are getting bigger and it might be best to control there length to some degree... I could go either way but I think 65,535 features is more than enough to choose from :> R Tuexen Michael wrote: > Randy, > > I think having a FEATURES parameter would be a good idea. I do not > like the idea of bitmask. Instead of this I would propose something > like a FEATURES parameter which looks like: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | FEATURES_PARAMETER_ID | Parameter Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | FEATURE_ID 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | FEATURE_ID 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | FEATURE_ID 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | FEATURE_ID 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Each feature will be an IANA assiged 32 bit uint. This is extendable. > > Best regards > Michael > > Michael Tuexen Tel.: +49 89 722 47210 > Siemens AG Fax: +49 89 722 48212 > ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > > >>-----Original Message----- >>From: Randall Stewart [mailto:randall@stewart.chicago.il.us] >>Sent: Wednesday, February 12, 2003 12:59 PM >>To: bidulock@openss7.org; Michael Tuexen >>Cc: Caitlin Bestler; tsvwg@ietf.org; Tuexen Michael; sigtran@ietf.org >>Subject: Re: [Tsvwg] A question of Un-Ordered SCTP >> >> >>Brian/Michael: >> >>I do like the idea of keeping things the same (aka same >>methodology)... this is good. >> >>It is also neat to be able to tell the difference between >>an implementation that supports this feature and one that >>does not. But there are positives and negatives, I think, >>to each idea... >> >>A) For using a TLV, (as Michael suggests) >> we really need to put this into a seperate >> draft.. when I do think one could easily fit >> this into the IG as Brian as suggested. >> >>B) montonically increasing numbers would eventually >> wrap when the SSN hit FFFF back to 0... thus >> the application would need to have some sort >> of state to track if the peer supported the >> feature. >> >>It seems to me it is only the first message that >>arrives that benefits from the start at 0. If the >>application assumes a "not supported", then by >>starting the SSN at 1 the app can flip the flag >>from "not supported" to "supported" on the arrival >>of the first message. >> >>If the application instead set its flag to "supported" >>the first message would not tell this information and >>instead it would only be upon the second arriving message >>that the app could make the flag determination... causing >>either a delay in delivery of the first message (yuck) or >>just toss it up and wait. >> >>More importantly, I am wondering, if the implementation does >>NOT support this, what will the app do? Change its >>message structure? If so it will need to have some clues >>(as the initiator) that its implementation does not >>support the feature .. possibly a HAVE_SCTP_UNORDERED_SSN >>in sctp.h... but the problem is you would not know about >>the other guy until its first unordered message arrives. >>So if you have to send the first message what do you do? >> >>if HAVE_SCTP_UNORDERED_SSN is 0.. no problem.. you >>send a message that has the imbedded sequence number.. but >>what do you send when HAVE_SCTP_UNRODERED_SSN is set to 1? >> >>If you send the imbedded sequence in the message anyway whats >>the point of this little trick? The second message (which you >>may have to send before knowing receiving a unordered >>msg from the peer) would still have this, and maybe the third >>etc... >> >>Hmm.. the more I think on this the more it becomes clear that >>you must know ahead of time i.e. when the association comes >>up to "do the right thing".... which goes back to Michaels >>idea of a TLV. >> >>I have been wondering for quite some time now if we don't >>just need a TLV in the INIT/INIT-ACK that indicate features >>in general... something like a bit mask or byte array indicating >>each feature... >> >>addip >>delip >>prsctp >>setprimary >>unordered-assigns-sequences >> >>etc.. >> >>Maybe this is a better way to go.. and we could write a short >>draft dictating this bit/byte TLV... code as a 0x80 class.. that >>way old implementations will throw it away... (we really don't >>care if they don't understand it)... >> >>I have been avoiding this.. but it might be the best approach.. >> >>Then again, I guess it could also be put in addip or prsctp since >>it would effect them as well :> Then one could put the >>other change in the IG and thus have a very easy change that >>is in the IG and a minor update to either addip or prsctp... >> >> >>What do you all think? >> >>R >> >>Brian F. G. Bidulock wrote: >> >>>Randall, >>> >>>I agree to having SCTP set the sequence number and, as you said in >>>your first note, SCTP passing the sequence number to the ULP on >>>the receiving side is already done for ordered traffic. Some even >>>pass the zero now. >>> >>>I suppose that SCTP would set this sequence number when it is given >>>the data for delivery at the sending ULP and the sequence >> >>would represent >> >>>the order that the data was presented to SCTP by the ULP at >> >>the sending >> >>>side. >>> >>>I think it would be good to see the requirement that the sequence >>>number begin at 1 and be monotonically increasing in the >> >>saem fashion >> >>>as ordered streams. >>> >>>That way RDDP and other applications could perform their >> >>own reordering >> >>>at the receiver. I think it would be a good thing to have SCTP set >>>this value. >>> >>>In fact, I can see another application for this feature. M2PA >>>(SIGTRAN protocol) needs in some circumstances to send data >> >>unordered >> >>>with the hope of expedited delivery (does not want control >> >>information >> >>>stuck behind large amounts of data in an ordered stream), >> >>however, the >> >>>order of processing of the expedited control information is >> >>important. >> >>>This facility would permit M2PA to send such information unordered >>>to expedite it and the receiver could perform the reordering itself. >>>Up until now, the only solution was to place a sequence >> >>number in with >> >>>the control information. >>> >>>Could we perhaps add a section to the SCTP IG. "Problem statement: >>>the sender wishes to send unordered data but the receive >> >>needs to know >> >>>the original order of sending..." or some such. >>> >>>It should be quite simple to add the feature to existing SCTP >>>implementations. >>> >>>--brian >>> >>> >>>On Tue, 11 Feb 2003, Randall Stewart wrote: >>> >>> >>> >>>>Michael: >>>> >>>>This seems like a valid method.. it gets around Brian's objection >>>>(which was a good point) and yet still provides the application with >>>>a hint about what the assigned sequence order was on the unordered >>>>messages... >>>> >>>>R >>>> >>>>Michael Tuexen wrote: >>>> >>>> >>>>>Caitlin, >>>>> >>>>>thank you very much for the clarification. >>>>> >>>>>I do not like the idea to pass the SSN transparently from >>>> >>the ULP to the >> >>>>>ULP. >>>>>But having two sequence spaces is OK for me. This means >>>> >>that the SSN at the >> >>>>>sending side is controlled by the SCTP and given to the ULP at the >>>>>receiving side. >>>>> >>>>>This would be a clean solution. So I voting for have two >>>> >>separate number >> >>>>>spaces >>>>>for user data. Since the one for ordered delivery exists >>>> >>already in RFC >> >>>>>2960, this >>>>>only means that a new one is introduced for the unordered >>>> >>delivery user >> >>>>>data. >>>>> >>>>>Best regards >>>>>Michael >>>>> >>>>>On Tuesday, Feb 11, 2003, at 17:37 Europe/Berlin, Caitlin >>>> >>Bestler wrote: >> >>>>> >>>>>>On 2/11/03, Tuexen Michael wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Dear all, >>>>>>> >>>>>>>does this mean that you want two sequence spaces per >>>>>>>stream: one for the 'ordered' user data and one for the >>>>>>>unordered user data? >>>>>>> >>>>>> >>>>>>The RDDP/SCTP adaptation only uses unordered delivery, so >>>>>>that question did not really arise. >>>>>> >>>>>>But if you were to generalize the problem, I believe the >>>>>>answer would be yes. >>>>>> >>>>>>The SSN for ordered delivery would be unchanged. The >>>>>>addition would be providing "advisory ordering" for >>>>>>unordered delivery. The general characteristic is that >>>>>>the receiving ULP wants the data in whatever order it >>>>>>arrives, but wants to know what the original order was. >>>>>> >>>>>>In addition to RDDP, RTP over UDP is another example of >>>>>>an application that wants to be aware of the original >>>>>>ordering, even while accepting the data out-of-order. >>>>>> >>>>>>Caitlin Bestler >>>>>>http://asomi.com/CaitlinBestler/ >>>>>>_______________________________________________ >>>>>>tsvwg mailing list >>>>>>tsvwg@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/tsvwg >>>>>> >>>>> >>>>>_______________________________________________ >>>>>tsvwg mailing list >>>>>tsvwg@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/tsvwg >>>>> >>>>> >>>> >>>> >>>>-- >>>>Randall R. Stewart >>>>randall@stewart.chicago.il.us 815-342-5222 (cell phone) >>>> >>>>_______________________________________________ >>>>tsvwg mailing list >>>>tsvwg@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/tsvwg >>> >>> >> >>-- >>Randall R. Stewart >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) >> > > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 12 07:28:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00725 for ; Wed, 12 Feb 2003 07:28:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CCbrp11428 for tsvwg-archive@odin.ietf.org; Wed, 12 Feb 2003 07:37:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCbbp11390; Wed, 12 Feb 2003 07:37:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCahp10694 for ; Wed, 12 Feb 2003 07:36:43 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00627; Wed, 12 Feb 2003 07:26:48 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1CCUQu6003598; Wed, 12 Feb 2003 06:30:26 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E4A3E62.4050207@stewart.chicago.il.us> Date: Wed, 12 Feb 2003 06:30:26 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org, Tuexen Michael , sigtran@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: <3E49899A.6010809@stewart.chicago.il.us> <20030211191543.A14481@openss7.org> <3E4A36FF.8050205@stewart.chicago.il.us> <20030212052223.A29464@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: > Randall, > > For the M2PA application, I think that reserving > '0' for unordered messages for which the order of > sending is unimportant is still a good idea. > So the number space from 1 to 0xffff indicates > importance of order. '0' indicates no importance > of order. As in M2PA's case, a sender could mix > both on the same stream. > > There then becomes three different types of messages: > > 1) Unordered messages for which the order of sending is > unimportant (U-bit SSN=0), > > 2) unordered messages for which the order of sending is > important (U-bit SSN!=0), and > > 3) ordered messages for which the order of sending is > important (~U-bit). > > And this also handles compatibility because previous > unordered messages fall into category (1) by nature > of the fact that SSN==0. > > But starting counting at 1, you get rid of the ability > to indicate that the order of sending is unimportant and > force the receiving ULP to handle ordering of all received > unordered data. > > So, in short, start counting at 1, regardless of whether > there is an indicator in the INIT/INIT-ACK. > That might be ok, but in the above does not that mean when you reach 0xffff you end up sending a type 1) message... unless of course you want to have a counting scheme where you always skip 0... which is a bit more code on every sequence increase... And I do still think you will need to "know" ahead of time if both sides support 2) otherwise you would not know to embed your own SSN (in cases where you must emulate 2) R > --brian > > Randall Stewart wrote: (Wed, 12 Feb 2003 05:58:55) > >>Brian/Michael: >> >>I do like the idea of keeping things the same (aka same >>methodology)... this is good. >> >>It is also neat to be able to tell the difference between >>an implementation that supports this feature and one that >>does not. But there are positives and negatives, I think, >>to each idea... >> >>A) For using a TLV, (as Michael suggests) >> we really need to put this into a seperate >> draft.. when I do think one could easily fit >> this into the IG as Brian as suggested. >> >>B) montonically increasing numbers would eventually >> wrap when the SSN hit FFFF back to 0... thus >> the application would need to have some sort >> of state to track if the peer supported the >> feature. >> >>It seems to me it is only the first message that >>arrives that benefits from the start at 0. If the >>application assumes a "not supported", then by >>starting the SSN at 1 the app can flip the flag >>from "not supported" to "supported" on the arrival >>of the first message. >> >>If the application instead set its flag to "supported" >>the first message would not tell this information and >>instead it would only be upon the second arriving message >>that the app could make the flag determination... causing >>either a delay in delivery of the first message (yuck) or >>just toss it up and wait. >> >>More importantly, I am wondering, if the implementation does >>NOT support this, what will the app do? Change its >>message structure? If so it will need to have some clues >>(as the initiator) that its implementation does not >>support the feature .. possibly a HAVE_SCTP_UNORDERED_SSN >>in sctp.h... but the problem is you would not know about >>the other guy until its first unordered message arrives. >>So if you have to send the first message what do you do? >> >>if HAVE_SCTP_UNORDERED_SSN is 0.. no problem.. you >>send a message that has the imbedded sequence number.. but >>what do you send when HAVE_SCTP_UNRODERED_SSN is set to 1? >> >>If you send the imbedded sequence in the message anyway whats >>the point of this little trick? The second message (which you >>may have to send before knowing receiving a unordered >>msg from the peer) would still have this, and maybe the third >>etc... >> >>Hmm.. the more I think on this the more it becomes clear that >>you must know ahead of time i.e. when the association comes >>up to "do the right thing".... which goes back to Michaels >>idea of a TLV. >> >>I have been wondering for quite some time now if we don't >>just need a TLV in the INIT/INIT-ACK that indicate features >>in general... something like a bit mask or byte array indicating >>each feature... >> >>addip >>delip >>prsctp >>setprimary >>unordered-assigns-sequences >> >>etc.. >> >>Maybe this is a better way to go.. and we could write a short >>draft dictating this bit/byte TLV... code as a 0x80 class.. that >>way old implementations will throw it away... (we really don't >>care if they don't understand it)... >> >>I have been avoiding this.. but it might be the best approach.. >> >>Then again, I guess it could also be put in addip or prsctp since >>it would effect them as well :> Then one could put the >>other change in the IG and thus have a very easy change that >>is in the IG and a minor update to either addip or prsctp... >> >> >>What do you all think? >> >>R >> >>Brian F. G. Bidulock wrote: >> >>>Randall, >>> >>>I agree to having SCTP set the sequence number and, as you said in >>>your first note, SCTP passing the sequence number to the ULP on >>>the receiving side is already done for ordered traffic. Some even >>>pass the zero now. >>> >>>I suppose that SCTP would set this sequence number when it is given >>>the data for delivery at the sending ULP and the sequence would represent >>>the order that the data was presented to SCTP by the ULP at the sending >>>side. >>> >>>I think it would be good to see the requirement that the sequence >>>number begin at 1 and be monotonically increasing in the saem fashion >>>as ordered streams. >>> >>>That way RDDP and other applications could perform their own reordering >>>at the receiver. I think it would be a good thing to have SCTP set >>>this value. >>> >>>In fact, I can see another application for this feature. M2PA >>>(SIGTRAN protocol) needs in some circumstances to send data unordered >>>with the hope of expedited delivery (does not want control information >>>stuck behind large amounts of data in an ordered stream), however, the >>>order of processing of the expedited control information is important. >>> >>>This facility would permit M2PA to send such information unordered >>>to expedite it and the receiver could perform the reordering itself. >>>Up until now, the only solution was to place a sequence number in with >>>the control information. >>> >>>Could we perhaps add a section to the SCTP IG. "Problem statement: >>>the sender wishes to send unordered data but the receive needs to know >>>the original order of sending..." or some such. >>> >>>It should be quite simple to add the feature to existing SCTP >>>implementations. >>> >>>--brian >>> >>> >>>On Tue, 11 Feb 2003, Randall Stewart wrote: >>> >>> >>> >>>>Michael: >>>> >>>>This seems like a valid method.. it gets around Brian's objection >>>>(which was a good point) and yet still provides the application with >>>>a hint about what the assigned sequence order was on the unordered >>>>messages... >>>> >>>>R >>>> >>>>Michael Tuexen wrote: >>>> >>>> >>>>>Caitlin, >>>>> >>>>>thank you very much for the clarification. >>>>> >>>>>I do not like the idea to pass the SSN transparently from the ULP to the >>>>>ULP. >>>>>But having two sequence spaces is OK for me. This means that the SSN at the >>>>>sending side is controlled by the SCTP and given to the ULP at the >>>>>receiving side. >>>>> >>>>>This would be a clean solution. So I voting for have two separate number >>>>>spaces >>>>>for user data. Since the one for ordered delivery exists already in RFC >>>>>2960, this >>>>>only means that a new one is introduced for the unordered delivery user >>>>>data. >>>>> >>>>>Best regards >>>>>Michael >>>>> >>>>>On Tuesday, Feb 11, 2003, at 17:37 Europe/Berlin, Caitlin Bestler wrote: >>>>> >>>>> >>>>> >>>>>>On 2/11/03, Tuexen Michael wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Dear all, >>>>>>> >>>>>>>does this mean that you want two sequence spaces per >>>>>>>stream: one for the 'ordered' user data and one for the >>>>>>>unordered user data? >>>>>>> >>>>>> >>>>>>The RDDP/SCTP adaptation only uses unordered delivery, so >>>>>>that question did not really arise. >>>>>> >>>>>>But if you were to generalize the problem, I believe the >>>>>>answer would be yes. >>>>>> >>>>>>The SSN for ordered delivery would be unchanged. The >>>>>>addition would be providing "advisory ordering" for >>>>>>unordered delivery. The general characteristic is that >>>>>>the receiving ULP wants the data in whatever order it >>>>>>arrives, but wants to know what the original order was. >>>>>> >>>>>>In addition to RDDP, RTP over UDP is another example of >>>>>>an application that wants to be aware of the original >>>>>>ordering, even while accepting the data out-of-order. >>>>>> >>>>>>Caitlin Bestler >>>>>>http://asomi.com/CaitlinBestler/ >>>>>>_______________________________________________ >>>>>>tsvwg mailing list >>>>>>tsvwg@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/tsvwg >>>>>> >>>>> >>>>>_______________________________________________ >>>>>tsvwg mailing list >>>>>tsvwg@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/tsvwg >>>>> >>>>> >>>> >>>> >>>>-- >>>>Randall R. Stewart >>>>randall@stewart.chicago.il.us 815-342-5222 (cell phone) >>>> >>>>_______________________________________________ >>>>tsvwg mailing list >>>>tsvwg@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/tsvwg >>> >>> >> >>-- >>Randall R. Stewart >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 12 07:29:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00796 for ; Wed, 12 Feb 2003 07:29:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CCdED11529 for tsvwg-archive@odin.ietf.org; Wed, 12 Feb 2003 07:39:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCd3p11503; Wed, 12 Feb 2003 07:39:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCc8p11448 for ; Wed, 12 Feb 2003 07:38:08 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00699 for ; Wed, 12 Feb 2003 07:28:14 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:zcYsFu85pHNq5O0OH+qRgn1Y9/h1QzfS@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1CCVwD17164; Wed, 12 Feb 2003 05:31:58 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1CCVw632286; Wed, 12 Feb 2003 05:31:58 -0700 Date: Wed, 12 Feb 2003 05:31:57 -0700 From: "Brian F. G. Bidulock" To: Randall Stewart Cc: Tuexen Michael , Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030212053157.B29464@openss7.org> Reply-To: bidulock@openss7.org References: <3E4A3D36.4030401@stewart.chicago.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E4A3D36.4030401@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Wed, Feb 12, 2003 at 06:25:26AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Randall, For RDDP why not just suppress ordered delivery (order of arrival rather than order of sending) of data in the stream at the receiver. That way you can use the SSN of ordered DATA chunks instead of trying to add SSNs to unorderd data chunks. Also, that way a RDDP/SCTP compliant sender will be compatible with a non-RDDP/SCTP compliant receiver. If you use unordered DATA chunks, the non-RDDP/SCTP compliant receiver will deliver data out of order (instead of in order) on the stream, which is a bad thing. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 12 07:36:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00992 for ; Wed, 12 Feb 2003 07:36:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CCjlL11954 for tsvwg-archive@odin.ietf.org; Wed, 12 Feb 2003 07:45:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCjIp11889; Wed, 12 Feb 2003 07:45:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCj0p11790 for ; Wed, 12 Feb 2003 07:45:00 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00918; Wed, 12 Feb 2003 07:35:02 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:tq1NvNhxlGYmkolmgEAF1dwn8oeWHWhu@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1CCchD17247; Wed, 12 Feb 2003 05:38:43 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1CCchg00685; Wed, 12 Feb 2003 05:38:43 -0700 Date: Wed, 12 Feb 2003 05:38:43 -0700 From: "Brian F. G. Bidulock" To: Randall Stewart Cc: Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org, Tuexen Michael , sigtran@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030212053843.C29464@openss7.org> Reply-To: bidulock@openss7.org Mail-Followup-To: Randall Stewart , Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org, Tuexen Michael , sigtran@ietf.org References: <3E49899A.6010809@stewart.chicago.il.us> <20030211191543.A14481@openss7.org> <3E4A36FF.8050205@stewart.chicago.il.us> <20030212052223.A29464@openss7.org> <3E4A3E62.4050207@stewart.chicago.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E4A3E62.4050207@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Wed, Feb 12, 2003 at 06:30:26AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Randall, So why not introduce another bit into the data chunk header? Say, the O-bit which indicates that data is ordered at the sender but not at the receiver? An SCTP which does not know about the O-bit will assume that ordered delivery is required. Receivers which know about the O-bit will know that unordered deliver is allowed. That way you can start counting at 0 and leave unordered data chunks alone. While your at it, why not place the offset of the data chunk in the final message in the DATA chunk header so that the payload is identical for RDDP and non-RDDP SCTPs. That way, the non-RDDP receiver will be able to ignore the O-bit and offset, and deliver the data ordered. The RDDP receiver will be able to observe the O-bit and offset and direct place the data chunk. --brian Randall Stewart wrote: (Wed, 12 Feb 2003 06:30:26) > Brian F. G. Bidulock wrote: > > Randall, > > > > For the M2PA application, I think that reserving > > '0' for unordered messages for which the order of > > sending is unimportant is still a good idea. > > So the number space from 1 to 0xffff indicates > > importance of order. '0' indicates no importance > > of order. As in M2PA's case, a sender could mix > > both on the same stream. > > > > There then becomes three different types of messages: > > > > 1) Unordered messages for which the order of sending is > > unimportant (U-bit SSN=0), > > > > 2) unordered messages for which the order of sending is > > important (U-bit SSN!=0), and > > > > 3) ordered messages for which the order of sending is > > important (~U-bit). > > > > And this also handles compatibility because previous > > unordered messages fall into category (1) by nature > > of the fact that SSN==0. > > > > But starting counting at 1, you get rid of the ability > > to indicate that the order of sending is unimportant and > > force the receiving ULP to handle ordering of all received > > unordered data. > > > > So, in short, start counting at 1, regardless of whether > > there is an indicator in the INIT/INIT-ACK. > > > > That might be ok, but in the above does not that mean > when you reach 0xffff you end up sending a type > 1) message... unless of course you want to have > a counting scheme where you always skip 0... which > is a bit more code on every sequence increase... > > And I do still think you will need to "know" ahead of > time if both sides support 2) otherwise you would not > know to embed your own SSN (in cases where you must > emulate 2) > > R > > > --brian > > > > Randall Stewart wrote: (Wed, 12 Feb 2003 05:58:55) > > > >>Brian/Michael: > >> > >>I do like the idea of keeping things the same (aka same > >>methodology)... this is good. > >> > >>It is also neat to be able to tell the difference between > >>an implementation that supports this feature and one that > >>does not. But there are positives and negatives, I think, > >>to each idea... > >> > >>A) For using a TLV, (as Michael suggests) > >> we really need to put this into a seperate > >> draft.. when I do think one could easily fit > >> this into the IG as Brian as suggested. > >> > >>B) montonically increasing numbers would eventually > >> wrap when the SSN hit FFFF back to 0... thus > >> the application would need to have some sort > >> of state to track if the peer supported the > >> feature. > >> > >>It seems to me it is only the first message that > >>arrives that benefits from the start at 0. If the > >>application assumes a "not supported", then by > >>starting the SSN at 1 the app can flip the flag > >>from "not supported" to "supported" on the arrival > >>of the first message. > >> > >>If the application instead set its flag to "supported" > >>the first message would not tell this information and > >>instead it would only be upon the second arriving message > >>that the app could make the flag determination... causing > >>either a delay in delivery of the first message (yuck) or > >>just toss it up and wait. > >> > >>More importantly, I am wondering, if the implementation does > >>NOT support this, what will the app do? Change its > >>message structure? If so it will need to have some clues > >>(as the initiator) that its implementation does not > >>support the feature .. possibly a HAVE_SCTP_UNORDERED_SSN > >>in sctp.h... but the problem is you would not know about > >>the other guy until its first unordered message arrives. > >>So if you have to send the first message what do you do? > >> > >>if HAVE_SCTP_UNORDERED_SSN is 0.. no problem.. you > >>send a message that has the imbedded sequence number.. but > >>what do you send when HAVE_SCTP_UNRODERED_SSN is set to 1? > >> > >>If you send the imbedded sequence in the message anyway whats > >>the point of this little trick? The second message (which you > >>may have to send before knowing receiving a unordered > >>msg from the peer) would still have this, and maybe the third > >>etc... > >> > >>Hmm.. the more I think on this the more it becomes clear that > >>you must know ahead of time i.e. when the association comes > >>up to "do the right thing".... which goes back to Michaels > >>idea of a TLV. > >> > >>I have been wondering for quite some time now if we don't > >>just need a TLV in the INIT/INIT-ACK that indicate features > >>in general... something like a bit mask or byte array indicating > >>each feature... > >> > >>addip > >>delip > >>prsctp > >>setprimary > >>unordered-assigns-sequences > >> > >>etc.. > >> > >>Maybe this is a better way to go.. and we could write a short > >>draft dictating this bit/byte TLV... code as a 0x80 class.. that > >>way old implementations will throw it away... (we really don't > >>care if they don't understand it)... > >> > >>I have been avoiding this.. but it might be the best approach.. > >> > >>Then again, I guess it could also be put in addip or prsctp since > >>it would effect them as well :> Then one could put the > >>other change in the IG and thus have a very easy change that > >>is in the IG and a minor update to either addip or prsctp... > >> > >> > >>What do you all think? > >> > >>R > >> > >>Brian F. G. Bidulock wrote: > >> > >>>Randall, > >>> > >>>I agree to having SCTP set the sequence number and, as you said in > >>>your first note, SCTP passing the sequence number to the ULP on > >>>the receiving side is already done for ordered traffic. Some even > >>>pass the zero now. > >>> > >>>I suppose that SCTP would set this sequence number when it is given > >>>the data for delivery at the sending ULP and the sequence would represent > >>>the order that the data was presented to SCTP by the ULP at the sending > >>>side. > >>> > >>>I think it would be good to see the requirement that the sequence > >>>number begin at 1 and be monotonically increasing in the saem fashion > >>>as ordered streams. > >>> > >>>That way RDDP and other applications could perform their own reordering > >>>at the receiver. I think it would be a good thing to have SCTP set > >>>this value. > >>> > >>>In fact, I can see another application for this feature. M2PA > >>>(SIGTRAN protocol) needs in some circumstances to send data unordered > >>>with the hope of expedited delivery (does not want control information > >>>stuck behind large amounts of data in an ordered stream), however, the > >>>order of processing of the expedited control information is important. > >>> > >>>This facility would permit M2PA to send such information unordered > >>>to expedite it and the receiver could perform the reordering itself. > >>>Up until now, the only solution was to place a sequence number in with > >>>the control information. > >>> > >>>Could we perhaps add a section to the SCTP IG. "Problem statement: > >>>the sender wishes to send unordered data but the receive needs to know > >>>the original order of sending..." or some such. > >>> > >>>It should be quite simple to add the feature to existing SCTP > >>>implementations. > >>> > >>>--brian > >>> > >>> > >>>On Tue, 11 Feb 2003, Randall Stewart wrote: > >>> > >>> > >>> > >>>>Michael: > >>>> > >>>>This seems like a valid method.. it gets around Brian's objection > >>>>(which was a good point) and yet still provides the application with > >>>>a hint about what the assigned sequence order was on the unordered > >>>>messages... > >>>> > >>>>R > >>>> > >>>>Michael Tuexen wrote: > >>>> > >>>> > >>>>>Caitlin, > >>>>> > >>>>>thank you very much for the clarification. > >>>>> > >>>>>I do not like the idea to pass the SSN transparently from the ULP to the > >>>>>ULP. > >>>>>But having two sequence spaces is OK for me. This means that the SSN at the > >>>>>sending side is controlled by the SCTP and given to the ULP at the > >>>>>receiving side. > >>>>> > >>>>>This would be a clean solution. So I voting for have two separate number > >>>>>spaces > >>>>>for user data. Since the one for ordered delivery exists already in RFC > >>>>>2960, this > >>>>>only means that a new one is introduced for the unordered delivery user > >>>>>data. > >>>>> > >>>>>Best regards > >>>>>Michael > >>>>> > >>>>>On Tuesday, Feb 11, 2003, at 17:37 Europe/Berlin, Caitlin Bestler wrote: > >>>>> > >>>>> > >>>>> > >>>>>>On 2/11/03, Tuexen Michael wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Dear all, > >>>>>>> > >>>>>>>does this mean that you want two sequence spaces per > >>>>>>>stream: one for the 'ordered' user data and one for the > >>>>>>>unordered user data? > >>>>>>> > >>>>>> > >>>>>>The RDDP/SCTP adaptation only uses unordered delivery, so > >>>>>>that question did not really arise. > >>>>>> > >>>>>>But if you were to generalize the problem, I believe the > >>>>>>answer would be yes. > >>>>>> > >>>>>>The SSN for ordered delivery would be unchanged. The > >>>>>>addition would be providing "advisory ordering" for > >>>>>>unordered delivery. The general characteristic is that > >>>>>>the receiving ULP wants the data in whatever order it > >>>>>>arrives, but wants to know what the original order was. > >>>>>> > >>>>>>In addition to RDDP, RTP over UDP is another example of > >>>>>>an application that wants to be aware of the original > >>>>>>ordering, even while accepting the data out-of-order. > >>>>>> > >>>>>>Caitlin Bestler > >>>>>>http://asomi.com/CaitlinBestler/ > >>>>>>_______________________________________________ > >>>>>>tsvwg mailing list > >>>>>>tsvwg@ietf.org > >>>>>>https://www1.ietf.org/mailman/listinfo/tsvwg > >>>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>tsvwg mailing list > >>>>>tsvwg@ietf.org > >>>>>https://www1.ietf.org/mailman/listinfo/tsvwg > >>>>> > >>>>> > >>>> > >>>> > >>>>-- > >>>>Randall R. Stewart > >>>>randall@stewart.chicago.il.us 815-342-5222 (cell phone) > >>>> > >>>>_______________________________________________ > >>>>tsvwg mailing list > >>>>tsvwg@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/tsvwg > >>> > >>> > >> > >>-- > >>Randall R. Stewart > >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) > > > > > > > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 12 08:23:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02022 for ; Wed, 12 Feb 2003 08:23:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CDWkc14958 for tsvwg-archive@odin.ietf.org; Wed, 12 Feb 2003 08:32:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CDTGp14763; Wed, 12 Feb 2003 08:29:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CDS2p14714 for ; Wed, 12 Feb 2003 08:28:02 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01917; Wed, 12 Feb 2003 08:18:05 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1CDLlu6003679; Wed, 12 Feb 2003 07:21:48 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E4A4A6B.4010405@stewart.chicago.il.us> Date: Wed, 12 Feb 2003 07:21:47 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org, Tuexen Michael , sigtran@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: <3E49899A.6010809@stewart.chicago.il.us> <20030211191543.A14481@openss7.org> <3E4A36FF.8050205@stewart.chicago.il.us> <20030212052223.A29464@openss7.org> <3E4A3E62.4050207@stewart.chicago.il.us> <20030212053843.C29464@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brian: I am really not interested in adding a bit in the header for RDDP. I think it is better to do something minimalist that meets there needs instead of burning a bit (of only 5 left) for one particular application. Having a second sequence number space that is allowed.. but not required.. and Michaels suggested TLV in INIT/INIT-ACK would be more than adequate for RDDP or for that matter any other application that wants data right away but yet would like to know presentation order to the sending SCTP. R Brian F. G. Bidulock wrote: > Randall, > > So why not introduce another bit into the data chunk header? > > Say, the O-bit which indicates that data is ordered at the > sender but not at the receiver? > > An SCTP which does not know about the O-bit will assume that > ordered delivery is required. Receivers which know about > the O-bit will know that unordered deliver is allowed. > > That way you can start counting at 0 and leave unordered > data chunks alone. > > While your at it, why not place the offset of the data chunk > in the final message in the DATA chunk header so that the > payload is identical for RDDP and non-RDDP SCTPs. That way, > the non-RDDP receiver will be able to ignore the O-bit and > offset, and deliver the data ordered. The RDDP receiver > will be able to observe the O-bit and offset and direct place > the data chunk. > > --brian > > > Randall Stewart wrote: (Wed, 12 Feb 2003 06:30:26) > >>Brian F. G. Bidulock wrote: >> >>>Randall, >>> >>>For the M2PA application, I think that reserving >>>'0' for unordered messages for which the order of >>>sending is unimportant is still a good idea. >>>So the number space from 1 to 0xffff indicates >>>importance of order. '0' indicates no importance >>>of order. As in M2PA's case, a sender could mix >>>both on the same stream. >>> >>>There then becomes three different types of messages: >>> >>>1) Unordered messages for which the order of sending is >>> unimportant (U-bit SSN=0), >>> >>>2) unordered messages for which the order of sending is >>> important (U-bit SSN!=0), and >>> >>>3) ordered messages for which the order of sending is >>> important (~U-bit). >>> >>>And this also handles compatibility because previous >>>unordered messages fall into category (1) by nature >>>of the fact that SSN==0. >>> >>>But starting counting at 1, you get rid of the ability >>>to indicate that the order of sending is unimportant and >>>force the receiving ULP to handle ordering of all received >>>unordered data. >>> >>>So, in short, start counting at 1, regardless of whether >>>there is an indicator in the INIT/INIT-ACK. >>> >> >>That might be ok, but in the above does not that mean >>when you reach 0xffff you end up sending a type >>1) message... unless of course you want to have >>a counting scheme where you always skip 0... which >>is a bit more code on every sequence increase... >> >>And I do still think you will need to "know" ahead of >>time if both sides support 2) otherwise you would not >>know to embed your own SSN (in cases where you must >>emulate 2) >> >>R >> >> >>>--brian >>> >>>Randall Stewart wrote: (Wed, 12 Feb 2003 05:58:55) >>> >>> >>>>Brian/Michael: >>>> >>>>I do like the idea of keeping things the same (aka same >>>>methodology)... this is good. >>>> >>>>It is also neat to be able to tell the difference between >>>>an implementation that supports this feature and one that >>>>does not. But there are positives and negatives, I think, >>>>to each idea... >>>> >>>>A) For using a TLV, (as Michael suggests) >>>> we really need to put this into a seperate >>>> draft.. when I do think one could easily fit >>>> this into the IG as Brian as suggested. >>>> >>>>B) montonically increasing numbers would eventually >>>> wrap when the SSN hit FFFF back to 0... thus >>>> the application would need to have some sort >>>> of state to track if the peer supported the >>>> feature. >>>> >>>>It seems to me it is only the first message that >>>>arrives that benefits from the start at 0. If the >>>>application assumes a "not supported", then by >>>>starting the SSN at 1 the app can flip the flag >>> >>>>from "not supported" to "supported" on the arrival >>> >>>>of the first message. >>>> >>>>If the application instead set its flag to "supported" >>>>the first message would not tell this information and >>>>instead it would only be upon the second arriving message >>>>that the app could make the flag determination... causing >>>>either a delay in delivery of the first message (yuck) or >>>>just toss it up and wait. >>>> >>>>More importantly, I am wondering, if the implementation does >>>>NOT support this, what will the app do? Change its >>>>message structure? If so it will need to have some clues >>>>(as the initiator) that its implementation does not >>>>support the feature .. possibly a HAVE_SCTP_UNORDERED_SSN >>>>in sctp.h... but the problem is you would not know about >>>>the other guy until its first unordered message arrives. >>>>So if you have to send the first message what do you do? >>>> >>>>if HAVE_SCTP_UNORDERED_SSN is 0.. no problem.. you >>>>send a message that has the imbedded sequence number.. but >>>>what do you send when HAVE_SCTP_UNRODERED_SSN is set to 1? >>>> >>>>If you send the imbedded sequence in the message anyway whats >>>>the point of this little trick? The second message (which you >>>>may have to send before knowing receiving a unordered >>>>msg from the peer) would still have this, and maybe the third >>>>etc... >>>> >>>>Hmm.. the more I think on this the more it becomes clear that >>>>you must know ahead of time i.e. when the association comes >>>>up to "do the right thing".... which goes back to Michaels >>>>idea of a TLV. >>>> >>>>I have been wondering for quite some time now if we don't >>>>just need a TLV in the INIT/INIT-ACK that indicate features >>>>in general... something like a bit mask or byte array indicating >>>>each feature... >>>> >>>>addip >>>>delip >>>>prsctp >>>>setprimary >>>>unordered-assigns-sequences >>>> >>>>etc.. >>>> >>>>Maybe this is a better way to go.. and we could write a short >>>>draft dictating this bit/byte TLV... code as a 0x80 class.. that >>>>way old implementations will throw it away... (we really don't >>>>care if they don't understand it)... >>>> >>>>I have been avoiding this.. but it might be the best approach.. >>>> >>>>Then again, I guess it could also be put in addip or prsctp since >>>>it would effect them as well :> Then one could put the >>>>other change in the IG and thus have a very easy change that >>>>is in the IG and a minor update to either addip or prsctp... >>>> >>>> >>>>What do you all think? >>>> >>>>R >>>> >>>>Brian F. G. Bidulock wrote: >>>> >>>> >>>>>Randall, >>>>> >>>>>I agree to having SCTP set the sequence number and, as you said in >>>>>your first note, SCTP passing the sequence number to the ULP on >>>>>the receiving side is already done for ordered traffic. Some even >>>>>pass the zero now. >>>>> >>>>>I suppose that SCTP would set this sequence number when it is given >>>>>the data for delivery at the sending ULP and the sequence would represent >>>>>the order that the data was presented to SCTP by the ULP at the sending >>>>>side. >>>>> >>>>>I think it would be good to see the requirement that the sequence >>>>>number begin at 1 and be monotonically increasing in the saem fashion >>>>>as ordered streams. >>>>> >>>>>That way RDDP and other applications could perform their own reordering >>>>>at the receiver. I think it would be a good thing to have SCTP set >>>>>this value. >>>>> >>>>>In fact, I can see another application for this feature. M2PA >>>>>(SIGTRAN protocol) needs in some circumstances to send data unordered >>>>>with the hope of expedited delivery (does not want control information >>>>>stuck behind large amounts of data in an ordered stream), however, the >>>>>order of processing of the expedited control information is important. >>>>> >>>>>This facility would permit M2PA to send such information unordered >>>>>to expedite it and the receiver could perform the reordering itself. >>>>>Up until now, the only solution was to place a sequence number in with >>>>>the control information. >>>>> >>>>>Could we perhaps add a section to the SCTP IG. "Problem statement: >>>>>the sender wishes to send unordered data but the receive needs to know >>>>>the original order of sending..." or some such. >>>>> >>>>>It should be quite simple to add the feature to existing SCTP >>>>>implementations. >>>>> >>>>>--brian >>>>> >>>>> >>>>>On Tue, 11 Feb 2003, Randall Stewart wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>Michael: >>>>>> >>>>>>This seems like a valid method.. it gets around Brian's objection >>>>>>(which was a good point) and yet still provides the application with >>>>>>a hint about what the assigned sequence order was on the unordered >>>>>>messages... >>>>>> >>>>>>R >>>>>> >>>>>>Michael Tuexen wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Caitlin, >>>>>>> >>>>>>>thank you very much for the clarification. >>>>>>> >>>>>>>I do not like the idea to pass the SSN transparently from the ULP to the >>>>>>>ULP. >>>>>>>But having two sequence spaces is OK for me. This means that the SSN at the >>>>>>>sending side is controlled by the SCTP and given to the ULP at the >>>>>>>receiving side. >>>>>>> >>>>>>>This would be a clean solution. So I voting for have two separate number >>>>>>>spaces >>>>>>>for user data. Since the one for ordered delivery exists already in RFC >>>>>>>2960, this >>>>>>>only means that a new one is introduced for the unordered delivery user >>>>>>>data. >>>>>>> >>>>>>>Best regards >>>>>>>Michael >>>>>>> >>>>>>>On Tuesday, Feb 11, 2003, at 17:37 Europe/Berlin, Caitlin Bestler wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>On 2/11/03, Tuexen Michael wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Dear all, >>>>>>>>> >>>>>>>>>does this mean that you want two sequence spaces per >>>>>>>>>stream: one for the 'ordered' user data and one for the >>>>>>>>>unordered user data? >>>>>>>>> >>>>>>>> >>>>>>>>The RDDP/SCTP adaptation only uses unordered delivery, so >>>>>>>>that question did not really arise. >>>>>>>> >>>>>>>>But if you were to generalize the problem, I believe the >>>>>>>>answer would be yes. >>>>>>>> >>>>>>>>The SSN for ordered delivery would be unchanged. The >>>>>>>>addition would be providing "advisory ordering" for >>>>>>>>unordered delivery. The general characteristic is that >>>>>>>>the receiving ULP wants the data in whatever order it >>>>>>>>arrives, but wants to know what the original order was. >>>>>>>> >>>>>>>>In addition to RDDP, RTP over UDP is another example of >>>>>>>>an application that wants to be aware of the original >>>>>>>>ordering, even while accepting the data out-of-order. >>>>>>>> >>>>>>>>Caitlin Bestler >>>>>>>>http://asomi.com/CaitlinBestler/ >>>>>>>>_______________________________________________ >>>>>>>>tsvwg mailing list >>>>>>>>tsvwg@ietf.org >>>>>>>>https://www1.ietf.org/mailman/listinfo/tsvwg >>>>>>>> >>>>>>> >>>>>>>_______________________________________________ >>>>>>>tsvwg mailing list >>>>>>>tsvwg@ietf.org >>>>>>>https://www1.ietf.org/mailman/listinfo/tsvwg >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>-- >>>>>>Randall R. Stewart >>>>>>randall@stewart.chicago.il.us 815-342-5222 (cell phone) >>>>>> >>>>>>_______________________________________________ >>>>>>tsvwg mailing list >>>>>>tsvwg@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/tsvwg >>>>> >>>>> >>>>-- >>>>Randall R. Stewart >>>>randall@stewart.chicago.il.us 815-342-5222 (cell phone) >>> >>> >> >>-- >>Randall R. Stewart >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 12 10:24:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05992 for ; Wed, 12 Feb 2003 10:24:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CFXcs23820 for tsvwg-archive@odin.ietf.org; Wed, 12 Feb 2003 10:33:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CFWPp23760; Wed, 12 Feb 2003 10:32:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CFVtp23732 for ; Wed, 12 Feb 2003 10:31:55 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05956; Wed, 12 Feb 2003 10:21:57 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:jgx+alQfkp9Pc8elrGS5BJhxdzCWB8w9@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1CFPdD20020; Wed, 12 Feb 2003 08:25:39 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1CFPdY24714; Wed, 12 Feb 2003 08:25:39 -0700 Date: Wed, 12 Feb 2003 08:25:39 -0700 From: "Brian F. G. Bidulock" To: Randall Stewart Cc: Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org, Tuexen Michael , sigtran@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030212082539.C21356@openss7.org> Reply-To: bidulock@openss7.org Mail-Followup-To: Randall Stewart , Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org, Tuexen Michael , sigtran@ietf.org References: <3E49899A.6010809@stewart.chicago.il.us> <20030211191543.A14481@openss7.org> <3E4A36FF.8050205@stewart.chicago.il.us> <20030212052223.A29464@openss7.org> <3E4A3E62.4050207@stewart.chicago.il.us> <20030212053843.C29464@openss7.org> <3E4A4A6B.4010405@stewart.chicago.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E4A4A6B.4010405@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Wed, Feb 12, 2003 at 07:21:47AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Randall, Then send them ordered and let the RDDP/SCTP receiver perform direct data placement without waiting for reordering. Ordered data chunks already have usable stream sequence numbers. It appears that you want to use the U-bit to tell the receiver that it doesn't need to order the messages when all you need is unordered delivery at the receiver. Ordered delivery across the SCTP ULP API is not a requirement as it is in TCP. --brian Randall Stewart wrote: (Wed, 12 Feb 2003 07:21:47) > Brian: > > I am really not interested in adding a bit in > the header for RDDP. I think it is better > to do something minimalist that meets there > needs instead of burning a bit (of only 5 left) > for one particular application. > > Having a second sequence number space that is > allowed.. but not required.. and Michaels suggested > TLV in INIT/INIT-ACK would be more than adequate for > RDDP or for that matter any other application that > wants data right away but yet would like to know > presentation order to the sending SCTP. > > R > > Brian F. G. Bidulock wrote: > > Randall, > > > > So why not introduce another bit into the data chunk header? > > > > Say, the O-bit which indicates that data is ordered at the > > sender but not at the receiver? > > > > An SCTP which does not know about the O-bit will assume that > > ordered delivery is required. Receivers which know about > > the O-bit will know that unordered deliver is allowed. > > > > That way you can start counting at 0 and leave unordered > > data chunks alone. > > > > While your at it, why not place the offset of the data chunk > > in the final message in the DATA chunk header so that the > > payload is identical for RDDP and non-RDDP SCTPs. That way, > > the non-RDDP receiver will be able to ignore the O-bit and > > offset, and deliver the data ordered. The RDDP receiver > > will be able to observe the O-bit and offset and direct place > > the data chunk. > > > > --brian > > > > > > Randall Stewart wrote: (Wed, 12 Feb 2003 06:30:26) > > > >>Brian F. G. Bidulock wrote: > >> > >>>Randall, > >>> > >>>For the M2PA application, I think that reserving > >>>'0' for unordered messages for which the order of > >>>sending is unimportant is still a good idea. > >>>So the number space from 1 to 0xffff indicates > >>>importance of order. '0' indicates no importance > >>>of order. As in M2PA's case, a sender could mix > >>>both on the same stream. > >>> > >>>There then becomes three different types of messages: > >>> > >>>1) Unordered messages for which the order of sending is > >>> unimportant (U-bit SSN=0), > >>> > >>>2) unordered messages for which the order of sending is > >>> important (U-bit SSN!=0), and > >>> > >>>3) ordered messages for which the order of sending is > >>> important (~U-bit). > >>> > >>>And this also handles compatibility because previous > >>>unordered messages fall into category (1) by nature > >>>of the fact that SSN==0. > >>> > >>>But starting counting at 1, you get rid of the ability > >>>to indicate that the order of sending is unimportant and > >>>force the receiving ULP to handle ordering of all received > >>>unordered data. > >>> > >>>So, in short, start counting at 1, regardless of whether > >>>there is an indicator in the INIT/INIT-ACK. > >>> > >> > >>That might be ok, but in the above does not that mean > >>when you reach 0xffff you end up sending a type > >>1) message... unless of course you want to have > >>a counting scheme where you always skip 0... which > >>is a bit more code on every sequence increase... > >> > >>And I do still think you will need to "know" ahead of > >>time if both sides support 2) otherwise you would not > >>know to embed your own SSN (in cases where you must > >>emulate 2) > >> > >>R > >> > >> > >>>--brian > >>> > >>>Randall Stewart wrote: (Wed, 12 Feb 2003 05:58:55) > >>> > >>> > >>>>Brian/Michael: > >>>> > >>>>I do like the idea of keeping things the same (aka same > >>>>methodology)... this is good. > >>>> > >>>>It is also neat to be able to tell the difference between > >>>>an implementation that supports this feature and one that > >>>>does not. But there are positives and negatives, I think, > >>>>to each idea... > >>>> > >>>>A) For using a TLV, (as Michael suggests) > >>>> we really need to put this into a seperate > >>>> draft.. when I do think one could easily fit > >>>> this into the IG as Brian as suggested. > >>>> > >>>>B) montonically increasing numbers would eventually > >>>> wrap when the SSN hit FFFF back to 0... thus > >>>> the application would need to have some sort > >>>> of state to track if the peer supported the > >>>> feature. > >>>> > >>>>It seems to me it is only the first message that > >>>>arrives that benefits from the start at 0. If the > >>>>application assumes a "not supported", then by > >>>>starting the SSN at 1 the app can flip the flag > >>> > >>>>from "not supported" to "supported" on the arrival > >>> > >>>>of the first message. > >>>> > >>>>If the application instead set its flag to "supported" > >>>>the first message would not tell this information and > >>>>instead it would only be upon the second arriving message > >>>>that the app could make the flag determination... causing > >>>>either a delay in delivery of the first message (yuck) or > >>>>just toss it up and wait. > >>>> > >>>>More importantly, I am wondering, if the implementation does > >>>>NOT support this, what will the app do? Change its > >>>>message structure? If so it will need to have some clues > >>>>(as the initiator) that its implementation does not > >>>>support the feature .. possibly a HAVE_SCTP_UNORDERED_SSN > >>>>in sctp.h... but the problem is you would not know about > >>>>the other guy until its first unordered message arrives. > >>>>So if you have to send the first message what do you do? > >>>> > >>>>if HAVE_SCTP_UNORDERED_SSN is 0.. no problem.. you > >>>>send a message that has the imbedded sequence number.. but > >>>>what do you send when HAVE_SCTP_UNRODERED_SSN is set to 1? > >>>> > >>>>If you send the imbedded sequence in the message anyway whats > >>>>the point of this little trick? The second message (which you > >>>>may have to send before knowing receiving a unordered > >>>>msg from the peer) would still have this, and maybe the third > >>>>etc... > >>>> > >>>>Hmm.. the more I think on this the more it becomes clear that > >>>>you must know ahead of time i.e. when the association comes > >>>>up to "do the right thing".... which goes back to Michaels > >>>>idea of a TLV. > >>>> > >>>>I have been wondering for quite some time now if we don't > >>>>just need a TLV in the INIT/INIT-ACK that indicate features > >>>>in general... something like a bit mask or byte array indicating > >>>>each feature... > >>>> > >>>>addip > >>>>delip > >>>>prsctp > >>>>setprimary > >>>>unordered-assigns-sequences > >>>> > >>>>etc.. > >>>> > >>>>Maybe this is a better way to go.. and we could write a short > >>>>draft dictating this bit/byte TLV... code as a 0x80 class.. that > >>>>way old implementations will throw it away... (we really don't > >>>>care if they don't understand it)... > >>>> > >>>>I have been avoiding this.. but it might be the best approach.. > >>>> > >>>>Then again, I guess it could also be put in addip or prsctp since > >>>>it would effect them as well :> Then one could put the > >>>>other change in the IG and thus have a very easy change that > >>>>is in the IG and a minor update to either addip or prsctp... > >>>> > >>>> > >>>>What do you all think? > >>>> > >>>>R > >>>> > >>>>Brian F. G. Bidulock wrote: > >>>> > >>>> > >>>>>Randall, > >>>>> > >>>>>I agree to having SCTP set the sequence number and, as you said in > >>>>>your first note, SCTP passing the sequence number to the ULP on > >>>>>the receiving side is already done for ordered traffic. Some even > >>>>>pass the zero now. > >>>>> > >>>>>I suppose that SCTP would set this sequence number when it is given > >>>>>the data for delivery at the sending ULP and the sequence would represent > >>>>>the order that the data was presented to SCTP by the ULP at the sending > >>>>>side. > >>>>> > >>>>>I think it would be good to see the requirement that the sequence > >>>>>number begin at 1 and be monotonically increasing in the saem fashion > >>>>>as ordered streams. > >>>>> > >>>>>That way RDDP and other applications could perform their own reordering > >>>>>at the receiver. I think it would be a good thing to have SCTP set > >>>>>this value. > >>>>> > >>>>>In fact, I can see another application for this feature. M2PA > >>>>>(SIGTRAN protocol) needs in some circumstances to send data unordered > >>>>>with the hope of expedited delivery (does not want control information > >>>>>stuck behind large amounts of data in an ordered stream), however, the > >>>>>order of processing of the expedited control information is important. > >>>>> > >>>>>This facility would permit M2PA to send such information unordered > >>>>>to expedite it and the receiver could perform the reordering itself. > >>>>>Up until now, the only solution was to place a sequence number in with > >>>>>the control information. > >>>>> > >>>>>Could we perhaps add a section to the SCTP IG. "Problem statement: > >>>>>the sender wishes to send unordered data but the receive needs to know > >>>>>the original order of sending..." or some such. > >>>>> > >>>>>It should be quite simple to add the feature to existing SCTP > >>>>>implementations. > >>>>> > >>>>>--brian > >>>>> > >>>>> > >>>>>On Tue, 11 Feb 2003, Randall Stewart wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Michael: > >>>>>> > >>>>>>This seems like a valid method.. it gets around Brian's objection > >>>>>>(which was a good point) and yet still provides the application with > >>>>>>a hint about what the assigned sequence order was on the unordered > >>>>>>messages... > >>>>>> > >>>>>>R > >>>>>> > >>>>>>Michael Tuexen wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Caitlin, > >>>>>>> > >>>>>>>thank you very much for the clarification. > >>>>>>> > >>>>>>>I do not like the idea to pass the SSN transparently from the ULP to the > >>>>>>>ULP. > >>>>>>>But having two sequence spaces is OK for me. This means that the SSN at the > >>>>>>>sending side is controlled by the SCTP and given to the ULP at the > >>>>>>>receiving side. > >>>>>>> > >>>>>>>This would be a clean solution. So I voting for have two separate number > >>>>>>>spaces > >>>>>>>for user data. Since the one for ordered delivery exists already in RFC > >>>>>>>2960, this > >>>>>>>only means that a new one is introduced for the unordered delivery user > >>>>>>>data. > >>>>>>> > >>>>>>>Best regards > >>>>>>>Michael > >>>>>>> > >>>>>>>On Tuesday, Feb 11, 2003, at 17:37 Europe/Berlin, Caitlin Bestler wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>On 2/11/03, Tuexen Michael wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>Dear all, > >>>>>>>>> > >>>>>>>>>does this mean that you want two sequence spaces per > >>>>>>>>>stream: one for the 'ordered' user data and one for the > >>>>>>>>>unordered user data? > >>>>>>>>> > >>>>>>>> > >>>>>>>>The RDDP/SCTP adaptation only uses unordered delivery, so > >>>>>>>>that question did not really arise. > >>>>>>>> > >>>>>>>>But if you were to generalize the problem, I believe the > >>>>>>>>answer would be yes. > >>>>>>>> > >>>>>>>>The SSN for ordered delivery would be unchanged. The > >>>>>>>>addition would be providing "advisory ordering" for > >>>>>>>>unordered delivery. The general characteristic is that > >>>>>>>>the receiving ULP wants the data in whatever order it > >>>>>>>>arrives, but wants to know what the original order was. > >>>>>>>> > >>>>>>>>In addition to RDDP, RTP over UDP is another example of > >>>>>>>>an application that wants to be aware of the original > >>>>>>>>ordering, even while accepting the data out-of-order. > >>>>>>>> > >>>>>>>>Caitlin Bestler > >>>>>>>>http://asomi.com/CaitlinBestler/ > >>>>>>>>_______________________________________________ > >>>>>>>>tsvwg mailing list > >>>>>>>>tsvwg@ietf.org > >>>>>>>>https://www1.ietf.org/mailman/listinfo/tsvwg > >>>>>>>> > >>>>>>> > >>>>>>>_______________________________________________ > >>>>>>>tsvwg mailing list > >>>>>>>tsvwg@ietf.org > >>>>>>>https://www1.ietf.org/mailman/listinfo/tsvwg > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>>-- > >>>>>>Randall R. Stewart > >>>>>>randall@stewart.chicago.il.us 815-342-5222 (cell phone) > >>>>>> > >>>>>>_______________________________________________ > >>>>>>tsvwg mailing list > >>>>>>tsvwg@ietf.org > >>>>>>https://www1.ietf.org/mailman/listinfo/tsvwg > >>>>> > >>>>> > >>>>-- > >>>>Randall R. Stewart > >>>>randall@stewart.chicago.il.us 815-342-5222 (cell phone) > >>> > >>> > >> > >>-- > >>Randall R. Stewart > >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) > > > > > > > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 12 11:24:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07855 for ; Wed, 12 Feb 2003 11:24:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CGYIq02910 for tsvwg-archive@odin.ietf.org; Wed, 12 Feb 2003 11:34:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CGWZp02486; Wed, 12 Feb 2003 11:32:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CGUQp02375 for ; Wed, 12 Feb 2003 11:30:26 -0500 Received: from thebe.your-site.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07798 for ; Wed, 12 Feb 2003 11:20:28 -0500 (EST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 0177A24531F; Wed, 12 Feb 2003 11:24:07 -0500 (EST) Date: Wed, 12 Feb 2003 10:25:19 -0600 From: Caitlin Bestler Subject: Re: [Tsvwg] A question of Un-Ordered SCTP To: tsvwg@ietf.org Cc: Randall Stewart , Tuexen Michael , Michael Tuexen , bidulock@openss7.org X-Priority: 3 In-Reply-To: <20030212053157.B29464@openss7.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 2/12/03, Brian F. G. Bidulock wrote: >Randall, > >For RDDP why not just suppress ordered delivery (order of >arrival rather than order of sending) of data in the >stream at the receiver. That way you can use the SSN of >ordered DATA chunks instead of trying to add SSNs to >unorderd data chunks. > One of RDDP's requirements is that data be provided to it as soon as possible. (Regular readers of this mailing list will note how carefully I avoided using the word "delivered"). So, trying to work with SCTP on SCTP's terms, you have three possible strategies: -- Include a SSN-equivalent in the Data Chunk. -- Allow out-of-order placement of ordered Data chunks. -- Make SCTP's SSN meaningful for unordered delivery. The pure ULP solution obviously has the least impact on the SCTP layer. But it smacks of having the ULP duplicate functionality that rightfully belongs at the transport layer. I believe the quick consenseus is that sequenced unordered delivery is a natural concept that has value beyond any single ULP. Allowing out-of-order placement of ordered Data chunks is possible, but strikes me as a major change to an SCTP reciever. To achieve the desired performance, the new feature must be integrated with the existing SCTP stack, and would likely require it to be restructured. NOT desirable. The last option is clearly easily implemented. This is particularly true if you adopt Randall's suggested algorithm for identifying traditional "no sequence information" unordered delivery by the fact that you have *never* gotten a non-zero SSN on an unordered packet. When a receiveer has *never* gotten a non-zero SSN on an unordered packet, it may only infer order from the TSN. That algorithm will work for RDDP. It even allows RDDP to be built on top of an unmodified SCTP stack, which is a very good thing. The impact of not supplying the SSN is that the RDDP receiver can only determine that a Data chunk is deliverable when *all* Data Chunks with lower TSNs have been delivered, whether they are part of the same stream or not. Given that one of the goals of SCTP is to avoid head-of-line blocking that didn't strike me as a complete solution. >Also, that way a RDDP/SCTP compliant sender will be >compatible with a non-RDDP/SCTP compliant receiver. > >If you use unordered DATA chunks, the non-RDDP/SCTP >compliant receiver will deliver data out of order (instead >of in order) on the stream, which is a bad thing. > The ULP is either RDDP or it is not. If the sender and receivers are not in agreement about what ULP is in use then you already have a bit of a problem. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 12 12:14:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09151 for ; Wed, 12 Feb 2003 12:14:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CHO7H07145 for tsvwg-archive@odin.ietf.org; Wed, 12 Feb 2003 12:24:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHNlp07133; Wed, 12 Feb 2003 12:23:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHLDp07044 for ; Wed, 12 Feb 2003 12:21:13 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09056 for ; Wed, 12 Feb 2003 12:11:13 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:d7747wa163cnykLyy5H1RtO2slYLbGLx@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1CHEpD22228; Wed, 12 Feb 2003 10:14:51 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1CHEpf08677; Wed, 12 Feb 2003 10:14:51 -0700 Date: Wed, 12 Feb 2003 10:14:51 -0700 From: "Brian F. G. Bidulock" To: Caitlin Bestler Cc: tsvwg@ietf.org, Randall Stewart , Tuexen Michael , Michael Tuexen Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030212101451.B5499@openss7.org> Reply-To: bidulock@openss7.org References: <20030212053157.B29464@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cait@asomi.com on Wed, Feb 12, 2003 at 10:25:19AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Caitlin, On Wed, 12 Feb 2003, Caitlin Bestler wrote: > On 2/12/03, Brian F. G. Bidulock wrote: > > >Randall, > > > >For RDDP why not just suppress ordered delivery (order of > >arrival rather than order of sending) of data in the > >stream at the receiver. That way you can use the SSN of > >ordered DATA chunks instead of trying to add SSNs to > >unorderd data chunks. > > > One of RDDP's requirements is that data be provided to it as > soon as possible. (Regular readers of this mailing list will > note how carefully I avoided using the word "delivered"). > > So, trying to work with SCTP on SCTP's terms, you have three > possible strategies: > > -- Include a SSN-equivalent in the Data Chunk. > > -- Allow out-of-order placement of ordered Data chunks. > > -- Make SCTP's SSN meaningful for unordered delivery. > > The pure ULP solution obviously has the least impact on > the SCTP layer. But it smacks of having the ULP duplicate > functionality that rightfully belongs at the transport > layer. I believe the quick consenseus is that sequenced > unordered delivery is a natural concept that has value > beyond any single ULP. > > Allowing out-of-order placement of ordered Data chunks > is possible, but strikes me as a major change to an SCTP > reciever. To achieve the desired performance, the new > feature must be integrated with the existing SCTP stack, > and would likely require it to be restructured. NOT > desirable. Not true. Ordered delivery takes work. Order of arrival delivery does not. SCTP does both. Altering the SCTP receiver merely consists of treating non U-bit Data Chunks like U-bit Data Chunks with SSNs. The SCTP receiver already has all the necessary mechanisms. > > The last option is clearly easily implemented. Not easier than allowing out of order placement of ordered data chunks. Implementations have been allowed to make the assumption that an SSN does not exist for U-bit data chunks. They already exist for ordered data chunks. The second approach requires that the SCTP transmitter start numbering unordered data chunks with a separate numbering space. This required another expensive 16-bits per stream structure. When supporting thousands of streams this is expensive, particularly if unused on a given association. Delivering unordered data chunks as they arrive is far less expensive. If done on a per-association basis, no per-stream structure increases are necessary. Even if doen on a per-stream basis, only one (probably already unused) flag bit per stream would be necessary. > > This is particularly true if you adopt Randall's suggested > algorithm for identifying traditional "no sequence > information" unordered delivery by the fact that you have > *never* gotten a non-zero SSN on an unordered packet. > > When a receiveer has *never* gotten a non-zero SSN on an > unordered packet, it may only infer order from the TSN. > That algorithm will work for RDDP. The algorithm does not help per-stream structure expense. The extra 16-bits per stream must be allocated in preparation for such a delivery. > > It even allows RDDP to be built on top of an unmodified SCTP > stack, which is a very good thing. The other approaches permit that too. > The impact of not > supplying the SSN is that the RDDP receiver can only > determine that a Data chunk is deliverable when *all* > Data Chunks with lower TSNs have been delivered, whether > they are part of the same stream or not. The second approach has the efficiency that (if unmodified) the data will be delivered ordered and RDDP can place them faster than if SSN is not included in the unordered data chunks. This is because data chunks will be delivered around missing TSNs from other streams. By working with TSNs you would re-introduce inter-stream HOL blocking which the second approach would eliminate. > Given that one > of the goals of SCTP is to avoid head-of-line blocking > that didn't strike me as a complete solution. > > > >Also, that way a RDDP/SCTP compliant sender will be > >compatible with a non-RDDP/SCTP compliant receiver. > > > >If you use unordered DATA chunks, the non-RDDP/SCTP > >compliant receiver will deliver data out of order (instead > >of in order) on the stream, which is a bad thing. > > > > The ULP is either RDDP or it is not. If the sender and > receivers are not in agreement about what ULP is in use > then you already have a bit of a problem. A receiving ULP could be configured to ignore the RDDP header in received data. The first approach does not require any SCTP modifications. The second approach (allowed unordered delivery of ordered data chunks) requires the least expense on the part of the SCTP implementation (no per-stream structure increases) and uses existing procedures (unordered delivery). The third approach requires the most expense (per-stream structure increases) and delivery of SSN to the ULP where it was not previously delivered. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 12 15:25:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14747 for ; Wed, 12 Feb 2003 15:25:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CKYg618538 for tsvwg-archive@odin.ietf.org; Wed, 12 Feb 2003 15:34:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CKYNp18529; Wed, 12 Feb 2003 15:34:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CKXmp18501 for ; Wed, 12 Feb 2003 15:33:48 -0500 Received: from thebe.your-site.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14725 for ; Wed, 12 Feb 2003 15:23:44 -0500 (EST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id D9C98244E4E; Wed, 12 Feb 2003 15:27:28 -0500 (EST) Date: Wed, 12 Feb 2003 14:28:40 -0600 From: Caitlin Bestler Subject: Re: [Tsvwg] A question of Un-Ordered SCTP To: bidulock@openss7.org, tsvwg@ietf.org X-Priority: 3 In-Reply-To: <20030212101451.B5499@openss7.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 2/12/03, Brian F. G. Bidulock wrote: >> >> It even allows RDDP to be built on top of an unmodified >> SCTP stack, which is a very good thing. > >The other approaches permit that too. > There is a distinction when running over unmodified SCTP stacks. With sequenced unordered delivery, an DDP receiver will have the Data Chunks delivered to it even with no modifications to either SCTP stack. In fact it will probably get the non-zero SSN if the sender's SCTP stack is the only one that has been modified. But even if there is no additional information, the data may be placed immediately. It is only final delivery that is subject to cross-stream head-of-line blocking. With a modified stack, early placement of ordered Data Chunks clearly fulfills the needs of RDDP. However, if the SCTP receiver is unmodified, in-stream drops will result in HOL blocking of placement. This will require intermediate buffering of the Data Chunks, which RDDP seeks to avoid. A scenario where unordered delivery is a problem: TSN: 101 Stream ID: 7 SSN: 0 TSN: 102 Stream ID: 8 SSN: 0 TSN: 104 Stream ID: 7 SSN: 0 When the Data Chunk with TSN 104 is received, it can be placed, but it cannot be delivered to the ULP because there is no way to know which Stream ID TSN 103 was for. Adding the SSN, solves that. In the following example it would be clear that TSN 104/SSN 18 is in fact deliverable. TSN: 101 Stream ID: 7 SSN: 17 TSN: 102 Stream ID: 8 SSN: 43 TSN: 104 Stream ID: 7 SSN: 18 The problem with ordered delivery over an unmodified SCTP receiver deals with the following scenario: TSN: 101 Stream ID: 7 SSN: 17 TSN: 103 Stream ID: 7 SSN: 19 An unmodified SCTP receiver will not make TSN-103/SSN-19 available to the DDP layer until TSN-102/SSN-18 shows up. The impact of the in-stream gap is that non-ULP buffering is required for post-gap Data Chunks. This is a far greater impact that the delay in delivery of the first scenario. One deals with buffering capacity and memory bandwidth, the other deals with latency. Clearly, either modification solves the problem. But I believe unordered delivery is clearly a better solution when working with unmodified SCTP stacks. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 12 15:40:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15172 for ; Wed, 12 Feb 2003 15:40:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CKoWB19924 for tsvwg-archive@odin.ietf.org; Wed, 12 Feb 2003 15:50:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CKo4p19890; Wed, 12 Feb 2003 15:50:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CKnOp19838 for ; Wed, 12 Feb 2003 15:49:24 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15141 for ; Wed, 12 Feb 2003 15:39:20 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:kNYTECGcU3L77KN8xnQ1MXmmJmV3lqYU@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1CKh4D26348; Wed, 12 Feb 2003 13:43:04 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1CKh4S07357; Wed, 12 Feb 2003 13:43:04 -0700 Date: Wed, 12 Feb 2003 13:43:04 -0700 From: "Brian F. G. Bidulock" To: Caitlin Bestler Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030212134304.B1284@openss7.org> Reply-To: bidulock@openss7.org References: <20030212101451.B5499@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cait@asomi.com on Wed, Feb 12, 2003 at 02:28:40PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Caitlin, On Wed, 12 Feb 2003, Caitlin Bestler wrote: > On 2/12/03, Brian F. G. Bidulock wrote: > > > >> > >> It even allows RDDP to be built on top of an unmodified > >> SCTP stack, which is a very good thing. > > > >The other approaches permit that too. > > > There is a distinction when running over unmodified SCTP > stacks. > > With sequenced unordered delivery, an DDP receiver will > have the Data Chunks delivered to it even with no > modifications to either SCTP stack. In fact it will probably > get the non-zero SSN if the sender's SCTP stack is the only > one that has been modified. Or probably not, because there was no need to deliver SSN=0 for each unordered data and it would be inefficient to do so. > > But even if there is no additional information, the data may > be placed immediately. It is only final delivery that is > subject to cross-stream head-of-line blocking. So? The time taken to place the last in-order pieces before indicating final delivery is probably to the time taken to place the last out-of-order piece before final delivery. > With a modified stack, early placement of ordered Data > Chunks clearly fulfills the needs of RDDP. However, if the > SCTP receiver is unmodified, in-stream drops will result > in HOL blocking of placement. This will require intermediate > buffering of the Data Chunks, which RDDP seeks to avoid. > > > A scenario where unordered delivery is a problem: > > TSN: 101 Stream ID: 7 SSN: 0 > TSN: 102 Stream ID: 8 SSN: 0 > > TSN: 104 Stream ID: 7 SSN: 0 > > When the Data Chunk with TSN 104 is received, it can > be placed, but it cannot be delivered to the ULP because > there is no way to know which Stream ID TSN 103 was for. > Using ordered data chunks solves that. > Adding the SSN, solves that. In the following example it > would be clear that TSN 104/SSN 18 is in fact deliverable. > > TSN: 101 Stream ID: 7 SSN: 17 > TSN: 102 Stream ID: 8 SSN: 43 > > TSN: 104 Stream ID: 7 SSN: 18 > > > The problem with ordered delivery over an unmodified SCTP > receiver deals with the following scenario: > > TSN: 101 Stream ID: 7 SSN: 17 > > TSN: 103 Stream ID: 7 SSN: 19 > > An unmodified SCTP receiver will not make TSN-103/SSN-19 > available to the DDP layer until TSN-102/SSN-18 shows up. So what? DDP cannot indicate delivery until SSN=18 shows up either. All it can do is place SSN=19 before SSN=18 which is hardly a boost. It still has to place SSN=18 in the gap and the unmodified ordered data chunks scenario is far better than the unmodified unordered data chunks scenario. > The impact of the in-stream gap is that non-ULP buffering > is required for post-gap Data Chunks. This is a far greater > impact that the delay in delivery of the first scenario. It is not. Replace last your example above wtih SSN: 0 on TSN 101 and TSN 103. The unmodified unordered data chunk scenario performs as poorly in that specific case than the unmodified ordered data chunk scenario. The unmodified ordered data chunk scenario performs better than the unmodified ordered data chunk scenaio in the first example: adding SSNs: TSN: 101 Stream ID: 7 SSN: 20 TSN: 102 Stream ID: 8 SSN: 12 TSN: 104 Stream ID: 7 SSN: 21 The unmodified ordered data chunk secnario will deliver TSN 104 immediately. The unmodified unordered data chunk scenario will have to wait for TSN 103 before it discovers that it could have placed and delivered TSN 104. The unmodified ordered data chunk scenrio is always equal to or better than the unmodified unordered data chunk scenario because the first can detect SSN gaps. > One deals with buffering capacity and memory bandwidth, > the other deals with latency. > > Clearly, either modification solves the problem. But I > believe unordered delivery is clearly a better solution > when working with unmodified SCTP stacks. Quite the reverse is the case for unmodified stacks. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Feb 13 08:56:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12288 for ; Thu, 13 Feb 2003 08:56:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DE60a21701 for tsvwg-archive@odin.ietf.org; Thu, 13 Feb 2003 09:06:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DE5gp21685; Thu, 13 Feb 2003 09:05:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DE4Mp21542 for ; Thu, 13 Feb 2003 09:04:22 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12205; Thu, 13 Feb 2003 08:53:57 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1DDvJQE000570; Thu, 13 Feb 2003 07:57:19 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E4BA43E.6010807@stewart.chicago.il.us> Date: Thu, 13 Feb 2003 07:57:18 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuexen Michael , Caitlin Bestler CC: Michael Tuexen , tsvwg@ietf.org, sigtran@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Michael/Caitlin: Ok, I think that there is enough mixed sentiment on this issue that here is how we should proceed: a) A CAPABILITIES TLV should probably be created, possibly in the add-ip draft? That could then indicate different supported cababilities like, add/del/set-primary/pr-sctp and our new idea unreliable with sender sequencing. b) A new small draft should be created outlining: 1) a seperate sequence space, 2) how it would be used with un-ordered 3) a recommendation to the receivers to pass the unordered SSN to the ULP as is, I know in my impelementation I did this anyway.. it takes extra code to NOT do this :> so I think thats pretty non-controversial. 4) specify a capability value for this. c) Update the pr-sctp draft to use the capabilites as well and get rid of its specialized TLV to annoucne pr-sctp. Get all of this submitted and see how the general wg feels about it.. If you would like I will send you a rought draft in a week or two.. sound ok? R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Feb 15 09:20:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03077 for ; Sat, 15 Feb 2003 09:20:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1FEOwd27016 for tsvwg-archive@odin.ietf.org; Sat, 15 Feb 2003 09:24:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1FEOPp26886; Sat, 15 Feb 2003 09:24:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C8kvp29495 for ; Wed, 12 Feb 2003 03:46:57 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26156; Wed, 12 Feb 2003 03:37:06 -0500 (EST) Received: from blues.mchh.siemens.de ([139.21.204.206]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA25330; Wed, 12 Feb 2003 09:40:45 +0100 (MET) Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA23879; Wed, 12 Feb 2003 09:40:19 +0100 (MET) Received: by MCHH253E with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Feb 2003 09:39:55 +0100 Message-ID: From: Tuexen Michael To: "'bidulock@openss7.org'" , Randall Stewart Cc: Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org, Tuexen Michael , sigtran@ietf.org Subject: RE: [Tsvwg] A question of Un-Ordered SCTP Date: Wed, 12 Feb 2003 09:39:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Brian, see my comments below. Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Wednesday, February 12, 2003 3:16 AM > To: Randall Stewart > Cc: Michael Tuexen; Caitlin Bestler; tsvwg@ietf.org; Tuexen Michael; > sigtran@ietf.org > Subject: Re: [Tsvwg] A question of Un-Ordered SCTP > > > Randall, > > I agree to having SCTP set the sequence number and, as you said in > your first note, SCTP passing the sequence number to the ULP on > the receiving side is already done for ordered traffic. Some even > pass the zero now. > > I suppose that SCTP would set this sequence number when it is given > the data for delivery at the sending ULP and the sequence > would represent > the order that the data was presented to SCTP by the ULP at > the sending > side. > > I think it would be good to see the requirement that the sequence > number begin at 1 and be monotonically increasing in the saem fashion > as ordered streams. > I would prefer that the two sequence spaces are handled the same way. Thus both start with SSN=0. > That way RDDP and other applications could perform their own > reordering > at the receiver. I think it would be a good thing to have SCTP set > this value. > > In fact, I can see another application for this feature. M2PA > (SIGTRAN protocol) needs in some circumstances to send data unordered > with the hope of expedited delivery (does not want control information > stuck behind large amounts of data in an ordered stream), however, the > order of processing of the expedited control information is important. > > This facility would permit M2PA to send such information unordered > to expedite it and the receiver could perform the reordering itself. > Up until now, the only solution was to place a sequence number in with > the control information. > > Could we perhaps add a section to the SCTP IG. "Problem statement: > the sender wishes to send unordered data but the receive needs to know > the original order of sending..." or some such. > > It should be quite simple to add the feature to existing SCTP > implementations. > > --brian > > > On Tue, 11 Feb 2003, Randall Stewart wrote: > > > Michael: > > > > This seems like a valid method.. it gets around Brian's objection > > (which was a good point) and yet still provides the application with > > a hint about what the assigned sequence order was on the unordered > > messages... > > > > R > > > > Michael Tuexen wrote: > > > Caitlin, > > > > > > thank you very much for the clarification. > > > > > > I do not like the idea to pass the SSN transparently from > the ULP to the > > > ULP. > > > But having two sequence spaces is OK for me. This means > that the SSN at the > > > sending side is controlled by the SCTP and given to the > ULP at the > > > receiving side. > > > > > > This would be a clean solution. So I voting for have two > separate number > > > spaces > > > for user data. Since the one for ordered delivery exists > already in RFC > > > 2960, this > > > only means that a new one is introduced for the unordered > delivery user > > > data. > > > > > > Best regards > > > Michael > > > > > > On Tuesday, Feb 11, 2003, at 17:37 Europe/Berlin, Caitlin > Bestler wrote: > > > > > >> On 2/11/03, Tuexen Michael wrote: > > >> > > >>> Dear all, > > >>> > > >>> does this mean that you want two sequence spaces per > > >>> stream: one for the 'ordered' user data and one for the > > >>> unordered user data? > > >>> > > >> The RDDP/SCTP adaptation only uses unordered delivery, so > > >> that question did not really arise. > > >> > > >> But if you were to generalize the problem, I believe the > > >> answer would be yes. > > >> > > >> The SSN for ordered delivery would be unchanged. The > > >> addition would be providing "advisory ordering" for > > >> unordered delivery. The general characteristic is that > > >> the receiving ULP wants the data in whatever order it > > >> arrives, but wants to know what the original order was. > > >> > > >> In addition to RDDP, RTP over UDP is another example of > > >> an application that wants to be aware of the original > > >> ordering, even while accepting the data out-of-order. > > >> > > >> Caitlin Bestler > > >> http://asomi.com/CaitlinBestler/ > > >> _______________________________________________ > > >> tsvwg mailing list > > >> tsvwg@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/tsvwg > > >> > > > > > > _______________________________________________ > > > tsvwg mailing list > > > tsvwg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/tsvwg > > > > > > > > > > > > -- > > Randall R. Stewart > > randall@stewart.chicago.il.us 815-342-5222 (cell phone) > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Feb 15 09:21:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03090 for ; Sat, 15 Feb 2003 09:21:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1FEPER27066 for tsvwg-archive@odin.ietf.org; Sat, 15 Feb 2003 09:25:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1FEOlp26919; Sat, 15 Feb 2003 09:24:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CBv4p08186 for ; Wed, 12 Feb 2003 06:57:04 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29722 for ; Wed, 12 Feb 2003 06:47:11 -0500 (EST) Received: from blues.mchh.siemens.de ([139.21.204.206]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA20888; Wed, 12 Feb 2003 12:50:55 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA24286; Wed, 12 Feb 2003 12:50:28 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2656.59) id ; Wed, 12 Feb 2003 12:50:04 +0100 Message-ID: From: Tuexen Michael To: "'bidulock@openss7.org'" , Tuexen Michael Cc: Randall Stewart , Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org Subject: RE: [Tsvwg] A question of Un-Ordered SCTP Date: Wed, 12 Feb 2003 12:50:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1CBv4p08187 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Brian, it is NOT a procedure. You just put the parameter in the INIT or INIT-ACK chunk if you support it. On a communication up event you pass this info to the ULP. That is all, very simple. Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Wednesday, February 12, 2003 12:34 PM > To: Tuexen Michael > Cc: Randall Stewart; Michael Tuexen; Caitlin Bestler; tsvwg@ietf.org > Subject: Re: [Tsvwg] A question of Un-Ordered SCTP > > > Michael, > > I disagree. Adding an new INIT/INIT ACK procedure to start > counting at 0 instead of 1 seems excessive to me. > > --brian > > On Wed, 12 Feb 2003, Tuexen Michael wrote: > > > Brian, > > > > I understand your point, but I think it is clearer to > > define a new parameter of length 8 bytes to be included > > in the INIT / INIT-ACK which indicates that this feature used. > > Like in the case of PR-SCTP. This make the stuff explicit > > and introduces almost no additional complexity. > > > > Best regards > > Michael > > > > Michael Tuexen Tel.: +49 89 722 47210 > > Siemens AG Fax: +49 89 722 48212 > > ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > > > > > -----Original Message----- > > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > > Sent: Wednesday, February 12, 2003 10:44 AM > > > To: Tuexen Michael > > > Cc: Randall Stewart; Michael Tuexen; Caitlin Bestler; > tsvwg@ietf.org > > > Subject: Re: [Tsvwg] A question of Un-Ordered SCTP > > > > > > > > > Michael, > > > > > > Tuexen Michael wrote: > > > (Wed, 12 Feb 2003 09:39:41) > > > > > > > > > > I think it would be good to see the requirement that > the sequence > > > > > number begin at 1 and be monotonically increasing in the > > > saem fashion > > > > > as ordered streams. > > > > > > > > > I would prefer that the two sequence spaces are handled the same > > > > way. Thus both start with SSN=0. > > > > > > That would make it impossible to distinguish between > SCTP's supporting > > > the feature and SCTP's not supporting the feature on the > first message > > > in a stream. > > > > > > Leaving '0' for unordered packets of unspecified transmission > > > order has > > > some value for backwards compatibility and interoperability. > > > > > > --brian > > > > > > -- > > > Brian F. G. Bidulock > > > bidulock@openss7.org > > > http://www.openss7.org/ > > > > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Feb 15 09:21:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03103 for ; Sat, 15 Feb 2003 09:21:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1FEPGs27079 for tsvwg-archive@odin.ietf.org; Sat, 15 Feb 2003 09:25:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1FEOup27009; Sat, 15 Feb 2003 09:24:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DEOjp23215 for ; Thu, 13 Feb 2003 09:24:45 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12540; Thu, 13 Feb 2003 09:14:19 -0500 (EST) Received: from blues.mchh.siemens.de ([139.21.204.206]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA23532; Thu, 13 Feb 2003 15:18:01 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA15070; Thu, 13 Feb 2003 15:17:36 +0100 (MET) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id <1JB5YMD4>; Thu, 13 Feb 2003 15:17:12 +0100 Message-ID: From: Tuexen Michael To: "'Randall Stewart'" , Tuexen Michael , Caitlin Bestler Cc: Michael Tuexen , tsvwg@ietf.org, sigtran@ietf.org Subject: RE: [Tsvwg] A question of Un-Ordered SCTP Date: Thu, 13 Feb 2003 15:17:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Sounds good to me. Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > -----Original Message----- > From: Randall Stewart [mailto:randall@stewart.chicago.il.us] > Sent: Thursday, February 13, 2003 2:57 PM > To: Tuexen Michael; Caitlin Bestler > Cc: Michael Tuexen; tsvwg@ietf.org; sigtran@ietf.org > Subject: Re: [Tsvwg] A question of Un-Ordered SCTP > > > Michael/Caitlin: > > Ok, I think that there is enough mixed sentiment on this issue > that here is how we should proceed: > > a) A CAPABILITIES TLV should probably be created, possibly in > the add-ip draft? That could then indicate different supported > cababilities like, add/del/set-primary/pr-sctp and our new > idea unreliable with sender sequencing. > > b) A new small draft should be created outlining: > 1) a seperate sequence space, > 2) how it would be used with un-ordered > 3) a recommendation to the receivers to pass > the unordered SSN to the ULP as is, I know > in my impelementation I did this anyway.. it > takes extra code to NOT do this :> so I think > thats pretty non-controversial. > 4) specify a capability value for this. > > c) Update the pr-sctp draft to use the capabilites as > well and get rid of its specialized TLV to annoucne > pr-sctp. > > Get all of this submitted and see how the general wg feels about > it.. > > If you would like I will send you a rought draft in a > week or two.. sound ok? > > R > > > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Feb 15 09:21:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03116 for ; Sat, 15 Feb 2003 09:21:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1FEPHP27092 for tsvwg-archive@odin.ietf.org; Sat, 15 Feb 2003 09:25:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1FEOqp26979; Sat, 15 Feb 2003 09:24:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CFtNp25554 for ; Wed, 12 Feb 2003 10:55:23 -0500 Received: from chuckie.dgms.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06779 for ; Wed, 12 Feb 2003 10:45:27 -0500 (EST) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id KAA21085; Wed, 12 Feb 2003 10:45:18 -0500 (EST) Message-ID: <3E4A6C0E.5080104@ulticom.com> Date: Wed, 12 Feb 2003 10:45:18 -0500 From: David Lehmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randall Stewart CC: TSV WG list , SCTP Implementors Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: <3E48EF01.9080502@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Randall Stewart wrote: > Currently the sender of a Unordered data chunk sets the > SSN to 0 and the receiver of the Unordered data chunk ignores > the contents of the field.. When did this change? RFC 2960, section 6.6 states, The 'Stream Sequence Number' field in a DATA chunk with U flag set to 1 has no significance. The sender can fill it with arbitrary value, but the receiver MUST ignore the field. Where is it stated that the SSN should be set to zero for unordered data chunks? -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Feb 15 09:21:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03129 for ; Sat, 15 Feb 2003 09:21:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1FEPJf27105 for tsvwg-archive@odin.ietf.org; Sat, 15 Feb 2003 09:25:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1FEOhp26903; Sat, 15 Feb 2003 09:24:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CBXHp06725 for ; Wed, 12 Feb 2003 06:33:17 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29217 for ; Wed, 12 Feb 2003 06:23:24 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA19257; Wed, 12 Feb 2003 12:27:04 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA02204; Wed, 12 Feb 2003 12:27:04 +0100 (MET) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id <1Z1M2RCJ>; Wed, 12 Feb 2003 12:26:15 +0100 Message-ID: From: Tuexen Michael To: "'bidulock@openss7.org'" , Tuexen Michael Cc: Randall Stewart , Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org Subject: RE: [Tsvwg] A question of Un-Ordered SCTP Date: Wed, 12 Feb 2003 12:26:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Brian, I understand your point, but I think it is clearer to define a new parameter of length 8 bytes to be included in the INIT / INIT-ACK which indicates that this feature used. Like in the case of PR-SCTP. This make the stuff explicit and introduces almost no additional complexity. Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Wednesday, February 12, 2003 10:44 AM > To: Tuexen Michael > Cc: Randall Stewart; Michael Tuexen; Caitlin Bestler; tsvwg@ietf.org > Subject: Re: [Tsvwg] A question of Un-Ordered SCTP > > > Michael, > > Tuexen Michael wrote: > (Wed, 12 Feb 2003 09:39:41) > > > > > > I think it would be good to see the requirement that the sequence > > > number begin at 1 and be monotonically increasing in the > saem fashion > > > as ordered streams. > > > > > I would prefer that the two sequence spaces are handled the same > > way. Thus both start with SSN=0. > > That would make it impossible to distinguish between SCTP's supporting > the feature and SCTP's not supporting the feature on the first message > in a stream. > > Leaving '0' for unordered packets of unspecified transmission > order has > some value for backwards compatibility and interoperability. > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Feb 15 09:21:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03142 for ; Sat, 15 Feb 2003 09:21:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1FEPKH27118 for tsvwg-archive@odin.ietf.org; Sat, 15 Feb 2003 09:25:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1FEOop26949; Sat, 15 Feb 2003 09:24:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCiIp11764 for ; Wed, 12 Feb 2003 07:44:18 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00907; Wed, 12 Feb 2003 07:34:23 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA24579; Wed, 12 Feb 2003 13:38:06 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA14552; Wed, 12 Feb 2003 13:38:05 +0100 (MET) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id <146820DR>; Wed, 12 Feb 2003 13:37:16 +0100 Message-ID: From: Tuexen Michael To: "'Randall Stewart'" , Tuexen Michael Cc: bidulock@openss7.org, Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org, sigtran@ietf.org Subject: RE: [Tsvwg] A question of Un-Ordered SCTP Date: Wed, 12 Feb 2003 13:37:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , 32 bits were easier to draw... No problem in making them 16 bit unsigned. Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > -----Original Message----- > From: Randall Stewart [mailto:randall@stewart.chicago.il.us] > Sent: Wednesday, February 12, 2003 1:25 PM > To: Tuexen Michael > Cc: bidulock@openss7.org; Michael Tuexen; Caitlin Bestler; > tsvwg@ietf.org; sigtran@ietf.org > Subject: Re: [Tsvwg] A question of Un-Ordered SCTP > > > This looks good.. but would it be > better to make the FEATURE_ID 16 bits.. > > .. my reasoning is that cookies are getting > bigger and it might be best to control there > length to some degree... I could go either way > but I think 65,535 features is more than enough > to choose from :> > > R > > Tuexen Michael wrote: > > Randy, > > > > I think having a FEATURES parameter would be a good idea. I do not > > like the idea of bitmask. Instead of this I would propose something > > like a FEATURES parameter which looks like: > > > > 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 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | FEATURES_PARAMETER_ID | Parameter > Length | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | FEATURE_ID 1 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | FEATURE_ID 2 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | FEATURE_ID 3 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | FEATURE_ID 4 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Each feature will be an IANA assiged 32 bit uint. This is > extendable. > > > > Best regards > > Michael > > > > Michael Tuexen Tel.: +49 89 722 47210 > > Siemens AG Fax: +49 89 722 48212 > > ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > > > > > >>-----Original Message----- > >>From: Randall Stewart [mailto:randall@stewart.chicago.il.us] > >>Sent: Wednesday, February 12, 2003 12:59 PM > >>To: bidulock@openss7.org; Michael Tuexen > >>Cc: Caitlin Bestler; tsvwg@ietf.org; Tuexen Michael; > sigtran@ietf.org > >>Subject: Re: [Tsvwg] A question of Un-Ordered SCTP > >> > >> > >>Brian/Michael: > >> > >>I do like the idea of keeping things the same (aka same > >>methodology)... this is good. > >> > >>It is also neat to be able to tell the difference between > >>an implementation that supports this feature and one that > >>does not. But there are positives and negatives, I think, > >>to each idea... > >> > >>A) For using a TLV, (as Michael suggests) > >> we really need to put this into a seperate > >> draft.. when I do think one could easily fit > >> this into the IG as Brian as suggested. > >> > >>B) montonically increasing numbers would eventually > >> wrap when the SSN hit FFFF back to 0... thus > >> the application would need to have some sort > >> of state to track if the peer supported the > >> feature. > >> > >>It seems to me it is only the first message that > >>arrives that benefits from the start at 0. If the > >>application assumes a "not supported", then by > >>starting the SSN at 1 the app can flip the flag > >>from "not supported" to "supported" on the arrival > >>of the first message. > >> > >>If the application instead set its flag to "supported" > >>the first message would not tell this information and > >>instead it would only be upon the second arriving message > >>that the app could make the flag determination... causing > >>either a delay in delivery of the first message (yuck) or > >>just toss it up and wait. > >> > >>More importantly, I am wondering, if the implementation does > >>NOT support this, what will the app do? Change its > >>message structure? If so it will need to have some clues > >>(as the initiator) that its implementation does not > >>support the feature .. possibly a HAVE_SCTP_UNORDERED_SSN > >>in sctp.h... but the problem is you would not know about > >>the other guy until its first unordered message arrives. > >>So if you have to send the first message what do you do? > >> > >>if HAVE_SCTP_UNORDERED_SSN is 0.. no problem.. you > >>send a message that has the imbedded sequence number.. but > >>what do you send when HAVE_SCTP_UNRODERED_SSN is set to 1? > >> > >>If you send the imbedded sequence in the message anyway whats > >>the point of this little trick? The second message (which you > >>may have to send before knowing receiving a unordered > >>msg from the peer) would still have this, and maybe the third > >>etc... > >> > >>Hmm.. the more I think on this the more it becomes clear that > >>you must know ahead of time i.e. when the association comes > >>up to "do the right thing".... which goes back to Michaels > >>idea of a TLV. > >> > >>I have been wondering for quite some time now if we don't > >>just need a TLV in the INIT/INIT-ACK that indicate features > >>in general... something like a bit mask or byte array indicating > >>each feature... > >> > >>addip > >>delip > >>prsctp > >>setprimary > >>unordered-assigns-sequences > >> > >>etc.. > >> > >>Maybe this is a better way to go.. and we could write a short > >>draft dictating this bit/byte TLV... code as a 0x80 class.. that > >>way old implementations will throw it away... (we really don't > >>care if they don't understand it)... > >> > >>I have been avoiding this.. but it might be the best approach.. > >> > >>Then again, I guess it could also be put in addip or prsctp since > >>it would effect them as well :> Then one could put the > >>other change in the IG and thus have a very easy change that > >>is in the IG and a minor update to either addip or prsctp... > >> > >> > >>What do you all think? > >> > >>R > >> > >>Brian F. G. Bidulock wrote: > >> > >>>Randall, > >>> > >>>I agree to having SCTP set the sequence number and, as you said in > >>>your first note, SCTP passing the sequence number to the ULP on > >>>the receiving side is already done for ordered traffic. Some even > >>>pass the zero now. > >>> > >>>I suppose that SCTP would set this sequence number when it is given > >>>the data for delivery at the sending ULP and the sequence > >> > >>would represent > >> > >>>the order that the data was presented to SCTP by the ULP at > >> > >>the sending > >> > >>>side. > >>> > >>>I think it would be good to see the requirement that the sequence > >>>number begin at 1 and be monotonically increasing in the > >> > >>saem fashion > >> > >>>as ordered streams. > >>> > >>>That way RDDP and other applications could perform their > >> > >>own reordering > >> > >>>at the receiver. I think it would be a good thing to have SCTP set > >>>this value. > >>> > >>>In fact, I can see another application for this feature. M2PA > >>>(SIGTRAN protocol) needs in some circumstances to send data > >> > >>unordered > >> > >>>with the hope of expedited delivery (does not want control > >> > >>information > >> > >>>stuck behind large amounts of data in an ordered stream), > >> > >>however, the > >> > >>>order of processing of the expedited control information is > >> > >>important. > >> > >>>This facility would permit M2PA to send such information unordered > >>>to expedite it and the receiver could perform the > reordering itself. > >>>Up until now, the only solution was to place a sequence > >> > >>number in with > >> > >>>the control information. > >>> > >>>Could we perhaps add a section to the SCTP IG. "Problem statement: > >>>the sender wishes to send unordered data but the receive > >> > >>needs to know > >> > >>>the original order of sending..." or some such. > >>> > >>>It should be quite simple to add the feature to existing SCTP > >>>implementations. > >>> > >>>--brian > >>> > >>> > >>>On Tue, 11 Feb 2003, Randall Stewart wrote: > >>> > >>> > >>> > >>>>Michael: > >>>> > >>>>This seems like a valid method.. it gets around Brian's objection > >>>>(which was a good point) and yet still provides the > application with > >>>>a hint about what the assigned sequence order was on the unordered > >>>>messages... > >>>> > >>>>R > >>>> > >>>>Michael Tuexen wrote: > >>>> > >>>> > >>>>>Caitlin, > >>>>> > >>>>>thank you very much for the clarification. > >>>>> > >>>>>I do not like the idea to pass the SSN transparently from > >>>> > >>the ULP to the > >> > >>>>>ULP. > >>>>>But having two sequence spaces is OK for me. This means > >>>> > >>that the SSN at the > >> > >>>>>sending side is controlled by the SCTP and given to the > ULP at the > >>>>>receiving side. > >>>>> > >>>>>This would be a clean solution. So I voting for have two > >>>> > >>separate number > >> > >>>>>spaces > >>>>>for user data. Since the one for ordered delivery exists > >>>> > >>already in RFC > >> > >>>>>2960, this > >>>>>only means that a new one is introduced for the unordered > >>>> > >>delivery user > >> > >>>>>data. > >>>>> > >>>>>Best regards > >>>>>Michael > >>>>> > >>>>>On Tuesday, Feb 11, 2003, at 17:37 Europe/Berlin, Caitlin > >>>> > >>Bestler wrote: > >> > >>>>> > >>>>>>On 2/11/03, Tuexen Michael wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Dear all, > >>>>>>> > >>>>>>>does this mean that you want two sequence spaces per > >>>>>>>stream: one for the 'ordered' user data and one for the > >>>>>>>unordered user data? > >>>>>>> > >>>>>> > >>>>>>The RDDP/SCTP adaptation only uses unordered delivery, so > >>>>>>that question did not really arise. > >>>>>> > >>>>>>But if you were to generalize the problem, I believe the > >>>>>>answer would be yes. > >>>>>> > >>>>>>The SSN for ordered delivery would be unchanged. The > >>>>>>addition would be providing "advisory ordering" for > >>>>>>unordered delivery. The general characteristic is that > >>>>>>the receiving ULP wants the data in whatever order it > >>>>>>arrives, but wants to know what the original order was. > >>>>>> > >>>>>>In addition to RDDP, RTP over UDP is another example of > >>>>>>an application that wants to be aware of the original > >>>>>>ordering, even while accepting the data out-of-order. > >>>>>> > >>>>>>Caitlin Bestler > >>>>>>http://asomi.com/CaitlinBestler/ > >>>>>>_______________________________________________ > >>>>>>tsvwg mailing list > >>>>>>tsvwg@ietf.org > >>>>>>https://www1.ietf.org/mailman/listinfo/tsvwg > >>>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>tsvwg mailing list > >>>>>tsvwg@ietf.org > >>>>>https://www1.ietf.org/mailman/listinfo/tsvwg > >>>>> > >>>>> > >>>> > >>>> > >>>>-- > >>>>Randall R. Stewart > >>>>randall@stewart.chicago.il.us 815-342-5222 (cell phone) > >>>> > >>>>_______________________________________________ > >>>>tsvwg mailing list > >>>>tsvwg@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/tsvwg > >>> > >>> > >> > >>-- > >>Randall R. Stewart > >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) > >> > > > > > > > > > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Feb 15 09:21:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03155 for ; Sat, 15 Feb 2003 09:21:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1FEPLq27134 for tsvwg-archive@odin.ietf.org; Sat, 15 Feb 2003 09:25:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1FEOpp26964; Sat, 15 Feb 2003 09:24:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCrvp12335 for ; Wed, 12 Feb 2003 07:53:57 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01166; Wed, 12 Feb 2003 07:44:01 -0500 (EST) Received: from blues.mchh.siemens.de ([139.21.204.206]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA18331; Wed, 12 Feb 2003 13:47:42 +0100 (MET) Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA02502; Wed, 12 Feb 2003 13:47:18 +0100 (MET) Received: by MCHH253E with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Feb 2003 13:46:53 +0100 Message-ID: From: Tuexen Michael To: "'bidulock@openss7.org'" , Randall Stewart Cc: Michael Tuexen , Caitlin Bestler , tsvwg@ietf.org, Tuexen Michael , sigtran@ietf.org Subject: RE: [Tsvwg] A question of Un-Ordered SCTP Date: Wed, 12 Feb 2003 13:46:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Brian, I disagree. The upper layer can say that he is interested in the order or not by using the ordered delivery service or not. The peer gets in both cases an indication of the sending sequence. You are proposing, that the ULP say I'm not interested in ordered delivery, but I would like to use unordered delivery. And now you have some Upper layer information that some messages belong to two classes (which you want to code SSN = 0 or != 0). From an SCTP service point of view there is NO difference. All messages marked for unordered delivery are given to the ULP as soon as possible. I think you want to encode some upper layer information by using SSN=0 or SSN=!0. For me this looks like layer violation. Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Wednesday, February 12, 2003 1:22 PM > To: Randall Stewart > Cc: Michael Tuexen; Caitlin Bestler; tsvwg@ietf.org; Tuexen Michael; > sigtran@ietf.org > Subject: Re: [Tsvwg] A question of Un-Ordered SCTP > > > Randall, > > For the M2PA application, I think that reserving > '0' for unordered messages for which the order of > sending is unimportant is still a good idea. > So the number space from 1 to 0xffff indicates > importance of order. '0' indicates no importance > of order. As in M2PA's case, a sender could mix > both on the same stream. > > There then becomes three different types of messages: > > 1) Unordered messages for which the order of sending is > unimportant (U-bit SSN=0), > > 2) unordered messages for which the order of sending is > important (U-bit SSN!=0), and > > 3) ordered messages for which the order of sending is > important (~U-bit). > > And this also handles compatibility because previous > unordered messages fall into category (1) by nature > of the fact that SSN==0. > > But starting counting at 1, you get rid of the ability > to indicate that the order of sending is unimportant and > force the receiving ULP to handle ordering of all received > unordered data. > > So, in short, start counting at 1, regardless of whether > there is an indicator in the INIT/INIT-ACK. > > --brian > > Randall Stewart wrote: > (Wed, 12 Feb 2003 05:58:55) > > Brian/Michael: > > > > I do like the idea of keeping things the same (aka same > > methodology)... this is good. > > > > It is also neat to be able to tell the difference between > > an implementation that supports this feature and one that > > does not. But there are positives and negatives, I think, > > to each idea... > > > > A) For using a TLV, (as Michael suggests) > > we really need to put this into a seperate > > draft.. when I do think one could easily fit > > this into the IG as Brian as suggested. > > > > B) montonically increasing numbers would eventually > > wrap when the SSN hit FFFF back to 0... thus > > the application would need to have some sort > > of state to track if the peer supported the > > feature. > > > > It seems to me it is only the first message that > > arrives that benefits from the start at 0. If the > > application assumes a "not supported", then by > > starting the SSN at 1 the app can flip the flag > > from "not supported" to "supported" on the arrival > > of the first message. > > > > If the application instead set its flag to "supported" > > the first message would not tell this information and > > instead it would only be upon the second arriving message > > that the app could make the flag determination... causing > > either a delay in delivery of the first message (yuck) or > > just toss it up and wait. > > > > More importantly, I am wondering, if the implementation does > > NOT support this, what will the app do? Change its > > message structure? If so it will need to have some clues > > (as the initiator) that its implementation does not > > support the feature .. possibly a HAVE_SCTP_UNORDERED_SSN > > in sctp.h... but the problem is you would not know about > > the other guy until its first unordered message arrives. > > So if you have to send the first message what do you do? > > > > if HAVE_SCTP_UNORDERED_SSN is 0.. no problem.. you > > send a message that has the imbedded sequence number.. but > > what do you send when HAVE_SCTP_UNRODERED_SSN is set to 1? > > > > If you send the imbedded sequence in the message anyway whats > > the point of this little trick? The second message (which you > > may have to send before knowing receiving a unordered > > msg from the peer) would still have this, and maybe the third > > etc... > > > > Hmm.. the more I think on this the more it becomes clear that > > you must know ahead of time i.e. when the association comes > > up to "do the right thing".... which goes back to Michaels > > idea of a TLV. > > > > I have been wondering for quite some time now if we don't > > just need a TLV in the INIT/INIT-ACK that indicate features > > in general... something like a bit mask or byte array indicating > > each feature... > > > > addip > > delip > > prsctp > > setprimary > > unordered-assigns-sequences > > > > etc.. > > > > Maybe this is a better way to go.. and we could write a short > > draft dictating this bit/byte TLV... code as a 0x80 class.. that > > way old implementations will throw it away... (we really don't > > care if they don't understand it)... > > > > I have been avoiding this.. but it might be the best approach.. > > > > Then again, I guess it could also be put in addip or prsctp since > > it would effect them as well :> Then one could put the > > other change in the IG and thus have a very easy change that > > is in the IG and a minor update to either addip or prsctp... > > > > > > What do you all think? > > > > R > > > > Brian F. G. Bidulock wrote: > > > Randall, > > > > > > I agree to having SCTP set the sequence number and, as you said in > > > your first note, SCTP passing the sequence number to the ULP on > > > the receiving side is already done for ordered traffic. Some even > > > pass the zero now. > > > > > > I suppose that SCTP would set this sequence number when > it is given > > > the data for delivery at the sending ULP and the sequence > would represent > > > the order that the data was presented to SCTP by the ULP > at the sending > > > side. > > > > > > I think it would be good to see the requirement that the sequence > > > number begin at 1 and be monotonically increasing in the > saem fashion > > > as ordered streams. > > > > > > That way RDDP and other applications could perform their > own reordering > > > at the receiver. I think it would be a good thing to > have SCTP set > > > this value. > > > > > > In fact, I can see another application for this feature. M2PA > > > (SIGTRAN protocol) needs in some circumstances to send > data unordered > > > with the hope of expedited delivery (does not want > control information > > > stuck behind large amounts of data in an ordered stream), > however, the > > > order of processing of the expedited control information > is important. > > > > > > This facility would permit M2PA to send such information unordered > > > to expedite it and the receiver could perform the > reordering itself. > > > Up until now, the only solution was to place a sequence > number in with > > > the control information. > > > > > > Could we perhaps add a section to the SCTP IG. "Problem > statement: > > > the sender wishes to send unordered data but the receive > needs to know > > > the original order of sending..." or some such. > > > > > > It should be quite simple to add the feature to existing SCTP > > > implementations. > > > > > > --brian > > > > > > > > > On Tue, 11 Feb 2003, Randall Stewart wrote: > > > > > > > > >>Michael: > > >> > > >>This seems like a valid method.. it gets around Brian's objection > > >>(which was a good point) and yet still provides the > application with > > >>a hint about what the assigned sequence order was on the unordered > > >>messages... > > >> > > >>R > > >> > > >>Michael Tuexen wrote: > > >> > > >>>Caitlin, > > >>> > > >>>thank you very much for the clarification. > > >>> > > >>>I do not like the idea to pass the SSN transparently > from the ULP to the > > >>>ULP. > > >>>But having two sequence spaces is OK for me. This means > that the SSN at the > > >>>sending side is controlled by the SCTP and given to the > ULP at the > > >>>receiving side. > > >>> > > >>>This would be a clean solution. So I voting for have two > separate number > > >>>spaces > > >>>for user data. Since the one for ordered delivery exists > already in RFC > > >>>2960, this > > >>>only means that a new one is introduced for the > unordered delivery user > > >>>data. > > >>> > > >>>Best regards > > >>>Michael > > >>> > > >>>On Tuesday, Feb 11, 2003, at 17:37 Europe/Berlin, > Caitlin Bestler wrote: > > >>> > > >>> > > >>>>On 2/11/03, Tuexen Michael wrote: > > >>>> > > >>>> > > >>>>>Dear all, > > >>>>> > > >>>>>does this mean that you want two sequence spaces per > > >>>>>stream: one for the 'ordered' user data and one for the > > >>>>>unordered user data? > > >>>>> > > >>>> > > >>>>The RDDP/SCTP adaptation only uses unordered delivery, so > > >>>>that question did not really arise. > > >>>> > > >>>>But if you were to generalize the problem, I believe the > > >>>>answer would be yes. > > >>>> > > >>>>The SSN for ordered delivery would be unchanged. The > > >>>>addition would be providing "advisory ordering" for > > >>>>unordered delivery. The general characteristic is that > > >>>>the receiving ULP wants the data in whatever order it > > >>>>arrives, but wants to know what the original order was. > > >>>> > > >>>>In addition to RDDP, RTP over UDP is another example of > > >>>>an application that wants to be aware of the original > > >>>>ordering, even while accepting the data out-of-order. > > >>>> > > >>>>Caitlin Bestler > > >>>>http://asomi.com/CaitlinBestler/ > > >>>>_______________________________________________ > > >>>>tsvwg mailing list > > >>>>tsvwg@ietf.org > > >>>>https://www1.ietf.org/mailman/listinfo/tsvwg > > >>>> > > >>> > > >>>_______________________________________________ > > >>>tsvwg mailing list > > >>>tsvwg@ietf.org > > >>>https://www1.ietf.org/mailman/listinfo/tsvwg > > >>> > > >>> > > >> > > >> > > >>-- > > >>Randall R. Stewart > > >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) > > >> > > >>_______________________________________________ > > >>tsvwg mailing list > > >>tsvwg@ietf.org > > >>https://www1.ietf.org/mailman/listinfo/tsvwg > > > > > > > > > > > > -- > > Randall R. Stewart > > randall@stewart.chicago.il.us 815-342-5222 (cell phone) > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Feb 15 09:21:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03168 for ; Sat, 15 Feb 2003 09:21:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1FEPNw27147 for tsvwg-archive@odin.ietf.org; Sat, 15 Feb 2003 09:25:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1FEOmp26934; Sat, 15 Feb 2003 09:24:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CCIMp09666 for ; Wed, 12 Feb 2003 07:18:22 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00082; Wed, 12 Feb 2003 07:08:28 -0500 (EST) Received: from blues.mchh.siemens.de ([139.21.204.206]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA22625; Wed, 12 Feb 2003 13:12:11 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA27398; Wed, 12 Feb 2003 13:11:43 +0100 (MET) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id <1JB5XSNB>; Wed, 12 Feb 2003 13:11:19 +0100 Message-ID: From: Tuexen Michael To: "'Randall Stewart'" , bidulock@openss7.org, Michael Tuexen Cc: Caitlin Bestler , tsvwg@ietf.org, Tuexen Michael , sigtran@ietf.org Subject: RE: [Tsvwg] A question of Un-Ordered SCTP Date: Wed, 12 Feb 2003 13:11:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Randy, I think having a FEATURES parameter would be a good idea. I do not like the idea of bitmask. Instead of this I would propose something like a FEATURES parameter which looks like: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEATURES_PARAMETER_ID | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEATURE_ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEATURE_ID 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEATURE_ID 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEATURE_ID 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Each feature will be an IANA assiged 32 bit uint. This is extendable. Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > -----Original Message----- > From: Randall Stewart [mailto:randall@stewart.chicago.il.us] > Sent: Wednesday, February 12, 2003 12:59 PM > To: bidulock@openss7.org; Michael Tuexen > Cc: Caitlin Bestler; tsvwg@ietf.org; Tuexen Michael; sigtran@ietf.org > Subject: Re: [Tsvwg] A question of Un-Ordered SCTP > > > Brian/Michael: > > I do like the idea of keeping things the same (aka same > methodology)... this is good. > > It is also neat to be able to tell the difference between > an implementation that supports this feature and one that > does not. But there are positives and negatives, I think, > to each idea... > > A) For using a TLV, (as Michael suggests) > we really need to put this into a seperate > draft.. when I do think one could easily fit > this into the IG as Brian as suggested. > > B) montonically increasing numbers would eventually > wrap when the SSN hit FFFF back to 0... thus > the application would need to have some sort > of state to track if the peer supported the > feature. > > It seems to me it is only the first message that > arrives that benefits from the start at 0. If the > application assumes a "not supported", then by > starting the SSN at 1 the app can flip the flag > from "not supported" to "supported" on the arrival > of the first message. > > If the application instead set its flag to "supported" > the first message would not tell this information and > instead it would only be upon the second arriving message > that the app could make the flag determination... causing > either a delay in delivery of the first message (yuck) or > just toss it up and wait. > > More importantly, I am wondering, if the implementation does > NOT support this, what will the app do? Change its > message structure? If so it will need to have some clues > (as the initiator) that its implementation does not > support the feature .. possibly a HAVE_SCTP_UNORDERED_SSN > in sctp.h... but the problem is you would not know about > the other guy until its first unordered message arrives. > So if you have to send the first message what do you do? > > if HAVE_SCTP_UNORDERED_SSN is 0.. no problem.. you > send a message that has the imbedded sequence number.. but > what do you send when HAVE_SCTP_UNRODERED_SSN is set to 1? > > If you send the imbedded sequence in the message anyway whats > the point of this little trick? The second message (which you > may have to send before knowing receiving a unordered > msg from the peer) would still have this, and maybe the third > etc... > > Hmm.. the more I think on this the more it becomes clear that > you must know ahead of time i.e. when the association comes > up to "do the right thing".... which goes back to Michaels > idea of a TLV. > > I have been wondering for quite some time now if we don't > just need a TLV in the INIT/INIT-ACK that indicate features > in general... something like a bit mask or byte array indicating > each feature... > > addip > delip > prsctp > setprimary > unordered-assigns-sequences > > etc.. > > Maybe this is a better way to go.. and we could write a short > draft dictating this bit/byte TLV... code as a 0x80 class.. that > way old implementations will throw it away... (we really don't > care if they don't understand it)... > > I have been avoiding this.. but it might be the best approach.. > > Then again, I guess it could also be put in addip or prsctp since > it would effect them as well :> Then one could put the > other change in the IG and thus have a very easy change that > is in the IG and a minor update to either addip or prsctp... > > > What do you all think? > > R > > Brian F. G. Bidulock wrote: > > Randall, > > > > I agree to having SCTP set the sequence number and, as you said in > > your first note, SCTP passing the sequence number to the ULP on > > the receiving side is already done for ordered traffic. Some even > > pass the zero now. > > > > I suppose that SCTP would set this sequence number when it is given > > the data for delivery at the sending ULP and the sequence > would represent > > the order that the data was presented to SCTP by the ULP at > the sending > > side. > > > > I think it would be good to see the requirement that the sequence > > number begin at 1 and be monotonically increasing in the > saem fashion > > as ordered streams. > > > > That way RDDP and other applications could perform their > own reordering > > at the receiver. I think it would be a good thing to have SCTP set > > this value. > > > > In fact, I can see another application for this feature. M2PA > > (SIGTRAN protocol) needs in some circumstances to send data > unordered > > with the hope of expedited delivery (does not want control > information > > stuck behind large amounts of data in an ordered stream), > however, the > > order of processing of the expedited control information is > important. > > > > This facility would permit M2PA to send such information unordered > > to expedite it and the receiver could perform the reordering itself. > > Up until now, the only solution was to place a sequence > number in with > > the control information. > > > > Could we perhaps add a section to the SCTP IG. "Problem statement: > > the sender wishes to send unordered data but the receive > needs to know > > the original order of sending..." or some such. > > > > It should be quite simple to add the feature to existing SCTP > > implementations. > > > > --brian > > > > > > On Tue, 11 Feb 2003, Randall Stewart wrote: > > > > > >>Michael: > >> > >>This seems like a valid method.. it gets around Brian's objection > >>(which was a good point) and yet still provides the application with > >>a hint about what the assigned sequence order was on the unordered > >>messages... > >> > >>R > >> > >>Michael Tuexen wrote: > >> > >>>Caitlin, > >>> > >>>thank you very much for the clarification. > >>> > >>>I do not like the idea to pass the SSN transparently from > the ULP to the > >>>ULP. > >>>But having two sequence spaces is OK for me. This means > that the SSN at the > >>>sending side is controlled by the SCTP and given to the ULP at the > >>>receiving side. > >>> > >>>This would be a clean solution. So I voting for have two > separate number > >>>spaces > >>>for user data. Since the one for ordered delivery exists > already in RFC > >>>2960, this > >>>only means that a new one is introduced for the unordered > delivery user > >>>data. > >>> > >>>Best regards > >>>Michael > >>> > >>>On Tuesday, Feb 11, 2003, at 17:37 Europe/Berlin, Caitlin > Bestler wrote: > >>> > >>> > >>>>On 2/11/03, Tuexen Michael wrote: > >>>> > >>>> > >>>>>Dear all, > >>>>> > >>>>>does this mean that you want two sequence spaces per > >>>>>stream: one for the 'ordered' user data and one for the > >>>>>unordered user data? > >>>>> > >>>> > >>>>The RDDP/SCTP adaptation only uses unordered delivery, so > >>>>that question did not really arise. > >>>> > >>>>But if you were to generalize the problem, I believe the > >>>>answer would be yes. > >>>> > >>>>The SSN for ordered delivery would be unchanged. The > >>>>addition would be providing "advisory ordering" for > >>>>unordered delivery. The general characteristic is that > >>>>the receiving ULP wants the data in whatever order it > >>>>arrives, but wants to know what the original order was. > >>>> > >>>>In addition to RDDP, RTP over UDP is another example of > >>>>an application that wants to be aware of the original > >>>>ordering, even while accepting the data out-of-order. > >>>> > >>>>Caitlin Bestler > >>>>http://asomi.com/CaitlinBestler/ > >>>>_______________________________________________ > >>>>tsvwg mailing list > >>>>tsvwg@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/tsvwg > >>>> > >>> > >>>_______________________________________________ > >>>tsvwg mailing list > >>>tsvwg@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/tsvwg > >>> > >>> > >> > >> > >>-- > >>Randall R. Stewart > >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) > >> > >>_______________________________________________ > >>tsvwg mailing list > >>tsvwg@ietf.org > >>https://www1.ietf.org/mailman/listinfo/tsvwg > > > > > > > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Feb 15 10:11:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03170 for ; Sat, 15 Feb 2003 09:21:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1FEPNe27160 for tsvwg-archive@odin.ietf.org; Sat, 15 Feb 2003 09:25:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1FEOsp26994; Sat, 15 Feb 2003 09:24:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CJKEp14478 for ; Wed, 12 Feb 2003 14:20:14 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12382 for ; Wed, 12 Feb 2003 14:10:12 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1CJDESQ019672; Wed, 12 Feb 2003 11:13:14 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADF85152; Wed, 12 Feb 2003 11:13:12 -0800 (PST) Message-ID: <3E4A9CC8.9080100@cisco.com> Date: Wed, 12 Feb 2003 13:13:12 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Lehmann CC: Randall Stewart , TSV WG list , SCTP Implementors Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: <3E48EF01.9080502@stewart.chicago.il.us> <3E4A6C0E.5080104@ulticom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit David Lehmann wrote: > Randall Stewart wrote: > >> Currently the sender of a Unordered data chunk sets the >> SSN to 0 and the receiver of the Unordered data chunk ignores >> the contents of the field.. > > > When did this change? RFC 2960, section 6.6 states, > The 'Stream Sequence Number' field in a DATA chunk with U flag set to > 1 has no significance. The sender can fill it with arbitrary value, > but the receiver MUST ignore the field. > > Where is it stated that the SSN should be set to zero for unordered data > chunks? > Your correct.. it is an arbitrary value.. R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Feb 15 13:46:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06185 for ; Sat, 15 Feb 2003 13:46:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1FIobZ07841 for tsvwg-archive@odin.ietf.org; Sat, 15 Feb 2003 13:50:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1FIoJp07819; Sat, 15 Feb 2003 13:50:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1FInIp07786 for ; Sat, 15 Feb 2003 13:49:18 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06171 for ; Sat, 15 Feb 2003 13:44:31 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:YUJMyE62d6qZtR4yM9d+lKK2qdYFqozK@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1FIhsD27351; Sat, 15 Feb 2003 11:43:54 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1FIhrw18199; Sat, 15 Feb 2003 11:43:53 -0700 Date: Sat, 15 Feb 2003 11:43:53 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: David Lehmann , Randall Stewart , TSV WG list , SCTP Implementors Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030215114353.B17855@openss7.org> Reply-To: bidulock@openss7.org References: <3E48EF01.9080502@stewart.chicago.il.us> <3E4A6C0E.5080104@ulticom.com> <3E4A9CC8.9080100@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E4A9CC8.9080100@cisco.com>; from rrs@cisco.com on Wed, Feb 12, 2003 at 01:13:12PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Randall, Meaning most of the argument for backwards compatability vaporizes... INIT negotiation will be required for an unordered data chunk approach, but would not be necessary for an ordered data chunk approach. --brian On Wed, 12 Feb 2003, Randall Stewart (cisco) wrote: > David Lehmann wrote: > > > Randall Stewart wrote: > > > >> Currently the sender of a Unordered data chunk sets the > >> SSN to 0 and the receiver of the Unordered data chunk ignores > >> the contents of the field.. > > > > > > When did this change? RFC 2960, section 6.6 states, > > The 'Stream Sequence Number' field in a DATA chunk with U flag set to > > 1 has no significance. The sender can fill it with arbitrary value, > > but the receiver MUST ignore the field. > > > > Where is it stated that the SSN should be set to zero for unordered data > > chunks? > > > Your correct.. it is an arbitrary value.. > > R > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Feb 15 15:27:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07073 for ; Sat, 15 Feb 2003 15:27:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1FKW4B12324 for tsvwg-archive@odin.ietf.org; Sat, 15 Feb 2003 15:32:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1FKVbp12306; Sat, 15 Feb 2003 15:31:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1FKUTp12238 for ; Sat, 15 Feb 2003 15:30:29 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07032 for ; Sat, 15 Feb 2003 15:25:42 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1FKP52k006539; Sat, 15 Feb 2003 14:25:06 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E4EA221.8050809@stewart.chicago.il.us> Date: Sat, 15 Feb 2003 14:25:05 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: "Randall Stewart (cisco)" , David Lehmann , TSV WG list , SCTP Implementors Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: <3E48EF01.9080502@stewart.chicago.il.us> <3E4A6C0E.5080104@ulticom.com> <3E4A9CC8.9080100@cisco.com> <20030215114353.B17855@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: > Randall, > > Meaning most of the argument for backwards compatability vaporizes... > And what pre-tell do you mean by "backwards compatability vaporizes"? RFC2960 basically says that an arbitrary value is put in the SSN. It seems to me that if my implementation wants to number each SSN that is un-ordered .. then that qualify's as an arbitrary value. If we call that a feature it does not break any backward compatability... and the only way it would effect the peer is if it was looking inside the SSN (which it is prohibited from doing). Now the only issue would be if the peer bothered to deliver the "arbitrary value" to the ULP. > INIT negotiation will be required for an unordered data chunk approach, > but would not be necessary for an ordered data chunk approach. > I don't see why negotiation is needed. It would be nice if I notified my peer that I could do something, aka, I number my unordered data, but telling you I am going to do something with a "arbitrary value" is far from negotiation... The only real issue would be if the peer delivered the SSN up to the ULP (as I said above). Which I would bet most implementations do.. since it is more work to NOT deliver the SSN and special case the code. I know I deliver what ever junk is in the SSN... it was easier... R > --brian > > On Wed, 12 Feb 2003, Randall Stewart (cisco) wrote: > > >>David Lehmann wrote: >> >> >>>Randall Stewart wrote: >>> >>> >>>>Currently the sender of a Unordered data chunk sets the >>>>SSN to 0 and the receiver of the Unordered data chunk ignores >>>>the contents of the field.. >>> >>> >>>When did this change? RFC 2960, section 6.6 states, >>> The 'Stream Sequence Number' field in a DATA chunk with U flag set to >>> 1 has no significance. The sender can fill it with arbitrary value, >>> but the receiver MUST ignore the field. >>> >>>Where is it stated that the SSN should be set to zero for unordered data >>>chunks? >>> >> >>Your correct.. it is an arbitrary value.. >> >>R >> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> >>_______________________________________________ >>tsvwg mailing list >>tsvwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Feb 15 19:14:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09013 for ; Sat, 15 Feb 2003 19:14:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1G0IPJ23142 for tsvwg-archive@odin.ietf.org; Sat, 15 Feb 2003 19:18:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1G0I1p23133; Sat, 15 Feb 2003 19:18:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1G0Gtp23107 for ; Sat, 15 Feb 2003 19:16:55 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09008 for ; Sat, 15 Feb 2003 19:12:01 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:9pJIkRw3mXLqmQ22dhN1m2bLt4SBpzqH@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1G0AYD31496; Sat, 15 Feb 2003 17:10:34 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1G0AXN24764; Sat, 15 Feb 2003 17:10:33 -0700 Date: Sat, 15 Feb 2003 17:10:33 -0700 From: "Brian F. G. Bidulock" To: Randall Stewart Cc: "Randall Stewart (cisco)" , David Lehmann , TSV WG list , SCTP Implementors Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030215171033.A24180@openss7.org> Reply-To: bidulock@openss7.org References: <3E48EF01.9080502@stewart.chicago.il.us> <3E4A6C0E.5080104@ulticom.com> <3E4A9CC8.9080100@cisco.com> <20030215114353.B17855@openss7.org> <3E4EA221.8050809@stewart.chicago.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E4EA221.8050809@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Sat, Feb 15, 2003 at 02:25:05PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Randall, On Sat, 15 Feb 2003, Randall Stewart wrote: > Brian F. G. Bidulock wrote: > > Randall, > > > > Meaning most of the argument for backwards compatability vaporizes... > > > > And what pre-tell do you mean by "backwards compatability vaporizes"? Pray-tell? > > RFC2960 basically says that an arbitrary value is put in the SSN. It > seems to me that if my implementation wants to number each SSN that is > un-ordered .. then that qualify's as an arbitrary value. If we call > that a feature it does not break any backward compatability... and the > only way it would effect the peer is if it was looking inside the > SSN (which it is prohibited from doing). Now the only issue would > be if the peer bothered to deliver the "arbitrary value" to the > ULP. The receiver cannot detect a modified SCTP by observing non-zero values in the SSN of unordered chunks. > > > INIT negotiation will be required for an unordered data chunk approach, > > but would not be necessary for an ordered data chunk approach. > > > > I don't see why negotiation is needed. It would be nice if I notified my > peer that I could do something, aka, I number my unordered data, but > telling you I am going to do something with a "arbitrary value" is > far from negotiation... The negotiation is: A tells B that it supports it and B tells A that it supports it. Otherwise, the modification is unsupported for ths association. A telling B and just numbering its SSNs acheives nothing. > > The only real issue would be if the peer delivered the SSN up to the > ULP (as I said above). Which I would bet most implementations > do.. Because SSN is monotonitcally increasing from zero on ordered data and the data is reliably delivered, there is no need to deliver SSN even of ordered data. For unordered data it is arbitrary and does not need to be delivered either. Nevertheless, if RDDP needs SSN and runs as a ULP, it would have to place this requirement on the SCTP ULP interface, regardless of whether it is order of arrival deliverery of ordered data chunks or delivery of unordered data chunks with modified SSNs. > since it is more work to NOT deliver the SSN and special > case the code. I know I deliver what ever junk is in the > SSN... it was easier... It is not more work not to deliver the SSN, you are making a presumpltion based on your implementation. In our implementation it must be requested and requires more work on each delivery (delivering the SSN when data will do) and is only applicable to ordered data. This is because SSN is an internal number for use by SCTP as defined in the RFC and has no use to applications. If unordered data is used by RDDP to perform its own reordering, RDDP will be unable to send unordered data using SCTP in the same fashion as today. (Some implementations expedite unordered data ahead of ordered data for such applications as SIGTRAN or other POC applications) If ordered data (with order of arrival delivery) is used for RDDP, RDDP will still be able to send unordered data which is expedited around ordered data for SIGTRAN/POC applications. Is there some reason to keep these applications from being able to use DDP effectively? I really think that it would be more useful to put RDDP "inside" SCTP rather than "above" SCTP. If RDDP information is placed at the beginning of ordered data chunks, SCTP could perform direct data placement internally on data sent from peers supporting the procedure and perform normal ordered delivery on those that do not. Modified SCTP receivers would perform DDP and strip the DDP header from the data. Unmodified SCTP receivers receiving DDP data chunks would ignore and deliver the DDP header prefixed to the data. Then if it can also support order of arrival delivery of ordered data, it can use an RDDP as a layer above SCTP to do placement based on the header in the data. Such an arrangement would still supported expedited delivery of out of order data. --brian > > R > > > --brian > > > > On Wed, 12 Feb 2003, Randall Stewart (cisco) wrote: > > > > > >>David Lehmann wrote: > >> > >> > >>>Randall Stewart wrote: > >>> > >>> > >>>>Currently the sender of a Unordered data chunk sets the > >>>>SSN to 0 and the receiver of the Unordered data chunk ignores > >>>>the contents of the field.. > >>> > >>> > >>>When did this change? RFC 2960, section 6.6 states, > >>> The 'Stream Sequence Number' field in a DATA chunk with U flag set to > >>> 1 has no significance. The sender can fill it with arbitrary value, > >>> but the receiver MUST ignore the field. > >>> > >>>Where is it stated that the SSN should be set to zero for unordered data > >>>chunks? > >>> > >> > >>Your correct.. it is an arbitrary value.. > >> > >>R > >> > >>-- > >>Randall R. Stewart > >>ITD > >>Cisco Systems Inc. > >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > >> > >> > >>_______________________________________________ > >>tsvwg mailing list > >>tsvwg@ietf.org > >>https://www1.ietf.org/mailman/listinfo/tsvwg > > > > > > > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sun Feb 16 17:31:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00447 for ; Sun, 16 Feb 2003 17:31:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1GMZwN31804 for tsvwg-archive@odin.ietf.org; Sun, 16 Feb 2003 17:35:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1GMZSp31784; Sun, 16 Feb 2003 17:35:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1G1j8p26899 for ; Sat, 15 Feb 2003 20:45:08 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09710 for ; Sat, 15 Feb 2003 20:40:14 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1G1hPsv024748; Sat, 15 Feb 2003 17:43:25 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADL25459; Sat, 15 Feb 2003 17:43:37 -0800 (PST) Message-ID: <3E4EECC8.70007@cisco.com> Date: Sat, 15 Feb 2003 19:43:36 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Randall Stewart , David Lehmann , TSV WG list , SCTP Implementors Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: <3E48EF01.9080502@stewart.chicago.il.us> <3E4A6C0E.5080104@ulticom.com> <3E4A9CC8.9080100@cisco.com> <20030215114353.B17855@openss7.org> <3E4EA221.8050809@stewart.chicago.il.us> <20030215171033.A24180@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: > > >The receiver cannot detect a modified SCTP by observing non-zero values >in the SSN of unordered chunks. > > I don't see this to be a problem. If the receiver needs this service it won't be running on that implementaition very long :> And I would think we could add one of the HAVE_SCTP_UNORDERED_SEQ flags to the socketapi draft... (HAVE_SCTP and some others will be showing up in the next version). > > >>>INIT negotiation will be required for an unordered data chunk approach, >>>but would not be necessary for an ordered data chunk approach. >>> >>> >>> >>I don't see why negotiation is needed. It would be nice if I notified my >>peer that I could do something, aka, I number my unordered data, but >>telling you I am going to do something with a "arbitrary value" is >>far from negotiation... >> >> > >The negotiation is: A tells B that it supports it and B tells A that it >supports it. Otherwise, the modification is unsupported for ths >association. > > I don't think this is negotiation.. my interpretation of negotiation is something more akin to what DCCP does... or PPP... >A telling B and just numbering its SSNs acheives nothing. > > > Depending on B's implementation yes.. but a lot of things depend on implementations... >>The only real issue would be if the peer delivered the SSN up to the >>ULP (as I said above). Which I would bet most implementations >>do.. >> >> > >Because SSN is monotonitcally increasing from zero on ordered data and >the data is reliably delivered, there is no need to deliver SSN even of >ordered data. For unordered data it is arbitrary and does not need to >be delivered either. > >Nevertheless, if RDDP needs SSN and runs as a ULP, it would have to >place this requirement on the SCTP ULP interface, regardless of whether >it is order of arrival deliverery of ordered data chunks or delivery of >unordered data chunks with modified SSNs. > > That sounds like requirements for the adaption layer draft... > > >>since it is more work to NOT deliver the SSN and special >>case the code. I know I deliver what ever junk is in the >>SSN... it was easier... >> >> > >It is not more work not to deliver the SSN, you are making a >presumpltion based on your implementation. In our implementation it >must be requested and requires more work on each delivery (delivering >the SSN when data will do) and is only applicable to ordered data. This >is because SSN is an internal number for use by SCTP as defined in the >RFC and has no use to applications. > > But it is in the socket api sinfo structure.. and this (for those that meet a socket api) will show up with the stream no.. and all the other fluf.. Of course not everyone supports a socket api.. and thats fine.. those that do would have the SSN as well as the SN. >If unordered data is used by RDDP to perform its own reordering, RDDP >will be unable to send unordered data using SCTP in the same fashion as >today. (Some implementations expedite unordered data ahead of ordered >data for such applications as SIGTRAN or other POC applications) > > But that is NOT specified in the RFC (expidited data). It mentions it yes, but this again would depend on the implementation... One would need the equivalant of a HAVE_UNORDERED_EXPIDITE in ones flags to recognize your implementation did this... Sigtran MAY have made such a requirments in some of its adaption layers.. But this is not standard in SCTP.. I see no reason that RDDP could not require it... And I don't see that your statement "RDDP will be unable to send unordered data" is true. Currently it is a "undefined value" and it has no meaning per requirment EXPIDITED as you elude to or otherwise. If RDDP sent unordered data with sequences this is COMPLETELY within valid scope of RFC2960. It is unknown if the receiver will ever be able to see what was in that field.. but it IS conformant to RFC2960 if a RDDP-SCTP implementation numbered each of its unordered data in a stream... nothing wrong with that.. If you think so, please direct me to the MUST (or SHOULD for that matter) in 2960 that tells me I can't sequence my outgoing unordered data.... >If ordered data (with order of arrival delivery) is used for RDDP, RDDP > What is "ordered data (with order of arrival delivery"? This does NOT exist in 2960. You either get unordered, or SCTP must hold the data in stream and re-sequence.. anything else is NOT in conformance with 2960.. >will still be able to send unordered data which is expedited around >ordered data for SIGTRAN/POC applications. Is there some reason to keep >these applications from being able to use DDP effectively? > > There is NO "expedited" data requirement in 2960. You may have implemented such a thing.. but this is left open to the implementation in 2960, so you can NOT depend on it... just like you can't depend on a receiver passing along the SSN on a un-ordered message. >I really think that it would be more useful to put RDDP "inside" SCTP >rather than "above" SCTP. If RDDP information is placed at the >beginning of ordered data chunks, SCTP could perform direct data >placement internally on data sent from peers supporting the procedure >and perform normal ordered delivery on those that do not. Modified SCTP >receivers would perform DDP and strip the DDP header from the data. >Unmodified SCTP receivers receiving DDP data chunks would ignore and >deliver the DDP header prefixed to the data. Then if it can also >support order of arrival delivery of ordered data, it can use an RDDP as > Please show me where this new feature is you mention in 2960.. I don't see it anywhere... R >a layer above SCTP to do placement based on the header in the data. >Such an arrangement would still supported expedited delivery of out of >order data. > >--brian > > > >>R >> >> >> >>>--brian >>> >>>On Wed, 12 Feb 2003, Randall Stewart (cisco) wrote: >>> >>> >>> >>> >>>>David Lehmann wrote: >>>> >>>> >>>> >>>> >>>>>Randall Stewart wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>Currently the sender of a Unordered data chunk sets the >>>>>>SSN to 0 and the receiver of the Unordered data chunk ignores >>>>>>the contents of the field.. >>>>>> >>>>>> >>>>>When did this change? RFC 2960, section 6.6 states, >>>>> The 'Stream Sequence Number' field in a DATA chunk with U flag set to >>>>> 1 has no significance. The sender can fill it with arbitrary value, >>>>> but the receiver MUST ignore the field. >>>>> >>>>>Where is it stated that the SSN should be set to zero for unordered data >>>>>chunks? >>>>> >>>>> >>>>> >>>>Your correct.. it is an arbitrary value.. >>>> >>>>R >>>> >>>>-- >>>>Randall R. Stewart >>>>ITD >>>>Cisco Systems Inc. >>>>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >>>> >>>> >>>>_______________________________________________ >>>>tsvwg mailing list >>>>tsvwg@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/tsvwg >>>> >>>> >>> >>> >>-- >>Randall R. Stewart >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) >> >> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sun Feb 16 17:39:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00546 for ; Sun, 16 Feb 2003 17:39:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1GMiTU32762 for tsvwg-archive@odin.ietf.org; Sun, 16 Feb 2003 17:44:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1GMi5p32751; Sun, 16 Feb 2003 17:44:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1GMhvp32735 for ; Sun, 16 Feb 2003 17:43:57 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00543 for ; Sun, 16 Feb 2003 17:38:36 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:Wp3aZnjLl66BEbnmn6BWrkScb+TuPdkt@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1GMacD20960; Sun, 16 Feb 2003 15:36:39 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1GMac022499; Sun, 16 Feb 2003 15:36:38 -0700 Date: Sun, 16 Feb 2003 15:36:38 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: Randall Stewart , David Lehmann , TSV WG list , SCTP Implementors Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030216153638.A22008@openss7.org> Reply-To: bidulock@openss7.org References: <3E48EF01.9080502@stewart.chicago.il.us> <3E4A6C0E.5080104@ulticom.com> <3E4A9CC8.9080100@cisco.com> <20030215114353.B17855@openss7.org> <3E4EA221.8050809@stewart.chicago.il.us> <20030215171033.A24180@openss7.org> <3E4EECC8.70007@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E4EECC8.70007@cisco.com>; from rrs@cisco.com on Sat, Feb 15, 2003 at 07:43:36PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Randall, On Sat, 15 Feb 2003, Randall Stewart (cisco) wrote: > Brian F. G. Bidulock wrote: > > > > > > >The receiver cannot detect a modified SCTP by observing non-zero values > >in the SSN of unordered chunks. > > > > > I don't see this to be a problem. If the receiver needs this service > it won't be running on that implementaition very long :> > And I would think we could add one of the > > HAVE_SCTP_UNORDERED_SEQ > > flags to the socketapi draft... (HAVE_SCTP and some others > will be showing up in the next version). I never gave the socketapi draft much notice. It largely deviates from POSIX/OpenGroup socket semantics and is, afterall, only a draft of an INFORMATIONAL, so feel free to say whatever you like in the draft. Noone is required to follow it. > > > > > > >>>INIT negotiation will be required for an unordered data chunk approach, > >>>but would not be necessary for an ordered data chunk approach. > >>> > >>> > >>> > >>I don't see why negotiation is needed. It would be nice if I notified my > >>peer that I could do something, aka, I number my unordered data, but > >>telling you I am going to do something with a "arbitrary value" is > >>far from negotiation... > >> > >> > > > >The negotiation is: A tells B that it supports it and B tells A that it > >supports it. Otherwise, the modification is unsupported for ths > >association. > > > > > I don't think this is negotiation.. my interpretation of negotiation is > something more akin to what DCCP does... or PPP... > > > >A telling B and just numbering its SSNs acheives nothing. > > > > > > > > Depending on B's implementation yes.. but a lot of things depend on > implementations... > > >>The only real issue would be if the peer delivered the SSN up to the > >>ULP (as I said above). Which I would bet most implementations > >>do.. > >> > >> > > > >Because SSN is monotonitcally increasing from zero on ordered data and > >the data is reliably delivered, there is no need to deliver SSN even of > >ordered data. For unordered data it is arbitrary and does not need to > >be delivered either. > > > >Nevertheless, if RDDP needs SSN and runs as a ULP, it would have to > >place this requirement on the SCTP ULP interface, regardless of whether > >it is order of arrival deliverery of ordered data chunks or delivery of > >unordered data chunks with modified SSNs. > > > > > That sounds like requirements for the adaption layer draft... Yes, if it needs something it is going to have to say so. > > > > > > >>since it is more work to NOT deliver the SSN and special > >>case the code. I know I deliver what ever junk is in the > >>SSN... it was easier... > >> > >> > > > >It is not more work not to deliver the SSN, you are making a > >presumpltion based on your implementation. In our implementation it > >must be requested and requires more work on each delivery (delivering > >the SSN when data will do) and is only applicable to ordered data. This > >is because SSN is an internal number for use by SCTP as defined in the > >RFC and has no use to applications. > > > > > But it is in the socket api sinfo structure.. and this (for those that > meet a socket api) will show up with the stream no.. and all the > other fluf.. Of course not everyone supports a socket api.. and thats > fine.. those that do would have the SSN as well as the SN. Meet the socket api? Noone is required to follow the socketapi draft. It is not on standards track. I disagree with most (if not all) of the draft on the basis that it violates POSIX/OpenGroup semantics for SOCK_SEQPACKET, but have needed to argue it because the draft is only a draft of an INFORMATIONAL. If you expect implementations to follow the socketapi draft you will have to make it more than INFORMATIONAL, and you will have to advance it to RFC status. > > >If unordered data is used by RDDP to perform its own reordering, RDDP > >will be unable to send unordered data using SCTP in the same fashion as > >today. (Some implementations expedite unordered data ahead of ordered > >data for such applications as SIGTRAN or other POC applications) > > > > > But that is NOT specified in the RFC (expidited data). It mentions it yes, > but this again would depend on the implementation... The RFC does not prohibit it. Those that expedite data (as mentioned, and thus implicitly permitted) will not be able to expedite and use RDDP as well. > One would need the > equivalant of a HAVE_UNORDERED_EXPIDITE in ones flags to > recognize your implementation did this... You are talking that INFORMATIONAL draft again... > Sigtran MAY have made > such a requirments in some of its adaption layers.. But this is not > standard in SCTP.. I see no reason that RDDP could not require > it... Not standard in SCTP? It is not prohibited, so a STANDARD SCTP is permitted to do so. SCTP will permit it, but an unordered approach to RDDP will not. An unorderd approach would. It is simply another failing of the unordered approach. > > And I don't see that your statement > > "RDDP will be unable to send unordered data" > > is true. Currently it is a "undefined value" and it has no > meaning per requirment EXPIDITED as you elude to or otherwise. > If RDDP sent unordered data with sequences this is COMPLETELY > within valid scope of RFC2960. It is unknown if the receiver > will ever be able to see what was in that field.. but it > IS conformant to RFC2960 if a RDDP-SCTP implementation numbered > each of its unordered data in a stream... nothing wrong with > that.. If you think so, please direct me to the MUST (or SHOULD > for that matter) in 2960 that tells me I can't sequence my > outgoing unordered data.... It just simple: as RDDP is going to be ordering unordered data itself, it cannot send unordered data. > > >If ordered data (with order of arrival delivery) is used for RDDP, RDDP > > > What is "ordered data (with order of arrival delivery"? This does NOT exist > in 2960. You either get unordered, or SCTP must hold the data in > stream and re-sequence.. anything else is NOT in conformance with > 2960.. Ok, now you start with the same argument TCP brought up with RDDP. The answer is simple, have RDDP reorder the data "inside" SCTP. > > >will still be able to send unordered data which is expedited around > >ordered data for SIGTRAN/POC applications. Is there some reason to keep > >these applications from being able to use DDP effectively? > > > > > There is NO "expedited" data requirement in 2960. You may have implemented > such a thing.. but this is left open to the implementation in 2960, so > you can > NOT depend on it... just like you can't depend on a receiver passing along > the SSN on a un-ordered message. So what? Implementations that actually do so (and are permitted to do so by RFC 2960) will not be able to use RDDP. If you simply take the ordered data approach rather than try to impose sequence on unordered data, then it is not a problem for implementations that chose to permit expedited data. > > >I really think that it would be more useful to put RDDP "inside" SCTP > >rather than "above" SCTP. If RDDP information is placed at the > >beginning of ordered data chunks, SCTP could perform direct data > >placement internally on data sent from peers supporting the procedure > >and perform normal ordered delivery on those that do not. Modified SCTP > >receivers would perform DDP and strip the DDP header from the data. > >Unmodified SCTP receivers receiving DDP data chunks would ignore and > >deliver the DDP header prefixed to the data. Then if it can also > >support order of arrival delivery of ordered data, it can use an RDDP as > > > Please show me where this new feature is you mention in 2960.. I don't see > it anywhere... That was a proposal, you goof. ;) --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sun Feb 16 20:22:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01909 for ; Sun, 16 Feb 2003 20:22:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1H1R3o07474 for tsvwg-archive@odin.ietf.org; Sun, 16 Feb 2003 20:27:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H1Psp07445; Sun, 16 Feb 2003 20:25:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H1O7p07390 for ; Sun, 16 Feb 2003 20:24:07 -0500 Received: from thebe.your-site.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01897 for ; Sun, 16 Feb 2003 20:18:43 -0500 (EST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 2A9A3244ED3; Sun, 16 Feb 2003 20:22:31 -0500 (EST) Date: Sun, 16 Feb 2003 19:23:53 -0600 From: Caitlin Bestler Subject: Re: [Tsvwg] A question of Un-Ordered SCTP To: bidulock@openss7.org, tsvwg@ietf.org X-Priority: 3 In-Reply-To: <20030216153638.A22008@openss7.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 2/16/03, Brian F. G. Bidulock wrote: >> But that is NOT specified in the RFC (expidited data). >> It mentions it yes, but this again would depend on the >> implementation... > >The RFC does not prohibit it. Those that expedite data >(as mentioned, and thus implicitly permitted) will not be >able to expedite and use RDDP as well. The RDDP/SCTP adapation draft specifies that RDDP semantics apply to an entire association. Non-RDDP streams must be done in another association. RDDP has its own requirements for delivery, which are quite specific. A full recounting RDMA theory would be severely off-topic, but given the existing seperation of tagged, untaggee and RDMA read messages there is no real opportunity for expedited delivery within a DDP stream. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sun Feb 16 20:28:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01954 for ; Sun, 16 Feb 2003 20:28:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1H1XG407679 for tsvwg-archive@odin.ietf.org; Sun, 16 Feb 2003 20:33:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H1W6p07652; Sun, 16 Feb 2003 20:32:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H1VKp07598 for ; Sun, 16 Feb 2003 20:31:20 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01937 for ; Sun, 16 Feb 2003 20:25:56 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:owBLk7xIxq8D4naLOVezvvi/+1oH7gux@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1H1TiD22896; Sun, 16 Feb 2003 18:29:44 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1H1Tia24816; Sun, 16 Feb 2003 18:29:44 -0700 Date: Sun, 16 Feb 2003 18:29:43 -0700 From: "Brian F. G. Bidulock" To: Caitlin Bestler Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030216182943.A24780@openss7.org> Reply-To: bidulock@openss7.org References: <20030216153638.A22008@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cait@asomi.com on Sun, Feb 16, 2003 at 07:23:53PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Caitlin, I thought that DDP was just an efficient placement algorithm. I do not think that it artificially imposes its own requirements on delivery order. If RDDP does, it shouldn't. --brian On Sun, 16 Feb 2003, Caitlin Bestler wrote: > On 2/16/03, Brian F. G. Bidulock wrote: > > >> But that is NOT specified in the RFC (expidited data). > >> It mentions it yes, but this again would depend on the > >> implementation... > > > >The RFC does not prohibit it. Those that expedite data > >(as mentioned, and thus implicitly permitted) will not be > >able to expedite and use RDDP as well. > > The RDDP/SCTP adapation draft specifies that RDDP semantics > apply to an entire association. Non-RDDP streams must be > done in another association. > > RDDP has its own requirements for delivery, which are quite > specific. A full recounting RDMA theory would be severely > off-topic, but given the existing seperation of tagged, > untaggee and RDMA read messages there is no real opportunity > for expedited delivery within a DDP stream. > > > > > > Caitlin Bestler > http://asomi.com/CaitlinBestler/ -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sun Feb 16 22:42:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03889 for ; Sun, 16 Feb 2003 22:42:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1H3l3h14846 for tsvwg-archive@odin.ietf.org; Sun, 16 Feb 2003 22:47:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H3kXp14824; Sun, 16 Feb 2003 22:46:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H3jBp14797 for ; Sun, 16 Feb 2003 22:45:11 -0500 Received: from thebe.your-site.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03874 for ; Sun, 16 Feb 2003 22:39:45 -0500 (EST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 174202451F8; Sun, 16 Feb 2003 22:43:32 -0500 (EST) Date: Sun, 16 Feb 2003 21:44:42 -0600 From: Caitlin Bestler Subject: Re: [Tsvwg] A question of Un-Ordered SCTP To: bidulock@openss7.org, tsvwg@ietf.org X-Priority: 3 In-Reply-To: <20030216182943.A24780@openss7.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 2/16/03, Brian F. G. Bidulock wrote: >Caitlin, > >I thought that DDP was just an efficient placement >algorithm. > >I do not think that it artificially imposes its own >requirements on delivery order. If RDDP does, it >shouldn't. > >--brian > We're in vehement agreement. Let me clarify what I meant by RDDP's "ordering rules": RDDP has its own rules on the order of its delivery *to the ULP*. RDDP is a user of SCTP services, it doesn't impose requirements. The point of RDDP's rule for delivery to the ULP is that they are already adequate. A ULP using RDDP has not need for expedited delivery. RDDP is free to use totally unordered delivery at the transport layer because it has its own ordering services for controlling delivery to the ULP. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sun Feb 16 23:05:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04177 for ; Sun, 16 Feb 2003 23:05:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1H4AT516555 for tsvwg-archive@odin.ietf.org; Sun, 16 Feb 2003 23:10:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H4AEp16537; Sun, 16 Feb 2003 23:10:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H49wp16456 for ; Sun, 16 Feb 2003 23:09:58 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04171 for ; Sun, 16 Feb 2003 23:04:32 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:RTEb/XqhW5xsuLFW1eAXhC3tLkBxRfKD@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1H48JD24940; Sun, 16 Feb 2003 21:08:19 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1H48IY27485; Sun, 16 Feb 2003 21:08:18 -0700 Date: Sun, 16 Feb 2003 21:08:18 -0700 From: "Brian F. G. Bidulock" To: Caitlin Bestler Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Message-ID: <20030216210818.A27125@openss7.org> Reply-To: bidulock@openss7.org References: <20030216182943.A24780@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cait@asomi.com on Sun, Feb 16, 2003 at 09:44:42PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Caitlin, On Sun, 16 Feb 2003, Caitlin Bestler wrote: > On 2/16/03, Brian F. G. Bidulock wrote: > > >Caitlin, > > > >I thought that DDP was just an efficient placement > >algorithm. > > > >I do not think that it artificially imposes its own > >requirements on delivery order. If RDDP does, it > >shouldn't. > > > >--brian > > > We're in vehement agreement. > > Let me clarify what I meant by RDDP's "ordering rules": RDDP > has its own rules on the order of its delivery *to the ULP*. > RDDP is a user of SCTP services, it doesn't impose > requirements. > > The point of RDDP's rule for delivery to the ULP is that > they are already adequate. A ULP using RDDP has not need > for expedited delivery. RDDP is free to use totally > unordered delivery at the transport layer because it has its > own ordering services for controlling delivery to the ULP. I have a ULP that needs expedited delivery (and note that RFC 2960 does support expedited delivery--unordered data is delivered ahead of ordered data in reordering queue--even if it does not support expedited transmission). An SCTP implementation provides this to my ULP. It appears RDDP cannot. Can my ULP not use RDDP? I thought RDDP was supposed to be somewhat transparent to the ULP. RDDP should preserve the ordering requirements (or lack of ordering requirements) of the sender and just perform efficient placement. Using unordered data always would make RDDP/SCTP incapable of that objective. Using ordered data and order of arrival delivery from SCTP to RDDP would make that objective attainable. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Feb 17 04:42:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18568 for ; Mon, 17 Feb 2003 04:42:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1H9lAQ13177 for tsvwg-archive@odin.ietf.org; Mon, 17 Feb 2003 04:47:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H9kfp13150; Mon, 17 Feb 2003 04:46:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H9jBp13104 for ; Mon, 17 Feb 2003 04:45:11 -0500 Received: from parmesan.cs.wisc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18539 for ; Mon, 17 Feb 2003 04:39:38 -0500 (EST) Received: (from poon@localhost) by parmesan.cs.wisc.edu (8.9.2/8.9.2) id DAA13013; Mon, 17 Feb 2003 03:27:30 -0600 (CST) Date: Mon, 17 Feb 2003 03:27:30 -0600 (CST) From: Kacheong Poon Message-Id: <200302170927.DAA13013@parmesan.cs.wisc.edu> To: cait@asomi.com, tsvwg@ietf.org Subject: Re: [Tsvwg] A question of Un-Ordered SCTP Cc: sctp-impl@external.cisco.com Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Included message from Caitlin Bestler : >---- >So, trying to work with SCTP on SCTP's terms, you have three >possible strategies: > >-- Include a SSN-equivalent in the Data Chunk. > >-- Allow out-of-order placement of ordered Data chunks. > >-- Make SCTP's SSN meaningful for unordered delivery. > >The pure ULP solution obviously has the least impact on >the SCTP layer. But it smacks of having the ULP duplicate >functionality that rightfully belongs at the transport >layer. I believe the quick consenseus is that sequenced >unordered delivery is a natural concept that has value >beyond any single ULP. I don't think that the above functionality "rightfully belongs to the transport layer (SCTP in this case)." To me, the unordered delivery mechanism as specified in RFC 2960 simply means that such data chunks can be delivered in whatever order the receiver wants. This also automatically means that the sender can send such chunks in whatever order it wants if it deems necessary. For example, an implementation can choose to place a smaller unordered data chunk ahead in the send queue before a bigger unordered data chunk. Assuming that the SSN is assigned when data chunk is sent, to make the suggested change to RFC 2960 to an implementation may mean more than what has been discussed. And it is really a protocol change, not just implementation's choice of how to generate "arbitrary numbers" to be put in the SSN field of unordered chunk as it actually places extra restrictions on how an implementation handled such chunks as described above. The SSN in SCTP is designed to be used for order of delivery by SCTP, that's why it is ignored for unordered delivery. If an ULP wants to have ordered delivery, don't use this feature of SCTP. If an ULP wants unordered delivery, but it still wants to know the sender's sending order, just place its own sequence number. Overloading the SSN in SCTP, even if it is assigned by SCTP, not by ULP, is really a bad design choice. Anyway, just my $0.02. BTW, I also cc the SCTP implementors' list. I believe people there should be aware of such things. I don't know why that list was removed from the cc list... >---- K. Poon. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Feb 17 11:27:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25178 for ; Mon, 17 Feb 2003 11:27:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1HGWIV04737 for tsvwg-archive@odin.ietf.org; Mon, 17 Feb 2003 11:32:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HGUlp04536; Mon, 17 Feb 2003 11:30:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HGRLp04330 for ; Mon, 17 Feb 2003 11:27:21 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24982 for ; Mon, 17 Feb 2003 11:21:36 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1HGJ72k009705; Mon, 17 Feb 2003 10:19:08 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E510B7B.50803@stewart.chicago.il.us> Date: Mon, 17 Feb 2003 10:19:07 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kacheong Poon CC: cait@asomi.com, tsvwg@ietf.org, sctp-impl@external.cisco.com Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: <200302170927.DAA13013@parmesan.cs.wisc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kacheong Poon wrote: > Included message from Caitlin Bestler : > > >>---- >>So, trying to work with SCTP on SCTP's terms, you have three >>possible strategies: >> >>-- Include a SSN-equivalent in the Data Chunk. >> >>-- Allow out-of-order placement of ordered Data chunks. >> >>-- Make SCTP's SSN meaningful for unordered delivery. >> >>The pure ULP solution obviously has the least impact on >>the SCTP layer. But it smacks of having the ULP duplicate >>functionality that rightfully belongs at the transport >>layer. I believe the quick consenseus is that sequenced >>unordered delivery is a natural concept that has value >>beyond any single ULP. > > > I don't think that the above functionality "rightfully > belongs to the transport layer (SCTP in this case)." To > me, the unordered delivery mechanism as specified in RFC > 2960 simply means that such data chunks can be delivered > in whatever order the receiver wants. This also > automatically means that the sender can send such chunks > in whatever order it wants if it deems necessary. For > example, an implementation can choose to place a smaller > unordered data chunk ahead in the send queue before a bigger > unordered data chunk. Assuming that the SSN is assigned > when data chunk is sent, to make the suggested change > to RFC 2960 to an implementation may mean more than what > has been discussed. And it is really a protocol change, > not just implementation's choice of how to generate > "arbitrary numbers" to be put in the SSN field of unordered > chunk as it actually places extra restrictions on how an > implementation handled such chunks as described above. > You make an excellent point.. for this very set of reasons one must not depend on being able to do priority of unordered data chunks as well. A implementation (as Brian mentioned his does) MAY prioritize un-ordered but it also MAY NOT... > The SSN in SCTP is designed to be used for order of > delivery by SCTP, that's why it is ignored for unordered > delivery. If an ULP wants to have ordered delivery, don't use > this feature of SCTP. If an ULP wants unordered delivery, but > it still wants to know the sender's sending order, just place > its own sequence number. Overloading the SSN in SCTP, even > if it is assigned by SCTP, not by ULP, is really a bad design > choice. > This brings up another point that I had not contemplated... if an implementation is assigning SSN's (as well as TSN's) at the last minute, the SSN assigned does NOT necessarily align with presentation order to SCTP. So by this reasoning it is really better if the ULP puts a SSN in its data as to how it presented the data to the SCTP stack... thus assuring the symantics it wants. I think you have convinced me it is better to let the ULP deal with it.. Oh, I do still think the CAPABILITIES indication may be a good thing though... R > Anyway, just my $0.02. BTW, I also cc the SCTP > implementors' list. I believe people there should > be aware of such things. I don't know why that list > was removed from the cc list... > > >>---- > > > > K. Poon. > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Feb 17 12:25:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26564 for ; Mon, 17 Feb 2003 12:25:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1HHUsM08846 for tsvwg-archive@odin.ietf.org; Mon, 17 Feb 2003 12:30:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HHUYp08835; Mon, 17 Feb 2003 12:30:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HHTfp08770 for ; Mon, 17 Feb 2003 12:29:41 -0500 Received: from thebe.your-site.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26548 for ; Mon, 17 Feb 2003 12:23:59 -0500 (EST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 4E4F3245233; Mon, 17 Feb 2003 12:27:45 -0500 (EST) Date: Mon, 17 Feb 2003 11:28:57 -0600 From: Caitlin Bestler Subject: Re: [Tsvwg] A question of Un-Ordered SCTP To: Randall Stewart Cc: Kacheong Poon , tsvwg@ietf.org, sctp-impl@external.cisco.com X-Priority: 3 In-Reply-To: <3E510B7B.50803@stewart.chicago.il.us> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 2/17/03, Randall Stewart wrote: > >This brings up another point that I had not >contemplated... if an implementation is assigning SSN's >(as well as TSN's) at the last minute, the SSN assigned >does NOT necessarily align with presentation order to >SCTP. So by this reasoning it is really better if the ULP >puts a SSN in its data as to how it presented the data to >the SCTP stack... thus assuring the symantics it wants. I >think you have convinced me it is better to let the ULP >deal with it.. > The essential characteristic of ULPs that would have used the sequenced unordered capability is that the order of presentation from the ULP has signifigance, but that data delivery should not be delayed at the receiving end to restore that original order, rather the information should be provided to the ULP to allow it to do so. Generally these applications would want their presentation order within a stream to match the actual transmit order. For streaming media applications this is crucial, it would be next to impossible for a sender transport re-ordering to be beneficial to the application. RDDP can be quite tolerant of order inversions between *some* Data Chunks (tagged ones between the same set of untagged messages), but complex "half-ordering" is pretty clearly ULP specific and not something that SCTP should be expected to support. So that leaves the same three options for comparison: 1) keep the sequence unordered capability, but clarify that in-stream order, as presented by the sending ULP, must be preserved by the sending SCTP layer. Any restoration of that order, however, is left to the receiving ULP. This contrasts with ordered delivery, where the receiving SCTP layer restores the order. The biggest hit here is that it is now clear that this method will not work for RDDP over unmodified SCTP stacks. If neither the TSN or SSN can be relied upon to reflect the sending RDDPs ordering critical RDDP ordering rules cannot be properly enforced. 2) ULP labeling of DDP stream ordering combined with unordered delivery. The receiving DDP layer is solely responsible for restoration of order. This actually isn't that bad for RDDP. For streaming media applications, particularly over partially reliable SCTP, it has the negative effect of failing to constrain the sending SCTP layer to send the data chunks in the order presented. 3) Unordered delivery of ordered data streams. A purely local interface option allows the receiving ULP to specify whether it wants SCTP to hold data chunks until they can be delivered in order, or to deliver them early and merely indicate the order they should have been in. This approach has some very nice features, but has very serious performance impilcations if RDDP is implemented on top of an unmodified SCTP receiver. If several implementers believe that the third option is a relatively minor fix, then I believe that it would be an adequate solution for both RDDP and streaming media ULPs. Otherwise the second option looks like the best approach. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 18 07:52:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26935 for ; Tue, 18 Feb 2003 07:52:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ICvoK24125 for tsvwg-archive@odin.ietf.org; Tue, 18 Feb 2003 07:57:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ICvHp24101; Tue, 18 Feb 2003 07:57:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ICtOp24043 for ; Tue, 18 Feb 2003 07:55:24 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26911 for ; Tue, 18 Feb 2003 07:49:17 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1ICr4KV023672 for ; Tue, 18 Feb 2003 13:53:04 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVGXR1X; Tue, 18 Feb 2003 13:53:03 +0100 Received: from res0010384da36.eed.ericsson.se (dhcp5-197 [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id NAA04494 for ; Tue, 18 Feb 2003 13:53:02 +0100 (MET) Message-Id: <5.1.0.14.0.20030218134100.02abf3c8@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Feb 2003 13:52:52 +0100 To: tsvwg@ietf.org From: Reiner Ludwig Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based schemes) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , during the current IESG review of , the following comment was made by an IESG member: > > **** The Eifel Detection Algorithm for TCP (Experimental) > > > >I have read this briefly. To me this seems ok, but I am somewhat >worried that this would open up a new type of ACK DOS as you could >potentially guess timestamps and attack the algorithm. The 2' and 5' >suggestions work around this, so I am (thinking out loud) if that >should not be the default. OTH it's easier to take out the session by >simply DoSing either the sender or the receiver... How do people think about this? This issue is probably not only relevant to Eifel Detection & Response, but also to F-RTO, and DSACK-based alternatives. Below is what I had responded ... ///Reiner ---------------------------------------------- I would argue against the view of the reviewer: * This is only a detection algorithm that does not alter TCP sender nor receiver state. Thus, no danger here. * When used together with a response algorithm, e.g., draft-ietf-tsvwg-tcp-eifel-response-02.txt, this is a different story. I don't know what the reviewer means with "take out the session". But clearly, by manipulating ACKs at the TCP receiver or by a flow-state-aware box in the middle, congestion control at the TCP sender could be pretty much disabled. So, one could argue along the lines of the reviewer when combining the Eifel Detection algorithm with a response algorithm that alters TCP state. On the other hand, we know (see Savage paper in ACM CCR, Oct. 99) that even a "standard conformant" TCP sender's congestion control is easily disabled. So, why be extra strict here? This is actually a relevant issue for the mailing list. Since, if we would follow the reviewer's suggestion, we raise the bar quite high also for the alternative schemes like F-RTO and DSACK-based schemes. Those should then also be comparably safe against misbehaving TCP receivers, I think. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 18 12:41:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02777 for ; Tue, 18 Feb 2003 12:41:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1IHkjl12310 for tsvwg-archive@odin.ietf.org; Tue, 18 Feb 2003 12:46:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IHghp12104; Tue, 18 Feb 2003 12:42:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IHbmp11809 for ; Tue, 18 Feb 2003 12:37:48 -0500 Received: from seraph3.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02555 for ; Tue, 18 Feb 2003 12:31:36 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id E87816BA44 for ; Tue, 18 Feb 2003 12:35:19 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id h1IHZJsW014798; Tue, 18 Feb 2003 12:35:19 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id MAA65851; Tue, 18 Feb 2003 12:35:19 -0500 (EST) Message-Id: <200302181735.MAA65851@guns.lerc.nasa.gov> To: Reiner Ludwig From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based schemes) In-Reply-To: <5.1.0.14.0.20030218134100.02abf3c8@mailhost.eed.ericsson.se> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Moondance Date: Tue, 18 Feb 2003 12:35:19 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > This issue is probably not only relevant to Eifel Detection & > Response, but also to F-RTO, and DSACK-based alternatives. Yes. In draft-blanton-dsack-use-02.txt we have the following text: 4 Security Considerations It is possible for the receiver to falsely indicate spurious retransmissions in the case of actual loss, potentially causing a TCP or SCTP sender to inaccurately conclude that no loss took place (and cause inappropriate changes to the senders congestion control state). Consider the following scenario: A receiver watches every segment or chunk that arrives and acknowledges any segment that arrives out of order by more than some threshold amount as a duplicate, assuming that it is a retransmission. A sender using the above algorithm will assume that the retransmission was spurious. As a more trivial example, a receiver could simply acknowledge every segment or chunk received as a duplicate as they arrive. This approach is more easily defeated by heuristics, but would nonetheless cause the algorithm in this document to come to an incorrect conclusion. The ECN nonce sum proposal [WES01] would help mitigate the ability of the receiver to hide real losses from the sender. Not sure what the right answer is... "ignore it completely" seems wrong. But, "ignore it after some thought" might be right. Is coupling the whole thing with the ECN nonce right? Probably not... hmm... And, I'll note that the attacks from the CCR paper you quote are getting cleaned up slowly. ABC certainly helps ACK division. I have a note that says one of the things I'd like to see in RFC2581.bis is a limit on the number of duplicate ACKs a sender will accept (which would mitigate the bogus-dup-ack-generation attack). The third attack ("optimistic ACKing") does not seem as troubling to me because it is such a pain to get going. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 18 18:36:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11546 for ; Tue, 18 Feb 2003 18:36:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1INgf304339 for tsvwg-archive@odin.ietf.org; Tue, 18 Feb 2003 18:42:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1INgKp04323; Tue, 18 Feb 2003 18:42:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1INfxp04288 for ; Tue, 18 Feb 2003 18:41:59 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11499 for ; Tue, 18 Feb 2003 18:35:39 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1INcG222483 for ; Wed, 19 Feb 2003 01:38:16 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Feb 2003 01:39:27 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 01:39:25 +0200 Subject: Re: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based schemes) From: Yogesh Prem Swami To: ext Reiner Ludwig Cc: tsvwg@ietf.org In-Reply-To: <5.1.0.14.0.20030218134100.02abf3c8@mailhost.eed.ericsson.se> References: <5.1.0.14.0.20030218134100.02abf3c8@mailhost.eed.ericsson.se> Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1045611563.30188.85.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 18 Feb 2003 17:39:24 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Feb 2003 23:39:25.0497 (UTC) FILETIME=[F896CA90:01C2D7A6] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Reiner, > > box in the middle, congestion control at the TCP sender could be pretty > much disabled. So, one could argue along the lines of the reviewer when > combining the Eifel Detection algorithm with a response algorithm that > alters TCP state. On the other hand, we know (see Savage paper in ACM CCR, > Oct. 99) that even a "standard conformant" TCP sender's congestion control > is easily disabled. So, why be extra strict here? > This is a wrong argument for not being extra strict. Just becase standard TCP is less secure right now, doesn't mean we should keep making it worse. To give an anology, someone can steal my car in 1000 ways; leaving it unlocked would be 1001st. Does this mean I should leave my cars open all the time (I'm not going to, even if you say so). And, yes, this argument applies to every new scheme as you already pointed out. I, however, don't like the fact that anyone making a small change to TCP has to put himself into the minds of attackers and think of one zillion possibilities of what an attacker could or could not do. It's also not prudent to have individual protection schemes for every feature (very soon, as any one in security community can tell, the interaction between these schemes will become so complex that it will be hard to analyze and assess the strength of the overall schemes). That's one reason why I was (and I'm still) not a big fan of ECN nounces. A protection scheme MUST protect every scheme in all circumstances (not just one)! [I, however, don't want to discuss ECN nounce anymore. Please. I've already spent too much time on this for no reason. If everyone is happy, then so am I :-)] I think one can devise a single, well though out, future proof scheme that can protect against *all* possible attacks. In addition, these schemes need not be invoked all the time, but only when the sender thinks it's under attack (for example by looking at the number of open TCP connections it has). This should appease those who are overly concerned about performance. This will allow people to focus more on transport layer problems rather than on security issues (which are quite time consuming). --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 19 04:56:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17396 for ; Wed, 19 Feb 2003 04:56:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JA2Gt25126 for tsvwg-archive@odin.ietf.org; Wed, 19 Feb 2003 05:02:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JA1jp24978; Wed, 19 Feb 2003 05:01:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JA0Kp24772 for ; Wed, 19 Feb 2003 05:00:20 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17212 for ; Wed, 19 Feb 2003 04:53:47 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1JA0Zm00880 for ; Wed, 19 Feb 2003 12:00:35 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Feb 2003 11:57:36 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 11:57:35 +0200 Received: from there (sarolaht@sahaja.research.nokia.com [172.21.40.118]) by mgw.research.nokia.com (8.9.3/8.9.3) with SMTP id LAA13185; Wed, 19 Feb 2003 11:57:35 +0200 (EET) Message-Id: <200302190957.LAA13185@mgw.research.nokia.com> X-Authentication-Warning: mgw.research.nokia.com: Host sarolaht@sahaja.research.nokia.com [172.21.40.118] claimed to be there Content-Type: text/plain; charset="iso-8859-1" From: Pasi Sarolahti Organization: Nokia Research Center To: "ext Reiner Ludwig" , tsvwg@ietf.org Subject: Re: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based schemes) Date: Wed, 19 Feb 2003 11:57:34 +0200 X-Mailer: KMail [version 1.3.2] References: <5.1.0.14.0.20030218134100.02abf3c8@mailhost.eed.ericsson.se> In-Reply-To: <5.1.0.14.0.20030218134100.02abf3c8@mailhost.eed.ericsson.se> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Feb 2003 09:57:35.0683 (UTC) FILETIME=[54100930:01C2D7FD] Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, On Tuesday 18 February 2003 14:52, ext Reiner Ludwig wrote: > >I have read this briefly. To me this seems ok, but I am somewhat > >worried that this would open up a new type of ACK DOS as you could > >potentially guess timestamps and attack the algorithm. The 2' and > > 5' suggestions work around this, so I am (thinking out loud) if > > that should not be the default. OTH it's easier to take out the > > session by simply DoSing either the sender or the receiver... > > How do people think about this? This issue is probably not only > relevant to Eifel Detection & Response, but also to F-RTO, and > DSACK-based alternatives. As for F-RTO, I don't quite see how this comment relates to it, since it can be used without any TCP options. Of the attacks given in Savage CCR paper, earlier there was a problem related to "ack division" that was raised on this list last fall, and I believe it to be fixed. "optimistic (& false) acking" could cause wrong response with F-RTO, but in that case it would break the state at any TCP sender, so I'm not very much worried about it concerning the F-RTO draft. But some discussion regarding these in F-RTO security considerations would probably be in place. Timestamps surely provide an additional tool for malicious hosts, with or without Eifel. A receiver could subtract something from every timestamp echo, causing reduced RTO estimate at the sender and eventually a spurious RTO. This would trigger unnecessary retransmissions in slow start (unless detected), possibly congesting the network with useless segments. > This is actually a relevant issue for the mailing list. Since, if we > would follow the reviewer's suggestion, we raise the bar quite high > also for the alternative schemes like F-RTO and DSACK-based schemes. > Those should then also be comparably safe against misbehaving TCP > receivers, I think. Fully agree. I'd still like to stick to the requirement we had set for our work: Never falsely declare a retransmission spurious (but not catching all spurious retransmissions is ok). - Pasi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 19 07:32:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21878 for ; Wed, 19 Feb 2003 07:32:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JCcB005111 for tsvwg-archive@odin.ietf.org; Wed, 19 Feb 2003 07:38:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JCbkp04974; Wed, 19 Feb 2003 07:37:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JCafp04310 for ; Wed, 19 Feb 2003 07:36:41 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21795 for ; Wed, 19 Feb 2003 07:30:05 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1JCXsAv026352; Wed, 19 Feb 2003 13:33:54 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4F5A57; Wed, 19 Feb 2003 13:33:53 +0100 Received: from res0010384da36.eed.ericsson.se (dhcp5-197 [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id NAA01486; Wed, 19 Feb 2003 13:33:53 +0100 (MET) Message-Id: <5.1.0.14.0.20030219131546.027b3e90@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 Feb 2003 13:33:43 +0100 To: mallman@grc.nasa.gov From: Reiner Ludwig Subject: Re: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based schemes) Cc: tsvwg@ietf.org In-Reply-To: <200302181735.MAA65851@guns.lerc.nasa.gov> References: <5.1.0.14.0.20030218134100.02abf3c8@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 18:35 18.02.2003, Mark Allman wrote: >Yes. In draft-blanton-dsack-use-02.txt we have the following text: > > >4 Security Considerations [...] > >Not sure what the right answer is... "ignore it completely" seems >wrong. But, "ignore it after some thought" might be right. Is >coupling the whole thing with the ECN nonce right? Probably >not... hmm... I think this needs to be discussed in general. If we are proposing ways to reverse congestion control state, we need to decide how secure (if at all) such schemes need to be. And a consensus should probably apply to any such proposal. Maybe the ECN nonce is already the consensus on the required level of security for such schemes? I.e., congestion-control-reversing proposals would be required to have security that is "equivalent" to the ECN nonce. Is that what we want? >And, I'll note that the attacks from the CCR paper you quote are >getting cleaned up slowly. ABC certainly helps ACK division. I >have a note that says one of the things I'd like to see in >RFC2581.bis is a limit on the number of duplicate ACKs a sender will >accept (which would mitigate the bogus-dup-ack-generation attack). >The third attack ("optimistic ACKing") does not seem as troubling to >me because it is such a pain to get going. True. But what do say with this? Do you think that, e.g., Eifel Detection/Response needs to be made safe against misbehaving receivers? ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 19 07:36:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22248 for ; Wed, 19 Feb 2003 07:36:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JCh1a05731 for tsvwg-archive@odin.ietf.org; Wed, 19 Feb 2003 07:43:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JCg8p05689; Wed, 19 Feb 2003 07:42:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JCfYp05605 for ; Wed, 19 Feb 2003 07:41:34 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22166 for ; Wed, 19 Feb 2003 07:34:59 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1JCclAv027579; Wed, 19 Feb 2003 13:38:47 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4F5CXY; Wed, 19 Feb 2003 13:38:46 +0100 Received: from res0010384da36.eed.ericsson.se (dhcp5-197 [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id NAA02409; Wed, 19 Feb 2003 13:38:46 +0100 (MET) Message-Id: <5.1.0.14.0.20030219133529.027c30f0@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 Feb 2003 13:38:36 +0100 To: Pasi Sarolahti From: Reiner Ludwig Subject: Re: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based schemes) Cc: tsvwg@ietf.org In-Reply-To: <200302190957.LAA13185@mgw.research.nokia.com> References: <5.1.0.14.0.20030218134100.02abf3c8@mailhost.eed.ericsson.se> <5.1.0.14.0.20030218134100.02abf3c8@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 10:57 19.02.2003, Pasi Sarolahti wrote: >I'd still like to stick to the requirement we had set for >our work: Never falsely declare a retransmission spurious (but not >catching all spurious retransmissions is ok). That's the point. Don't you think that a TCP receiver or a middle-box could play "ACK games" that would make F-RTO falsely believe a timeout was spurious? ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 19 07:53:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23341 for ; Wed, 19 Feb 2003 07:53:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JCx7706771 for tsvwg-archive@odin.ietf.org; Wed, 19 Feb 2003 07:59:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JCwNp06679; Wed, 19 Feb 2003 07:58:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JCvup06592 for ; Wed, 19 Feb 2003 07:57:56 -0500 Received: from pop-4.dnv.wideopenwest.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23261 for ; Wed, 19 Feb 2003 07:51:05 -0500 (EST) Received: from thoth.ir.bbn.com (d53-203-209.clv.wideopenwest.com [64.53.209.203]) by pop-4.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h1JD36m10080; Wed, 19 Feb 2003 07:03:07 -0600 Received: from thoth.ir.bbn.com (localhost [127.0.0.1]) by thoth.ir.bbn.com (8.12.6/8.12.6) with ESMTP id h1JCtYht062303; Wed, 19 Feb 2003 07:55:34 -0500 (EST) (envelope-from mallman@thoth.ir.bbn.com) Message-Id: <200302191255.h1JCtYht062303@thoth.ir.bbn.com> To: Reiner Ludwig From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tsvwg@ietf.org Subject: Re: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based schemes) In-Reply-To: <5.1.0.14.0.20030219131546.027b3e90@mailhost.eed.ericsson.se> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Moondance Date: Wed, 19 Feb 2003 07:55:34 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > I think this needs to be discussed in general. Yep. > If we are proposing ways to reverse congestion control state, we > need to decide how secure (if at all) such schemes need to be. And > a consensus should probably apply to any such proposal. Yep. > Maybe the ECN nonce is already the consensus on the required level > of security for such schemes? I.e., congestion-control-reversing > proposals would be required to have security that is "equivalent" > to the ECN nonce. Is that what we want? ?? > Do you think that, e.g., Eifel Detection/Response needs to be made > safe against misbehaving receivers? ?? I am not sure what I think the right answer is here.... I think that it could be Damn Hard to find a single solution. One way to go that gets you *some* protection is that the sender applies some scheme where it is only allowed to revert CC state "every so often". So, even if the receiver could game things it would not cause the sender to behave poorly each time the receiver tried to conceal something. I.e., we could think about saying "a sender can only undo CC changes once every 30 seconds" or "a sender can only undo CC changes in every tenth 'loss events' throughout the connection. I don't know that those are right - they are just examples. Of course, this does not really cure the problem so much as treat the symptom -- i.e., we don't try to detect lying receivers (& thus stop helping them) we just decide to not let it hurt too bad when we are reacting to a malicious receiver. I am not sure I like this idea... just throwing it out... allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 19 07:56:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23579 for ; Wed, 19 Feb 2003 07:56:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JD2pW07040 for tsvwg-archive@odin.ietf.org; Wed, 19 Feb 2003 08:02:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JD25p06981; Wed, 19 Feb 2003 08:02:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JD1cp06952 for ; Wed, 19 Feb 2003 08:01:38 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23459 for ; Wed, 19 Feb 2003 07:55:02 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1JCvd210758 for ; Wed, 19 Feb 2003 14:57:39 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Feb 2003 14:58:50 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 14:58:50 +0200 Received: from there (sarolaht@sahaja.research.nokia.com [172.21.40.118]) by mgw.research.nokia.com (8.9.3/8.9.3) with SMTP id OAA14371; Wed, 19 Feb 2003 14:58:49 +0200 (EET) Message-Id: <200302191258.OAA14371@mgw.research.nokia.com> X-Authentication-Warning: mgw.research.nokia.com: Host sarolaht@sahaja.research.nokia.com [172.21.40.118] claimed to be there Content-Type: text/plain; charset="iso-8859-1" From: Pasi Sarolahti Organization: Nokia Research Center To: "ext Reiner Ludwig" Subject: Re: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based schemes) Date: Wed, 19 Feb 2003 14:58:49 +0200 X-Mailer: KMail [version 1.3.2] Cc: tsvwg@ietf.org References: <5.1.0.14.0.20030218134100.02abf3c8@mailhost.eed.ericsson.se> <5.1.0.14.0.20030219133529.027c30f0@mailhost.eed.ericsson.se> In-Reply-To: <5.1.0.14.0.20030219133529.027c30f0@mailhost.eed.ericsson.se> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Feb 2003 12:58:50.0078 (UTC) FILETIME=[A5B507E0:01C2D816] Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Wednesday 19 February 2003 14:38, ext Reiner Ludwig wrote: > At 10:57 19.02.2003, Pasi Sarolahti wrote: > >I'd still like to stick to the requirement we had set for > >our work: Never falsely declare a retransmission spurious (but not > >catching all spurious retransmissions is ok). > > That's the point. Don't you think that a TCP receiver or a middle-box > could play "ACK games" that would make F-RTO falsely believe a > timeout was spurious? Currently I'm in belief that F-RTO should be quite robust against these. To cause false declaration of spurious RTO at an F-RTO sender the other end (or midbox) should acknowledge a segment that was actually lost. If that is the case, the false F-RTO response is the smallest of problems the TCP sender has at that time, because the TCP end-to-end semantics are messed up anyway at that point. Btw, I think this is a reason that speaks for not fully reverting the congestion control state after detecting a spurious retransmission. Should a malicious host find a way to cause false spurious RTO notifications at a sender, at least it would not be able to buy more congestion window by doing so. - Pasi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Feb 20 09:26:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15528 for ; Thu, 20 Feb 2003 09:26:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KEWhY16370 for tsvwg-archive@odin.ietf.org; Thu, 20 Feb 2003 09:32:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KEW4p16337; Thu, 20 Feb 2003 09:32:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KETDp16209 for ; Thu, 20 Feb 2003 09:29:13 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15444 for ; Thu, 20 Feb 2003 09:22:06 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1KEPtAv008928; Thu, 20 Feb 2003 15:25:55 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVMQ743; Thu, 20 Feb 2003 15:25:54 +0100 Received: from res0010384da36.eed.ericsson.se (rac175pc.edd.ericsson.se [164.48.123.175]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id PAA10942; Thu, 20 Feb 2003 15:25:50 +0100 (MET) Message-Id: <5.1.0.14.0.20030220143958.00aa9b48@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 20 Feb 2003 15:14:08 +0100 To: mallman@grc.nasa.gov From: Reiner Ludwig Subject: Re: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based schemes) Cc: tsvwg@ietf.org In-Reply-To: <200302191255.h1JCtYht062303@thoth.ir.bbn.com> References: <5.1.0.14.0.20030219131546.027b3e90@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 13:55 19.02.2003, Mark Allman wrote: > > Do you think that, e.g., Eifel Detection/Response needs to be made > > safe against misbehaving receivers? > >?? > >I am not sure what I think the right answer is here.... I think that >it could be Damn Hard to find a single solution. One way to go that >gets you *some* protection is that the sender applies some scheme >where it is only allowed to revert CC state "every so often". So, >even if the receiver could game things it would not cause the sender >to behave poorly each time the receiver tried to conceal something. >I.e., we could think about saying "a sender can only undo CC changes >once every 30 seconds" or "a sender can only undo CC changes in >every tenth 'loss events' throughout the connection. I don't know >that those are right - they are just examples. On the other hand, we are discussing potentially-to-be *experimental* RFCs. Given that, one could argue that we could/should be a bit more relaxed about misbehaving TCP receivers and/or bad-mid-boxes. This is not saying that we should ignore easy protection mechanisms, but maybe during the "experimental phase" we do not have to put all possible engineering smarts into such protection schemes. *If* at some stage we start discussing about advancing a proposal to *proposed standard* RFC, it is probably the right time to think harder about these security considerations. So, my current opinion is that at least Eifel Detection/Response (and probably also the alternative schemes - I haven't reviewed then yet) should go ahead as defined in the current drafts. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Feb 20 10:26:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17730 for ; Thu, 20 Feb 2003 10:26:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KFWx120812 for tsvwg-archive@odin.ietf.org; Thu, 20 Feb 2003 10:32:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFWHp20729; Thu, 20 Feb 2003 10:32:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFVXp20679 for ; Thu, 20 Feb 2003 10:31:33 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17562 for ; Thu, 20 Feb 2003 10:24:25 -0500 (EST) Received: from isi.edu ([207.151.149.14]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h1KFSBH22723; Thu, 20 Feb 2003 07:28:11 -0800 (PST) Message-ID: <3E54F407.2070601@isi.edu> Date: Thu, 20 Feb 2003 07:28:07 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Reiner Ludwig CC: mallman@grc.nasa.gov, tsvwg@ietf.org Subject: Re: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based schemes) References: <5.1.0.14.0.20030219131546.027b3e90@mailhost.eed.ericsson.se> <5.1.0.14.0.20030220143958.00aa9b48@mailhost.eed.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Reiner Ludwig wrote: > At 13:55 19.02.2003, Mark Allman wrote: > >> > Do you think that, e.g., Eifel Detection/Response needs to be made >> > safe against misbehaving receivers? >> >> ?? >> >> I am not sure what I think the right answer is here.... I think that >> it could be Damn Hard to find a single solution. One way to go that >> gets you *some* protection is that the sender applies some scheme >> where it is only allowed to revert CC state "every so often". So, >> even if the receiver could game things it would not cause the sender >> to behave poorly each time the receiver tried to conceal something. >> I.e., we could think about saying "a sender can only undo CC changes >> once every 30 seconds" or "a sender can only undo CC changes in >> every tenth 'loss events' throughout the connection. I don't know >> that those are right - they are just examples. > > > On the other hand, we are discussing potentially-to-be *experimental* > RFCs. Given that, one could argue that we could/should be a bit more > relaxed about misbehaving TCP receivers and/or bad-mid-boxes. This is > not saying that we should ignore easy protection mechanisms, but maybe > during the "experimental phase" we do not have to put all possible > engineering smarts into such protection schemes. > > *If* at some stage we start discussing about advancing a proposal to > *proposed standard* RFC, it is probably the right time to think harder > about these security considerations. Reiner (et al.), Is Eifel intended/designed to be _more_ secure against such attacks than conventional TCP? I.e., the metric (for proposed standard, not experimental yet) should be "no more insecure than TCP" unless Eifel is specifically trying to address these attacks (and that isn't my impression). Joe _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Feb 20 10:27:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17810 for ; Thu, 20 Feb 2003 10:27:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KFYSh20881 for tsvwg-archive@odin.ietf.org; Thu, 20 Feb 2003 10:34:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFY5p20864; Thu, 20 Feb 2003 10:34:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFXRp20835 for ; Thu, 20 Feb 2003 10:33:27 -0500 Received: from MAIL.cynetanetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17726 for ; Thu, 20 Feb 2003 10:26:18 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based schemes) Date: Thu, 20 Feb 2003 09:30:08 -0600 Message-ID: <9255B6CD76A88943A3062F7D4E6432F543BB48@mail.cynetanetworks.com> Thread-Topic: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based schemes) Thread-Index: AcLY9Ab4czDZMN6USPmiLa2cjIU9MwAABurQ From: "Spencer Dawkins" To: Cc: "Carl Williams (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1KFXRp20836 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit We've also been having similar conversations about the security considerations for "triggers for transport" triggers, thinking about questions like, "should a sender respond every time it gets a Link Up/Connectivity Restored notification?". So, we're also pretty interested in people's opinions about how often a sender should adjust its notion of what's "really" happening, and about high the bar needs to be, especially re: "bad-mid-boxes". Spencer > -----Original Message----- > From: Reiner Ludwig [mailto:Reiner.Ludwig@eed.ericsson.se] > Sent: Thursday, February 20, 2003 8:14 AM > To: mallman@grc.nasa.gov > Cc: tsvwg@ietf.org > Subject: Re: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based > schemes) > > > At 13:55 19.02.2003, Mark Allman wrote: > > > >I am not sure what I think the right answer is here.... I think that > >it could be Damn Hard to find a single solution. One way to go that > >gets you *some* protection is that the sender applies some scheme > >where it is only allowed to revert CC state "every so often". So, > >even if the receiver could game things it would not cause the sender > >to behave poorly each time the receiver tried to conceal something. > >I.e., we could think about saying "a sender can only undo CC changes > >once every 30 seconds" or "a sender can only undo CC changes in > >every tenth 'loss events' throughout the connection. I don't know > >that those are right - they are just examples. > > On the other hand, we are discussing potentially-to-be > *experimental* RFCs. > Given that, one could argue that we could/should be a bit > more relaxed > about misbehaving TCP receivers and/or bad-mid-boxes. This is > not saying > that we should ignore easy protection mechanisms, but maybe > during the > "experimental phase" we do not have to put all possible > engineering smarts > into such protection schemes. > > *If* at some stage we start discussing about advancing a proposal to > *proposed standard* RFC, it is probably the right time to > think harder > about these security considerations. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Feb 20 10:46:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18534 for ; Thu, 20 Feb 2003 10:46:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KFrPY22590 for tsvwg-archive@odin.ietf.org; Thu, 20 Feb 2003 10:53:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFr7p22575; Thu, 20 Feb 2003 10:53:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFqKp22544 for ; Thu, 20 Feb 2003 10:52:20 -0500 Received: from seraph2.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18496 for ; Thu, 20 Feb 2003 10:45:11 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 0FFAF68972 for ; Thu, 20 Feb 2003 10:49:02 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id h1KFn1sW011252; Thu, 20 Feb 2003 10:49:01 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id KAA93379; Thu, 20 Feb 2003 10:49:01 -0500 (EST) Message-Id: <200302201549.KAA93379@guns.lerc.nasa.gov> To: Joe Touch From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based schemes) In-Reply-To: <3E54F407.2070601@isi.edu> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Imagine Date: Thu, 20 Feb 2003 10:49:01 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Joe- > Is Eifel intended/designed to be _more_ secure against such > attacks than conventional TCP? > > I.e., the metric (for proposed standard, not experimental yet) > should be "no more insecure than TCP" unless Eifel is specifically > trying to address these attacks (and that isn't my impression). But, that's still pretty fuzzy... We know that TCP's congestion control can be gamed (e.g., by ACK division). And, we know that adding eifel or DSACK adds an additional way for congestion control to be gamed. So, does that mean ... * the new schemes are "no more insecure than TCP" because we can trick a TCP sender now and we can trick a TCP sender with the new schemes, or * the new schemes are "more insecure than TCP" because they open new avenues for a receiver to trick the sender's congestion control ? I can see it both ways. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Feb 20 11:36:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20408 for ; Thu, 20 Feb 2003 11:36:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KGge827041 for tsvwg-archive@odin.ietf.org; Thu, 20 Feb 2003 11:42:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGevp26899; Thu, 20 Feb 2003 11:40:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGd2p26770 for ; Thu, 20 Feb 2003 11:39:02 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20253 for ; Thu, 20 Feb 2003 11:31:51 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1KGZRsv008992; Thu, 20 Feb 2003 08:35:27 -0800 (PST) Received: from cisco.com (sjc-vpn3-656.cisco.com [10.21.66.144]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEI42514; Thu, 20 Feb 2003 08:31:06 -0800 (PST) Message-ID: <3E550527.7A71899@cisco.com> Date: Thu, 20 Feb 2003 08:41:11 -0800 From: mbashyam X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,Tamil MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] slow-start restart Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Is the problem of persistent HTTP connections slow starting after an idle period of a round trip time been addressed? I know the problem is well understood and there are solutions which can preserve the conservative spirit behind slow starting and also maintain the congestion window high enough for the subsequent transfers, but are there any standards/drafts in progress that address this issue already? If not is there a need to write one? Murali _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Feb 20 11:36:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20465 for ; Thu, 20 Feb 2003 11:36:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KGhWu27169 for tsvwg-archive@odin.ietf.org; Thu, 20 Feb 2003 11:43:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGh5p27123; Thu, 20 Feb 2003 11:43:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGgSp27020 for ; Thu, 20 Feb 2003 11:42:28 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20365 for ; Thu, 20 Feb 2003 11:35:18 -0500 (EST) Received: from isi.edu ([207.151.149.14]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h1KGd5H16134; Thu, 20 Feb 2003 08:39:05 -0800 (PST) Message-ID: <3E5504A5.7040202@isi.edu> Date: Thu, 20 Feb 2003 08:39:01 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@grc.nasa.gov CC: Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based schemes) References: <200302201549.KAA93379@guns.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mark Allman wrote: > Joe- > > >>Is Eifel intended/designed to be _more_ secure against such >>attacks than conventional TCP? >> >>I.e., the metric (for proposed standard, not experimental yet) >>should be "no more insecure than TCP" unless Eifel is specifically >>trying to address these attacks (and that isn't my impression). > > > But, that's still pretty fuzzy... We know that TCP's congestion > control can be gamed (e.g., by ACK division). And, we know that > adding eifel or DSACK adds an additional way for congestion control > to be gamed. So, does that mean ... > > * the new schemes are "no more insecure than TCP" because we can > trick a TCP sender now and we can trick a TCP sender with the > new schemes, or > > * the new schemes are "more insecure than TCP" because they open > new avenues for a receiver to trick the sender's congestion > control It depends primarily on whether the amount to which you can trick the sender (i.e., what you can trick the sender into doing) is worse with Eifel or not. Whether it's a new avenue is less significant than whether it causes more resultant instability. Joe _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Feb 20 11:48:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20940 for ; Thu, 20 Feb 2003 11:48:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KGtbP28165 for tsvwg-archive@odin.ietf.org; Thu, 20 Feb 2003 11:55:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGt7p28156; Thu, 20 Feb 2003 11:55:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGsip28080 for ; Thu, 20 Feb 2003 11:54:44 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20881 for ; Thu, 20 Feb 2003 11:47:34 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 3EE869DAB; Thu, 20 Feb 2003 11:51:25 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 54BB59DA7; Thu, 20 Feb 2003 11:51:23 -0500 (EST) Date: Thu, 20 Feb 2003 11:51:23 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Spencer Dawkins Cc: , "Carl Williams (E-mail)" Subject: RE: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based schemes) In-Reply-To: <9255B6CD76A88943A3062F7D4E6432F543BB48@mail.cynetanetworks.com> Message-ID: X-Spam-Status: No, hits=-103.0 required=6.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE,USER_IN_WHITELIST version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Thu, 20 Feb 2003, Spencer Dawkins wrote: > We've also been having similar conversations about the security > considerations for "triggers for transport" triggers, thinking about > questions like, "should a sender respond every time it gets a Link > Up/Connectivity Restored notification?". > > So, we're also pretty interested in people's opinions about how often > a sender should adjust its notion of what's "really" happening, and > about high the bar needs to be, especially re: "bad-mid-boxes". I think if a mechanism cannot be trusted enough to respond to each event, then the mechanism is not very useful. These proposed event notifications (triggers, eifel, etc) attempt to help the sender further infer information from the network. However, if each event notification itself needs yet another mechanism for the sender to "believe" the notification, then nothing is gained. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Feb 20 14:10:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25899 for ; Thu, 20 Feb 2003 14:10:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KJGgN07409 for tsvwg-archive@odin.ietf.org; Thu, 20 Feb 2003 14:16:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KJGKp07382; Thu, 20 Feb 2003 14:16:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KJFPp07332 for ; Thu, 20 Feb 2003 14:15:25 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25831 for ; Thu, 20 Feb 2003 14:08:13 -0500 (EST) Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h1KJBXH19422; Thu, 20 Feb 2003 11:11:33 -0800 (PST) Message-ID: <3E5527E9.4010908@isi.edu> Date: Thu, 20 Feb 2003 11:09:29 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbashyam CC: tsvwg@ietf.org Subject: Re: [Tsvwg] slow-start restart References: <3E550527.7A71899@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit mbashyam wrote: > Hi > > Is the problem of persistent HTTP connections slow starting after an > idle period of a round trip time been addressed? I know the problem is > well understood and there are solutions which can preserve the > conservative spirit behind slow starting and also maintain the > congestion window high enough for the subsequent transfers, but are > there any standards/drafts in progress that address this issue already? > If not is there a need to write one? http://www/touch/pubs/draft-hughes-restart-00.txt This is pending an implementation to proceed... interested ;-)? Joe _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Feb 20 14:22:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26303 for ; Thu, 20 Feb 2003 14:22:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KJSfS08189 for tsvwg-archive@odin.ietf.org; Thu, 20 Feb 2003 14:28:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KJS9p08164; Thu, 20 Feb 2003 14:28:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KJR8p08124 for ; Thu, 20 Feb 2003 14:27:08 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26215 for ; Thu, 20 Feb 2003 14:19:56 -0500 (EST) Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h1KJN3H28878; Thu, 20 Feb 2003 11:23:03 -0800 (PST) Message-ID: <3E552A9C.1090100@isi.edu> Date: Thu, 20 Feb 2003 11:21:00 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch CC: mbashyam , tsvwg@ietf.org Subject: Re: [Tsvwg] slow-start restart References: <3E550527.7A71899@cisco.com> <3E5527E9.4010908@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Joe Touch wrote: > mbashyam wrote: > >> Hi >> >> Is the problem of persistent HTTP connections slow starting after an >> idle period of a round trip time been addressed? I know the problem is >> well understood and there are solutions which can preserve the >> conservative spirit behind slow starting and also maintain the >> congestion window high enough for the subsequent transfers, but are >> there any standards/drafts in progress that address this issue already? >> If not is there a need to write one? > > > http://www/touch/pubs/draft-hughes-restart-00.txt > > This is pending an implementation to proceed... interested ;-)? It's also pending a better URL ;-0 http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt Joe _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Feb 21 08:09:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28509 for ; Fri, 21 Feb 2003 08:09:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LDGon21880 for tsvwg-archive@odin.ietf.org; Fri, 21 Feb 2003 08:16:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LDGQp21845; Fri, 21 Feb 2003 08:16:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H7esp05855 for ; Mon, 17 Feb 2003 02:40:54 -0500 Received: from web41302.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16652 for ; Mon, 17 Feb 2003 02:35:22 -0500 (EST) Message-ID: <20030217073910.21089.qmail@web41302.mail.yahoo.com> Received: from [210.3.50.157] by web41302.mail.yahoo.com via HTTP; Sun, 16 Feb 2003 23:39:10 PST Date: Sun, 16 Feb 2003 23:39:10 -0800 (PST) From: "K. Poon" To: Randall Stewart , TSV WG list , SCTP Implementors In-Reply-To: <3E48EF01.9080502@stewart.chicago.il.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Tsvwg] Re: A question of Un-Ordered SCTP Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --- Randall Stewart wrote: > What has been discussed is, "could we instead allow the > ULP to specify a value to be set in the SSN and sent > in that field with the receiving SCTP to continue to ignore the > value but instead pass it, as is, to the ULP" Do you mean the sinfo_ssn field in the sctp_sndrcvinfo structure? I believe it is specified to be not "writeable" on the send side. And I think that it is best not to be "writeable" by socket apps. SSN is a SCTP internal concept. It should not be "changeable" by an app. To me, even the receiver should not need to see it at all. It is there now, if I remember correctly, simply because of the requirement of returning unsent data. Please correct me if I am wrong. > Now, the more I have thought on this the more I think that > it is rather harmless for the following reasons: There are a lot of harmless things, it does not mean that we need to do them all, although it is just code (-: > a) Currently receivers are ignoring the SSN, they have to > be otherwise they could not process the unordered data > properly. This just means that the SSN field is not used in this situation by SCTP. It does not argue for the use of the field by ULP... To me, this is a semantic overload of the SSN field. It is really not a good idea in protocol design, especially if the overload is for the sake of an ULP. > b) The sending side API is pretty much in place for this > since the send_rcv_info structure (in the socket api) includes > the SSN which currently on sending is ignored. The sinfo_ssn is there because of simplicity reason. We don't want to have different data structures for send and receive. I guess this should not be used as a reason for letting an app change an internal SCTP concept. > c) It seems to me that these 16 bits are just wasted bandwidth > and with minor changes to most implementations it would allow > useage of these bits in other situations besides RDDP.. Is this similar in suggesting that since there are some bits unused (wasted) in the TCP reserved bit field, we should allow an app to set whatever value it likes in those bits? This may sound a little bit extreme, but the idea is similar. I believe if it is allowed, it will be a very bad precedence in SCTP protocol development. We should not encourage app protocol to "require" changes in SCTP simply because it is "convenient" and "harmless" while it is just a simple matter to support the changes in the app protocol itself. > So what do all think of the idea? Good? Bad? Just my $0.02, I think it is a bad idea... ===== K. Poon. kcpoon@yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Feb 21 08:09:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28522 for ; Fri, 21 Feb 2003 08:09:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LDGqY21897 for tsvwg-archive@odin.ietf.org; Fri, 21 Feb 2003 08:16:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LDGYp21868; Fri, 21 Feb 2003 08:16:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFdKp20094 for ; Wed, 19 Feb 2003 10:39:20 -0500 Received: from chuckie.dgms.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28979 for ; Wed, 19 Feb 2003 10:32:40 -0500 (EST) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id KAA27039; Wed, 19 Feb 2003 10:32:32 -0500 (EST) Message-ID: <3E53A390.4000509@ulticom.com> Date: Wed, 19 Feb 2003 10:32:32 -0500 From: David Lehmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "K. Poon" CC: Randall Stewart , TSV WG list , SCTP Implementors References: <20030217073910.21089.qmail@web41302.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: A question of Un-Ordered SCTP Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit K. Poon wrote: > Is this similar in suggesting that since there are some bits > unused (wasted) in the TCP reserved bit field, we should allow > an app to set whatever value it likes in those bits? This may > sound a little bit extreme, but the idea is similar. I believe > if it is allowed, it will be a very bad precedence in SCTP > protocol development. We should not encourage app protocol > to "require" changes in SCTP simply because it is "convenient" > and "harmless" while it is just a simple matter to support the > changes in the app protocol itself. > > >>So what do all think of the idea? Good? Bad? > > > Just my $0.02, I think it is a bad idea... I agree with K. Poon 100%. Let the ULP put the sequence numbers of unordered data (and whatever else it wants) in its own headers. (K. Poon's stated it much more articulately, I must admit.) -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Feb 24 03:59:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05067 for ; Mon, 24 Feb 2003 03:59:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O98O709331 for tsvwg-archive@odin.ietf.org; Mon, 24 Feb 2003 04:08:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O97up09282; Mon, 24 Feb 2003 04:07:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LFkIp31988 for ; Fri, 21 Feb 2003 10:46:18 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03821 for ; Fri, 21 Feb 2003 10:38:41 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 701C79DD1; Fri, 21 Feb 2003 10:42:32 -0500 (EST) Received: from frink.ece.udel.edu (frink.ece.udel.edu [128.4.130.33]) by mail.eecis.udel.edu (Postfix) with ESMTP id D03FC9DD1 for ; Fri, 21 Feb 2003 10:42:30 -0500 (EST) Date: Fri, 21 Feb 2003 10:42:30 -0500 (EST) From: Liangping Ma X-X-Sender: To: Message-ID: X-Spam-Status: No, hits=-99.8 required=6.0 tests=SPAM_PHRASE_00_01,USER_AGENT_PINE,USER_IN_WHITELIST version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Subject: [Tsvwg] Anyone know any statistical analysis of RTO algorithm? Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Does anyone know if there is any rigorous statistical analysis of TCP's Retransmission Timeout (RTO) algorithm? If there is, please give me some references. I am currently working on an analysis based on an auto-regressive model of the RTT process. Thanks! Liangping Ma _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Feb 24 04:00:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05097 for ; Mon, 24 Feb 2003 04:00:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O98WA09347 for tsvwg-archive@odin.ietf.org; Mon, 24 Feb 2003 04:08:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O98Ap09308; Mon, 24 Feb 2003 04:08:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LFnMp32101 for ; Fri, 21 Feb 2003 10:49:22 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03922 for ; Fri, 21 Feb 2003 10:41:44 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 08B859DD1; Fri, 21 Feb 2003 10:45:36 -0500 (EST) Received: from frink.ece.udel.edu (frink.ece.udel.edu [128.4.130.33]) by mail.eecis.udel.edu (Postfix) with ESMTP id C5D0E9D99 for ; Fri, 21 Feb 2003 10:45:34 -0500 (EST) Date: Fri, 21 Feb 2003 10:45:34 -0500 (EST) From: Liangping Ma X-X-Sender: To: Message-ID: X-Spam-Status: No, hits=-99.8 required=6.0 tests=SPAM_PHRASE_00_01,USER_AGENT_PINE,USER_IN_WHITELIST version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Subject: [Tsvwg] Anyone know any explanation of the distribution of RTT? Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Mukherjee reported based on his experiments that the Round-trip Time (RTT) follows a shifted Gamma distribution, but gave no explanation from theory. Does anyone know if there is a theoretical explanation for the Gamma distribution. I currently have one. Thanks! Liangping Ma _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Feb 24 04:00:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05110 for ; Mon, 24 Feb 2003 04:00:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O98mP09365 for tsvwg-archive@odin.ietf.org; Mon, 24 Feb 2003 04:08:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O98Cp09323; Mon, 24 Feb 2003 04:08:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LG15p00357 for ; Fri, 21 Feb 2003 11:01:05 -0500 Received: from auds951.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04336 for ; Fri, 21 Feb 2003 10:53:27 -0500 (EST) Received: from morgoth.pet.usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.6/8.12.6) with ESMTP id h1LFv7JT011687; Fri, 21 Feb 2003 09:57:07 -0600 (CST) Received: from alcatel.com (localhost [127.0.0.1]) by morgoth.pet.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id h1LFvXG13210; Fri, 21 Feb 2003 07:57:33 -0800 (PST) Message-ID: <3E564C4E.99932560@alcatel.com> Date: Fri, 21 Feb 2003 07:57:02 -0800 From: Mudhafar Hassan-Ali Organization: Alcatel, USA X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: tsvwg@ietf.org, Scott Bradner , Allison Mankin , floyd@icir.org, vern@icir.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Redundant TCP connection Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit All, I am wondering if any one is aware of the feasibility in practice to make a redundant TCP connection? This type of connection is needed in a redundant system. In such system (call it X), there are two sides, an active one and a standby one. Let's say the active one has a TCP connection with a piece of equipment Y somewhere in the network. At some point, the active fails, which will lead to a protection switch. This event will disrupt the TCP connection, which means Y will close its connection, and the second side of X need to open the connection also. However, my goal is not to disrupt the connection during the side switch. So the question is: Is it feasible to make a redundant TCP connection, such that the two sides somehow are synchronized (what are the parameters needed?). So for a given TCP/IP stack, how feasible and practical to do that? Any feedback is highly appreciated. Best regards, Mudhafar Hassan-Ali Wireline Access Alcatel _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Feb 24 04:17:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05633 for ; Mon, 24 Feb 2003 04:17:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O9Pmj10257 for tsvwg-archive@odin.ietf.org; Mon, 24 Feb 2003 04:25:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O9PEp10241; Mon, 24 Feb 2003 04:25:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O9Okp10210 for ; Mon, 24 Feb 2003 04:24:46 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05621 for ; Mon, 24 Feb 2003 04:15:47 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:JXHot/UB63hJFSK2Zl0LnFDnBKDh8HU1@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1O9JXD25836; Mon, 24 Feb 2003 02:19:33 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1O9JXk08666; Mon, 24 Feb 2003 02:19:33 -0700 Date: Mon, 24 Feb 2003 02:19:32 -0700 From: "Brian F. G. Bidulock" To: Mudhafar Hassan-Ali Cc: tsvwg@ietf.org, Scott Bradner , Allison Mankin , floyd@icir.org, vern@icir.org Subject: Re: [Tsvwg] Redundant TCP connection Message-ID: <20030224021932.B8034@openss7.org> Reply-To: bidulock@openss7.org References: <3E564C4E.99932560@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E564C4E.99932560@alcatel.com>; from mudhafar.hassan-ali@alcatel.com on Fri, Feb 21, 2003 at 07:57:02AM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Mudhafar, Have you looked at SCTP? Its multi-homed feature will do what you want. --brian On Fri, 21 Feb 2003, Mudhafar Hassan-Ali wrote: > All, > > I am wondering if any one is aware of the feasibility in practice to > make a redundant TCP connection? This type of connection is needed in a > redundant system. In such system (call it X), there are two sides, an > active one and a standby one. Let's say the active one has a TCP > connection with a piece of equipment Y somewhere in the network. At some > point, the active fails, which will lead to a protection switch. This > event will disrupt the TCP connection, which means Y will close its > connection, and the second side of X need to open the connection also. > However, my goal is not to disrupt the connection during the side > switch. So the question is: Is it feasible to make a redundant TCP > connection, such that the two sides somehow are synchronized (what are > the parameters needed?). So for a given TCP/IP stack, how feasible and > practical to do that? > > Any feedback is highly appreciated. > > Best regards, > Mudhafar Hassan-Ali > Wireline Access > Alcatel > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Feb 24 05:58:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07569 for ; Mon, 24 Feb 2003 05:58:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OB6pe15737 for tsvwg-archive@odin.ietf.org; Mon, 24 Feb 2003 06:06:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OB6Vp15720; Mon, 24 Feb 2003 06:06:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OB5kp15700 for ; Mon, 24 Feb 2003 06:05:46 -0500 Received: from zctfs063.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07558 for ; Mon, 24 Feb 2003 05:56:41 -0500 (EST) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1OAwxK12652; Mon, 24 Feb 2003 11:58:59 +0100 (MET) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1L432B6W>; Mon, 24 Feb 2003 11:58:59 +0100 Message-ID: From: "Jean-Marc Fenart" To: bidulock@openss7.org, Mudhafar Hassan-Ali Cc: tsvwg@ietf.org, Scott Bradner , Allison Mankin , floyd@icir.org, vern@icir.org Subject: RE: [Tsvwg] Redundant TCP connection Date: Mon, 24 Feb 2003 11:58:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DBF3.BA07B1BC" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DBF3.BA07B1BC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As far as I undertand SCTP multi-homing is dealing more with transport = links redundancy, e.g. multiple links to the same node.=20 An issue is the active/standby mode of an SCTP association between = different nodes/memories. This would help for instance 5*9 call control nodes = where an SCTP endpoint can be a single point of failure. Alternative is transaction/re-establish/.. at application level on top. UDP enables some level of tranport layer transparency between active = and standy endpoints by performing on the standby node and aliasing of the failed node IP at failover time. Nevertheless, the app. have to deal = with lost data... This *aliasing* is much more complex with a TCP or SCTP transport as = many complex states are maintained by the transport endpoints.=20 In SS7, the MTP3/SCCP internal states are classified into transients = which can be loss during an active/standby failover and persistants which = have to be checkpointed between the active and the standby SS7 nodes. This sub-division makes SS7 active/standby do-able.=20 Such transport active/standby mechanism might help for the app. which = would have to deal with their own states and not with the transport layer redundancy issues. Jean-Marc Fenart MIR 212bis Nortel Networks Tel (33) 1 39 44-55 08 (ESN 579) Fax (33) 1 39 44-50 04 (ESN 579) email:jmfenart@nortelnetworks.com -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: lundi 24 f=E9vrier 2003 10:20 To: Mudhafar Hassan-Ali Cc: tsvwg@ietf.org; Scott Bradner; Allison Mankin; floyd@icir.org; vern@icir.org Subject: Re: [Tsvwg] Redundant TCP connection Mudhafar, Have you looked at SCTP? Its multi-homed feature will do what you = want. --brian On Fri, 21 Feb 2003, Mudhafar Hassan-Ali wrote: > All, >=20 > I am wondering if any one is aware of the feasibility in practice to > make a redundant TCP connection? This type of connection is needed in = a > redundant system. In such system (call it X), there are two sides, an > active one and a standby one. Let's say the active one has a TCP > connection with a piece of equipment Y somewhere in the network. At = some > point, the active fails, which will lead to a protection switch. This > event will disrupt the TCP connection, which means Y will close its > connection, and the second side of X need to open the connection = also. > However, my goal is not to disrupt the connection during the side > switch. So the question is: Is it feasible to make a redundant TCP > connection, such that the two sides somehow are synchronized (what = are > the parameters needed?). So for a given TCP/IP stack, how feasible = and > practical to do that? >=20 > Any feedback is highly appreciated. >=20 > Best regards, > Mudhafar Hassan-Ali > Wireline Access > Alcatel >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the = =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in = =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. = =A6 =A6 Therefore all progress depends on the = =A6 =A6 unreasonable man. -- George Bernard Shaw = =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg ------_=_NextPart_001_01C2DBF3.BA07B1BC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Tsvwg] Redundant TCP connection

As far as I undertand SCTP multi-homing is dealing = more with transport links redundancy, e.g. multiple links to the same = node.

An issue is the active/standby mode of an SCTP = association between different nodes/memories. This would help for = instance 5*9 call control nodes where an SCTP endpoint can be a single = point of failure. Alternative is transaction/re-establish/.. at = application level on top.

UDP enables some level of tranport layer transparency = between active and standy endpoints by performing on the standby node = and aliasing of the failed node IP at failover time. Nevertheless, the = app. have to deal with lost data...

This *aliasing* is much more complex with a TCP or = SCTP transport as many complex states are maintained by the transport = endpoints.

In SS7, the MTP3/SCCP internal states are classified = into transients which can be loss during an active/standby failover and = persistants which have to be checkpointed between the active and the = standby SS7 nodes. This sub-division makes SS7 active/standby do-able. =

Such transport active/standby mechanism might help = for the app. which would have to deal with their own states and not = with the transport layer redundancy issues.

Jean-Marc Fenart
MIR 212bis
Nortel Networks
Tel  (33) 1 39 44-55 08 (ESN 579)
Fax (33) 1 39 44-50 04 (ESN 579)
email:jmfenart@nortelnetworks.com

-----Original Message-----
From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]
Sent: lundi 24 f=E9vrier 2003 10:20
To: Mudhafar Hassan-Ali
Cc: tsvwg@ietf.org; Scott Bradner; Allison Mankin; = floyd@icir.org;
vern@icir.org
Subject: Re: [Tsvwg] Redundant TCP connection


Mudhafar,

Have you looked at SCTP?  Its multi-homed = feature will do what you want.

--brian

On Fri, 21 Feb 2003, Mudhafar Hassan-Ali = wrote:

> All,
>
> I am wondering if any one is aware of the = feasibility in practice to
> make a redundant TCP connection? This type of = connection is needed in a
> redundant system. In such system (call it X), = there are two sides, an
> active one and a standby one. Let's say the = active one has a TCP
> connection with a piece of equipment Y = somewhere in the network. At some
> point, the active fails, which will lead to a = protection switch. This
> event will disrupt the TCP connection, which = means Y will close its
> connection, and the second side of X need to = open the connection also.
> However, my goal is not to disrupt the = connection during the side
> switch. So the question is: Is it feasible to = make a redundant TCP
> connection, such that the two sides somehow are = synchronized (what are
> the parameters needed?). So for a given TCP/IP = stack, how feasible and
> practical to do that?
>
> Any feedback is highly appreciated.
>
> Best regards,
> Mudhafar Hassan-Ali
> Wireline Access
> Alcatel
>
> = _______________________________________________
> tsvwg mailing list
> tsvwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/tsvwg

--
Brian F. G. Bidulock    =A6 The = reasonable man adapts himself to the =A6
bidulock@openss7.org    =A6 world; = the unreasonable one persists in  =A6
http://www.openss7.org/ =A6 trying  to adapt = the  world  to himself. =A6
          &nb= sp;           &nb= sp; =A6 Therefore  all  progress  depends on the = =A6
          &nb= sp;           &nb= sp; =A6 unreasonable man. -- George Bernard Shaw =A6
_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg

------_=_NextPart_001_01C2DBF3.BA07B1BC-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Feb 24 07:19:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10875 for ; Mon, 24 Feb 2003 07:19:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OCSFx20837 for tsvwg-archive@odin.ietf.org; Mon, 24 Feb 2003 07:28:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OCRRp20786; Mon, 24 Feb 2003 07:27:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OCQZp20737 for ; Mon, 24 Feb 2003 07:26:35 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10702 for ; Mon, 24 Feb 2003 07:17:32 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:fWjsEUtYwpZOwlXY6fmbWfB0xjY3KhCx@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h1OCLID30212; Mon, 24 Feb 2003 05:21:18 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h1OCLHR16530; Mon, 24 Feb 2003 05:21:17 -0700 Date: Mon, 24 Feb 2003 05:21:17 -0700 From: "Brian F. G. Bidulock" To: Jean-Marc Fenart Cc: Mudhafar Hassan-Ali , tsvwg@ietf.org, Scott Bradner , Allison Mankin , floyd@icir.org, vern@icir.org Subject: Re: [Tsvwg] Redundant TCP connection Message-ID: <20030224052117.A16375@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jmfenart@nortelnetworks.com on Mon, Feb 24, 2003 at 11:58:56AM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Jean-Marc, On Mon, 24 Feb 2003, Jean-Marc Fenart wrote: > > As far as I undertand SCTP multi-homing is dealing more with transport > links redundancy, e.g. multiple links to the same node. > > An issue is the active/standby mode of an SCTP association between > different nodes/memories. This would help for instance 5*9 call > control nodes where an SCTP endpoint can be a single point of failure. > Alternative is transaction/re-establish/.. at application level on > top. > > UDP enables some level of tranport layer transparency between active > and standy endpoints by performing on the standby node and aliasing of > the failed node IP at failover time. Nevertheless, the app. have to > deal with lost data... > > This *aliasing* is much more complex with a TCP or SCTP transport as > many complex states are maintained by the transport endpoints. > > In SS7, the MTP3/SCCP internal states are classified into transients > which can be loss during an active/standby failover and persistants > which have to be checkpointed between the active and the standby SS7 > nodes. This sub-division makes SS7 active/standby do-able. For this see RFC 3332. > > Such transport active/standby mechanism might help for the app. which > would have to deal with their own states and not with the transport > layer redundancy issues. If you are interested in multiple hosts, see RSERPOOL. --brian > > Jean-Marc Fenart > MIR 212bis > Nortel Networks > Tel (33) 1 39 44-55 08 (ESN 579) > Fax (33) 1 39 44-50 04 (ESN 579) > email:jmfenart@nortelnetworks.com > > -----Original Message----- > From: Brian F. G. Bidulock [[1]mailto:bidulock@openss7.org] > Sent: lundi 24 février 2003 10:20 > To: Mudhafar Hassan-Ali > Cc: tsvwg@ietf.org; Scott Bradner; Allison Mankin; floyd@icir.org; > vern@icir.org > Subject: Re: [Tsvwg] Redundant TCP connection > > Mudhafar, > > Have you looked at SCTP? Its multi-homed feature will do what you > want. > > --brian > > On Fri, 21 Feb 2003, Mudhafar Hassan-Ali wrote: > > > All, > > > > I am wondering if any one is aware of the feasibility in practice to > > make a redundant TCP connection? This type of connection is needed > in a > > redundant system. In such system (call it X), there are two sides, > an > > active one and a standby one. Let's say the active one has a TCP > > connection with a piece of equipment Y somewhere in the network. At > some > > point, the active fails, which will lead to a protection switch. > This > > event will disrupt the TCP connection, which means Y will close its > > connection, and the second side of X need to open the connection > also. > > However, my goal is not to disrupt the connection during the side > > switch. So the question is: Is it feasible to make a redundant TCP > > connection, such that the two sides somehow are synchronized (what > are > > the parameters needed?). So for a given TCP/IP stack, how feasible > and > > practical to do that? > > > > Any feedback is highly appreciated. > > > > Best regards, > > Mudhafar Hassan-Ali > > Wireline Access > > Alcatel > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > [2]https://www1.ietf.org/mailman/listinfo/tsvwg > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > [3]http://www.openss7.org/ ¦ trying to adapt the world to himself. > ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > [4]https://www1.ietf.org/mailman/listinfo/tsvwg > > References > > 1. mailto:bidulock@openss7.org > 2. https://www1.ietf.org/mailman/listinfo/tsvwg > 3. http://www.openss7.org/ > 4. https://www1.ietf.org/mailman/listinfo/tsvwg -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Feb 24 08:01:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13045 for ; Mon, 24 Feb 2003 08:01:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ODA9324030 for tsvwg-archive@odin.ietf.org; Mon, 24 Feb 2003 08:10:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OD9pp23980; Mon, 24 Feb 2003 08:09:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OD7Op23822 for ; Mon, 24 Feb 2003 08:07:24 -0500 Received: from pop-4.dnv.wideopenwest.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12776 for ; Mon, 24 Feb 2003 07:58:22 -0500 (EST) Received: from thoth.ir.bbn.com (d53-203-209.clv.wideopenwest.com [64.53.209.203]) by pop-4.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h1ODCqT19805; Mon, 24 Feb 2003 07:12:52 -0600 Received: from thoth.ir.bbn.com (localhost [127.0.0.1]) by thoth.ir.bbn.com (8.12.6/8.12.6) with ESMTP id h1OD3Mv6014246; Mon, 24 Feb 2003 08:03:22 -0500 (EST) (envelope-from mallman@thoth.ir.bbn.com) Message-Id: <200302241303.h1OD3Mv6014246@thoth.ir.bbn.com> To: Liangping Ma From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tsvwg@ietf.org Subject: Re: [Tsvwg] Anyone know any statistical analysis of RTO algorithm? In-Reply-To: Organization: BBN Technologies/NASA GRC Song-of-the-Day: Ain't Even Done With the Night Date: Mon, 24 Feb 2003 08:03:22 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > Does anyone know if there is any rigorous statistical analysis of > TCP's Retransmission Timeout (RTO) algorithm? If there is, please > give me some references. Not exactly sure what you're looking for, but I'll flog... Mark Allman, Vern Paxson. On Estimating End-to-End Network Path Properties. ACM SIGCOMM, September 1999. http://roland.grc.nasa.gov/~mallman/papers/estimation.ps Hope that helps! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Feb 24 15:52:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26245 for ; Mon, 24 Feb 2003 15:52:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OL1Lj23419 for tsvwg-archive@odin.ietf.org; Mon, 24 Feb 2003 16:01:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OL0Op23304; Mon, 24 Feb 2003 16:00:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OKx7p23219 for ; Mon, 24 Feb 2003 15:59:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26159; Mon, 24 Feb 2003 15:49:54 -0500 (EST) Message-Id: <200302242049.PAA26159@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , tsvwg@ietf.org From: The IESG Date: Mon, 24 Feb 2003 15:49:54 -0500 Subject: [Tsvwg] Document Action: The Eifel Detection Algorithm for TCP to Experimental Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'The Eifel Detection Algorithm for TCP' as an Experimental RFC. This document is the product of the Transport Area Working Group Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Feb 24 21:25:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03246 for ; Mon, 24 Feb 2003 21:25:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1P2Y2s10357 for tsvwg-archive@odin.ietf.org; Mon, 24 Feb 2003 21:34:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P2Wup10320; Mon, 24 Feb 2003 21:32:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P2Vbp10295 for ; Mon, 24 Feb 2003 21:31:37 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03213 for ; Mon, 24 Feb 2003 21:22:17 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h1P2Pqm6001674 for ; Mon, 24 Feb 2003 19:25:52 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id TAA24210 for ; Mon, 24 Feb 2003 19:26:10 -0700 (MST)] Received: from Motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id WD6NN8GS; Mon, 24 Feb 2003 20:26:10 -0600 Message-ID: <3E5AD183.F250D818@Motorola.com> Date: Mon, 24 Feb 2003 20:14:27 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kacheong Poon CC: cait@asomi.com, tsvwg@ietf.org, sctp-impl@external.cisco.com Subject: Re: [Tsvwg] A question of Un-Ordered SCTP References: <200302170927.DAA13013@parmesan.cs.wisc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I fully agree with Kacheong's assessment that adding the 2nd sequence number to SCTP would constitute a *protocol* change. It would basically alter the semantics of an existing SCTP parameter. If we do that, I don't think anyone knows for sure which existing implementations would be broken and which wouldn't. It would also create a dangerous precedence; if we alter the protocol for the sake of this ULP, there might be many more down the road with a similar "minor" request to change SCTP. Moreover, from a coder's viewpoint, the change may be very easy to make (a couple of lines), but to some one who has already had the old implementation widely deployed (or worse, embedded in some widely sold applications), the cost of upgrading/replacing the stack could be huge. We want to people to think SCTP is stable. Changes of this nature, if easily allowed, would shake people's believe that SCTP is stable and make them wonder if their investment in implementing and deploying SCTP is going to be wasted. Let the ULP have the 2nd sequence number is a better idea, IMO. -Qiaobing Kacheong Poon wrote: > > Included message from Caitlin Bestler : > > >---- > >So, trying to work with SCTP on SCTP's terms, you have three > >possible strategies: > > > >-- Include a SSN-equivalent in the Data Chunk. > > > >-- Allow out-of-order placement of ordered Data chunks. > > > >-- Make SCTP's SSN meaningful for unordered delivery. > > > >The pure ULP solution obviously has the least impact on > >the SCTP layer. But it smacks of having the ULP duplicate > >functionality that rightfully belongs at the transport > >layer. I believe the quick consenseus is that sequenced > >unordered delivery is a natural concept that has value > >beyond any single ULP. > > I don't think that the above functionality "rightfully > belongs to the transport layer (SCTP in this case)." To > me, the unordered delivery mechanism as specified in RFC > 2960 simply means that such data chunks can be delivered > in whatever order the receiver wants. This also > automatically means that the sender can send such chunks > in whatever order it wants if it deems necessary. For > example, an implementation can choose to place a smaller > unordered data chunk ahead in the send queue before a bigger > unordered data chunk. Assuming that the SSN is assigned > when data chunk is sent, to make the suggested change > to RFC 2960 to an implementation may mean more than what > has been discussed. And it is really a protocol change, > not just implementation's choice of how to generate > "arbitrary numbers" to be put in the SSN field of unordered > chunk as it actually places extra restrictions on how an > implementation handled such chunks as described above. > > The SSN in SCTP is designed to be used for order of > delivery by SCTP, that's why it is ignored for unordered > delivery. If an ULP wants to have ordered delivery, don't use > this feature of SCTP. If an ULP wants unordered delivery, but > it still wants to know the sender's sending order, just place > its own sequence number. Overloading the SSN in SCTP, even > if it is assigned by SCTP, not by ULP, is really a bad design > choice. > > Anyway, just my $0.02. BTW, I also cc the SCTP > implementors' list. I believe people there should > be aware of such things. I don't know why that list > was removed from the cc list... > > >---- > > K. Poon. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 25 07:39:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27990 for ; Tue, 25 Feb 2003 07:39:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PCmui25663 for tsvwg-archive@odin.ietf.org; Tue, 25 Feb 2003 07:48:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PCmdp25629; Tue, 25 Feb 2003 07:48:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PClfp25571 for ; Tue, 25 Feb 2003 07:47:41 -0500 Received: from pop-4.dnv.wideopenwest.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27845 for ; Tue, 25 Feb 2003 07:38:10 -0500 (EST) Received: from thoth.ir.bbn.com (d53-203-209.clv.wideopenwest.com [64.53.209.203]) by pop-4.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h1PCr8T02880 for ; Tue, 25 Feb 2003 06:53:08 -0600 Received: from thoth.ir.bbn.com (localhost [127.0.0.1]) by thoth.ir.bbn.com (8.12.6/8.12.6) with ESMTP id h1PCh5v6022837 for ; Tue, 25 Feb 2003 07:43:05 -0500 (EST) (envelope-from mallman@thoth.ir.bbn.com) Message-Id: <200302251243.h1PCh5v6022837@thoth.ir.bbn.com> To: tsvwg@ietf.org From: Mark Allman Reply-To: mallman@grc.nasa.gov Organization: BBN Technologies/NASA GRC Song-of-the-Day: Ticket to Ride Date: Tue, 25 Feb 2003 07:43:05 -0500 Subject: [Tsvwg] early retransmit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Folks- In December the Early Retransmit (ER) scheme that was originally coupled with Limited Transmit (LT) (RFC 3042) received some discussion on the list. When doing limited transmit we decoupled it from early retransmit because we had clear consensus for LT but not the story was somewhat rockier for ER (which does not mean that we had consensus *against* ER -- just that it was clear that if left coupled ER would have held LT back). In any case, there seemed to be some positive vibes for ER in Decemeber and so a few of us dusted off the old text, updated it and released it again. The id will appear in the archives shortly, but until then you can grab it form the URL below... Mark Allman, Konstantin Avrachenkov, Urtzi Ayesta, Josh Blanton. Early Retransmit for TCP, February 2003. Internet-Draft draft-allman-tcp-early-rexmt-00.txt (work in progress). http://roland.grc.nasa.gov/~mallman/papers/draft-allman-tcp-early-rexmt-00.txt We'd love to see feedback in a couple of areas... (1) Is early retransmit, as specified, ever a good idea? (That is, should we stop now? is it just fundementally busted?) (2) The draft details a couple of scenarios in which reordering coupled with ER could cause a significant fraction (1/3) of traffic to be spurious. We wonder if these scenarios are a big concern? Or, are the probabilities low enough that we shouldn't worry about adding a bunch of complexity to deal with them? (3) If we should deal with these cases with some algorithmic mechanism, what should we use? We have a bunch of possible schemes sketched in the appendix. Should we mandate one of these? Or, something else? Of course, any other feedback is always welcome. Thanks! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 25 13:13:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09206 for ; Tue, 25 Feb 2003 13:13:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PIMWC19028 for tsvwg-archive@odin.ietf.org; Tue, 25 Feb 2003 13:22:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PIMAp19018; Tue, 25 Feb 2003 13:22:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PIKup18907 for ; Tue, 25 Feb 2003 13:20:56 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09091 for ; Tue, 25 Feb 2003 13:11:19 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 961389E67; Tue, 25 Feb 2003 13:15:12 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id C0FF19E67; Tue, 25 Feb 2003 13:15:10 -0500 (EST) Date: Tue, 25 Feb 2003 13:15:10 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Mark Allman Cc: Subject: Re: [Tsvwg] early retransmit In-Reply-To: <200302251243.h1PCh5v6022837@thoth.ir.bbn.com> Message-ID: X-Spam-Status: No, hits=-23.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Mark, I have a few comments on the draft (and the topic in general)... The draft says: "Research shows that a general reduction in the number of duplicate ACKs required to trigger fast retransmission of a segment to two (rather than three) leads to a reduction in the ratio of good to bad retransmits by a factor of three [Pax97]. However, this analysis did not include the additional conditioning on the event that the ownd was smaller than 4 segments." I don't see how the condition of ownd < 4 segments matters. If 3 dupacks is more appropriate to due the amount of reordering, then less than 3 isn't appropriate regardless of ownd. I prefer solutions which induce the possibility of 3 dupacks (or 4 missing reports for SCTP). Hari Balakrishnan's solution of sending zero-byte segments and Marco Mellia et al.'s solution of breaking segments into smaller pieces are two ideas which I think deserve more attention. Although these mechanisms may add _some_ load to the network, I think more research is needed with these type of solutions. I also think that more research is needed to determine what dupack threshold is appropriate. It may be worthwhile to investigate the use of a mechanism which begins with a conservative threshold, and then gets adjusted over time. To start, DSACKs/Eifel/etc may be useful for increasing the threshold. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 On Tue, 25 Feb 2003, Mark Allman wrote: > > Folks- > > In December the Early Retransmit (ER) scheme that was originally > coupled with Limited Transmit (LT) (RFC 3042) received some > discussion on the list. When doing limited transmit we decoupled it > from early retransmit because we had clear consensus for LT but not > the story was somewhat rockier for ER (which does not mean that we > had consensus *against* ER -- just that it was clear that if left > coupled ER would have held LT back). > > In any case, there seemed to be some positive vibes for ER in > Decemeber and so a few of us dusted off the old text, updated it and > released it again. The id will appear in the archives shortly, but > until then you can grab it form the URL below... > > Mark Allman, Konstantin Avrachenkov, Urtzi Ayesta, Josh > Blanton. Early Retransmit for TCP, February 2003. Internet-Draft > draft-allman-tcp-early-rexmt-00.txt (work in progress). > http://roland.grc.nasa.gov/~mallman/papers/draft-allman-tcp-early-rexmt-00.txt > > We'd love to see feedback in a couple of areas... > > (1) Is early retransmit, as specified, ever a good idea? (That is, > should we stop now? is it just fundementally busted?) > > (2) The draft details a couple of scenarios in which reordering > coupled with ER could cause a significant fraction (1/3) of > traffic to be spurious. We wonder if these scenarios are a big > concern? Or, are the probabilities low enough that we shouldn't > worry about adding a bunch of complexity to deal with them? > > (3) If we should deal with these cases with some algorithmic > mechanism, what should we use? We have a bunch of possible > schemes sketched in the appendix. Should we mandate one of > these? Or, something else? > > Of course, any other feedback is always welcome. > > Thanks! > > allman > > > -- > Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 25 13:29:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09726 for ; Tue, 25 Feb 2003 13:29:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PIcjM20529 for tsvwg-archive@odin.ietf.org; Tue, 25 Feb 2003 13:38:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PIcDp20510; Tue, 25 Feb 2003 13:38:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PIbwp20476 for ; Tue, 25 Feb 2003 13:37:58 -0500 Received: from localhost.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09697 for ; Tue, 25 Feb 2003 13:28:20 -0500 (EST) Received: (from elb@localhost) by localhost.localdomain (8.11.6/8.11.6) id h1PIVlK16882; Tue, 25 Feb 2003 13:31:47 -0500 Date: Tue, 25 Feb 2003 13:31:47 -0500 From: Ethan Blanton To: "Armando L. Caro Jr." Cc: Mark Allman , tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit Message-ID: <20030225183147.GG26478@paco.resnet.purdue.edu> Mail-Followup-To: "Armando L. Caro Jr." , Mark Allman , tsvwg@ietf.org References: <200302251243.h1PCh5v6022837@thoth.ir.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Armando L. Caro Jr. spake unto us the following wisdom: > "Research shows that a general reduction in > the number of duplicate ACKs required to trigger fast retransmission > of a segment to two (rather than three) leads to a reduction in the > ratio of good to bad retransmits by a factor of three [Pax97]. > However, this analysis did not include the additional conditioning > on the event that the ownd was smaller than 4 segments." > > I don't see how the condition of ownd < 4 segments matters. If 3 dupacks > is more appropriate to due the amount of reordering, then less than 3 > isn't appropriate regardless of ownd. It may be slightly aggressive, but if it is effective at helping to avoid RTOs and doesn't cause "too many" needless retransmits, I think it's worth playing with. > I prefer solutions which induce the possibility of 3 dupacks (or 4 missing > reports for SCTP). Hari Balakrishnan's solution of sending zero-byte > segments and Marco Mellia et al.'s solution of breaking segments into > smaller pieces are two ideas which I think deserve more attention. > Although these mechanisms may add _some_ load to the network, I think more > research is needed with these type of solutions. Going on the (common, I think) that load is mostly per-packet rather than per-byte, it seems to me that retransmitting on two dupacks (or whatever) could in some cases cause less "needless" traffic, even if it blows it sometimes and retransmits unnecessarily, than indiscriminately sending some extra packets in every window. I'm not saying these other methods don't have merit, or that they should not be researched -- I think they should. But I would say that their existence does not preclude the usefulness of trying and evaluating early retransmit, and especially comparisons between the various methods' virtues and disadvantages. Ethan _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 25 13:38:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09975 for ; Tue, 25 Feb 2003 13:38:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PIlU220879 for tsvwg-archive@odin.ietf.org; Tue, 25 Feb 2003 13:47:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PIlBp20868; Tue, 25 Feb 2003 13:47:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PIkfp20848 for ; Tue, 25 Feb 2003 13:46:41 -0500 Received: from seraph3.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09960 for ; Tue, 25 Feb 2003 13:37:03 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 72E9E6B9E1 for ; Tue, 25 Feb 2003 13:40:56 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id h1PIetsW029315; Tue, 25 Feb 2003 13:40:55 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id NAA46221; Tue, 25 Feb 2003 13:40:55 -0500 (EST) Message-Id: <200302251840.NAA46221@guns.lerc.nasa.gov> To: "Armando L. Caro Jr." From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit In-Reply-To: Organization: BBN Technologies/NASA GRC Song-of-the-Day: Jailhouse Rock Date: Tue, 25 Feb 2003 13:40:55 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > "Research shows that a general reduction in > the number of duplicate ACKs required to trigger fast retransmission > of a segment to two (rather than three) leads to a reduction in the > ratio of good to bad retransmits by a factor of three [Pax97]. > However, this analysis did not include the additional conditioning > on the event that the ownd was smaller than 4 segments." > > I don't see how the condition of ownd < 4 segments matters. If 3 > dupacks is more appropriate to due the amount of reordering, then > less than 3 isn't appropriate regardless of ownd. Unless the pattern of reordering a connection experiences is effected by the amount of load that connection is placing on the network. The Bennett, Partridge, et. al. study on reordering (ToN, 12/1999) suggests that reordering and congestion are linked (but, I do not think they analyzed that correlation at the connection level). Maybe all that needs stated a bit better. But, I think the point is still valid. (And, you might be right... my point is really that we don't know.) > I prefer solutions which induce the possibility of 3 dupacks (or 4 > missing reports for SCTP). Well, that is best. I like limited transmit. And, you'll note that this ID is for the case when you don't have new data to send. But, you knew that because... > Hari Balakrishnan's solution of sending zero-byte segments and So, I'd be interested in hearing from people who understand these sorts of things... Given that I am going to form up a packet and send it across a network path, what is the marginal cost of adding data to that packet? I.e., what is the delta in effort between a zero byte packet and a full packet? (I realize that this is likely hard to quantify in any sort of general way. But, is it "a lot more effort" or "not much more effort" or what?) My gut says that in the general case we might as well dump data into the packet. > Marco Mellia et al.'s solution of breaking segments into smaller > pieces are two ideas which I think deserve more attention. > Although these mechanisms may add _some_ load to the network, I > think more research is needed with these type of solutions. I agree that more research is needed. No doubt. But, it comes down to a question of what is the unit that matters. Is it the number of bytes I throw into the network or the number of packets I inject? (And, yes, I am sure the answer is "both". ;) I think early retransmit sounds like a fine idea. Digging a little deeper into one of my questions of this morning... What sorts of limitations should we place on the use of ER? I think a possible approach is to say that you should use DSACK or Eifel or something in conjunction with ER to detect the cases when ER retransmitted spuriously. And, if you figure that out then you have to stop using ER. > I also think that more research is needed to determine what dupack > threshold is appropriate. It may be worthwhile to investigate the > use of a mechanism which begins with a conservative threshold, and > then gets adjusted over time. To start, DSACKs/Eifel/etc may be > useful for increasing the threshold. Ethan Blanton, Mark Allman. On Making TCP More Robust to Packet Reordering. ACM Computer Communication Review, 32(1), January 2002. http://roland.grc.nasa.gov/~mallman/papers/tcp-reorder-ccr.ps Ethan Blanton, Robert Dimond, Mark Allman. Practices for TCP Senders in the Face of Segment Reordering, February 2003. Internet-Draft draft-blanton-tcp-reordering-00.txt (work in progress). Ming Zhang, Brad Karp, Sally Floyd, and Larry Peterson. RR-TCP: A Reordering-Robust TCP with DSACK, ICSI Technical Report TR-02-006, Berkeley, CA, July 2002. http://www.icir.org/bkarp/reordering-TR.ps.gz I am sure others, too. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 25 14:07:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11032 for ; Tue, 25 Feb 2003 14:07:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PJGVj22761 for tsvwg-archive@odin.ietf.org; Tue, 25 Feb 2003 14:16:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJGBp22752; Tue, 25 Feb 2003 14:16:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJFSp22726 for ; Tue, 25 Feb 2003 14:15:28 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10938 for ; Tue, 25 Feb 2003 14:05:48 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h1PJ9Wmi000568; Tue, 25 Feb 2003 13:09:32 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E5BBF6C.50003@stewart.chicago.il.us> Date: Tue, 25 Feb 2003 13:09:32 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@grc.nasa.gov CC: "Armando L. Caro Jr." , tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit References: <200302251840.NAA46221@guns.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mark Allman wrote: >> "Research shows that a general reduction in >> the number of duplicate ACKs required to trigger fast retransmission >> of a segment to two (rather than three) leads to a reduction in the >> ratio of good to bad retransmits by a factor of three [Pax97]. >> However, this analysis did not include the additional conditioning >> on the event that the ownd was smaller than 4 segments." >> >>I don't see how the condition of ownd < 4 segments matters. If 3 >>dupacks is more appropriate to due the amount of reordering, then >>less than 3 isn't appropriate regardless of ownd. > I had this same sort of thought as well.. I just could not see the connection between ownd < 4... > > Unless the pattern of reordering a connection experiences is > effected by the amount of load that connection is placing on the > network. The Bennett, Partridge, et. al. study on reordering (ToN, > 12/1999) suggests that reordering and congestion are linked (but, I > do not think they analyzed that correlation at the connection > level). > > Maybe all that needs stated a bit better. But, I think the point is > still valid. (And, you might be right... my point is really that we > don't know.) > > >>I prefer solutions which induce the possibility of 3 dupacks (or 4 >>missing reports for SCTP). > > > Well, that is best. I like limited transmit. And, you'll note that > this ID is for the case when you don't have new data to send. But, > you knew that because... > Yes, when you have enough data in the pipe things are fine.. its for these cases where you don't that a problem arises.. in my recent testing I have seen this A LOT in trailing packets in my simulated satellite network... you end up always taking a RTO if its in the last 2 or 3 packets that the drop occurs... something not all that uncommon when you are looking at 2-6% error rates...surprisingly... I also have seen this a lot when you approach the peer rwnd limit and thus stop sending again.. I think in all my recent work almost all the RTO drops were this form.. rwnd full & drop in last few packets OR trailing edge of a transfer.... > >>Hari Balakrishnan's solution of sending zero-byte segments and > > This does not help an SCTP case.. since you are not allowed to send a data segment with zero bytes... I like using the DSACK info (since SCTP has it :>) and combine this with a limit on reducing your limit once for some time say a RTT (only when you are in this state.. no data to send)... > So, I'd be interested in hearing from people who understand these > sorts of things... Given that I am going to form up a packet and > send it across a network path, what is the marginal cost of adding > data to that packet? I.e., what is the delta in effort between a > zero byte packet and a full packet? (I realize that this is likely > hard to quantify in any sort of general way. But, is it "a lot more > effort" or "not much more effort" or what?) > > My gut says that in the general case we might as well dump data into > the packet. > Well, I am NOT an expert but I have been digging a bit deeper into one of the Routers that is in the I-net.. and I don't really think it makes that much difference if the packet is 50 bytes or 1500 bytes.. you still have all of the internal structures you must use in moving the packet through the router... often times these are optimized to fit a full MTU depending of course on how the packet is being switched through the router... sometimes you can get by with smaller pieces...depending on the type of forwarding that is going on of course... It would be worth doing a little lab work to see if you route N fulls size segments through a network and contrast that with N small segments.. does it make a huge difference... There will be some.. but I don't know how much... Maybe when I get a few cycles (don't hold your breath :-0) I will set something up...I am interested in knowing this little gem.. for at least one of the routers that is out in the world :-) > >>Marco Mellia et al.'s solution of breaking segments into smaller >>pieces are two ideas which I think deserve more attention. >>Although these mechanisms may add _some_ load to the network, I >>think more research is needed with these type of solutions. > > > I agree that more research is needed. No doubt. > Yep... it still needs to be baked a bit... > But, it comes down to a question of what is the unit that matters. > Is it the number of bytes I throw into the network or the number of > packets I inject? (And, yes, I am sure the answer is "both". ;) > > I think early retransmit sounds like a fine idea. Digging a little > deeper into one of my questions of this morning... What sorts of > limitations should we place on the use of ER? I think a possible > approach is to say that you should use DSACK or Eifel or something > in conjunction with ER to detect the cases when ER retransmitted > spuriously. And, if you figure that out then you have to stop using > ER. I like DSACK myself (as I said above :>) R > > >>I also think that more research is needed to determine what dupack >>threshold is appropriate. It may be worthwhile to investigate the >>use of a mechanism which begins with a conservative threshold, and >>then gets adjusted over time. To start, DSACKs/Eifel/etc may be >>useful for increasing the threshold. > > > Ethan Blanton, Mark Allman. On Making TCP More Robust to Packet > Reordering. ACM Computer Communication Review, 32(1), January > 2002. > http://roland.grc.nasa.gov/~mallman/papers/tcp-reorder-ccr.ps > > Ethan Blanton, Robert Dimond, Mark Allman. Practices for TCP > Senders in the Face of Segment Reordering, February > 2003. Internet-Draft draft-blanton-tcp-reordering-00.txt (work > in progress). > > Ming Zhang, Brad Karp, Sally Floyd, and Larry Peterson. RR-TCP: > A Reordering-Robust TCP with DSACK, ICSI Technical Report > TR-02-006, Berkeley, CA, July 2002. > http://www.icir.org/bkarp/reordering-TR.ps.gz > > I am sure others, too. > > allman > > > -- > Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 25 14:12:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11203 for ; Tue, 25 Feb 2003 14:12:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PJLXg23031 for tsvwg-archive@odin.ietf.org; Tue, 25 Feb 2003 14:21:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJL6p22993; Tue, 25 Feb 2003 14:21:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJKKp22947 for ; Tue, 25 Feb 2003 14:20:20 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11150 for ; Tue, 25 Feb 2003 14:10:41 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 0C89D9DA1; Tue, 25 Feb 2003 14:14:31 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 9ADE09D9F; Tue, 25 Feb 2003 14:14:29 -0500 (EST) Date: Tue, 25 Feb 2003 14:14:29 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Mark Allman Cc: Subject: Re: [Tsvwg] early retransmit In-Reply-To: <200302251840.NAA46221@guns.lerc.nasa.gov> Message-ID: X-Spam-Status: No, hits=-23.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Tue, 25 Feb 2003, Mark Allman wrote: > I think early retransmit sounds like a fine idea. I don't have a problem with exploring this idea... I was just showing my preference :-) Is this draft being pushed as "experimental"? > Digging a little deeper into one of my questions of this morning... > What sorts of limitations should we place on the use of ER? I think a > possible approach is to say that you should use DSACK or Eifel or > something in conjunction with ER to detect the cases when ER > retransmitted spuriously. And, if you figure that out then you have > to stop using ER. Yeah, I like this idea. In the draft, you also mention the possibility of limiting a connection to only one early rtx. I think that this limitation is too restrictive. Application-limited connections may need multiple early rtxs. I think that if early rtxs are done at all, then they should be allowed until the sender detects a problem in doing so... possibly using the approach you describe above with DSACK/Eifel. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 25 14:24:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11497 for ; Tue, 25 Feb 2003 14:24:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PJXhD23584 for tsvwg-archive@odin.ietf.org; Tue, 25 Feb 2003 14:33:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJXIp23571; Tue, 25 Feb 2003 14:33:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJWcp23541 for ; Tue, 25 Feb 2003 14:32:38 -0500 Received: from maestra.inria.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11486 for ; Tue, 25 Feb 2003 14:22:58 -0500 (EST) Received: from sophia.inria.fr (localhost [127.0.0.1]) by maestra.inria.fr (8.12.5/8.12.5) with ESMTP id h1PJQp5f006531 for ; Tue, 25 Feb 2003 20:26:51 +0100 X-Authentication-Warning: maestra.inria.fr: Host localhost [127.0.0.1] claimed to be sophia.inria.fr Message-ID: <3E5BC37B.0@sophia.inria.fr> Date: Tue, 25 Feb 2003 20:26:51 +0100 From: Urtzi Ayesta User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203 X-Accept-Language: fr-FR, en, eu, es-ES MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello all, >I also think that more research is needed to determine what dupack >threshold is appropriate. It may be worthwhile to investigate the use of >a mechanism which begins with a conservative threshold, and then gets >adjusted over time. To start, DSACKs/Eifel/etc may be useful for >increasing the threshold. > > That would be ideal, but short connections don't have time to determine which dupack is appropriate and experiencing a timeout has a dramatic impact on their transfer time. Early retransmission may reduce the timeout incidence at the cost of unnecessary retransmissions. To limit the number of unnecessary retransmission one could think of using ER at most once (as suggested in the appendix). This would still permit short connections to recover more effectively from a loss. >I don't see how the condition of ownd < 4 segments matters. If 3 dupacks >is more appropriate to due the amount of reordering, then less than 3 >isn't appropriate regardless of ownd. > it matters, if you only reduce the number of duplicate ACKS when ownd < 4, then the result found by Pax97 is not valid anymore. One would expect a smaller reduction on the ratio. >I prefer solutions which induce the possibility of 3 dupacks (or 4 missing >reports for SCTP). Hari Balakrishnan's solution of sending zero-byte >segments and Marco Mellia et al.'s solution of breaking segments into >smaller pieces are two ideas which I think deserve more attention. >Although these mechanisms may add _some_ load to the network, I think more >research is needed with these type of solutions. > > Solutions to induce the reception 3 dupacks may increase the number of segments sistematically, whereas ER proposes to retransmit early only in situations where the sender will inevitably timeout if a packet has been indeed lost. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 25 14:27:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11585 for ; Tue, 25 Feb 2003 14:27:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PJaOL23756 for tsvwg-archive@odin.ietf.org; Tue, 25 Feb 2003 14:36:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJa4p23745; Tue, 25 Feb 2003 14:36:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJZnp23708 for ; Tue, 25 Feb 2003 14:35:49 -0500 Received: from maestra.inria.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11557 for ; Tue, 25 Feb 2003 14:26:10 -0500 (EST) Received: from sophia.inria.fr (localhost [127.0.0.1]) by maestra.inria.fr (8.12.5/8.12.5) with ESMTP id h1PJU15f006543; Tue, 25 Feb 2003 20:30:01 +0100 X-Authentication-Warning: maestra.inria.fr: Host localhost [127.0.0.1] claimed to be sophia.inria.fr Message-ID: <3E5BC439.701@sophia.inria.fr> Date: Tue, 25 Feb 2003 20:30:01 +0100 From: Urtzi Ayesta User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203 X-Accept-Language: fr-FR, en, eu, es-ES MIME-Version: 1.0 To: Randall Stewart CC: tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit References: <200302251840.NAA46221@guns.lerc.nasa.gov> <3E5BBF6C.50003@stewart.chicago.il.us> In-Reply-To: <3E5BBF6C.50003@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > Yes, when you have enough data in the pipe things are fine.. its > for these cases where you don't that a problem arises.. in my > recent testing I have seen this A LOT in trailing packets in > my simulated satellite network... you end up always taking > a RTO if its in the last 2 or 3 packets that the drop occurs... > something not all that uncommon when you are looking at > 2-6% error rates...surprisingly... I also have seen > this a lot when you approach the peer rwnd limit and > thus stop sending again.. > > I think in all my recent work almost all the RTO drops > were this form.. rwnd full & drop in last few packets OR > trailing edge of a transfer.... In fact, this particular scenario is one of the motivations for ER. urtzi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 25 14:31:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11758 for ; Tue, 25 Feb 2003 14:31:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PJeSA24760 for tsvwg-archive@odin.ietf.org; Tue, 25 Feb 2003 14:40:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJe9p24748; Tue, 25 Feb 2003 14:40:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJdqp24667 for ; Tue, 25 Feb 2003 14:39:52 -0500 Received: from seraph3.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11711 for ; Tue, 25 Feb 2003 14:30:13 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 21A2D6BA14 for ; Tue, 25 Feb 2003 14:34:07 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id h1PJY6sW013672; Tue, 25 Feb 2003 14:34:06 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id OAA46869; Tue, 25 Feb 2003 14:34:06 -0500 (EST) Message-Id: <200302251934.OAA46869@guns.lerc.nasa.gov> To: "Armando L. Caro Jr." From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit In-Reply-To: Organization: BBN Technologies/NASA GRC Song-of-the-Day: Jailhouse Rock Date: Tue, 25 Feb 2003 14:34:06 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > > I think early retransmit sounds like a fine idea. > > I don't have a problem with exploring this idea... I was just > showing my preference :-) And, I do not think you are alone. When we coupled ER and limited transmit we got the same sort of reaction---i.e., that limited transmit seemed nice and should go forward, but there was some reservation about ER. > Is this draft being pushed as "experimental"? ?? Without thinking about it or consulting with anyone (ADs, co-authors, etc.) I'd say that experimental sounds about right for the current state. Although, if we mandated use of some spurious rexmt detection to turn off ER or some some limit (like once/connection) then I think it should be PS. What harm would there be in practice? (The harm would be 1 bogus retransmit / connection. If the real world caused that to happen to every connection then I'd step back and say that it wasn't ready. But, I doubt that is the case.) Thanks! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 25 14:31:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11773 for ; Tue, 25 Feb 2003 14:31:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PJeUG24773 for tsvwg-archive@odin.ietf.org; Tue, 25 Feb 2003 14:40:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJe6p24733; Tue, 25 Feb 2003 14:40:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJdVp24600 for ; Tue, 25 Feb 2003 14:39:31 -0500 Received: from maestra.inria.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11684 for ; Tue, 25 Feb 2003 14:29:51 -0500 (EST) Received: from sophia.inria.fr (localhost [127.0.0.1]) by maestra.inria.fr (8.12.5/8.12.5) with ESMTP id h1PJXg5f006563; Tue, 25 Feb 2003 20:33:42 +0100 X-Authentication-Warning: maestra.inria.fr: Host localhost [127.0.0.1] claimed to be sophia.inria.fr Message-ID: <3E5BC516.4000604@sophia.inria.fr> Date: Tue, 25 Feb 2003 20:33:42 +0100 From: Urtzi Ayesta User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203 X-Accept-Language: fr-FR, en, eu, es-ES MIME-Version: 1.0 To: "Armando L. Caro Jr." CC: Mark Allman , tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > >In the draft, you also mention the possibility of limiting a connection to >only one early rtx. I think that this limitation is too restrictive. >Application-limited connections may need multiple early rtxs. I think that >if early rtxs are done at all, then they should be allowed until the >sender detects a problem in doing so... possibly using the approach you >describe above with DSACK/Eifel. > > > I agree. This sounds as a reasonable thing to do. There is no reason for long-lived connections to stop using ER if packets were indeed lost. urtzi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Feb 25 14:33:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11865 for ; Tue, 25 Feb 2003 14:33:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PJgSK24908 for tsvwg-archive@odin.ietf.org; Tue, 25 Feb 2003 14:42:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJg6p24887; Tue, 25 Feb 2003 14:42:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJfdp24829 for ; Tue, 25 Feb 2003 14:41:39 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11803 for ; Tue, 25 Feb 2003 14:31:53 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id E9DF19D9F; Tue, 25 Feb 2003 14:35:46 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 887F69DA1; Tue, 25 Feb 2003 14:35:45 -0500 (EST) Date: Tue, 25 Feb 2003 14:35:45 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Urtzi Ayesta Cc: Subject: Re: [Tsvwg] early retransmit In-Reply-To: <3E5BC37B.0@sophia.inria.fr> Message-ID: X-Spam-Status: No, hits=-23.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Tue, 25 Feb 2003, Urtzi Ayesta wrote: > Solutions to induce the reception 3 dupacks may increase the number of > segments sistematically, whereas ER proposes to retransmit early only > in situations where the sender will inevitably timeout if a packet has > been indeed lost. Yes, this point is valid... agreed. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 26 05:39:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00318 for ; Wed, 26 Feb 2003 05:39:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QAnES29626 for tsvwg-archive@odin.ietf.org; Wed, 26 Feb 2003 05:49:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QAmwp29574; Wed, 26 Feb 2003 05:48:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PMVCp04323 for ; Tue, 25 Feb 2003 17:31:12 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20081 for ; Tue, 25 Feb 2003 17:21:29 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 66BC39DA1; Tue, 25 Feb 2003 17:25:20 -0500 (EST) Received: from frink.ece.udel.edu (frink.ece.udel.edu [128.4.130.33]) by mail.eecis.udel.edu (Postfix) with ESMTP id BD2E79DAA for ; Tue, 25 Feb 2003 17:25:18 -0500 (EST) Date: Tue, 25 Feb 2003 17:25:18 -0500 (EST) From: Liangping Ma X-X-Sender: To: Message-ID: X-Spam-Status: No, hits=-19.8 required=6.0 tests=DEPT_RCVD,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Subject: [Tsvwg] references on RTT distribution Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Based on experiments, Mukherjee in 1994 reported that the Round-trip Time (RTT) along a certain Internet path follows a shifted Gamma distribution. But he did not give any theoretical explanation. Does anyone know if there is one proposed after 1994? If the answer is yes, please give me some references. Thanks! Liangping Ma _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 26 05:39:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00339 for ; Wed, 26 Feb 2003 05:39:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QAnHu29640 for tsvwg-archive@odin.ietf.org; Wed, 26 Feb 2003 05:49:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QAmxp29590; Wed, 26 Feb 2003 05:48:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PMatp04473 for ; Tue, 25 Feb 2003 17:36:55 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20155 for ; Tue, 25 Feb 2003 17:27:11 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id B6D759D97; Tue, 25 Feb 2003 17:31:06 -0500 (EST) Received: from frink.ece.udel.edu (frink.ece.udel.edu [128.4.130.33]) by mail.eecis.udel.edu (Postfix) with ESMTP id 84A9F9D87 for ; Tue, 25 Feb 2003 17:31:05 -0500 (EST) Date: Tue, 25 Feb 2003 17:31:05 -0500 (EST) From: Liangping Ma X-X-Sender: To: Message-ID: X-Spam-Status: No, hits=-19.8 required=6.0 tests=DEPT_RCVD,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Subject: [Tsvwg] references on RTT distribution (expanded) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Based on experiments, Mukherjee in 1994 reported that the Round-trip Time (RTT) along a certain Internet path follows a shifted Gamma distribution. But he did not give any theoretical explanation. Does anyone know if there is one proposed after 1994? If the answer is yes, please give me some references. Thanks! Mukherjee's results are in "On the dynamics and significance of low frequency components of Internet load", A. Mukherjee, December 1994, Internetworking: Research and Experience, Vol.5, pp. 163-205. And they are also mentioned in Vern Paxson's "End-to-End Internet Packet Dynamics", ACM SIGCOMM, Sep. 1997. Liangping Ma Sincerely yours, Liangping Ma _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Feb 26 06:25:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00316 for ; Wed, 26 Feb 2003 05:39:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QAnEf29613 for tsvwg-archive@odin.ietf.org; Wed, 26 Feb 2003 05:49:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QAmpp29551; Wed, 26 Feb 2003 05:48:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OFPep31974 for ; Mon, 24 Feb 2003 10:25:40 -0500 Received: from auds951.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16302 for ; Mon, 24 Feb 2003 10:16:34 -0500 (EST) Received: from morgoth.pet.usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.6/8.12.6) with ESMTP id h1OFKHJT023637; Mon, 24 Feb 2003 09:20:18 -0600 (CST) Received: from alcatel.com (localhost [127.0.0.1]) by morgoth.pet.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id h1OFKhG02890; Mon, 24 Feb 2003 07:20:43 -0800 (PST) Message-ID: <3E5A382D.9CAB8753@alcatel.com> Date: Mon, 24 Feb 2003 07:20:13 -0800 From: Mudhafar Hassan-Ali Organization: Alcatel, USA X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: bidulock@openss7.org CC: tsvwg@ietf.org, Scott Bradner , Allison Mankin , floyd@icir.org, vern@icir.org Subject: Re: [Tsvwg] Redundant TCP connection References: <3E564C4E.99932560@alcatel.com> <20030224021932.B8034@openss7.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Brian, Thanks for the suggestion. Actually I looked at it briefly, but my concern was that I needed to make sure the client would have to be of regular TCP (any version). I was not sure that was possible with an SCTP server. Regards, Mudhafar "Brian F. G. Bidulock" wrote: > Mudhafar, > > Have you looked at SCTP? Its multi-homed feature will do what you want. > > --brian > > On Fri, 21 Feb 2003, Mudhafar Hassan-Ali wrote: > > > All, > > > > I am wondering if any one is aware of the feasibility in practice to > > make a redundant TCP connection? This type of connection is needed in a > > redundant system. In such system (call it X), there are two sides, an > > active one and a standby one. Let's say the active one has a TCP > > connection with a piece of equipment Y somewhere in the network. At some > > point, the active fails, which will lead to a protection switch. This > > event will disrupt the TCP connection, which means Y will close its > > connection, and the second side of X need to open the connection also. > > However, my goal is not to disrupt the connection during the side > > switch. So the question is: Is it feasible to make a redundant TCP > > connection, such that the two sides somehow are synchronized (what are > > the parameters needed?). So for a given TCP/IP stack, how feasible and > > practical to do that? > > > > Any feedback is highly appreciated. > > > > Best regards, > > Mudhafar Hassan-Ali > > Wireline Access > > Alcatel > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Feb 28 08:33:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27330 for ; Fri, 28 Feb 2003 08:33:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SDiQE28826 for tsvwg-archive@odin.ietf.org; Fri, 28 Feb 2003 08:44:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SDhtp28809; Fri, 28 Feb 2003 08:43:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SDgEp28743 for ; Fri, 28 Feb 2003 08:42:14 -0500 Received: from alaska.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27195 for ; Fri, 28 Feb 2003 08:31:13 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by alaska.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1SDZ9pX016980; Fri, 28 Feb 2003 14:35:09 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVLBV1G; Fri, 28 Feb 2003 14:35:08 +0100 Received: from res0010384da36.eed.ericsson.se (rac178pc.edd.ericsson.se [164.48.123.178]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id OAA19846; Fri, 28 Feb 2003 14:35:05 +0100 (MET) Message-Id: <5.1.0.14.0.20030228134039.029015c8@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 28 Feb 2003 14:15:33 +0100 To: mallman@grc.nasa.gov From: Reiner Ludwig Subject: Re: [Tsvwg] early retransmit Cc: tsvwg@ietf.org In-Reply-To: <200302251243.h1PCh5v6022837@thoth.ir.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , a few comments to the draft: - First of all, I think, it's nice work, and I hope that we can move forward with this soon. - section 1: Do you really need to make a special case for (4) (connections winding down)? Isn't this just a special case of (1) (application limited connections)? - You talk about [All00] and the many short http transfers. I don't question that result, but I think that you could maybe put it a bit more into perspective. From our recent measurements, we find that http 1.1 and especially pipelining are becoming increasingly popular. Thus, http transfers should be getting longer on average these days. - Concerning the solutions mentioned in the appendix. How about if the sender maintained a ratio of ER-based-spurious-retransmits over total-number-of-transmitted-segments, assuming something like Eifel/DSACK/FRTO-based detection. Then we could say that this ratio MUST not be larger than some threshold, say 2 percent. As soon as the ratio goes higher, we turn off ER, and turn it on again as soon as the ratio goes below the threshold again. We do something similar with a new retransmit timer we are working on. It maintains the ratio of timeout-based-spurious-retransmits over total-number-of-transmitted-segments. We use that ratio to dynamically adapt the conservativeness of the new retransmit timer. In general, I think that we could allow TCP some redundancy in the form of occasional spurious retransmits (e.g., 5 percent in total), when on the other hand the avt people are allowed to define FEC for their streams. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Feb 28 09:14:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29310 for ; Fri, 28 Feb 2003 09:14:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SEOWX31651 for tsvwg-archive@odin.ietf.org; Fri, 28 Feb 2003 09:24:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SEOBp31629; Fri, 28 Feb 2003 09:24:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SENvp31585 for ; Fri, 28 Feb 2003 09:23:57 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29275 for ; Fri, 28 Feb 2003 09:12:55 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id DCF6F9DE8; Fri, 28 Feb 2003 09:16:52 -0500 (EST) Received: from ren.eecis.udel.edu (ren.eecis.udel.edu [128.4.40.13]) by mail.eecis.udel.edu (Postfix) with ESMTP id A2B019DE5; Fri, 28 Feb 2003 09:16:51 -0500 (EST) Date: Fri, 28 Feb 2003 09:16:51 -0500 (EST) From: Sourabh Ladha X-X-Sender: To: Reiner Ludwig Cc: , Subject: Re: [Tsvwg] early retransmit In-Reply-To: <5.1.0.14.0.20030228134039.029015c8@mailhost.eed.ericsson.se> Message-ID: X-Spam-Status: No, hits=-3.4 required=6.0 tests=DEPT_RCVD,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Greetings, > - section 1: > Do you really need to make a special case for (4) (connections winding > down)? Isn't this just a special case of (1) (application limited connections)? IMO (4) may be called a special case of (1). But the idea that point makes to state is that one of the things ER is specifically meant for is the trail of the connection, at the last phase of the window and so the emphasis. > - Concerning the solutions mentioned in the appendix. How about if the > sender maintained a ratio of ER-based-spurious-retransmits over > total-number-of-transmitted-segments, assuming something like > Eifel/DSACK/FRTO-based detection. Then we could say that this ratio MUST > not be larger than some threshold, say 2 percent. As soon as the ratio goes > higher, we turn off ER, and turn it on again as soon as the ratio goes > below the threshold again. Correct. Infact there was exactly a similar discussion offline to include a similar approach in the appendix for the next ID update by which time we would have researched this and other solutions further. Sourabh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Feb 28 09:54:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00591 for ; Fri, 28 Feb 2003 09:54:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SF4eX01636 for tsvwg-archive@odin.ietf.org; Fri, 28 Feb 2003 10:04:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SF4Gp01619; Fri, 28 Feb 2003 10:04:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SF36p01580 for ; Fri, 28 Feb 2003 10:03:06 -0500 Received: from maestra.inria.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00559 for ; Fri, 28 Feb 2003 09:52:05 -0500 (EST) Received: from sophia.inria.fr (localhost [127.0.0.1]) by maestra.inria.fr (8.12.5/8.12.5) with ESMTP id h1SEtv5f010102; Fri, 28 Feb 2003 15:55:57 +0100 X-Authentication-Warning: maestra.inria.fr: Host localhost [127.0.0.1] claimed to be sophia.inria.fr Message-ID: <3E5F787D.8060701@sophia.inria.fr> Date: Fri, 28 Feb 2003 15:55:57 +0100 From: Urtzi Ayesta User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203 X-Accept-Language: fr-FR, en, eu, es-ES MIME-Version: 1.0 To: Reiner.Ludwig@eed.ericsson.se CC: tsvwg@ietf.org, mallman@grc.nasa.gov Subject: Re: [Tsvwg] early retransmit References: <5.1.0.14.0.20030228134039.029015c8@mailhost.eed.ericsson.se> In-Reply-To: <5.1.0.14.0.20030228134039.029015c8@mailhost.eed.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all Reiner Ludwig wrote: > - section 1: > Do you really need to make a special case for (4) (connections winding > down)? Isn't this just a special case of (1) (application limited > connections)? Maybe we should modify a bit the approach of this part. Indeed the problems of points (2) and (3) are handled by Limited Transmit. It is not exactly having a small congestion window what makes connections prone to timeout, but the addition of having small congestion window and not to have more "new" data to send. In the of case of small congestion window and more "new" data, Limited Tramited would take over and eventually induce the reception of three duplicate ACKs. For ER we had in mind two main motivations. The first case corresponds to long lived interactive applications which send data in small bursts, such as telnet and network games. The second case correspond to the fact any loss of the last three packets would provoke a timeout, which is especially harmful for short connections. > > - Concerning the solutions mentioned in the appendix. How about if the > sender maintained a ratio of ER-based-spurious-retransmits over > total-number-of-transmitted-segments, assuming something like > Eifel/DSACK/FRTO-based detection. Then we could say that this ratio > MUST not be larger than some threshold, say 2 percent. As soon as the > ratio goes higher, we turn off ER, and turn it on again as soon as the > ratio goes below the threshold again We do something similar with a > new retransmit timer we are working on. It maintains the ratio of > timeout-based-spurious-retransmits over > total-number-of-transmitted-segments. We use that ratio to dynamically > adapt the conservativeness of the new retransmit timer. > In general, I think that we could allow TCP some redundancy in the > form of occasional spurious retransmits (e.g., 5 percent in total), > when on the other hand the avt people are allowed to define FEC for > their streams. > This is clearly a point which needs further discussion. Maybe a higher value for this threshold could be considered If we take into consideration that the overload introduced by ER on average would be equal to Porcentage_Packet_reordering x Ratio_spurios-rtx_Total-rtx. regards, Urtzi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Feb 28 11:15:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03445 for ; Fri, 28 Feb 2003 11:15:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SGPtw08104 for tsvwg-archive@odin.ietf.org; Fri, 28 Feb 2003 11:25:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGPWp08008; Fri, 28 Feb 2003 11:25:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGMWp07739 for ; Fri, 28 Feb 2003 11:22:32 -0500 Received: from MAIL.cynetanetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03018 for ; Fri, 28 Feb 2003 11:11:29 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] early retransmit Date: Fri, 28 Feb 2003 10:15:24 -0600 Message-ID: <9255B6CD76A88943A3062F7D4E6432F5639EAE@mail.cynetanetworks.com> Thread-Topic: [Tsvwg] early retransmit Thread-Index: AcLfPgjJ1l1K4auPSGGYXBnn0qFIqQABmI0w From: "Spencer Dawkins" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1SGMWp07742 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, Reiner, Can you provide a pointer to these recent measurements? Thanks! Spencer > -----Original Message----- > From: Reiner Ludwig [mailto:Reiner.Ludwig@eed.ericsson.se] > > - You talk about [All00] and the many short http transfers. I don't > question that result, but I think that you could maybe put it > a bit more > into perspective. From our recent measurements, we find that > http 1.1 and > especially pipelining are becoming increasingly popular. Thus, http > transfers should be getting longer on average these days. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Feb 28 13:36:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08443 for ; Fri, 28 Feb 2003 13:36:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SIknW18896 for tsvwg-archive@odin.ietf.org; Fri, 28 Feb 2003 13:46:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SIkNp18877; Fri, 28 Feb 2003 13:46:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SIj1p18821 for ; Fri, 28 Feb 2003 13:45:01 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08381 for ; Fri, 28 Feb 2003 13:33:53 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1SIbo58011484; Fri, 28 Feb 2003 10:37:50 -0800 (PST) Received: from cisco.com (mbashyam-u10.cisco.com [10.34.36.39]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEO68588; Fri, 28 Feb 2003 10:32:50 -0800 (PST) Message-ID: <3E5FAC7C.DB29A027@cisco.com> Date: Fri, 28 Feb 2003 10:37:48 -0800 From: Murali Bashyam Organization: Cisco Systems Inc X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Joe Touch CC: tsvwg@ietf.org Subject: Re: [Tsvwg] slow-start restart References: <3E550527.7A71899@cisco.com> <3E5527E9.4010908@isi.edu> <3E552A9C.1090100@isi.edu> Content-Type: multipart/alternative; boundary="------------6166BC194D1857766D895958" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --------------6166BC194D1857766D895958 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Joe Touch wrote: > Joe Touch wrote: > > mbashyam wrote: > > > >> Hi > >> > >> Is the problem of persistent HTTP connections slow starting after an > >> idle period of a round trip time been addressed? I know the problem is > >> well understood and there are solutions which can preserve the > >> conservative spirit behind slow starting and also maintain the > >> congestion window high enough for the subsequent transfers, but are > >> there any standards/drafts in progress that address this issue already? > >> If not is there a need to write one? > > > > > > http://www/touch/pubs/draft-hughes-restart-00.txt > > > > This is pending an implementation to proceed... interested ;-)? > > It's also pending a better URL ;-0 > > http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt The timeout u are referring to in BOL, is the same receive timeout that exists in today's BSD implementations, correct? If so then BOL suffers from the same problems of using a receive timeout, correct? Wouldn't it be better to have a last-snd-time in TCP control block and detect send idle period? Murali > > > Joe > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --------------6166BC194D1857766D895958 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Joe Touch wrote:
Joe Touch wrote:
> mbashyam wrote:
>
>> Hi
>>
>> Is the problem of persistent HTTP connections slow starting after an
>> idle period of a round trip time  been addressed?  I know the problem is
>> well understood and there are solutions which can preserve the
>> conservative spirit  behind  slow starting and also maintain  the
>> congestion window high enough for the subsequent transfers, but are
>> there any standards/drafts in progress that address this issue already?
>> If not is there a need to write one?
>
>
> http://www/touch/pubs/draft-hughes-restart-00.txt
>
> This is pending an implementation to proceed... interested ;-)?

It's also pending a better URL ;-0

http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt


The timeout u are referring to in BOL, is the same receive timeout that exists in today's BSD implementations, correct?  If so then BOL suffers from the same problems of using a receive timeout,
correct? Wouldn't it be better to have a last-snd-time in TCP control block and detect send idle
period?

Murali

 

Joe

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg

--------------6166BC194D1857766D895958-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Feb 28 16:01:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13274 for ; Fri, 28 Feb 2003 16:01:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SLAdh28403 for tsvwg-archive@odin.ietf.org; Fri, 28 Feb 2003 16:10:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SLAKp28353; Fri, 28 Feb 2003 16:10:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SL95p28316 for ; Fri, 28 Feb 2003 16:09:05 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13201 for ; Fri, 28 Feb 2003 15:59:54 -0500 (EST) Received: from isi.edu (host29.tethered.net [206.117.27.29]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h1SL04H25217; Fri, 28 Feb 2003 13:00:04 -0800 (PST) Message-ID: <3E5FCDCA.8040401@isi.edu> Date: Fri, 28 Feb 2003 12:59:54 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Murali Bashyam CC: tsvwg@ietf.org Subject: Re: [Tsvwg] slow-start restart References: <3E550527.7A71899@cisco.com> <3E5527E9.4010908@isi.edu> <3E552A9C.1090100@isi.edu> <3E5FAC7C.DB29A027@cisco.com> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Murali Bashyam wrote: > Joe Touch wrote: > >> Joe Touch wrote: >> > mbashyam wrote: >> > >> >> Hi >> >> >> >> Is the problem of persistent HTTP connections slow starting after an >> >> idle period of a round trip time been addressed? I know the >> problem is >> >> well understood and there are solutions which can preserve the >> >> conservative spirit behind slow starting and also maintain the >> >> congestion window high enough for the subsequent transfers, but are >> >> there any standards/drafts in progress that address this issue >> already? >> >> If not is there a need to write one? >> > >> > >> > http://www/touch/pubs/draft-hughes-restart-00.txt >> > >> > This is pending an implementation to proceed... interested ;-)? >> >> It's also pending a better URL ;-0 >> >> http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt >> > > The timeout u are referring to in BOL, is the same receive timeout that > exists in today's BSD implementations, correct? There is no timeout in BOL. It's a bucket. If you send as fast as the bucket fills with ACKs, you can sustain the send rate. If you don't, then you lose the ability to burst, except for the size of the bucket. The loss is immediate upon reception of more ACKs than fit in the bucket. Joe _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Feb 28 18:33:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17173 for ; Fri, 28 Feb 2003 18:33:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SNfn105044 for tsvwg-archive@odin.ietf.org; Fri, 28 Feb 2003 18:41:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SNfXp05034; Fri, 28 Feb 2003 18:41:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SNe5p05005 for ; Fri, 28 Feb 2003 18:40:05 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17112 for ; Fri, 28 Feb 2003 18:30:50 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1SNWUHK021502; Fri, 28 Feb 2003 15:32:30 -0800 (PST) Received: from cisco.com (mbashyam-u10.cisco.com [10.34.36.39]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEO96836; Fri, 28 Feb 2003 15:27:48 -0800 (PST) Message-ID: <3E5FF1A0.9DAFB087@cisco.com> Date: Fri, 28 Feb 2003 15:32:48 -0800 From: Murali Bashyam Organization: Cisco Systems Inc X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Joe Touch CC: tsvwg@ietf.org Subject: Re: [Tsvwg] slow-start restart References: <3E550527.7A71899@cisco.com> <3E5527E9.4010908@isi.edu> <3E552A9C.1090100@isi.edu> <3E5FAC7C.DB29A027@cisco.com> <3E5FCDCA.8040401@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Joe Touch wrote: > Murali Bashyam wrote: > > Joe Touch wrote: > > > >> Joe Touch wrote: > >> > mbashyam wrote: > >> > > >> >> Hi > >> >> > >> >> Is the problem of persistent HTTP connections slow starting after an > >> >> idle period of a round trip time been addressed? I know the > >> problem is > >> >> well understood and there are solutions which can preserve the > >> >> conservative spirit behind slow starting and also maintain the > >> >> congestion window high enough for the subsequent transfers, but are > >> >> there any standards/drafts in progress that address this issue > >> already? > >> >> If not is there a need to write one? > >> > > >> > > >> > http://www/touch/pubs/draft-hughes-restart-00.txt > >> > > >> > This is pending an implementation to proceed... interested ;-)? > >> > >> It's also pending a better URL ;-0 > >> > >> http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt > >> > > > > The timeout u are referring to in BOL, is the same receive timeout that > > exists in today's BSD implementations, correct? > > There is no timeout in BOL. It's a bucket. If you send as fast as the > bucket fills with ACKs, you can sustain the send rate. If you don't, > then you lose the ability to burst, except for the size of the bucket. > The loss is immediate upon reception of more ACKs than fit in the bucket. > > Joe Here's a snippet from the draft with the code for BOL, the timeout u are referring to in the snippet is the receive timeout, correct? Murali The code is as follows: /* define the state for BOL */ int ack_ratio, /* max number of packets per ack */ int bucket, /* max burst size */ #DEFINE init_win 2 /* set the bucket on ACK receipt */ bucket = ack_ratio * 2 + 1; /* set bucket on timeout */ bucket = init_win; /* decrement the bucket accordingly */ can_send = min(bucket - want_send, 0); bucket -= can_send; do_send(can_send); return can_send; _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Feb 28 19:38:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18521 for ; Fri, 28 Feb 2003 19:38:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h210liO08209 for tsvwg-archive@odin.ietf.org; Fri, 28 Feb 2003 19:47:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h210lNp08198; Fri, 28 Feb 2003 19:47:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h210kIp08147 for ; Fri, 28 Feb 2003 19:46:18 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18393 for ; Fri, 28 Feb 2003 19:37:02 -0500 (EST) Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h210cKH15745; Fri, 28 Feb 2003 16:38:20 -0800 (PST) Message-ID: <3E6000FF.7030203@isi.edu> Date: Fri, 28 Feb 2003 16:38:23 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Murali Bashyam CC: tsvwg@ietf.org Subject: Re: [Tsvwg] slow-start restart References: <3E550527.7A71899@cisco.com> <3E5527E9.4010908@isi.edu> <3E552A9C.1090100@isi.edu> <3E5FAC7C.DB29A027@cisco.com> <3E5FCDCA.8040401@isi.edu> <3E5FF1A0.9DAFB087@cisco.com> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Murali Bashyam wrote: > Joe Touch wrote: ... >>>>>mbashyam wrote: ... >>>>>>Is the problem of persistent HTTP connections slow starting after an >>>>>>idle period of a round trip time been addressed? ... >>>>http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt ... >>>The timeout u are referring to in BOL, is the same receive timeout that >>>exists in today's BSD implementations, correct? >> >>There is no timeout in BOL. It's a bucket. If you send as fast as the >>bucket fills with ACKs, you can sustain the send rate. If you don't, >>then you lose the ability to burst, except for the size of the bucket. >>The loss is immediate upon reception of more ACKs than fit in the bucket. >> >>Joe > > Here's a snippet from the draft with the code for BOL, the timeout u are > referring to in the snippet is the receive timeout, correct? > > The code is as follows: > > /* define the state for BOL */ > int ack_ratio, /* max number of packets per ack */ > int bucket, /* max burst size */ > > #DEFINE init_win 2 > > /* set the bucket on ACK receipt */ > bucket = ack_ratio * 2 + 1; > > /* set bucket on timeout */ > bucket = init_win; > > /* decrement the bucket accordingly */ > can_send = min(bucket - want_send, 0); > bucket -= can_send; > do_send(can_send); > return can_send; The primary function of that part of the code is to set the bucket on the timeout, (i.e., when it's smaller than init_win before the timeout) rather than to empty it down. The use of the receive timer and init_win is designed to make this variant behave conservatively when the ACK clock is lost. For that, receive timout is correct. The problem with current code is that it uses "time since last received", rather than setting a flag on timeout. Joe _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg