From mailnull@www1.ietf.org Mon Jun 2 02:33: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 CAA25398 for ; Mon, 2 Jun 2003 02:33:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h526XEp13023 for tsvwg-archive@odin.ietf.org; Mon, 2 Jun 2003 02:33:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h526VgB12961; Mon, 2 Jun 2003 02:31:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h526UBB12852 for ; Mon, 2 Jun 2003 02:30:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25292 for ; Mon, 2 Jun 2003 02:30:06 -0400 (EDT) From: ashw@iitk.ac.in Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mint-0007ix-00 for tsvwg@ietf.org; Mon, 02 Jun 2003 02:28:21 -0400 Received: from [203.197.196.2] (helo=mail2.iitk.ac.in) by ietf-mx with esmtp (Exim 4.12) id 19Mins-0007if-00 for tsvwg@ietf.org; Mon, 02 Jun 2003 02:28:20 -0400 Received: from antivirus.cc.iitk.ac.in (antivirus.cc.iitk.ac.in [172.31.1.102]) by mail2.iitk.ac.in (8.12.8/8.12.8) with SMTP id h526fSeF015163 for ; Mon, 2 Jun 2003 12:11:33 +0530 Received: from iitk.ac.in ([172.31.1.212]) by antivirus.cc.iitk.ac.in (NAVGW 2.5.2.12) with SMTP id M2003060211585027921 for ; Mon, 02 Jun 2003 11:58:50 +0530 Received: from 137.132.3.12 (proxying for 137.132.82.100) (SquirrelMail authenticated user ashw) by www.iitk.ac.in with HTTP; Mon, 2 Jun 2003 12:33:07 +0530 (IST) Message-ID: <55827.137.132.3.12.1054537387.squirrel@www.iitk.ac.in> Date: Mon, 2 Jun 2003 12:33:07 +0530 (IST) To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.7) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Tsvwg] Multihoming in SCTP patch for ns-2 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 all, This is regarding the sctp patch for ns developed at PEL , Univ of Delaware . I am working on running simulation of SCTP over ad hoc scenarios. In this connection I would be grateful if anyone can clarify the following . In "Interesting features" of the readme (http://www.cis.udel.edu/~acaro/research/ns2sctp/sctp.README), the idea behind how multihoming is actually implemented in ns is explained , by using more than one nodes for one endpoint. It mentions , to quote "There is a "core node" and multiple "interface nodes" to simulate the interfaces. The SCTP agent resides on all the nodes, but traffic only goes to and from the interface nodes. The core node is used for routing and is connected to each interface node via a uni-directional link towards the interface node. Traffic does not traverse this link." Is this true also in adhoc scenarios as well ? Because the nodes that are used as interfaces to the core node , may be moving independently (according to a movement pattern file ) and may also go out of "range" of the core node , and the "uni-directional link" mentioned above may no longer be present. Thanks in advance , Ashwini _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Jun 3 04:53:24 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 EAA23585 for ; Tue, 3 Jun 2003 04:53:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h538qwB23237 for tsvwg-archive@odin.ietf.org; Tue, 3 Jun 2003 04:52:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h538pDB23161; Tue, 3 Jun 2003 04:51:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h538nqB23052 for ; Tue, 3 Jun 2003 04:49:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23530 for ; Tue, 3 Jun 2003 04:49:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N7Sb-00037Q-00 for tsvwg@ietf.org; Tue, 03 Jun 2003 04:48:01 -0400 Received: from ns.unisa.it ([193.205.160.3]) by ietf-mx with esmtp (Exim 4.12) id 19N7Sb-00037M-00 for tsvwg@ietf.org; Tue, 03 Jun 2003 04:48:01 -0400 Received: from fw-2 (dmz2.unisa.it [193.205.160.61]) by ns.unisa.it (8.12.8/8.12.0) with SMTP id h538njrE004291 for ; Tue, 3 Jun 2003 10:49:45 +0200 (MET DST) Received: from ([193.205.164.89]) by fw-2; Tue, 03 Jun 2003 09:33:35 +0200 (CEST) From: giuseppe To: TSWG Content-Type: text/plain Message-Id: <1054629818.4378.6.camel@cori17> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 03 Jun 2003 10:43:38 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] load sharing in ns 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; I posted few day ago a messages about a problem in ns. We are developped a patch the SCTP module which enable both interfaces to send data. The thing run well when the paths are totally separated. But when I do an intersection of the paths, so only one path is present, the routing protocol of ns doesn't allow to send data over both interfaces. 1------\ /--------3 \______________/ / \ 2------/ \--------4 1,2,3,4 are SCTP interfaces. In nam visualization I see that only one interface is being transmitting to both 3,4 destination. Anyone has some word on this? Giuseppe _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Jun 3 18:38: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 SAA28488 for ; Tue, 3 Jun 2003 18:38:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53McIa04125 for tsvwg-archive@odin.ietf.org; Tue, 3 Jun 2003 18:38:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53MajB03183; Tue, 3 Jun 2003 18:36:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53MYwB03096 for ; Tue, 3 Jun 2003 18:34:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28305 for ; Tue, 3 Jun 2003 18:34:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NKL3-0003W4-00 for tsvwg@ietf.org; Tue, 03 Jun 2003 18:33:05 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19NKL2-0003W0-00 for tsvwg@ietf.org; Tue, 03 Jun 2003 18:33:04 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h53MXL7r071841; Tue, 3 Jun 2003 17:33:41 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EDD2231.5060700@stewart.chicago.il.us> Date: Tue, 03 Jun 2003 17:33:21 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Caitlin Bestler CC: umesh@ccpu.com, tsvwg@ietf.org Subject: Re: [Tsvwg] A query 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 Caitlin Bestler wrote: >>Umesh Vats wrote: >> >>>Can an SCTP endpoint use different set of source address for different >>>associations >>>origination/terminating on it ? E.g, suppose an endpoint >> >>(ASP/SGP/IPSP) has >> >>>source(self) >>>IP addresses A, B, C, D, E, F and G. >>> >>>Can this endpoint assign source addresses to three associations as : >>> Assoc 1 : A, B, C >>> Assoc 2 : C, D, E >>> Assoc 3 : F, G >>> >>>Umesh Vats >>> > > > In addition to whatever limitations the local stack may have, you have > to consider how things would look to the remote end if multiple of > these endpoints attempted to connected to the same remote endpoint. > > If Assoc 1 and Assoc 2 had the same port number, I believe there would > be problems attempting to form an association with the same remote endpoint. > It would appear that the host that included C was trying to change its list > of IP addresses. While the remote host would never realize that Assoc 1 and > Assoc 3 were the same machine. Ditto for Assoc 2 and Assoc 3. > Well.. maybe.. it depends on what addresses are listed by the endpoints. If I send a INIT(A,B,C)---------> E-X and INIT(D,E)-----------------> E-X I can and do setup two assocations and both sides can tell the difference.... as long as the two init's don't have an overlapping set of addresses.. That is what would cause a problem :-0 R > > _______________________________________________ > 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 Jun 4 02:47:44 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 CAA05672 for ; Wed, 4 Jun 2003 02:47:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h546lJ016856 for tsvwg-archive@odin.ietf.org; Wed, 4 Jun 2003 02:47:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h546jbB16809; Wed, 4 Jun 2003 02:45:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52BKlB03491 for ; Mon, 2 Jun 2003 07:20:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01473 for ; Mon, 2 Jun 2003 07:20:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MnLA-0001jh-00 for tsvwg@ietf.org; Mon, 02 Jun 2003 07:19:00 -0400 Received: from mail.poliba.it ([193.204.49.50]) by ietf-mx with esmtp (Exim 4.12) id 19MnL9-0001jd-00 for tsvwg@ietf.org; Mon, 02 Jun 2003 07:18:59 -0400 Received: (from apache@localhost) by mail.poliba.it (8.11.6/8.11.6) id h52BaKt08905; Mon, 2 Jun 2003 13:36:20 +0200 From: "Prof." X-Authentication-Warning: mail.poliba.it: apache set sender to mascolo@poliba.it using -f Received: from 130.238.47.211 ( [130.238.47.211]) as user mascolo@mail.poliba.it by mail.poliba.it with HTTP; Mon, 2 Jun 2003 13:36:20 +0200 Message-ID: <1054553780.3edb36b405700@mail.poliba.it> Date: Mon, 2 Jun 2003 13:36:20 +0200 To: tsvwg@ietf.org, end2end-interest@postel.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: 8bit Subject: [Tsvwg] (no subject) 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 all, we have made available our implementation of TCP westwood+ in ns-2 at http://www-ictserv.poliba.it/mascolo/tcp%20westwood/modules.htm To summarize, TCP Westwood+ proposes an e2e bandwdith estimation to adaptively set the congestion window after a congestion episode, thus avoiding the "blind" by half window reduction of standard AIMD algorithms. S. Mascolo and L. Grieco _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Jun 4 02:49: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 CAA05736 for ; Wed, 4 Jun 2003 02:49:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h546nKd17060 for tsvwg-archive@odin.ietf.org; Wed, 4 Jun 2003 02:49:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h546llB16905; Wed, 4 Jun 2003 02:47:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52DLgB12887 for ; Mon, 2 Jun 2003 09:21:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06088 for ; Mon, 2 Jun 2003 09:21:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MpE9-0002sq-00 for tsvwg@ietf.org; Mon, 02 Jun 2003 09:19:53 -0400 Received: from deemail.poliba.it ([193.204.59.11]) by ietf-mx with esmtp (Exim 4.12) id 19MpE8-0002sa-00 for tsvwg@ietf.org; Mon, 02 Jun 2003 09:19:52 -0400 Received: from deectl18 (130.238.47.211) by deemail.poliba.it with ESMTP (Eudora Internet Mail Server 3.0.3); Mon, 2 Jun 2003 15:18:06 +0200 Message-ID: <024e01c3290a$b7e732e0$5fc8a8c0@poliba.it> From: "Saverio Mascolo" To: , Date: Mon, 2 Jun 2003 15:27:29 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_024B_01C3291B.7A9EF740" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [Tsvwg] e2e bandwisth estimation-ns modules for Westwood+ TCP 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_000_024B_01C3291B.7A9EF740 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 we have made available our implementation of TCP westwood+ in ns-2 for = testing at =20 http://www-ictserv.poliba.it/mascolo/tcp%20westwood/modules.htm =20 To summarize, TCP Westwood+ proposes an e2e bandwdith estimation to = adaptively set the congestion window after a congestion episode, thus avoiding the "blind" by half window reduction of standard AIMD algorithms. =20 S. Mascolo and L. Grieco =20 ------=_NextPart_000_024B_01C3291B.7A9EF740 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
we have made = available our=20 implementation of TCP westwood+ in ns-2 for testing = at
 
http://www-ictserv.poliba.it/mascolo/tcp%20westwood= /modules.htm
 
To=20 summarize, TCP Westwood+ proposes an e2e bandwdith estimation to=20 adaptively
set the congestion window after a congestion episode, = thus =20 avoiding the
 "blind"  by half window  reduction of = standard=20 AIMD algorithms.
 
S. Mascolo and L.=20 Grieco
 
------=_NextPart_000_024B_01C3291B.7A9EF740-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Jun 4 04:24: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 EAA07723 for ; Wed, 4 Jun 2003 04:24:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h548NcR24406 for tsvwg-archive@odin.ietf.org; Wed, 4 Jun 2003 04:23:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h548FcB24039; Wed, 4 Jun 2003 04:15:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h548EPB24002 for ; Wed, 4 Jun 2003 04:14:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07506 for ; Wed, 4 Jun 2003 04:14:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NTNq-0007Rw-00 for tsvwg@ietf.org; Wed, 04 Jun 2003 04:12:34 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19NTNp-0007Rt-00 for tsvwg@ietf.org; Wed, 04 Jun 2003 04:12:33 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h548EKW18861 for ; Wed, 4 Jun 2003 11:14:20 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Jun 2003 11:14:20 +0300 Received: from sahaja.research.nokia.com ([172.21.40.118]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 11:14:20 +0300 From: Pasi Sarolahti To: tsvwg@ietf.org Cc: jon.peterson@neustar.biz Content-Type: text/plain Organization: Nokia Research Center Message-Id: <1054714458.3063.61.camel@optiplex> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Jun 2003 11:14:20 +0300 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jun 2003 08:14:20.0637 (UTC) FILETIME=[4CE6C8D0:01C32A71] Content-Transfer-Encoding: 7bit Subject: [Tsvwg] New version of the F-RTO draft 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, A new version of our draft titled "F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP" is available at http://www.ietf.org/internet-drafts/draft-sarolahti-tsvwg-tcp-frto-04.txt There are no open issues that I am aware of, so I think the draft would be ready to be moved forward towards experimental RFC. Therefore, following the earlier instructions from Allison, I'd like to ask for a last call for this draft under the tsvwg. In addition to some editorial work, the most significant changes for this draft version are: - We have added some text about applying the algorithm with SCTP, since I belive the same idea applies there, too. - Some new text in the Security Considerations section. - We have changed some terminology (e.g. by using the "SpuriousRecovery" variable) to be better aligned with the Eifel Detection RFC. All comments are welcome, of course. Especially, I'd be interested to hear what the SCTP folks think about the current version. Thanks, - Pasi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Jun 4 10:32: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 KAA22859 for ; Wed, 4 Jun 2003 10:32:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54EVx520297 for tsvwg-archive@odin.ietf.org; Wed, 4 Jun 2003 10:31:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54EUVB20026; Wed, 4 Jun 2003 10:30:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54ERlB19826 for ; Wed, 4 Jun 2003 10:27:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22466 for ; Wed, 4 Jun 2003 10:27:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NZD6-0003Ic-00 for tsvwg@ietf.org; Wed, 04 Jun 2003 10:25:52 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19NZD6-0003IN-00 for tsvwg@ietf.org; Wed, 04 Jun 2003 10:25:52 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h54EQN7r076600; Wed, 4 Jun 2003 09:26:23 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EDD268B.4050407@stewart.chicago.il.us> Date: Tue, 03 Jun 2003 17:51:55 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: umesh@ccpu.com CC: tsvwg@ietf.org Subject: Re: [Tsvwg] A query References: <3ED941C0.3040106@stewart.chicago.il.us> In-Reply-To: <3ED941C0.3040106@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 Hi: Kacheong just pointed out a typo I made... in my hurry :-0 see below.. Randall Stewart wrote: > Umesh Vats wrote: > >> Can an SCTP endpoint use different set of source address for different >> associations >> origination/terminating on it ? E.g, suppose an endpoint >> (ASP/SGP/IPSP) has >> source(self) >> IP addresses A, B, C, D, E, F and G. >> >> Can this endpoint assign source addresses to three associations as : >> Assoc 1 : A, B, C >> Assoc 2 : C, D, E >> Assoc 3 : F, G >> >> Umesh Vats >> >> _______________________________________________ >> tsvwg mailing list >> tsvwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/tsvwg >> >> > Hmm... > > Yes, I think this could be done.. as long as the stack > can handle it and not confuse the packets.. > > If I wanted to do this with the sockets api on the KAME-FreeBSD machine it > would have to be three sockets > > One would do > > bind(a) > sctp_bindx(b,c) > I missed that you had c in two associations.. this is NOT legal. You could do the above and bind(d) sctp_bindx(e) > the second > bind(c) > sctp_bindx(d,e) Scratch the lines (3) above... > > and the third > bind(f) > sctp_bindx(g) > > I am assuming here you are talking about the same port number on all of > them. > > In the above (for kame) you would actually have 3 endpoints... But one > could > open them in the same program if one wanted.. > > 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 Thu Jun 12 16:31: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 QAA25928 for ; Thu, 12 Jun 2003 16:31:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CKUbw22218 for tsvwg-archive@odin.ietf.org; Thu, 12 Jun 2003 16:30:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CHv2a12267; Thu, 12 Jun 2003 13:57:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CHudm12244 for ; Thu, 12 Jun 2003 13:56:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21002 for ; Thu, 12 Jun 2003 13:56:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QWHN-0004qT-00 for tsvwg@ietf.org; Thu, 12 Jun 2003 13:54:29 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19QWHN-0004qI-00 for tsvwg@ietf.org; Thu, 12 Jun 2003 13:54:29 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h5CHtvHu002413 for ; Thu, 12 Jun 2003 12:55:59 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EE8BEAD.9000708@stewart.chicago.il.us> Date: Thu, 12 Jun 2003 12:55:57 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 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] PR 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: Well after the bakeoff (last week) we had a couple of minor updates to the PR-SCTP draft. I am putting once again the proposed differences on http://www.sctp.org Go to the RFC's and internet-drafts tab and click the "here" on the proposed changes. Have a look.. I intend to submit this in a couple of days.... Note that we did have 4 inter-operable implementations of PR-SCTP at the bakeoff.... things went quite well :> 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 Mon Jun 16 09:54: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 JAA13972 for ; Mon, 16 Jun 2003 09:54:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GDrb104260 for tsvwg-archive@odin.ietf.org; Mon, 16 Jun 2003 09:53:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GBw1a28277; Mon, 16 Jun 2003 07:58:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GBvgm28261 for ; Mon, 16 Jun 2003 07:57:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09328 for ; Mon, 16 Jun 2003 07:57:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rsa6-0001Xf-00 for tsvwg@ietf.org; Mon, 16 Jun 2003 07:55:26 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19Rsa5-0001XZ-00 for tsvwg@ietf.org; Mon, 16 Jun 2003 07:55:25 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h5GBvd7M022379 for ; Mon, 16 Jun 2003 04:57:39 -0700 (MST) Received: from zuk28exm03.ecid.cig.mot.com (zuk28exm03.ecid.cig.mot.com [10.128.69.72]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h5GBvb1U007393 for ; Mon, 16 Jun 2003 06:57:38 -0500 Received: by zuk28exm03.ecid.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 16 Jun 2003 12:57:36 +0100 Message-ID: From: Gil Jose-josegil1 To: tsvwg@ietf.org Date: Mon, 16 Jun 2003 12:57:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: [Tsvwg] Fast retransmit and RTO re-start 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 would like to know (confirmation) if the RTO timer is re-started when a fast retransmit happens, that is, the RTO re-started as soon as the detected lost segment is retransmitted. I couldn't get a clear answer on this specific question from reading RFC 2581 and RFC 2988. I would appreciate if somebody can let me know the answer or point me to any other appropriate RFC. Would any of the three duplicate ACKs alter the current calculated RTO value? Thank you Jose _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Jun 16 11:52: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 LAA18569 for ; Mon, 16 Jun 2003 11:52:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GFqSm13429 for tsvwg-archive@odin.ietf.org; Mon, 16 Jun 2003 11:52:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GD92a01742; Mon, 16 Jun 2003 09:09:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GD90m01728 for ; Mon, 16 Jun 2003 09:09:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12753 for ; Mon, 16 Jun 2003 09:08:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rth5-0002Vd-00 for tsvwg@ietf.org; Mon, 16 Jun 2003 09:06:43 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19Rth5-0002Va-00 for tsvwg@ietf.org; Mon, 16 Jun 2003 09:06:43 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h5GD8u7M021877 for ; Mon, 16 Jun 2003 06:08:56 -0700 (MST) Received: from zuk28exm03.ecid.cig.mot.com (zuk28exm03.ecid.cig.mot.com [10.128.69.72]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h5GD8scl007811 for ; Mon, 16 Jun 2003 08:08:55 -0500 Received: by zuk28exm03.ecid.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 16 Jun 2003 14:08:53 +0100 Message-ID: From: Gil Jose-josegil1 To: "'Reiner Ludwig'" , Gil Jose-josegil1 Cc: tsvwg@ietf.org Subject: RE: [Tsvwg] Fast retransmit and RTO re-start Date: Mon, 16 Jun 2003 14:08:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain 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: , Thanks for the answer, Reiner. I see, the timer is switched off after the third dupack. Now the paragraph below makes sense and is consistent with what I read in some computer networking books (it was actually this paragraph the one that confused me because the way I was reading it meant to me that the RTO should not be re-started after fast retransmit since the RTO would be already running for the lost packet). >Then RFC2988 continues: > (5.1) Every time a packet containing data is sent (including a > retransmission), if the timer is not running, start it running > so that it will expire after RTO seconds (for the current value > of RTO). _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Jun 16 12:53: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 MAA20754 for ; Mon, 16 Jun 2003 12:53:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GGrN617993 for tsvwg-archive@odin.ietf.org; Mon, 16 Jun 2003 12:53:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GCd2a31927; Mon, 16 Jun 2003 08:39:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GCcNm31899 for ; Mon, 16 Jun 2003 08:38:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11006 for ; Mon, 16 Jun 2003 08:38:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RtDT-0001zG-00 for tsvwg@ietf.org; Mon, 16 Jun 2003 08:36:07 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19RtDS-0001z8-00 for tsvwg@ietf.org; Mon, 16 Jun 2003 08:36:06 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GCd9cv017837; Mon, 16 Jun 2003 14:39:09 +0200 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 LYGLD49Y; Mon, 16 Jun 2003 14:38:12 +0200 Received: from res0010384da36.eed.ericsson.se (dhcp5-109.eed.ericsson.se [164.48.135.109]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id OAA26519; Mon, 16 Jun 2003 14:38:00 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030616143336.0299cdc8@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 16 Jun 2003 14:38:49 +0200 To: Gil Jose-josegil1 From: Reiner Ludwig Subject: Re: [Tsvwg] Fast retransmit and RTO re-start Cc: tsvwg@ietf.org In-Reply-To: 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:57 16.06.2003, Gil Jose-josegil1 wrote: >I would like to know (confirmation) if the RTO timer is re-started when a >fast retransmit happens, that is, the RTO re-started as soon as the detected >lost segment is retransmitted. I couldn't get a clear answer on this >specific question from reading RFC 2581 and RFC 2988. I would appreciate if >somebody can let me know the answer or point me to any other appropriate >RFC. The retransmission timer is turned off when the 3rd DUPACK arrives. That's the part that's not explicitly mentioned in any RFC as far as I know. It's in the original BSD code, though. Then RFC2988 continues: (5.1) Every time a packet containing data is sent (including a retransmission), if the timer is not running, start it running so that it will expire after RTO seconds (for the current value of RTO). >Would any of the three duplicate ACKs alter the current calculated RTO >value? Usually not. However, if those DUPACKs would carry timestamps, one could actually retrofit the RTO. The same is true for any other DUPACK beyond the 3rd one ... ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jun 18 10:44:46 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 KAA10295 for ; Wed, 18 Jun 2003 10:44:46 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IEiI318511 for tsvwg-archive@odin.ietf.org; Wed, 18 Jun 2003 10:44:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdeT-00036C-1T; Wed, 18 Jun 2003 10:11:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdIP-0001Yh-Gy for tsvwg@optimus.ietf.org; Wed, 18 Jun 2003 09:48:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06870; Wed, 18 Jun 2003 09:48:14 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdG8-0004n7-00; Wed, 18 Jun 2003 09:45:56 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19SdG7-0004n4-00; Wed, 18 Jun 2003 09:45:55 -0400 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id 96B95572EF; Wed, 18 Jun 2003 15:48:11 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id PAA13818; Wed, 18 Jun 2003 15:48:09 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id PAA06076; Wed, 18 Jun 2003 15:48:08 +0200 (MEST) To: tsvwg@ietf.org Cc: mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 18 Jun 2003 15:39:18 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 18/06/2003 15:49:12 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Tsvwg] stream switching 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: , Hello TSV, I am trying to get feedback about: http://www.ietf.org/internet-drafts/draft-gentric-mmusic-stream-switching-req-00.txt and http://www.ietf.org/internet-drafts/draft-gentric-mmusic-stream-switching-00.txt specifically I would like to validate the idea that stream switching "is a good idea" with respect to the idea that it can be used to "extend" RFC3448 to *any type* of streaming media for rate/congestion control. (quote from RFC3448: "TFRC is designed for applications that use a fixed packet size, and vary their sending rate in packets per second in response to congestion.") (Note that stream switching is used today by the 3GPP PSS spec but so far is restricted to server-side rate changes without changing the codec configuration.) In draft-gentric-mmusic-stream-switching-req-00.txt I am trying to extend stream switching to the general case i.e. being able to switch streams that have different encodings. The document explains why there is a need for "additional control" in order to do that. [... and draft-gentric-mmusic-stream-switching-00.txt is an example of how to bring such control capabilities by extending RTSP] regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jun 19 09:08: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 JAA16314 for ; Thu, 19 Jun 2003 09:08:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JD85Z27850 for tsvwg-archive@odin.ietf.org; Thu, 19 Jun 2003 09:08:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sygy-0005Z7-FG; Thu, 19 Jun 2003 08:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SyFn-0003sJ-Nd for tsvwg@optimus.ietf.org; Thu, 19 Jun 2003 08:10:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11324 for ; Thu, 19 Jun 2003 08:10:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SyDV-0002FZ-00 for tsvwg@ietf.org; Thu, 19 Jun 2003 08:08:37 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19SyDV-0002FG-00 for tsvwg@ietf.org; Thu, 19 Jun 2003 08:08:37 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h5JCAFHu056127; Thu, 19 Jun 2003 07:10:15 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EF1A825.8070607@stewart.chicago.il.us> Date: Thu, 19 Jun 2003 07:10:13 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kacheong Poon , Mark Allman , TSV WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Max Burst again 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/Kacheong/All: I have been doing a bit of poking around on the max.burst issue. I have not adjusted the KAME-SCTP stack so that you can apply max-burst in either the "Kacheong" method i.e. counting packets... or the "Mark" method of adjusting the cwnd (default is the kacheong method :>). I have done a few preliminary studies...I do need more work yet to prove anything conclusive though.. my findings are so far: 1) It does not seem to make a difference on a LAN 100Meg link as to if we use either options. I tranfer in roughly the same time a large elephant type transfer. And it seems to run at about line-rate. 2) It is true that the cwnd seems to get to be a much larger value on the Kacheong method... close to the rwnd... but I think the max.burst kicking in aka 4 packets sent.. shuts down further sending... 3) Without a maxburst (of any type) it appears that I over-send to the network card and actually drop packets... need to test this again ... but this causes a decrease in performance. 4) There is one issue that I think may be a bad thing for the kacheong method. Consider a sender doing: while(1){ send(100-bytes); } with nagle off... What I have seen in the above case is oversending by the sender. The reason being the cwnd is never blocking us. What seems to occur is the sack comes in and we burst out 4 packets.. then right behind that a send comes in from the user and we burst out 4 packets. Now this assumes a very high send-side socket buffer (I have both the receive/send sockbuf's at 512k).... and it may be an extreme example.. but it does show a weakness to the counting packets method I think... aka an opportunity to send is not only on a SACK but also possibly on a user send... which means you do have the potential to burst out packets in larger than maxburst. With the "Mark" method.. the cwnd is adjusted down and gates you at maxburst packets... so when the user sends presto... no packets are sent since the full cwnd is used up already... I need to do a bit more study on the two issues .. and I would like to get on a Gigabity e-net.. which will have to wait until I get another large server (sometime in August)... I am curious to see if higher speed will also have an effect on use of the bandwidth.. R _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jun 19 09:12: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 JAA16438 for ; Thu, 19 Jun 2003 09:12:00 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JDBWf28376 for tsvwg-archive@odin.ietf.org; Thu, 19 Jun 2003 09:11:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sygy-0005ZF-Uc; Thu, 19 Jun 2003 08:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SyGA-0003sT-Ob for tsvwg@optimus.ietf.org; Thu, 19 Jun 2003 08:11:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11336 for ; Thu, 19 Jun 2003 08:11:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SyDs-0002Fl-00 for tsvwg@ietf.org; Thu, 19 Jun 2003 08:09:00 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19SyDs-0002FV-00 for tsvwg@ietf.org; Thu, 19 Jun 2003 08:09:00 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h5JCAgHu056130; Thu, 19 Jun 2003 07:10:43 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EF1A842.3020904@stewart.chicago.il.us> Date: Thu, 19 Jun 2003 07:10:42 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kacheong Poon , Mark Allman , TSV WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Max Burst again 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/Kacheong/All: I have been doing a bit of poking around on the max.burst issue. I have not adjusted the KAME-SCTP stack so that you can apply max-burst in either the "Kacheong" method i.e. counting packets... or the "Mark" method of adjusting the cwnd (default is the kacheong method :>). I have done a few preliminary studies...I do need more work yet to prove anything conclusive though.. my findings are so far: 1) It does not seem to make a difference on a LAN 100Meg link as to if we use either options. I tranfer in roughly the same time a large elephant type transfer. And it seems to run at about line-rate. 2) It is true that the cwnd seems to get to be a much larger value on the Kacheong method... close to the rwnd... but I think the max.burst kicking in aka 4 packets sent.. shuts down further sending... 3) Without a maxburst (of any type) it appears that I over-send to the network card and actually drop packets... need to test this again ... but this causes a decrease in performance. 4) There is one issue that I think may be a bad thing for the kacheong method. Consider a sender doing: while(1){ send(100-bytes); } with nagle off... What I have seen in the above case is oversending by the sender. The reason being the cwnd is never blocking us. What seems to occur is the sack comes in and we burst out 4 packets.. then right behind that a send comes in from the user and we burst out 4 packets. Now this assumes a very high send-side socket buffer (I have both the receive/send sockbuf's at 512k).... and it may be an extreme example.. but it does show a weakness to the counting packets method I think... aka an opportunity to send is not only on a SACK but also possibly on a user send... which means you do have the potential to burst out packets in larger than maxburst. With the "Mark" method.. the cwnd is adjusted down and gates you at maxburst packets... so when the user sends presto... no packets are sent since the full cwnd is used up already... I need to do a bit more study on the two issues .. and I would like to get on a Gigabity e-net.. which will have to wait until I get another large server (sometime in August)... I am curious to see if higher speed will also have an effect on use of the bandwidth.. R _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jun 19 19:36: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 TAA25445 for ; Thu, 19 Jun 2003 19:36:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JNa8E08254 for tsvwg-archive@odin.ietf.org; Thu, 19 Jun 2003 19:36:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T8wj-00028I-Bs; Thu, 19 Jun 2003 19:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T8w9-000282-I9 for tsvwg@optimus.ietf.org; Thu, 19 Jun 2003 19:35:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25436 for ; Thu, 19 Jun 2003 19:35:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T8tr-0004hZ-00 for tsvwg@ietf.org; Thu, 19 Jun 2003 19:33:03 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19T8tq-0004hW-00 for tsvwg@ietf.org; Thu, 19 Jun 2003 19:33:02 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h5JNZNe3092779 for ; Thu, 19 Jun 2003 16:35:23 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200306192335.h5JNZNe3092779@cougar.icir.org> To: TSV WG list From: Sally Floyd Date: Thu, 19 Jun 2003 16:35:23 -0700 Subject: [Tsvwg] Taking NewReno 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: , We have submitted draft-ietf-tsvwg-newreno-00.txt to the internet-drafts repository. A local copy is at: http://www.icir.org/floyd/papers/draft-ietf-tsvwg-newreno-00.txt This is a revised version of draft-floyd-newreno-00.txt, and differs from it as follows: Changes from draft-floyd-newreno-00.txt: * In Section 8 on "Implementation issues for the data sender", mentioned alternate methods for limiting bursts when exiting Fast Recovery. * Changed draft from draft-floyd-newreno to draft-ietf-tsvwg-newreno Section 8, which contains the only change other than the title, is appended below. The change to Section 8 is basically the addition of the last two sentences. We are asking that this be considered for advancement to Proposed Standard. Many thanks, Sally and Tom 8. Implementation issues for the data sender. In Section 3, Step 5 above, it is noted that implementations should take measures to avoid a possible burst of data when leaving Fast Recovery, in case the amount of new data that the sender is eligible to send due to the new value of the congestion window is large. This can arise during NewReno when ACKs are lost or treated as pure window updates, thereby causing the sender to underestimate the number of new segments that can be sent during the recovery procedure. Specifically, bursts can occur when the FlightSize is much less than the new congestion window when exiting from Fast Recovery. One simple mechanism to avoid a burst of data when leaving Fast Recovery is to limit the number of data packets that can be sent in response to a single acknowledgment. (This is known as "maxburst_" in the ns simulator.) Other possible mechanisms for avoiding bursts include rate-based pacing, or setting the slow-start threshold to the resultant congestion window and then resetting the congestion window to FlightSize. A recommendation on the general mechanism to avoid excessively bursty sending patterns is outside the scope of this document. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jun 19 20:14: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 UAA26384 for ; Thu, 19 Jun 2003 20:14:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5K0E2918065 for tsvwg-archive@odin.ietf.org; Thu, 19 Jun 2003 20:14:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T9XU-0004gb-OW; Thu, 19 Jun 2003 20:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T9Wz-0004gO-MV for tsvwg@optimus.ietf.org; Thu, 19 Jun 2003 20:13:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26363 for ; Thu, 19 Jun 2003 20:13:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T9Ug-0004vd-00 for tsvwg@ietf.org; Thu, 19 Jun 2003 20:11:06 -0400 Received: from pec.etri.re.kr ([129.254.114.50]) by ietf-mx with esmtp (Exim 4.12) id 19T9Uf-0004vZ-00 for tsvwg@ietf.org; Thu, 19 Jun 2003 20:11:06 -0400 Received: from LocalHost (sjkoh.etri.re.kr [129.254.112.15]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h5K0Q2900666 for ; Fri, 20 Jun 2003 09:26:02 +0900 (KST) Message-ID: <001301c336c0$8e0b93d0$0f70fe81@LocalHost> From: "Seok Joo Koh" To: Date: Fri, 20 Jun 2003 09:11:54 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] mobile 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 everybody The mSCTP (mobile SCTP) I-D has been uploaded at http://www.ietf.org/internet-drafts/draft-sjkoh-sctp-mobility-02.txt This aims at fostering the discussion on the use of SCTP for IP mobility. Any comments or feedbacks will be appreciated. Thanks for your attentions ! Yours faithfully, Seok J. Koh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jun 20 07:36: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 HAA26656 for ; Fri, 20 Jun 2003 07:36:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KBa5a20008 for tsvwg-archive@odin.ietf.org; Fri, 20 Jun 2003 07:36:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKBW-00059w-Ip; Fri, 20 Jun 2003 07:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKBM-00056j-Lp for tsvwg@optimus.ietf.org; Fri, 20 Jun 2003 07:35:52 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26515; Fri, 20 Jun 2003 07:35:50 -0400 (EDT) Message-Id: <200306201135.HAA26515@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: tsvwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 20 Jun 2003 07:35:50 -0400 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-prsctp-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : SCTP Partial Reliability Extension Author(s) : R. Stewart et al. Filename : draft-ietf-tsvwg-prsctp-00.txt Pages : 27 Date : 2003-6-19 This memo describes an extension to the Stream Control Transmission Protocol (SCTP) RFC2960 [5] that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes (1) the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type (2) one example partially reliable service that can be provided to the upper layer via this mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-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-tsvwg-prsctp-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-tsvwg-prsctp-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 Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-19154449.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-prsctp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-prsctp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-19154449.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jun 20 14:31: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 OAA24376 for ; Fri, 20 Jun 2003 14:31:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KIV6Y08825 for tsvwg-archive@odin.ietf.org; Fri, 20 Jun 2003 14:31:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQf8-0002CS-8M; Fri, 20 Jun 2003 14:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQeT-00026Q-Ia for tsvwg@optimus.ietf.org; Fri, 20 Jun 2003 14:30:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24050; Fri, 20 Jun 2003 14:30:17 -0400 (EDT) Message-Id: <200306201830.OAA24050@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: tsvwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 20 Jun 2003 14:30:17 -0400 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-newreno-00.txt,.ps 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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : The NewReno Modification to TCP's Fast Recovery Algorithm Author(s) : S. Floyd, T. Henderson Filename : draft-ietf-tsvwg-newreno-00.txt,.ps Pages : 15 Date : 2003-6-20 RFC 2581 [RFC2581] documents the following four intertwined TCP congestion control algorithms: Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery. RFC 2581 [RFC2581] explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option [RFC2018], and modifications that respond to 'partial acknowledgments' (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. The NewReno mechanism described in this document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This response to partial acknowledgments was first proposed by Janey Hoe in [Hoe95]. RFC 2582 [RFC2582] specified the NewReno mechanisms as Experimental in 1999. This document is a small revision of RFC 2582 intended to advance the NewReno mechanisms to Proposed Standard. RFC 2581 notes that the Fast Retransmit/Fast Recovery algorithm specified in that document does not recover very efficiently from multiple losses in a single flight of packets, and that RFC 2582 contains one set of modifications to address this problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-newreno-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-tsvwg-newreno-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-tsvwg-newreno-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 Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-20140902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-newreno-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-newreno-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-20140902.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sun Jun 22 17: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 RAA19090 for ; Sun, 22 Jun 2003 17:24:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5MLO7514525 for tsvwg-archive@odin.ietf.org; Sun, 22 Jun 2003 17:24:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UCJd-0003lV-3B; Sun, 22 Jun 2003 17:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UCJX-0003lK-3t for tsvwg@optimus.ietf.org; Sun, 22 Jun 2003 17:23:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19066 for ; Sun, 22 Jun 2003 17:23:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UCIz-0005cI-00 for tsvwg@ietf.org; Sun, 22 Jun 2003 17:23:21 -0400 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 19UCIp-0005cD-00 for tsvwg@ietf.org; Sun, 22 Jun 2003 17:23:11 -0400 Received: from chiimc01.npac.com ([10.32.90.4]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id h5MLLLN27300 for ; Sun, 22 Jun 2003 21:21:21 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Sun, 22 Jun 2003 16:24:03 -0500 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257BA5@stntexch2.va.neustar.com> From: "Peterson, Jon" To: tsvwg@ietf.org Date: Sun, 22 Jun 2003 16:21:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Tsvwg] WGLC on draft-ietf-tsvwg-prsctp-00 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 chairs would like to initate a two week working group last call for the PR SCTP draft commencing Monday 6/23/2003. Please direct all relevant comments to this list. Thanks! Jon Peterson NeuStar, Inc. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sun Jun 22 20:42: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 UAA22865 for ; Sun, 22 Jun 2003 20:42:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N0g4G01073 for tsvwg-archive@odin.ietf.org; Sun, 22 Jun 2003 20:42:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UFPF-0000HB-F8; Sun, 22 Jun 2003 20:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UFP4-0000Gz-RA for tsvwg@optimus.ietf.org; Sun, 22 Jun 2003 20:41:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22834 for ; Sun, 22 Jun 2003 20:41:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UFOn-0006EK-00 for tsvwg@ietf.org; Sun, 22 Jun 2003 20:41:33 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 19UFOc-0006Ds-00 for tsvwg@ietf.org; Sun, 22 Jun 2003 20:41:22 -0400 Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h5N0eAC01853 for ; Mon, 23 Jun 2003 00:40:10 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Sun, 22 Jun 2003 20:40:50 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257BAE@stntexch2.va.neustar.com> From: "Peterson, Jon" To: tsvwg@ietf.org Date: Sun, 22 Jun 2003 20:40:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Tsvwg] agenda slots in for 57th IETF in Vienna 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 chairs are soliciting agenda items for the meeting of TSVWG working group at the 57th IETF in Vienna. We have received some requests already (so you do not need to resubmit if you have already asked us for a slot). Please send requests to Allison and myself. Jon Peterson NeuStar, Inc. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Jun 23 08:46: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 IAA18485 for ; Mon, 23 Jun 2003 08:46:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NCk4s28831 for tsvwg-archive@odin.ietf.org; Mon, 23 Jun 2003 08:46:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UQhu-0007Uu-1S; Mon, 23 Jun 2003 08:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UQh5-0007UH-TK for tsvwg@optimus.ietf.org; Mon, 23 Jun 2003 08:45:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18469 for ; Mon, 23 Jun 2003 08:45:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UQh4-0001sm-00 for tsvwg@ietf.org; Mon, 23 Jun 2003 08:45:10 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 19UQgu-0001sD-00 for tsvwg@ietf.org; Mon, 23 Jun 2003 08:45:00 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id A127268956 for ; Mon, 23 Jun 2003 08:44:09 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.grc.nasa.gov [139.88.122.88]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h5NCi9uW005349; Mon, 23 Jun 2003 08:44:09 -0400 (EDT) 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 IAA70847; Mon, 23 Jun 2003 08:44:08 -0400 (EDT) Message-Id: <200306231244.IAA70847@guns.lerc.nasa.gov> To: tsvwg@ietf.org Cc: Urtzi Ayesta , "Joshua T. Blanton" , Konstantin.Avratchenkov@sophia.inria.fr From: Mark Allman Reply-To: mallman@grc.nasa.gov Organization: BBN Technologies/NASA GRC Song-of-the-Day: Night Moves Date: Mon, 23 Jun 2003 08:44:08 -0400 Subject: [Tsvwg] new rev of early retransmit i-d 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- We have just sent off a new rev of the Early Retransmit i-d to the archives. It should show up shortly. You can slurp it from: http://roland.grc.nasa.gov/~mallman/papers/draft-allman-tcp-early-rexmt-01.txt now. The changes in this version... * general cleanup * incorporated SCTP into the draft We believe the technique applies to both protocols and including SCTP seemed relatively straightforward. We'd love to hear comments on whether this melding of TCP and SCTP works or not. * did some cleanup and streamlining of the appendix (future research) I believe this draft now represents the consensus of this group given our last go around where most folks picked "option B" - which is what was (and is) codified in the draft. We'd be interested in contrarian viewpoints, though (scoped to this i-d, preferably!). 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 exim@www1.ietf.org Tue Jun 24 07:01: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 HAA11421 for ; Tue, 24 Jun 2003 07:01:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OB16o22806 for tsvwg-archive@odin.ietf.org; Tue, 24 Jun 2003 07:01:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UlXr-0005sp-4Q; Tue, 24 Jun 2003 07:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UlXm-0005ql-Ov for tsvwg@optimus.ietf.org; Tue, 24 Jun 2003 07:00:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11322; Tue, 24 Jun 2003 07:00:53 -0400 (EDT) Message-Id: <200306241100.HAA11322@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: tsvwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 24 Jun 2003 07:00:53 -0400 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-dsack-use-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions Author(s) : E. Blanton, M. Allman Filename : draft-ietf-tsvwg-dsack-use-00.txt Pages : 0 Date : 2003-6-23 TCP and SCTP provide notification of duplicate segment receipt through DSACK and Duplicate TSN notification, respectively. This document presents a conservative method of using this information to identify unnecessary retransmissions for various applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-dsack-use-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-tsvwg-dsack-use-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-tsvwg-dsack-use-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 Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-23142600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-dsack-use-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-dsack-use-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-23142600.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jun 24 12:16: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 MAA22258 for ; Tue, 24 Jun 2003 12:16:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OGG5a06381 for tsvwg-archive@odin.ietf.org; Tue, 24 Jun 2003 12:16:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UqSf-0001ea-ID; Tue, 24 Jun 2003 12:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UqRn-0001Vf-Ix for tsvwg@optimus.ietf.org; Tue, 24 Jun 2003 12:15:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22154 for ; Tue, 24 Jun 2003 12:15:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UqRm-00041g-00 for tsvwg@ietf.org; Tue, 24 Jun 2003 12:15:06 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19UqRb-00040w-00 for tsvwg@ietf.org; Tue, 24 Jun 2003 12:14:55 -0400 Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 4.14) id 19UqQy-000JzP-SH; Tue, 24 Jun 2003 16:14:16 +0000 To: tsvwg@ietf.org Cc: mankin@psg.com, jon.peterson@neustar.biz Reply-To: mankin@psg.com Date: Tue, 24 Jun 2003 09:14:16 -0700 From: Allison Mankin Message-Id: Subject: [Tsvwg] TSVWG agenda building 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: , TSVWG will meet on Friday in Vienna - we have a little more time this time. We'll have an area overview, and we have several other topics already lined up including Gbit TCP, Advancing NewReno to PS, and the MH per hop behavior (more details to come). Please send additional requests for agenda time to Jon and me. Allison _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jun 26 08:26: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 IAA18790 for ; Thu, 26 Jun 2003 08:26:13 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QCPjq07493 for tsvwg-archive@odin.ietf.org; Thu, 26 Jun 2003 08:25:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VVoD-0001p7-J9; Thu, 26 Jun 2003 08:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VVnW-0001nO-8Z for tsvwg@optimus.ietf.org; Thu, 26 Jun 2003 08:24:18 -0400 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18528 for ; Thu, 26 Jun 2003 08:24:15 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5QCO0G5010763 for ; Thu, 26 Jun 2003 14:24:00 +0200 (MEST) Received: from ESEALNT745.al.sw.ericsson.se ([153.88.251.5]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NV4Q80T6; Thu, 26 Jun 2003 14:25:53 +0200 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 14:23:57 +0200 Message-ID: <5E5172B4DE05D311B3AB0008C75DA941123CEF85@edeacnt100.eed.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Sourabh Ladha (EED)" To: "'tsvwg@ietf.org'" Date: Thu, 26 Jun 2003 14:22:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00 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: , Since the draft is for last call, I would be glad to hear comments/clarifications on the following: (i) Consider a scenario, where a chunk is marked "abandoned" by the sender (due to timed reliability or any other newcoming service definition). Consider that the abandoned message was actually lost and that after having marked "abandoned", the sender recieved the 4th missing report for this chunk in a SACK (If sticking to the timed reliability service: if the lifetime expires and is evaluated before the 4th missing report comes in). For a PR-SCTP sender, the chunk is no longer outstanding and it does NOT react (i.e. reduce its cwnd and so on) to this 4th missing report. Note that both reliable and partially reliable messages can be carried in the same association. Isnt congestion a property of the network. If so, then shouldnt the PR-SCTP sender react to this 4th missing report of the abandoned chunk by reducing congestion control state, however it does not need to do a fast retransmit because the data is useless anyway. The draft may point out, that if this is the case, th! en it is being aggressive. This may not be a corner case. (ii) A Forward TSN (FW-TSN) chunk generation algorithm (section 3.5) is followed for every incoming SACK. Consider the scenario: A 1 B -----lost ------2------> . . . ------10-----> dup ack 1 <------------- At this point of time A abandons 1. From now on every dup-ack that comes in may generate a FW-TSN (with the same cum TSN value of 2). So in effect the sender: (a) If the app still has data to send, reduce the effective payload by bundling repetative FW-TSN chunks in the packet. (b) If the app has nothing to send currently, then either: (i) it "MAY" delay the FW-TSN (ii) or it may do a FW-TSN implosion if it is not delayed. Either way the issue is why to send the same FW-TSN over and over again? For large congestion windows and high RTT paths this may cause trouble. (iii) A forward TSN when recieved, updates and normally advances the cum-ACK point. Now, if the chunks prior to that which were "abandoned" by the sender are now recieved (they may have gone through delay or reordering or some other cause), the reciever generates a "fake" dup-tsn report for each of them. This is because the data chunk TSN recieved is behind the current cum-TSN point at the reciever. Not only this adds extra SACK traffic (carrying fake dup-tsn reports which are of no use to the sender) but may also cause problems to certain algorithms (like blanton&allman's "Using dup-tsn to detect spurious retransmissions" ). Since PR-SCTP is not a new transport protocol, it is an extension which very well resides with RFC 2960. So either PR-SCTP reciever may be made capable of not generating these "fake" dup-tsns or the other drafts (proposed or future) which use dup-tsn reports should make an attempt to mention if they work well even when PR-SCTP is enabled in an assoction. (iv) This is sort of a tangent. But, seems like there can be services which remain in the framework of PR-SCTP but are aggressive and can motivate unfriendly applications. I think, the draft dosent stress on the REQUIREMENT for service definitions to be standardized within the IETF. Thanks -Sourabh >From: "Peterson, Jon" >To: tsvwg@ietf.org >Date: Sun, 22 Jun 2003 16:21:54 -0500 >X-Mailer: Internet Mail Service (5.5.2653.19) >Subject: [Tsvwg] WGLC on draft-ietf-tsvwg-prsctp-00 >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: , > >X-OriginalArrivalTime: 22 Jun 2003 21:25:48.0590 (UTC) >FILETIME=[D95CDCE0:01C33904] > > >The chairs would like to initate a two week working group last call for the >PR SCTP draft commencing Monday 6/23/2003. Please direct all relevant >comments to this list. > >Thanks! > >Jon Peterson >NeuStar, Inc. > >_______________________________________________ >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 exim@www1.ietf.org Thu Jun 26 09:40: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 JAA24439 for ; Thu, 26 Jun 2003 09:40:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QDe5X28841 for tsvwg-archive@odin.ietf.org; Thu, 26 Jun 2003 09:40:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VWyo-0007Ux-5d; Thu, 26 Jun 2003 09:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VWy6-0007UA-Rm for tsvwg@optimus.ietf.org; Thu, 26 Jun 2003 09:39:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24364 for ; Thu, 26 Jun 2003 09:39:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VWxp-0001aC-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 09:39:01 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19VWxe-0001Zx-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 09:38:50 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h5QDbDMg058351; Thu, 26 Jun 2003 08:37:35 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EFAF709.7080906@stewart.chicago.il.us> Date: Thu, 26 Jun 2003 08:37:13 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Sourabh Ladha (EED)" CC: "'tsvwg@ietf.org'" Subject: Re: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00 References: <5E5172B4DE05D311B3AB0008C75DA941123CEF85@edeacnt100.eed.ericsson.se> In-Reply-To: <5E5172B4DE05D311B3AB0008C75DA941123CEF85@edeacnt100.eed.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: quoted-printable Sourabh Ladha (EED) wrote: >Since the draft is for last call, I would be glad to hear comments/clari= fications on the following: > >(i) Consider a scenario, where a chunk is marked "abandoned" by the send= er (due to timed reliability or any other newcoming service definition). = Consider that the abandoned message was actually lost and that after havi= ng marked "abandoned", the sender recieved the 4th missing report for thi= s chunk in a SACK (If sticking to the timed reliability service: if the l= ifetime expires and is evaluated before the 4th missing report comes in).= For a PR-SCTP sender, the chunk is no longer outstanding and it does NOT= react (i.e. reduce its cwnd and so on) to this 4th missing report. Note = that both reliable and partially reliable messages can be carried in the = same association. Isnt congestion a property of the network. If so, then = shouldnt the PR-SCTP sender react to this 4th missing report of the aband= oned chunk by reducing congestion control state, however it does not need= to do a fast retransmit because the data is useless anyway. The draft ma= y point out, that if this is the case, th! > en it is being aggressive. This may not be a corner case. > =20 > We added for the above case: F5) If a decision to "abandon" a chunk is made based on a retransmission decision (e.g T3-Timeout or Fast Retransmit) the appropriate congestion adjustment as specified in RFC2960 MUST be made before any FORWARD TSN chunk is sent. But I can see it may not have been clear enough. Maybe it should be=20 tightened up a bit .. I think the main issue that people forget when looking at PR-SCTP is=20 that just because the sender decides to abandon a chunk does NOT mean that all records of the chunk=20 are dropped... in fact the sender MUST maintain some basic state on the chunk until the=20 Cumulative-Ack point passes the chunk being abandonded... you don't have to maintain the data.. but=20 you DO have to maintain things such as the TSN and strike count etc. Maybe F5) should be reworded: F5) If a decision to "abandon" a chunk is made, no matter how such decisi= on is made, the appropriate congestion adjustment MUST be made as=20 specified in RFC2960 if the chunk later would have been marked for retransmission=20 (e.g. T3-Timeout or Fast Retransmit). I will add the above change to the list of WG-Last call changes if no=20 one objects... > >(ii) A Forward TSN (FW-TSN) chunk generation algorithm (section 3.5) is = followed for every incoming SACK. Consider the scenario: > >A 1 B >-----lost =20 >------2------> > . =09 > . =09 > . =09 >------10-----> > =09 > dup ack 1 =20 ><------------- >At this point of time A abandons 1.=20 > >>From now on every dup-ack that comes in may generate a FW-TSN (with the= same cum TSN value of 2).=20 > >So in effect the sender: >(a) If the app still has data to send, reduce the effective payload by b= undling repetative FW-TSN chunks in the packet. >(b) If the app has nothing to send currently, then either:=20 > (i) it "MAY" delay the FW-TSN=20 > (ii) or it may do a FW-TSN implosion if it is not delayed. > >Either way the issue is why to send the same FW-TSN over and over again?= For large congestion windows and high RTT paths this may cause trouble. = > The reason you must send it until you get a SACK is that you don't know=20 if the peer received it. A Fwd-TSN can be lost just like a data chunk.... A=20 fwd-TSN is relatively small (smaller than a SACK).. I don't see how this is a big=20 issue.. however I suppose we could modify the algorithm a bit and add a rule that states:= No matter if the sender does a delayed FWD-TSN or a FWD-TSN in response to a SACK, the sender MUST NOT send more than one FWD-TSN every RTT. This would then eliminate (ii) as an issue no matter how many SACK's the = peer sends at you ... So how about changing F2) to state: F2) The data sender SHOULD always attempt to bundle an outgoing FORWARD TSN with outbound DATA chunks for efficiency. A sender MAY even choose to delay the sending of the FORWARD TSN in the hope of bundling it with an outbound DATA chunk. But no matt= er if a sender delays a FORWARD TSN or sends one in response to a SACK= , a sender MUST NOT have more than one FORWARD TSN in flight per round trip time. > > >(iii) A forward TSN when recieved, updates and normally advances the cum= -ACK point. Now, if the chunks prior to that which were "abandoned" by th= e sender are now recieved (they may have gone through delay or reordering= or some other cause), the reciever generates a "fake" dup-tsn report for= each of them. This is because the data chunk TSN recieved is behind the = current cum-TSN point at the reciever. Not only this adds extra SACK traf= fic (carrying fake dup-tsn reports which are of no use to the sender) but= may also cause problems to certain algorithms (like blanton&allman's "Us= ing dup-tsn to detect spurious retransmissions" ). Since PR-SCTP is not a= new transport protocol, it is an extension which very well resides with = RFC 2960. So either PR-SCTP reciever may be made capable of not generatin= g these "fake" dup-tsns or the other drafts (proposed or future) which us= e dup-tsn reports should make an attempt to mention if they work well eve= n when PR-SCTP is enabled in an assoction. > =20 > I am missing something here.. what do you mean by 'chunks prior to theat = which were "abandonded"' Do you mean you abandonded it and then later it arrived... or Do you mean you abandoned a chunk 10 and then 8 and 9 arrived? I think the first definition.. if I read your concern correctly .. is=20 what you mean.. I.e. I send a fwd-tsn(10)-------> and then some time later TSN-10 arrives. First of all I think this is a real corner case and does not happen that = often... basically the network must reorder and hold a packet for longer than the RTT time...=20 Yes I realize routing loops and such during convergance may cause this.. but it is a=20 rare event. So I don't see how one extra dup report that is very rare is going cause an = issue... now on to using the dup report.. as I said above, the sender MUST keep track = of things until the cum-ack passes by.... Now looking specifically at=20 blanton/allman it says something to the effect that "the sender MUST detect if the=20 duplicate was retransmitted and if not (i.e. the network duplicated it) stop using the = algorithm"... now this wording was made for network duplications.. but it makes me think=20 of a couple of things: 1) In order to do the above, the cum-ack must NOT have passed the TSN..=20 otherwise the sender would have no way to do the above.... which means you=20 know you skipped it on the sender side... see my above statements on state :->= 2) The statement from blanton/allman would give the impression that the=20 FWD'd chunk was a network duplicate thus disabling the algorithm.. So I think that: a) the blanton/allman document already covers it and b) Once the cum-ack is past a point the blanton-allman document will have= little effect to PR-SCTP or just plain SCTP... > >(iv) This is sort of a tangent. But, seems like there can be services wh= ich remain in the framework of PR-SCTP but are aggressive and can motivat= e unfriendly applications. I think, the draft dosent stress on the REQUIR= EMENT for service definitions to be standardized within the IETF.=20 > =20 > You are off on a tangent here IMO :> ... Please explain to me how=20 PR-SCTP can motivate aggressive behavior? We have had long converstations on this list about=20 this.. and a lot of off-line conversations as well with Mark Allman.. We have not been able=20 to come up with a scenario for this.. I believe at one point (off-line) Phil=20 Conrad offered to do some simulation work on this very issue.. and we could not come up wit= h a valid scenario.. the cwnd is being obeyed by the underlying SCTP=20 stack... the rwnd as well.. how does PR-SCTP make the sender more aggressive? I would contend that PR-SCTP does just the opposite.. in times of=20 congestion it reduces network traffic by taking data OFF the network... can you please specify = something besides a vague statement? If you can come up with a valid scenario I am sure=20 between Phil and I, we could do a simulation or study to prove or dis-prove your=20 contention of aggressiveness... As to the service definition.. maybe you could connect this thought to=20 the aggressive claim above? How would when a decision to abandon being made change the=20 aggressiveness of PR-SCTP.. please consider also the clearication to F5) above .. I would=20 like to know if this is possible that a definition could influence the on-wire=20 performance.. I don't see how.. but as I said.. I would be glad to try to find through=20 simulation or test such a weakness... R > >Thanks >-Sourabh > > > > > =20 > >>From: "Peterson, Jon" >>To: tsvwg@ietf.org >>Date: Sun, 22 Jun 2003 16:21:54 -0500 >>X-Mailer: Internet Mail Service (5.5.2653.19) >>Subject: [Tsvwg] WGLC on draft-ietf-tsvwg-prsctp-00 >>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: , >> >>X-OriginalArrivalTime: 22 Jun 2003 21:25:48.0590 (UTC)=20 >>FILETIME=3D[D95CDCE0:01C33904] >> >> >>The chairs would like to initate a two week working group last call for= the >>PR SCTP draft commencing Monday 6/23/2003. Please direct all relevant >>comments to this list. >> >>Thanks! >> >>Jon Peterson >>NeuStar, Inc. >> >>_______________________________________________ >>tsvwg mailing list >>tsvwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/tsvwg >> =20 >> > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg > > > =20 > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jun 26 10: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 KAA28637 for ; Thu, 26 Jun 2003 10:45:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QEj6922892 for tsvwg-archive@odin.ietf.org; Thu, 26 Jun 2003 10:45:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VXzh-0005vX-68; Thu, 26 Jun 2003 10:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VXyz-0005tF-Fd for tsvwg@optimus.ietf.org; Thu, 26 Jun 2003 10:44:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28513 for ; Thu, 26 Jun 2003 10:43:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VXxu-00027t-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 10:43:10 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[2ZZe1sbuOmto69jz9I7mmEZTudcRGzrb]) by ietf-mx with esmtp (Exim 4.12) id 19VXxd-00027G-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 10:42:54 -0400 Received: from ns.pigworks.openss7.net (IDENT:K78kBpku4nELsFzdfLvULlqdHi3Y+IhJ@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h5QEgFX27199; Thu, 26 Jun 2003 08:42:15 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h5QEgE003820; Thu, 26 Jun 2003 08:42:14 -0600 Date: Thu, 26 Jun 2003 08:42:14 -0600 From: "Brian F. G. Bidulock" To: "Randall R. Stewart (home)" Cc: "Sourabh Ladha (EED)" , "'tsvwg@ietf.org'" Subject: Re: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00 Message-ID: <20030626084214.A3522@openss7.org> Reply-To: bidulock@openss7.org References: <5E5172B4DE05D311B3AB0008C75DA941123CEF85@edeacnt100.eed.ericsson.se> <3EFAF709.7080906@stewart.chicago.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3EFAF709.7080906@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Thu, Jun 26, 2003 at 08:37:13AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id h5QEgFX27199 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Randall, On Thu, 26 Jun 2003, Randall Stewart wrote: > Sourabh Ladha (EED) wrote: >=20 > >Since the draft is for last call, I would be glad to hear > >comments/clarifications on the following: > > > >(i) Consider a scenario, where a chunk is marked "abandoned" by the se= nder > >(due to timed reliability or any other newcoming service definition). > >Consider that the abandoned message was actually lost and that after h= aving > >marked "abandoned", the sender recieved the 4th missing report for thi= s > >chunk in a SACK (If sticking to the timed reliability service: if the > >lifetime expires and is evaluated before the 4th missing report comes = in). > >For a PR-SCTP sender, the chunk is no longer outstanding and it does N= OT > >react (i.e. reduce its cwnd and so on) to this 4th missing report. Not= e > >that both reliable and partially reliable messages can be carried in t= he > >same association. Isnt congestion a property of the network. If so, th= en > >shouldnt the PR-SCTP sender react to this 4th missing report of the > >abandoned chunk by reducing congestion control state, however it does = not > >need to do a fast retransmit because the data is useless anyway. The d= raft > >may point out, that if this is the case, th! en it is being aggressiv= e. > >This may not be a corner case. > > =20 > > >=20 > We added for the above case: >=20 > F5) If a decision to "abandon" a chunk is made based on a > retransmission decision (e.g T3-Timeout or Fast Retransmit) the > appropriate congestion adjustment as specified in RFC2960 MUST be > made before any FORWARD TSN chunk is sent. >=20 >=20 > But I can see it may not have been clear enough. Maybe it should be=20 > tightened up a bit .. >=20 > I think the main issue that people forget when looking at PR-SCTP is th= at > just because the sender decides to abandon a chunk does NOT mean that a= ll > records of the chunk are dropped... in fact the sender MUST maintain so= me > basic state on the chunk until the Cumulative-Ack point passes the chun= k > being abandonded... you don't have to maintain the data.. but you DO ha= ve to > maintain things such as the TSN and strike count etc. >=20 > Maybe F5) should be reworded: >=20 > F5) If a decision to "abandon" a chunk is made, no matter how such deci= sion > is made, the appropriate congestion adjustment MUST be made as spec= ified > in RFC2960 if the chunk later would have been marked for retransmis= sion > (e.g. T3-Timeout or Fast Retransmit). >=20 >=20 > I will add the above change to the list of WG-Last call changes if no o= ne > objects... The above sounds fine to me. >=20 >=20 >=20 > > > >(ii) A Forward TSN (FW-TSN) chunk generation algorithm (section 3.5) i= s > >followed for every incoming SACK. Consider the scenario: > > > >A 1 B > >-----lost =20 > >------2------> > > . =09 > > . =09 > > . =09 > >------10-----> > > =09 > > dup ack 1 =20 > ><------------- > >At this point of time A abandons 1.=20 > > > >From now on every dup-ack that comes in may generate a FW-TSN (with th= e > >same cum TSN value of 2).=20 > > > >So in effect the sender: > >(a) If the app still has data to send, reduce the effective payload by > > bundling repetative FW-TSN chunks in the packet. > >(b) If the app has nothing to send currently, then either:=20 > > (i) it "MAY" delay the FW-TSN=20 > > (ii) or it may do a FW-TSN implosion if it is not delayed. > > > >Either way the issue is why to send the same FW-TSN over and over agai= n? > >For large congestion windows and high RTT paths this may cause trouble= .=20 > > >=20 > The reason you must send it until you get a SACK is that you don't know= if > the peer received it. A Fwd-TSN can be lost just like a data chunk.... = A > fwd-TSN is relatively small (smaller than a SACK).. I don't see how thi= s is > a big issue.. however I suppose we could modify the algorithm a bit and= add > a rule that states: >=20 > No matter if the sender does a delayed FWD-TSN or a FWD-TSN in response= to a > SACK, the sender MUST NOT send more than one FWD-TSN every RTT. >=20 > This would then eliminate (ii) as an issue no matter how many SACK's th= e > peer sends at you ... >=20 >=20 > So how about changing F2) to state: >=20 > F2) The data sender SHOULD always attempt to bundle an outgoing > FORWARD TSN with outbound DATA chunks for efficiency. >=20 > A sender MAY even choose to delay the sending of the FORWARD TSN > in the hope of bundling it with an outbound DATA chunk. But no ma= tter > if a sender delays a FORWARD TSN or sends one in response to a SA= CK, > a sender MUST NOT have more than one FORWARD TSN in flight per > round trip time. I disagree. The receiver is allowed to have more than one SACK in flight per RTT, why is the sender not allowed to have one FORWARD TSN per SACK? If the FORWARD TSNs cause problems, then so will the SACKs alone. If there is a problem here, it is with the SACKs. >=20 >=20 > > > > > >(iii) A forward TSN when recieved, updates and normally advances the > >cum-ACK point. Now, if the chunks prior to that which were "abandoned"= by > >the sender are now recieved (they may have gone through delay or reord= ering > >or some other cause), the reciever generates a "fake" dup-tsn report f= or > >each of them. This is because the data chunk TSN recieved is behind th= e > >current cum-TSN point at the reciever. Not only this adds extra SACK > >traffic (carrying fake dup-tsn reports which are of no use to the send= er) > >but may also cause problems to certain algorithms (like blanton&allman= 's > >"Using dup-tsn to detect spurious retransmissions" ). Since PR-SCTP is= not > >a new transport protocol, it is an extension which very well resides w= ith > >RFC 2960. So either PR-SCTP reciever may be made capable of not genera= ting > >these "fake" dup-tsns or the other drafts (proposed or future) which u= se > >dup-tsn reports should make an attempt to mention if they work well ev= en > >when PR-SCTP is enabled in an assoction. > > =20 > > >=20 > I am missing something here.. what do you mean by 'chunks prior to thea= t=20 > which were "abandonded"' >=20 > Do you mean you abandonded it and then later it arrived... >=20 > or >=20 > Do you mean you abandoned a chunk 10 and then 8 and 9 arrived? >=20 > I think the first definition.. if I read your concern correctly .. is=20 > what you mean.. >=20 > I.e. I send a fwd-tsn(10)-------> >=20 > and then some time later TSN-10 arrives. >=20 > First of all I think this is a real corner case and does not happen tha= t > often... basically the network must reorder and hold a packet for longe= r > than the RTT time... Yes I realize routing loops and such during > convergance may cause this.. but it is a rare event. So I don't see how= one > extra dup report that is very rare is going cause an issue... now on to > using the dup report.. as I said above, the sender MUST keep track of t= hings > until the cum-ack passes by.... Now looking specifically at blanton/all= man > it says something to the effect that "the sender MUST detect if the > duplicate was retransmitted and if not (i.e. the network duplicated it)= stop > using the algorithm"... now this wording was made for network duplicati= ons.. > but it makes me think of a couple of things: >=20 > 1) In order to do the above, the cum-ack must NOT have passed the TSN.. > otherwise the sender would have no way to do the above.... which means = you > know you skipped it on the sender side... see my above statements on st= ate > :-> >=20 > 2) The statement from blanton/allman would give the impression that the > FWD'd chunk was a network duplicate thus disabling the algorithm.. >=20 > So I think that: >=20 > a) the blanton/allman document already covers it > and > b) Once the cum-ack is past a point the blanton-allman document will ha= ve > little effect to PR-SCTP or just plain SCTP... >=20 I think is is the responsibility of these other drafts to consider PR-SCTP, rather than visa versa. >=20 >=20 > > > >(iv) This is sort of a tangent. But, seems like there can be services = which > >remain in the framework of PR-SCTP but are aggressive and can motivate > >unfriendly applications. I think, the draft dosent stress on the > >REQUIREMENT for service definitions to be standardized within the IETF= .=20 > > =20 > > > You are off on a tangent here IMO :> ... Please explain to me how PR-S= CTP > can motivate aggressive behavior? We have had long converstations on th= is > list about this.. and a lot of off-line conversations as well with Mark > Allman.. We have not been able to come up with a scenario for this.. I > believe at one point (off-line) Phil Conrad offered to do some simulati= on > work on this very issue.. and we could not come up with a valid scenari= o.. > the cwnd is being obeyed by the underlying SCTP stack... the rwnd as we= ll.. > how does PR-SCTP make the sender more aggressive? >=20 > I would contend that PR-SCTP does just the opposite.. in times of conge= stion > it reduces network traffic by taking data OFF the network... can you pl= ease > specify something besides a vague statement? If you can come up with a = valid > scenario I am sure between Phil and I, we could do a simulation or stud= y to > prove or dis-prove your contention of aggressiveness... >=20 > As to the service definition.. maybe you could connect this thought to = the > aggressive claim above? How would when a decision to abandon being made > change the aggressiveness of PR-SCTP.. please consider also the clearic= ation > to F5) above .. I would like to know if this is possible that a definit= ion > could influence the on-wire performance.. I don't see how.. but as I sa= id.. > I would be glad to try to find through simulation or test such a weakne= ss... I think we had this discussion already and came to concensus that this discussion has much greater scope that PR-SCTP and PR-SCTP should not be held up waiting for this greater discussion to occur or conclude. --brian --=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 From exim@www1.ietf.org Thu Jun 26 11:00: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 LAA29469 for ; Thu, 26 Jun 2003 11:00:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QF05226802 for tsvwg-archive@odin.ietf.org; Thu, 26 Jun 2003 11:00:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYED-0006xO-Sn; Thu, 26 Jun 2003 11:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYDg-0006vo-45 for tsvwg@optimus.ietf.org; Thu, 26 Jun 2003 10:59:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29380 for ; Thu, 26 Jun 2003 10:59:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VYDd-0002Kl-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 10:59:25 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19VYDR-0002Ja-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 10:59:13 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h5QEvZMg058765; Thu, 26 Jun 2003 09:57:35 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EFB09DF.3000304@stewart.chicago.il.us> Date: Thu, 26 Jun 2003 09:57:35 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: "Sourabh Ladha (EED)" , "'tsvwg@ietf.org'" Subject: Re: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00 References: <5E5172B4DE05D311B3AB0008C75DA941123CEF85@edeacnt100.eed.ericsson.se> <3EFAF709.7080906@stewart.chicago.il.us> <20030626084214.A3522@openss7.org> In-Reply-To: <20030626084214.A3522@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, > >On Thu, 26 Jun 2003, Randall Stewart wrote: > > > >>Sourabh Ladha (EED) wrote: >> >> >> >>>Since the draft is for last call, I would be glad to hear >>>comments/clarifications on the following: >>> >>>(i) Consider a scenario, where a chunk is marked "abandoned" by the sender >>>(due to timed reliability or any other newcoming service definition). >>>Consider that the abandoned message was actually lost and that after having >>>marked "abandoned", the sender recieved the 4th missing report for this >>>chunk in a SACK (If sticking to the timed reliability service: if the >>>lifetime expires and is evaluated before the 4th missing report comes in). >>>For a PR-SCTP sender, the chunk is no longer outstanding and it does NOT >>>react (i.e. reduce its cwnd and so on) to this 4th missing report. Note >>>that both reliable and partially reliable messages can be carried in the >>>same association. Isnt congestion a property of the network. If so, then >>>shouldnt the PR-SCTP sender react to this 4th missing report of the >>>abandoned chunk by reducing congestion control state, however it does not >>>need to do a fast retransmit because the data is useless anyway. The draft >>>may point out, that if this is the case, th! en it is being aggressive. >>>This may not be a corner case. >>> >>> >>> >>> >>We added for the above case: >> >>F5) If a decision to "abandon" a chunk is made based on a >> retransmission decision (e.g T3-Timeout or Fast Retransmit) the >> appropriate congestion adjustment as specified in RFC2960 MUST be >> made before any FORWARD TSN chunk is sent. >> >> >>But I can see it may not have been clear enough. Maybe it should be >>tightened up a bit .. >> >>I think the main issue that people forget when looking at PR-SCTP is that >>just because the sender decides to abandon a chunk does NOT mean that all >>records of the chunk are dropped... in fact the sender MUST maintain some >>basic state on the chunk until the Cumulative-Ack point passes the chunk >>being abandonded... you don't have to maintain the data.. but you DO have to >>maintain things such as the TSN and strike count etc. >> >>Maybe F5) should be reworded: >> >>F5) If a decision to "abandon" a chunk is made, no matter how such decision >> is made, the appropriate congestion adjustment MUST be made as specified >> in RFC2960 if the chunk later would have been marked for retransmission >> (e.g. T3-Timeout or Fast Retransmit). >> >> >>I will add the above change to the list of WG-Last call changes if no one >>objects... >> >> > >The above sounds fine to me. > > > >> >> >> >>>(ii) A Forward TSN (FW-TSN) chunk generation algorithm (section 3.5) is >>>followed for every incoming SACK. Consider the scenario: >>> >>>A 1 B >>>-----lost >>>------2------> >>> . >>> . >>> . >>>------10-----> >>> >>> dup ack 1 >>><------------- >>>At this point of time A abandons 1. >>> >>> >>> >>>From now on every dup-ack that comes in may generate a FW-TSN (with the >> >> >>>same cum TSN value of 2). >>> >>>So in effect the sender: >>>(a) If the app still has data to send, reduce the effective payload by >>> bundling repetative FW-TSN chunks in the packet. >>> >>> > > > >>>(b) If the app has nothing to send currently, then either: >>> (i) it "MAY" delay the FW-TSN >>> (ii) or it may do a FW-TSN implosion if it is not delayed. >>> >>>Either way the issue is why to send the same FW-TSN over and over again? >>>For large congestion windows and high RTT paths this may cause trouble. >>> >>> >>> >>The reason you must send it until you get a SACK is that you don't know if >>the peer received it. A Fwd-TSN can be lost just like a data chunk.... A >>fwd-TSN is relatively small (smaller than a SACK).. I don't see how this is >>a big issue.. however I suppose we could modify the algorithm a bit and add >>a rule that states: >> >>No matter if the sender does a delayed FWD-TSN or a FWD-TSN in response to a >>SACK, the sender MUST NOT send more than one FWD-TSN every RTT. >> >>This would then eliminate (ii) as an issue no matter how many SACK's the >>peer sends at you ... >> >> >>So how about changing F2) to state: >> >> F2) The data sender SHOULD always attempt to bundle an outgoing >> FORWARD TSN with outbound DATA chunks for efficiency. >> >> A sender MAY even choose to delay the sending of the FORWARD TSN >> in the hope of bundling it with an outbound DATA chunk. But no matter >> if a sender delays a FORWARD TSN or sends one in response to a SACK, >> a sender MUST NOT have more than one FORWARD TSN in flight per >> round trip time. >> >> > >I disagree. The receiver is allowed to have more than one SACK in flight >per RTT, why is the sender not allowed to have one FORWARD TSN per SACK? > >If the FORWARD TSNs cause problems, then so will the SACKs alone. > >If there is a problem here, it is with the SACKs. > > That is a good point... the FWD-TSN's are generally even smaller than the SACKs... Delaying the FWD-TSN could in theory cause held data at the reciever to remain there longer... its definetly a trade-off.. What do others think? worth worrying about... or better left alone?? > > >> >> >>>(iii) A forward TSN when recieved, updates and normally advances the >>>cum-ACK point. Now, if the chunks prior to that which were "abandoned" by >>>the sender are now recieved (they may have gone through delay or reordering >>>or some other cause), the reciever generates a "fake" dup-tsn report for >>>each of them. This is because the data chunk TSN recieved is behind the >>>current cum-TSN point at the reciever. Not only this adds extra SACK >>>traffic (carrying fake dup-tsn reports which are of no use to the sender) >>>but may also cause problems to certain algorithms (like blanton&allman's >>>"Using dup-tsn to detect spurious retransmissions" ). Since PR-SCTP is not >>>a new transport protocol, it is an extension which very well resides with >>>RFC 2960. So either PR-SCTP reciever may be made capable of not generating >>>these "fake" dup-tsns or the other drafts (proposed or future) which use >>>dup-tsn reports should make an attempt to mention if they work well even >>>when PR-SCTP is enabled in an assoction. >>> >>> >>> >>> >>I am missing something here.. what do you mean by 'chunks prior to theat >>which were "abandonded"' >> >>Do you mean you abandonded it and then later it arrived... >> >>or >> >>Do you mean you abandoned a chunk 10 and then 8 and 9 arrived? >> >>I think the first definition.. if I read your concern correctly .. is >>what you mean.. >> >>I.e. I send a fwd-tsn(10)-------> >> >>and then some time later TSN-10 arrives. >> >>First of all I think this is a real corner case and does not happen that >>often... basically the network must reorder and hold a packet for longer >>than the RTT time... Yes I realize routing loops and such during >>convergance may cause this.. but it is a rare event. So I don't see how one >>extra dup report that is very rare is going cause an issue... now on to >>using the dup report.. as I said above, the sender MUST keep track of things >>until the cum-ack passes by.... Now looking specifically at blanton/allman >>it says something to the effect that "the sender MUST detect if the >>duplicate was retransmitted and if not (i.e. the network duplicated it) stop >>using the algorithm"... now this wording was made for network duplications.. >>but it makes me think of a couple of things: >> >>1) In order to do the above, the cum-ack must NOT have passed the TSN.. >>otherwise the sender would have no way to do the above.... which means you >>know you skipped it on the sender side... see my above statements on state >>:-> >> >>2) The statement from blanton/allman would give the impression that the >>FWD'd chunk was a network duplicate thus disabling the algorithm.. >> >>So I think that: >> >>a) the blanton/allman document already covers it >>and >>b) Once the cum-ack is past a point the blanton-allman document will have >> little effect to PR-SCTP or just plain SCTP... >> >> >> > >I think is is the responsibility of these other drafts to consider >PR-SCTP, rather than visa versa. > > Yeah, its really kind of hard for a RFC/draft to figure out what things will be written in the future :> If we could do that, hey we could get rich in the stock market :-D > > >> >> >>>(iv) This is sort of a tangent. But, seems like there can be services which >>>remain in the framework of PR-SCTP but are aggressive and can motivate >>>unfriendly applications. I think, the draft dosent stress on the >>>REQUIREMENT for service definitions to be standardized within the IETF. >>> >>> >>> >>> >>You are off on a tangent here IMO :> ... Please explain to me how PR-SCTP >>can motivate aggressive behavior? We have had long converstations on this >>list about this.. and a lot of off-line conversations as well with Mark >>Allman.. We have not been able to come up with a scenario for this.. I >>believe at one point (off-line) Phil Conrad offered to do some simulation >>work on this very issue.. and we could not come up with a valid scenario.. >>the cwnd is being obeyed by the underlying SCTP stack... the rwnd as well.. >>how does PR-SCTP make the sender more aggressive? >> >>I would contend that PR-SCTP does just the opposite.. in times of congestion >>it reduces network traffic by taking data OFF the network... can you please >>specify something besides a vague statement? If you can come up with a valid >>scenario I am sure between Phil and I, we could do a simulation or study to >>prove or dis-prove your contention of aggressiveness... >> >>As to the service definition.. maybe you could connect this thought to the >>aggressive claim above? How would when a decision to abandon being made >>change the aggressiveness of PR-SCTP.. please consider also the clearication >>to F5) above .. I would like to know if this is possible that a definition >>could influence the on-wire performance.. I don't see how.. but as I said.. >>I would be glad to try to find through simulation or test such a weakness... >> >> > >I think we had this discussion already and came to concensus that this >discussion has much greater scope that PR-SCTP and PR-SCTP should not be >held up waiting for this greater discussion to occur or conclude. > > That is my thought as well.. unless Sourabh has a further clearification to add to this... R >--brian > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jun 26 11:04:28 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 LAA29856 for ; Thu, 26 Jun 2003 11:04:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QF42k28237 for tsvwg-archive@odin.ietf.org; Thu, 26 Jun 2003 11:04:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYI5-0007LK-F5; Thu, 26 Jun 2003 11:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYI1-0007L9-Re for tsvwg@optimus.ietf.org; Thu, 26 Jun 2003 11:03:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29810 for ; Thu, 26 Jun 2003 11:03:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VYHz-0002NX-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 11:03:55 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19VYHo-0002NR-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 11:03:44 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5QF3bG5011199; Thu, 26 Jun 2003 17:03:37 +0200 (MEST) Received: from ESEALNT744.al.sw.ericsson.se ([153.88.251.4]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NV4LZ21V; Thu, 26 Jun 2003 17:03:40 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 17:03:38 +0200 Message-ID: <5E5172B4DE05D311B3AB0008C75DA941123CEF89@edeacnt100.eed.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Sourabh Ladha (EED)" To: "'Randall R. Stewart (home)'" Cc: "'tsvwg@ietf.org'" Subject: RE: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00 Date: Thu, 26 Jun 2003 17:01:57 +0200 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: , Hi Randall, Thanks for the clarification. My comments inline. >We added for the above case: > >F5) If a decision to "abandon" a chunk is made based on a > retransmission decision (e.g T3-Timeout or Fast Retransmit) the > appropriate congestion adjustment as specified in RFC2960 MUST be > made before any FORWARD TSN chunk is sent. > >But I can see it may not have been clear enough. Maybe it should be >tightened up a bit .. > >I think the main issue that people forget when looking at PR-SCTP is >that just because the sender >decides to abandon a chunk does NOT mean that all records of the chunk >are dropped... in fact >the sender MUST maintain some basic state on the chunk until the >Cumulative-Ack point passes >the chunk being abandonded... you don't have to maintain the data.. but >you DO have to maintain >things such as the TSN and strike count etc. > >Maybe F5) should be reworded: > >F5) If a decision to "abandon" a chunk is made, no matter how such decision > is made, the appropriate congestion adjustment MUST be made as >specified in RFC2960 > if the chunk later would have been marked for retransmission >(e.g. T3-Timeout or > Fast Retransmit). >I will add the above change to the list of WG-Last call changes if no >one objects... OK I see the picture. The main confusion started from point A2 which states: "When a data chunk is "abandoned", the sender MUST treat the data chunk as being finally acked and no longer outstanding." coupled with F5 which only allowed congestion control to kick in if the "abondoning" decision was made on a retransmission decision. What may have been mentioned was that if the CumTSNpoint < Advanced.Peer.Ack.Point then all the congestion control mechanisms when needed MUST be applied (or, are still applicable) for the chunks lying between these two points. >The reason you must send it until you get a SACK is that you don't know >if the >peer received it. A Fwd-TSN can be lost just like a data chunk.... A >fwd-TSN is >relatively small (smaller than a SACK).. I don't see how this is a big >issue.. It may very well not be. Timestamps (12 bytes) and other options for TCP have been debataed a lot about adding overheads. But again I am not an expert in this, so if others think that this overhead is permissible then maybe we can go by it. >however >I suppose we could modify the algorithm a bit and add a rule that states: >No matter if the sender does a delayed FWD-TSN or a FWD-TSN in response >to a SACK, the sender MUST NOT send more than one FWD-TSN every RTT. > >This would then eliminate (ii) as an issue no matter how many SACK's the >peer >sends at you ... >So how about changing F2) to state: > > F2) The data sender SHOULD always attempt to bundle an outgoing > FORWARD TSN with outbound DATA chunks for efficiency. > > A sender MAY even choose to delay the sending of the FORWARD TSN > in the hope of bundling it with an outbound DATA chunk. But no matter > if a sender delays a FORWARD TSN or sends one in response to a SACK, > a sender MUST NOT have more than one FORWARD TSN in flight per > round trip time. I may say that will be a feasible solution, but this per RTT rule should be relaxed if the FORWARD TSN is updating the "NewCumTSN" point reported in the last FORWARD TSN . To be clear this per RTT rule (if adopted at all) should only be for duplicate FORWARD TSNs. And this scheme may add some state at the sender? >I am missing something here.. what do you mean by 'chunks prior to theat >which were "abandonded"' >Do you mean you abandonded it and then later it arrived... I meant this. > >I.e. I send a fwd-tsn(10)-------> >and then some time later TSN-10 arrives. > >First of all I think this is a real corner case and does not happen that >often... basically the >network must reorder and hold a packet for longer than the RTT time... Not necessarily an RTT time. It can be less than that. >2) The statement from blanton/allman would give the impression that the >FWD'd chunk was a > network duplicate thus disabling the algorithm.. >So I think that: >a) the blanton/allman document already covers it >and >b) Once the cum-ack is past a point the blanton-allman document will have > little effect to PR-SCTP or just plain SCTP... Well yes maybe a corner case for example consider a sender had retransmitted a chunk (the original transmit being lost). And then abandoned it immediately. Lets assume that the retransmitted chunk reached after the FW-TSN (which can very well be considering multihomed endpoints and retransmission to the alternate). Then the reciever will generate a "fake" dup-tsn report. And blanton-allman's draft will be happy with the dup-tsn report and declare that retransmission spurious. Again I may agree that this is a corner case. >You are off on a tangent here IMO :> ... Please explain to me how >PR-SCTP can motivate >aggressive behavior? We have had long converstations on this list about This comment had nothing to do with previous discussions on PR-SCTP. My comments about being aggressive were only linked to point (i) which I think you have now clarified. Thanks, Sourabh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jun 26 11:28: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 LAA02909 for ; Thu, 26 Jun 2003 11:28:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QFS5807081 for tsvwg-archive@odin.ietf.org; Thu, 26 Jun 2003 11:28:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYfI-0001mI-Or; Thu, 26 Jun 2003 11:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYeW-0001lK-Bv for tsvwg@optimus.ietf.org; Thu, 26 Jun 2003 11:27:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02751 for ; Thu, 26 Jun 2003 11:27:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VYeV-0002gE-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 11:27:11 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19VYeJ-0002ft-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 11:27:00 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h5QFQEMg058931; Thu, 26 Jun 2003 10:26:15 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EFB1096.7000702@stewart.chicago.il.us> Date: Thu, 26 Jun 2003 10:26:14 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Sourabh Ladha (EED)" CC: "'tsvwg@ietf.org'" Subject: Re: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00 References: <5E5172B4DE05D311B3AB0008C75DA941123CEF89@edeacnt100.eed.ericsson.se> In-Reply-To: <5E5172B4DE05D311B3AB0008C75DA941123CEF89@edeacnt100.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 Sourabh Ladha (EED) wrote: >Hi Randall, > >Thanks for the clarification. My comments inline. > > > >>We added for the above case: >> >>F5) If a decision to "abandon" a chunk is made based on a >> retransmission decision (e.g T3-Timeout or Fast Retransmit) the >> appropriate congestion adjustment as specified in RFC2960 MUST be >> made before any FORWARD TSN chunk is sent. >> >>But I can see it may not have been clear enough. Maybe it should be >>tightened up a bit .. >> >>I think the main issue that people forget when looking at PR-SCTP is >>that just because the sender >>decides to abandon a chunk does NOT mean that all records of the chunk >>are dropped... in fact >>the sender MUST maintain some basic state on the chunk until the >>Cumulative-Ack point passes >>the chunk being abandonded... you don't have to maintain the data.. but >>you DO have to maintain >>things such as the TSN and strike count etc. >> >>Maybe F5) should be reworded: >> >>F5) If a decision to "abandon" a chunk is made, no matter how such decision >> is made, the appropriate congestion adjustment MUST be made as >>specified in RFC2960 >> if the chunk later would have been marked for retransmission >>(e.g. T3-Timeout or >> Fast Retransmit). >>I will add the above change to the list of WG-Last call changes if no >>one objects... >> >> > > >OK I see the picture. The main confusion started from point A2 which states: >"When a data chunk is "abandoned", the sender MUST treat the data chunk as being finally acked and no longer outstanding." coupled with F5 which only allowed congestion control to kick in if the "abondoning" decision was made on a retransmission decision. > >What may have been mentioned was that if the CumTSNpoint < Advanced.Peer.Ack.Point then all the congestion control mechanisms when needed MUST be applied (or, are still applicable) for the chunks lying between these two points. > > > > >>The reason you must send it until you get a SACK is that you don't know >>if the >>peer received it. A Fwd-TSN can be lost just like a data chunk.... A >>fwd-TSN is >>relatively small (smaller than a SACK).. I don't see how this is a big >>issue.. >> >> > >It may very well not be. Timestamps (12 bytes) and other options for TCP have been debataed a lot about adding overheads. But again I am not an expert in this, so if others think that this overhead is permissible then maybe we can go by it. > Well, I know that FreeBSD and Linux have timestamps on by default in TCP.. so you always see this extra "12 bytes" in the the releases I played with :-0 > > > >>however >>I suppose we could modify the algorithm a bit and add a rule that states: >> >> > > > >>No matter if the sender does a delayed FWD-TSN or a FWD-TSN in response >>to a SACK, the sender MUST NOT send more than one FWD-TSN every RTT. >> >>This would then eliminate (ii) as an issue no matter how many SACK's the >>peer >>sends at you ... >> >> > > > >>So how about changing F2) to state: >> >> F2) The data sender SHOULD always attempt to bundle an outgoing >> FORWARD TSN with outbound DATA chunks for efficiency. >> >> A sender MAY even choose to delay the sending of the FORWARD TSN >> in the hope of bundling it with an outbound DATA chunk. But no matter >> if a sender delays a FORWARD TSN or sends one in response to a SACK, >> a sender MUST NOT have more than one FORWARD TSN in flight per >> round trip time. >> >> > > >I may say that will be a feasible solution, but this per RTT rule should be relaxed if the FORWARD TSN is updating the "NewCumTSN" point reported in the last FORWARD TSN . To be clear this per RTT rule (if adopted at all) should only be for duplicate FORWARD TSNs. > >And this scheme may add some state at the sender? > > > Yeah, we would have to tweak the wording.. but I tend to agree with Brian on this.. and maybe we should wait and hear what others say... > > >>I am missing something here.. what do you mean by 'chunks prior to theat >>which were "abandonded"' >> >> > > > >>Do you mean you abandonded it and then later it arrived... >> >> > >I meant this. > > > > >>I.e. I send a fwd-tsn(10)-------> >>and then some time later TSN-10 arrives. >> >>First of all I think this is a real corner case and does not happen that >>often... basically the >>network must reorder and hold a packet for longer than the RTT time... >> >> > >Not necessarily an RTT time. It can be less than that. > > But you don't send the FWD-TSN until you would normally send a retransmission.. abandoning something does NOT mean you send a FWD-TSN.. so you A> abandon the TSN. B> At some later time, where you would do the retrans, you send the fwd-tsn... The two are seperate events... and so you end up waiting until 4 strikes or a T-O. I guess you could get 4 strikes in less than a RTT .. this is true.. but at least 1/2 of the RTT must have passed.. aka you had to get the SACK's back to strike the chunk... this is a real corner case in my opinion... > > >>2) The statement from blanton/allman would give the impression that the >>FWD'd chunk was a >> network duplicate thus disabling the algorithm.. >> >> > > > >>So I think that: >> >> > > > >>a) the blanton/allman document already covers it >>and >>b) Once the cum-ack is past a point the blanton-allman document will have >> little effect to PR-SCTP or just plain SCTP... >> >> > > >Well yes maybe a corner case for example consider a sender had retransmitted a chunk (the original transmit being lost). And then abandoned it immediately. Lets assume that the retransmitted chunk reached after the FW-TSN (which can very well be considering multihomed endpoints and retransmission to the alternate). Then the reciever will generate a "fake" dup-tsn report. And blanton-allman's draft will be happy with the dup-tsn report and declare that retransmission spurious. Again I may agree that this is a corner case. > So now you are doing 1 retransmission and a abandon chunk. Again.. the sender still has the information and can KNOW that it abandoned the chunk and you are still in a corner case... since you do ----TSN(111)---->XlostX <4 strikes or T-O aka at LEAST 1/2 RTT + some amount> ----TSN(111)----->Retran---> "mark for abandon 111" ------FWD-TSN(111)---------> Now in the above, where is the duplicate... the only way this would happen is if the retransmission gets held a full RTO the FWD-TSN arrives and then the retran arrives... this is IMO an even further strech than your first example.. > > > > >>You are off on a tangent here IMO :> ... Please explain to me how >>PR-SCTP can motivate >>aggressive behavior? We have had long converstations on this list about >> >> > >This comment had nothing to do with previous discussions on PR-SCTP. My comments about being aggressive were only linked to point (i) which I think you have now clarified. > > I was wondering if you were not back addressing (i) so this comment is a non-issue with the F5) clearification... R > >Thanks, >Sourabh > >_______________________________________________ >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 exim@www1.ietf.org Thu Jun 26 11:57: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 LAA05870 for ; Thu, 26 Jun 2003 11:57:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QFv8S12849 for tsvwg-archive@odin.ietf.org; Thu, 26 Jun 2003 11:57:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VZ7N-0003Jd-If; Thu, 26 Jun 2003 11:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VZ6s-0003H8-1A for tsvwg@optimus.ietf.org; Thu, 26 Jun 2003 11:56:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05503 for ; Thu, 26 Jun 2003 11:56:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VZ3g-00039f-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 11:53:12 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19VZ3V-000362-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 11:53:01 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5QFqXw2017177; Thu, 26 Jun 2003 17:52:33 +0200 (MEST) Received: from ESEALNT745.al.sw.ericsson.se ([153.88.251.5]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NV4SX5P9; Thu, 26 Jun 2003 17:52:27 +0200 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 17:52:30 +0200 Message-ID: <5E5172B4DE05D311B3AB0008C75DA941123CEF8B@edeacnt100.eed.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Sourabh Ladha (EED)" To: "'bidulock@openss7.org'" , "Randall R. Stewart (home)" Cc: "Sourabh Ladha (EED)" , "'tsvwg@ietf.org'" Subject: RE: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00 Date: Thu, 26 Jun 2003 17:50:51 +0200 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, > So how about changing F2) to state: > > F2) The data sender SHOULD always attempt to bundle an outgoing > FORWARD TSN with outbound DATA chunks for efficiency. > > A sender MAY even choose to delay the sending of the FORWARD TSN > in the hope of bundling it with an outbound DATA chunk. But no matter > if a sender delays a FORWARD TSN or sends one in response to a SACK, > a sender MUST NOT have more than one FORWARD TSN in flight per > round trip time. >I disagree. The receiver is allowed to have more than one SACK in flight >per RTT, why is the sender not allowed to have one FORWARD TSN per SACK? >If the FORWARD TSNs cause problems, then so will the SACKs alone. > >If there is a problem here, it is with the SACKs. for the sake of arguement.. How can FORWARD TSN and SACK be compared? If you made this comparison only based on bytes then yes. otherwise, Each SACK being generated has hopes of delivering new information. The Forward TSNs (the case which I pointed out in the previous mail) generated are redundant. The only purpose they can serve is an improved reliability, which is again debatable. i.e. Is it a "correct" behaviour to improve reliability by duplicating information? I would say not. -Sourabh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jun 26 12:48:28 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 MAA08557 for ; Thu, 26 Jun 2003 12:48:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QGm2X26543 for tsvwg-archive@odin.ietf.org; Thu, 26 Jun 2003 12:48:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VZuj-0006tM-2t; Thu, 26 Jun 2003 12:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VZuB-0006sU-UF for tsvwg@optimus.ietf.org; Thu, 26 Jun 2003 12:47:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08487 for ; Thu, 26 Jun 2003 12:47:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VZuA-0003jJ-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 12:47:26 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19VZtz-0003j7-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 12:47:15 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5QGklG5025357; Thu, 26 Jun 2003 18:46:47 +0200 (MEST) Received: from ESEALNT744.al.sw.ericsson.se ([153.88.251.4]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NV4SYF8F; Thu, 26 Jun 2003 18:46:41 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 18:46:47 +0200 Message-ID: <5E5172B4DE05D311B3AB0008C75DA941123CEF8C@edeacnt100.eed.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Sourabh Ladha (EED)" To: "'Randall R. Stewart (home)'" Cc: "'tsvwg@ietf.org'" Subject: RE: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00 Date: Thu, 26 Jun 2003 18:45:08 +0200 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: , [snip] >>Well yes maybe a corner case for example consider a sender had retransmitted a chunk (the >original transmit being lost). And then abandoned it immediately. Lets assume that the >>retransmitted chunk reached after the FW-TSN (which can very well be considering >>multihomed endpoints and retransmission to the alternate). Then the reciever will generate >>a "fake" dup-tsn report. And blanton-allman's draft will be happy with the dup-tsn report >>and declare that retransmission spurious. Again I may agree that this is a corner case. > >So now you are doing 1 retransmission and a abandon chunk. Again.. the >sender still has the >information and can KNOW that it abandoned the chunk and you are still >in a corner >case... since you do > ----TSN(111)---->XlostX > <4 strikes or T-O aka at LEAST 1/2 RTT + some amount> > ----TSN(111)----->Retran---> > "mark for abandon 111" > > ------FWD-TSN(111)---------> > Now in the above, where is the duplicate... the only way this would > happen is if the retransmission gets held a full RTO the FWD-TSN arrives > and then the retran arrives... this is IMO an even further strech than your > first example.. maybe I am missing something. My reading of the draft says that in F3> "If" any delay is applied to sending of FW-TSN chunk, it SHOULD NOT exceed 200 ms and MUST not exceed 500ms. I dont understand how this "at LEAST 1 RTO wait" in sending the FWD TSN comes. Anyway, one of the reasons of pointing this out was to to cause a thought process for blanton&allman's draft or any other work that "may" get influenced by PR-SCTP. If not, well and good. >> >>This comment had nothing to do with previous discussions on PR-SCTP. My comments about >>being aggressive were only linked to point (i) which I think you have now clarified. >I was wondering if you were not back addressing (i) so this >comment is a non-issue with the F5) clearification... Again, the F5 clarification clears this case. -Sourabh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jun 26 12:56:29 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 MAA09046 for ; Thu, 26 Jun 2003 12:56:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QGu2l27815 for tsvwg-archive@odin.ietf.org; Thu, 26 Jun 2003 12:56:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Va2U-0007EW-Cm; Thu, 26 Jun 2003 12:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Va2Q-0007EB-B8 for tsvwg@optimus.ietf.org; Thu, 26 Jun 2003 12:55:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09014 for ; Thu, 26 Jun 2003 12:55:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Va2O-0003pk-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 12:55:56 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19Va2D-0003pX-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 12:55:45 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h5QGspMg059378; Thu, 26 Jun 2003 11:54:51 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EFB255B.7040702@stewart.chicago.il.us> Date: Thu, 26 Jun 2003 11:54:51 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Sourabh Ladha (EED)" CC: "'tsvwg@ietf.org'" Subject: Re: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00 References: <5E5172B4DE05D311B3AB0008C75DA941123CEF8C@edeacnt100.eed.ericsson.se> In-Reply-To: <5E5172B4DE05D311B3AB0008C75DA941123CEF8C@edeacnt100.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 Sourabh Ladha (EED) wrote: >maybe I am missing something. > >My reading of the draft says that in F3> "If" any delay is applied to sending of FW-TSN chunk, it SHOULD NOT exceed 200 ms and MUST not exceed 500ms. I dont understand how this "at LEAST 1 RTO wait" in sending the FWD TSN comes. > >Anyway, one of the reasons of pointing this out was to to cause a thought process for blanton&allman's draft or any other work that "may" get influenced by PR-SCTP. If not, well and goo > You can't send the FWD-TSN until the left edge of the number of TSN's is concurrent with your "abandoned chunk" So Consider -----TSN101----> -----TSN102----> XlostX -----TSN103----> .. at some point, 102 is abandoned. the FWD-TSN(102)-----> can NOT be sent until: 1) TSN101 is acknowledged (aka the cumack is to the immediate left of the chunk to be forwarded... the left edge). 2) You would normally make a retransmission decision. Just because you abandon it does not mean you tell the peer.. you have to follow all or the normal RFC2960 procedures and ONLY when you have marked it to abandon and you would have retransmitted and the left edge is aligned will you send the FWD-TSN... you may decide to delay a while... aka the 200ms but you send only at the normal retrans opp.. R > > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jun 26 13:07: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 NAA09585 for ; Thu, 26 Jun 2003 13:07:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QH74h30244 for tsvwg-archive@odin.ietf.org; Thu, 26 Jun 2003 13:07:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VaD8-0007ql-87; Thu, 26 Jun 2003 13:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VaCS-0007nB-36 for tsvwg@optimus.ietf.org; Thu, 26 Jun 2003 13:06:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09497 for ; Thu, 26 Jun 2003 13:06:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VaCQ-0003we-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 13:06:18 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19VaCF-0003wW-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 13:06:07 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5QH61G5027492; Thu, 26 Jun 2003 19:06:01 +0200 (MEST) Received: from ESEALNT744.al.sw.ericsson.se ([153.88.251.4]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NV43H114; Thu, 26 Jun 2003 19:04:29 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 19:06:02 +0200 Message-ID: <5E5172B4DE05D311B3AB0008C75DA941123CEF8E@edeacnt100.eed.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Sourabh Ladha (EED)" To: "'Randall R. Stewart (home)'" Cc: "'tsvwg@ietf.org'" Subject: RE: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00 Date: Thu, 26 Jun 2003 19:04:22 +0200 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: , You can't send the FWD-TSN until the left edge of the number of TSN's is concurrent with your "abandoned chunk" >Just because you abandon it does not mean you tell the peer.. you have >to follow all or the normal RFC2960 procedures and ONLY when you >have marked it to abandon and you would have retransmitted and the >left edge is aligned will you send the FWD-TSN... you may decide >to delay a while... aka the 200ms but you send only at the normal >retrans opp.. So consider this: everything before has been ACKed -----TSN101----> XlostX -----TSN102----> -----TSN103----> -----TSN104----> -----TSN105----> ----TSN101-----> retransmitted ---abandon 101-- Now all your three points for sending a FW-TSN (as mentioned by you above) hold. So, -----FW TSN---- Where is the "at least 1RTO"?? What if the FW TSN now reaches before TSN 101 going on a possible alternate path? -S _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jun 26 13:56: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 NAA11417 for ; Thu, 26 Jun 2003 13:56:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QHu5312814 for tsvwg-archive@odin.ietf.org; Thu, 26 Jun 2003 13:56:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VayX-0003Jv-UY; Thu, 26 Jun 2003 13:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vaxc-0003JA-4G for tsvwg@optimus.ietf.org; Thu, 26 Jun 2003 13:55:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11364 for ; Thu, 26 Jun 2003 13:55:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VaxZ-0004Ig-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 13:55:01 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19VaxO-0004I7-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 13:54:51 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5QHs6G5001539; Thu, 26 Jun 2003 19:54:06 +0200 (MEST) Received: from ESEALNT744.al.sw.ericsson.se ([153.88.251.4]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NV4SYRQA; Thu, 26 Jun 2003 19:54:00 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 19:54:06 +0200 Message-ID: <5E5172B4DE05D311B3AB0008C75DA941123CEF8F@edeacnt100.eed.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Sourabh Ladha (EED)" To: "'Randall R. Stewart (home)'" Cc: "'tsvwg@ietf.org'" Subject: RE: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00 Date: Thu, 26 Jun 2003 19:52:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , >You have not reached a point to retransmit it yet... >You must hit a RTO or 4 strikes the key is in A4 and A5... you must >have a stimuleous to send the FWD-TSN i.e. a T3-Timeout (A5) or >a SACK (A4).. >You retransmitted 101 as shown for one of two reasons (before >it was abandoned)... >If you retransmitted TSN101 due to T3.. you are collapsed to 1 MTU and >have burnt that in sending TSN101. If the SACK of 105 is the 4th strike >for fast retransmit... you have sent 101 and have done a CWND reduction >and must await the T3 for 101 or a SACK for 101... so you have >no chance to send the FWD-TSN until a SACK or T3 occurs... Well, You could add another TSN106 to the picture if thats the case..and let me explain the stimulus again: everything before has been ACKed -----TSN101----> XlostX -----TSN102----> -----TSN103----> -----TSN104----> -----TSN105----> -----TSN106----> on the 4th missing report >----TSN101-----> retransmitted ---abandon 101-- recieve another dupsack (coming due to TSN106) Now all your three points for sending a FW-TSN (as mentioned by you above) hold and the stimulus. So, ----FWTSN------- What about now? -Sourabh (last try ;) ..If it doesnt work..I'll see if I can spend some time making a scenario and get back then) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jun 26 14:21: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 OAA12847 for ; Thu, 26 Jun 2003 14:21:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QIL3D24138 for tsvwg-archive@odin.ietf.org; Thu, 26 Jun 2003 14:21:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VbMj-0006GZ-FL; Thu, 26 Jun 2003 14:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VbLs-0006DB-Uu for tsvwg@optimus.ietf.org; Thu, 26 Jun 2003 14:20:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12751 for ; Thu, 26 Jun 2003 14:20:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VbLq-0004Yy-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 14:20:06 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19VbLL-0004Y4-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 14:19:55 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h5QHeuMg059619; Thu, 26 Jun 2003 12:40:57 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EFB3028.1020102@stewart.chicago.il.us> Date: Thu, 26 Jun 2003 12:40:56 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Sourabh Ladha (EED)" CC: "'tsvwg@ietf.org'" Subject: Re: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00 References: <5E5172B4DE05D311B3AB0008C75DA941123CEF8E@edeacnt100.eed.ericsson.se> In-Reply-To: <5E5172B4DE05D311B3AB0008C75DA941123CEF8E@edeacnt100.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 Sourabh Ladha (EED) wrote: >You can't send the FWD-TSN until the left edge of the number >of TSN's is concurrent with your "abandoned chunk" > > > > >>Just because you abandon it does not mean you tell the peer.. you have >>to follow all or the normal RFC2960 procedures and ONLY when you >>have marked it to abandon and you would have retransmitted and the >>left edge is aligned will you send the FWD-TSN... you may decide >>to delay a while... aka the 200ms but you send only at the normal >>retrans opp.. >> >> > >So consider this: > >everything before has been ACKed >-----TSN101----> XlostX >-----TSN102----> >-----TSN103----> >-----TSN104----> >-----TSN105----> > >----TSN101-----> retransmitted >---abandon 101-- >Now all your three points for sending a FW-TSN (as mentioned by you above) hold. So, > <<<<-----FW TSN---- > > So you can't send the FWD-TSN here.. unless a T3 occured >Where is the "at least 1RTO"?? What if the FW TSN now reaches before TSN 101 going on a possible alternate path? > > You have not reached a point to retransmit it yet... You must hit a RTO or 4 strikes the key is in A4 and A5... you must have a stimuleous to send the FWD-TSN i.e. a T3-Timeout (A5) or a SACK (A4).. You retransmitted 101 as shown for one of two reasons (before it was abandoned)... If you retransmitted TSN101 due to T3.. you are collapsed to 1 MTU and have burnt that in sending TSN101. If the SACK of 105 is the 4th strike for fast retransmit... you have sent 101 and have done a CWND reduction and must await the T3 for 101 or a SACK for 101... so you have no chance to send the FWD-TSN until a SACK or T3 occurs... I see at a minimum a RTO or if 101 is sack'd no FWD-TSN is needed... R > >-S > >_______________________________________________ >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 exim@www1.ietf.org Thu Jun 26 14:21: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 OAA12848 for ; Thu, 26 Jun 2003 14:21:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QIL3U24139 for tsvwg-archive@odin.ietf.org; Thu, 26 Jun 2003 14:21:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VbMj-0006H9-UT; Thu, 26 Jun 2003 14:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VbMX-0006Fj-55 for tsvwg@optimus.ietf.org; Thu, 26 Jun 2003 14:20:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12792 for ; Thu, 26 Jun 2003 14:20:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VbMU-0004ZB-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 14:20:46 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19VbMJ-0004Z1-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 14:20:35 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h5QIJhMg059809; Thu, 26 Jun 2003 13:19:54 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EFB393F.9040108@stewart.chicago.il.us> Date: Thu, 26 Jun 2003 13:19:43 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Sourabh Ladha (EED)" CC: "'tsvwg@ietf.org'" Subject: Re: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00 References: <5E5172B4DE05D311B3AB0008C75DA941123CEF8F@edeacnt100.eed.ericsson.se> In-Reply-To: <5E5172B4DE05D311B3AB0008C75DA941123CEF8F@edeacnt100.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 Sourabh Ladha (EED) wrote: >>You have not reached a point to retransmit it yet... >> >> > > > >>You must hit a RTO or 4 strikes the key is in A4 and A5... you must >>have a stimuleous to send the FWD-TSN i.e. a T3-Timeout (A5) or >>a SACK (A4).. >> >> > > > >>You retransmitted 101 as shown for one of two reasons (before >>it was abandoned)... >> >> > > > >>If you retransmitted TSN101 due to T3.. you are collapsed to 1 MTU and >>have burnt that in sending TSN101. If the SACK of 105 is the 4th strike >>for fast retransmit... you have sent 101 and have done a CWND reduction >>and must await the T3 for 101 or a SACK for 101... so you have >>no chance to send the FWD-TSN until a SACK or T3 occurs... >> >> > > >Well, You could add another TSN106 to the picture if thats the case..and let me explain the stimulus again: > >everything before has been ACKed >-----TSN101----> XlostX >-----TSN102----> >-----TSN103----> >-----TSN104----> >-----TSN105----> >-----TSN106----> >on the 4th missing report > > >>----TSN101-----> retransmitted >> >> >---abandon 101-- >recieve another dupsack (coming due to TSN106) >Now all your three points for sending a FW-TSN (as mentioned by you above) hold and the stimulus. So, >----FWTSN------- > >What about now? > > > Yes... now you finally have a case that you would send the fwd-tsn.. but so what... it now still takes over 1/2 RTT for your FWD-TSN to arrive plus whatever difference there is between sending 105 and 106... you have further complicated your corner case in that the "abandon" time MUST be before the SACK for 106 arrives.. that is still a corner case.. routers generally don't hold packets to dump them on innocent transport protocols later :-D they forward or drop the packets... You are still talking about occurances that are rare.. aka a routing reconvergance that lets the TSN101 get held somewhere and then later put to the transport... I don't see building a strange corner case is justification for changes... nor what the changes would be.. I have of late thought that the sending time and RTT might be used in conjunction with the "4 strikes" in making retransmission decisions.. this could be a case where that would be worth doing.. if it were more than an isolated corner case... If we were really worried about this case (I look for others to chime in on this) we could add something that said you MUST wait until you would normally retransmit the chunk before sending the FWD-TSN.. but I don't know if that is needed... not for this case at least... it may well be how folks implement PR-SCTP... but I don't see it has a requirment to implement it that way... R > >-Sourabh > >(last try ;) ..If it doesnt work..I'll see if I can spend some time making a scenario and get back then) > > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jun 26 14:31: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 OAA13629 for ; Thu, 26 Jun 2003 14:31:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFn5l29052 for tsvwg-archive@odin.ietf.org; Wed, 25 Jun 2003 11:49:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCVE-0006w1-1A; Wed, 25 Jun 2003 11:48:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VC0K-0008Af-Cx for tsvwg@optimus.ietf.org; Wed, 25 Jun 2003 11:16:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01470; Tue, 24 Jun 2003 21:31:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uy14-0000W8-00; Tue, 24 Jun 2003 20:20:02 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19Uy0t-0000Vs-00; Tue, 24 Jun 2003 20:19:51 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h5OMgiK20609; Tue, 24 Jun 2003 15:42:44 -0700 (PDT) Message-Id: <200306242242.h5OMgiK20609@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, tsvwg@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 24 Jun 2003 15:42:43 -0700 Subject: [Tsvwg] RFC 3540 on Robust Explicit Congestion Notification (ECN) Signaling with Nonces 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: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3540 Title: Robust Explicit Congestion Notification (ECN) Signaling with Nonces Author(s): N. Spring, D. Wetherall, D. Ely Status: Experimental Date: June 2003 Mailbox: nspring@cs.washington.edu, djw@cs.washington.edu, ely@cs.washington.edu Pages: 13 Characters: 30081 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tsvwg-tcp-nonce-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3540.txt This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts. This document is a product of the Transport Area Working Group of the IETF. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030624154127.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3540 --OtherAccess Content-Type: Message/External-body; name="rfc3540.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030624154127.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jun 26 15:12: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 PAA16252 for ; Thu, 26 Jun 2003 15:12:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QJC3V14086 for tsvwg-archive@odin.ietf.org; Thu, 26 Jun 2003 15:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VcA3-0003f5-RR; Thu, 26 Jun 2003 15:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vc9w-0003en-IS for tsvwg@optimus.ietf.org; Thu, 26 Jun 2003 15:11:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16165 for ; Thu, 26 Jun 2003 15:11:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vc9t-000500-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 15:11:49 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Vc9i-0004zu-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 15:11:38 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5QJB7G5008300; Thu, 26 Jun 2003 21:11:07 +0200 (MEST) Received: from ESEALNT745.al.sw.ericsson.se ([153.88.251.5]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NV4RA9B1; Thu, 26 Jun 2003 21:13:01 +0200 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 21:11:04 +0200 Message-ID: <5E5172B4DE05D311B3AB0008C75DA941123CEF90@edeacnt100.eed.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Sourabh Ladha (EED)" To: "'Randall R. Stewart (home)'" Cc: "'tsvwg@ietf.org'" Subject: RE: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00 Date: Thu, 26 Jun 2003 21:09:25 +0200 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: , > Yes... now you finally have a case that you would send the > fwd-tsn.. but > so what... it > now still takes over 1/2 RTT for your FWD-TSN to arrive plus whatever > difference > there is between sending 105 and 106... you have further > complicated your > corner case in that the "abandon" time MUST be before the SACK for > 106 arrives.. that is still a corner case.. routers generally > don't hold packets to dump them on innocent transport protocols later > :-D they > forward or drop the packets... I dont understand..consider multihomed endpoints and the primary path RTT (RTT1) << Alternate path RTT (RTT2) Now your retransmission of TSN101 is going to experience 1/2 RTT2 but the forward TSN will experience 1/2 RTT1 + whatever delay you want to add. I dont see this as what you call "real" corner case..moreover the "abandon" time "in this case" needs to be just before TSN106..but as I had previously said I wanted to look at the bigger picture..what if you have a higher cwnd say TSNs101-150 (as compared to TSNs101-106 in the example)..any dupsack coming after the "abandon" can trigger this forward TSN..so you have some range on "abandon" time.. > > You are still talking about occurances that are rare.. aka a routing > reconvergance that > lets the TSN101 get held somewhere and then later put to the > transport... I dont think so...I am not necessarily referring to a routing instability phase..see above. > I don't see building a strange corner case is justification for > changes... nor what > the changes would be.. changes where? I wasnt proposing any changes on "this" particular point for PR-SCTP. The option always was for other drafts to consider it, if needed. > >(I look for others > to chime in on this) we could add something Same here..To summarize, with PR-SCTP: A reciever may at some point of time generate "fake" dup-tsn reports..but these cases may be called corner cases. And, (i) should PR-SCTP attemp to address this.. (I too think that the answer to this is "no") (ii) should drafts like blanton-allman duptsn draft consider such cases? -Sourabh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jun 26 16: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 QAA19065 for ; Thu, 26 Jun 2003 16:03:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QK33x01952 for tsvwg-archive@odin.ietf.org; Thu, 26 Jun 2003 16:03:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VcxR-0000Uj-R8; Thu, 26 Jun 2003 16:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vcwf-0000Tn-4J for tsvwg@optimus.ietf.org; Thu, 26 Jun 2003 16:02:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19001 for ; Thu, 26 Jun 2003 16:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VcwO-0005S5-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 16:01:56 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19VcwD-0005Qy-00 for tsvwg@ietf.org; Thu, 26 Jun 2003 16:01:45 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 2F82832909; Thu, 26 Jun 2003 15:59:25 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 673D1328D7; Thu, 26 Jun 2003 15:59:24 -0400 (EDT) Date: Thu, 26 Jun 2003 15:59:24 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: "Randall R. Stewart (home)" Cc: , "Sourabh Ladha (EED)" , "'tsvwg@ietf.org'" Subject: Re: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00 In-Reply-To: <3EFB09DF.3000304@stewart.chicago.il.us> Message-ID: X-Spam-Status: No, hits=-5.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 Thu, 26 Jun 2003, Randall R. Stewart (home) wrote: > Brian F. G. Bidulock wrote: > > > >I disagree. The receiver is allowed to have more than one SACK in flight > >per RTT, why is the sender not allowed to have one FORWARD TSN per SACK? > > > >If the FORWARD TSNs cause problems, then so will the SACKs alone. > > > >If there is a problem here, it is with the SACKs. > > That is a good point... the FWD-TSN's are generally even > smaller than the SACKs... > > Delaying the FWD-TSN could in theory cause held data at > the reciever to remain there longer... its definetly a trade-off.. > > What do others think? worth worrying about... or better left alone?? I think it is better left alone. I don't see a problem, but delaying FWD-TSN would be a problem. ~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 exim@www1.ietf.org Mon Jun 30 01: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 BAA18409 for ; Mon, 30 Jun 2003 01:23:04 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5U5M5T28143 for tsvwg-archive@odin.ietf.org; Mon, 30 Jun 2003 01:22:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wr73-0007Jn-Kr; Mon, 30 Jun 2003 01:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wr6P-0007JU-0h for tsvwg@optimus.ietf.org; Mon, 30 Jun 2003 01:21:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18280; Mon, 30 Jun 2003 01:21:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wr67-0003Vk-00; Mon, 30 Jun 2003 01:21:03 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19Wr5r-0003VW-00; Mon, 30 Jun 2003 01:20:47 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h5U5Kbe3018946; Sun, 29 Jun 2003 22:20:37 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200306300520.h5U5Kbe3018946@cougar.icir.org> To: Internet-Drafts@ietf.org cc: tsvwg@ietf.org From: Sally Floyd Date: Sun, 29 Jun 2003 22:20:37 -0700 Subject: [Tsvwg] Internet drafts submission: draft-floyd-tcp-highspeed-03.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 to submit the following two internet-drafts: http://www.icir.org/floyd/papers/draft-floyd-tcp-highspeed-03.txt http://www.icir.org/floyd/papers/draft-floyd-tcp-highspeed-03.ps and: http://www.icir.org/floyd/papers/draft-floyd-tcp-slowstart-02.txt http://www.icir.org/floyd/papers/draft-floyd-tcp-slowstart-02.ps Many thanks. - Sally _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Jun 30 01:44: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 BAA19210 for ; Mon, 30 Jun 2003 01:44:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5U5i2J32091 for tsvwg-archive@odin.ietf.org; Mon, 30 Jun 2003 01:44:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WrSM-0008Kb-42; Mon, 30 Jun 2003 01:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WrRN-0008Hj-9K for tsvwg@optimus.ietf.org; Mon, 30 Jun 2003 01:43:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19157; Mon, 30 Jun 2003 01:42:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WrLt-0003e0-00; Mon, 30 Jun 2003 01:37:21 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 19WrLi-0003dq-00; Mon, 30 Jun 2003 01:37:10 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h5U5an1R019898; Mon, 30 Jun 2003 14:36:49 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h5U5an8E029542; Mon, 30 Jun 2003 14:36:49 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h5U5ameH000053; Mon, 30 Jun 2003 14:36:48 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id OAA10209; Mon, 30 Jun 2003 14:36:48 +0900 (JST) Received: from morita-vaiodtop.lab.ntt.co.jp by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id OAA21621; Mon, 30 Jun 2003 14:36:47 +0900 (JST) Message-Id: <5.1.1.9.2.20030630143131.040e8388@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr3 Date: Mon, 30 Jun 2003 14:37:18 +0900 To: tsvwg@ietf.org, sipping@ietf.org From: "MORITA, Naotaka" Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Priority Promotion Scheme 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 am Naotaka Morita working for NTT Laboratories. I would like to draw your attention to the following new ID. The purpose of this draft is to identify the Priority Promotion Scheme and to define a new Measurable Forwarding Per-Hop Behavior. Althouhg this is targeted to tsvwg, I would like to discuss this regarding the interaction between SIP proxies and edge routers to provide QoS guaranteed service. Naotaka Morita ============ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Framework of Priority Promotion Scheme Author(s) : N. Morita, G. Karlsson Filename : draft-morita-tsvwg-pps-00.txt Pages : 20 Date : 2003-6-25 This document describes a framework of a new scheme for traffic control to achieve end-to-end QoS for interactive multimedia services. The scheme is based on end-to-end measurement of network resources by end systems. The network is assumed to fully support the priority control scheme specified in the Diffserv architecture for QoS and SIP [1] for session control. Since the scheme relies on the behavior of the end systems, this document also touches on mechanisms for monitoring end-system behavior. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-00.txt ---------------------------------- Naotaka MORITA, Senior Research Engineer, Supervisor Network Service Systems Laboratories Information Sharing Laboratory Group NTT 3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012 E-mail: morita.naotaka@lab.ntt.co.jp MSN messenger: moritanaotaka@hotmail.com NTT home page: http://www.ntt.co.jp/about/e/index.html _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Jun 30 17:52: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 RAA17721 for ; Mon, 30 Jun 2003 17:52:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ULq5c14840 for tsvwg-archive@odin.ietf.org; Mon, 30 Jun 2003 17:52:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X6Z7-0003q2-Md; Mon, 30 Jun 2003 17:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wuyz-0004A3-4Y for tsvwg@optimus.ietf.org; Mon, 30 Jun 2003 05:31:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06862 for ; Mon, 30 Jun 2003 05:29:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wuyg-00058j-00 for tsvwg@ietf.org; Mon, 30 Jun 2003 05:29:38 -0400 Received: from mail.poliba.it ([193.204.49.50]) by ietf-mx with esmtp (Exim 4.12) id 19WuyU-00058M-00 for tsvwg@ietf.org; Mon, 30 Jun 2003 05:29:26 -0400 Received: from deectl18 (deectl18.poliba.it [193.204.59.114]) by mail.poliba.it (8.11.6/8.11.6) with SMTP id h5U9SXN08083; Mon, 30 Jun 2003 11:28:33 +0200 Message-ID: <008801c33eea$5210adc0$723bccc1@poliba.it> From: "Saverio Mascolo" To: , Date: Mon, 30 Jun 2003 11:30:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] TCP Westwood+ 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, we have made available the following two technical reports for comments: A. Dell'Aera, L. A. Grieco and S. Mascolo "Linux 2.4 Implementation of Westwood+ TCP with rate-halving: A Performance Evaluation over the Internet", Tech. Rep. No. 08/03/S, submitted for publication on May 2003. L. A. Grieco and S. Mascolo "Performance Comparison of Reno, Vegas and Westwood+ TCP Congestion Control" , Tech. Rep. No. 07/03/S, submitted for publication o July 2002. The ns-2 modules of TCP Westwood+ are available at http://www-ictserv.poliba.it/mascolo/tcp%20westwood/modules.htm To summarize, TCP Westwood+ proposes to set the congestion window and the slow start threshold after a congestion episode by using an e2e estimate of the available bandwidth obtained by filtering the stream of ACK packets. The setting substitutes the "blind" by half window reduction of standard AIMD algorithms with an adaptive setting that takes into account the state of the network. Saverio Mascolo ----------- Saverio Mascolo, Ph.D Associate Professor Dipartimento di Elettrotecnica ed Elettronica, Politecnico di Bari Via Orabona 4, 70125 Bari, Italy email: mascolo@poliba.it or saverio@ieee.org tel. +39 080 5963621 fax. +39 080 5963410 http://www-dee.poliba.it/dee-web/Personale/mascolo.html _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg