From exim@www1.ietf.org Tue Jul 1 10:47: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 KAA03203 for ; Tue, 1 Jul 2003 10:47:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61El9p06340 for tsvwg-archive@odin.ietf.org; Tue, 1 Jul 2003 10:47:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XMPO-0001dQ-7E; Tue, 01 Jul 2003 10:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XMOy-0001cw-Hv for tsvwg@optimus.ietf.org; Tue, 01 Jul 2003 10:46:36 -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 KAA03182 for ; Tue, 1 Jul 2003 10:46:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XMOw-0005Fy-00 for tsvwg@ietf.org; Tue, 01 Jul 2003 10:46:34 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19XMOl-0005F4-00 for tsvwg@ietf.org; Tue, 01 Jul 2003 10:46:23 -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 h61EiAMg098362 for ; Tue, 1 Jul 2003 09:44:10 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F019E38.3020702@stewart.chicago.il.us> Date: Tue, 01 Jul 2003 09:44:08 -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: "'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: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all: I just want to summarize where I think we are from the comments I have seen in this thread: 1) We will modify F5 to be more clear.. it will end up as follows (quoting from the XML source): " 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). " 2) We have not a consensus either way on if we need to limit the number of forward TSN's.. I had put out a proposed text change... and asked for comments... Brian and Armando chimed in that no change was needed.. I am open to the group opinion... there are 3 basic things I have heard of (onlist and off): a) No change b) only one FWD-TSN out per RTT (I lean towards this if we do anything) c) send a FWD-TSN every other SACK Opinons???? R _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 2 02:52:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26150 for ; Wed, 2 Jul 2003 02:52:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XbTK-0001FW-ON for tsvwg-archive@odin.ietf.org; Wed, 02 Jul 2003 02:52:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h626q6OI004762 for tsvwg-archive@odin.ietf.org; Wed, 2 Jul 2003 02:52:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XbTE-0001Dt-To; Wed, 02 Jul 2003 02:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XbSc-0001DJ-NF for tsvwg@optimus.ietf.org; Wed, 02 Jul 2003 02:51: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 CAA26143 for ; Wed, 2 Jul 2003 02:51:19 -0400 (EDT) From: loretosa@vodafone.it Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XbSY-0006ap-00 for tsvwg@ietf.org; Wed, 02 Jul 2003 02:51:18 -0400 Received: from [194.185.97.41] (helo=gsp07-c21d5.vodafone.it) by ietf-mx with esmtp (Exim 4.12) id 19XbSY-0006al-00 for tsvwg@ietf.org; Wed, 02 Jul 2003 02:51:18 -0400 Received: from vodafone.it (127.0.0.1) by gsp07-c21d5.vodafone.it (NPlex 5.1.046) id 3EEACBCF0000485D for tsvwg@ietf.org; Wed, 2 Jul 2003 08:50:42 +0200 X-CNS-Auth: Date: Wed, 02 Jul 2003 08:50:42 +0200 Message-Id: MIME-Version: 1.0 Message-Context: text-message Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Subject: [Tsvwg] SIP client over 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: quoted-printable Hi, I'm developping the first SIP over SCTP User Agent in Linux. For this I use the SIP UA KPhone, and I'm modifying it. A first version of SIP SCTP client ( KPhone SCTP) is ready !!! If you are interested, I update my home page ( http://utenti.lycos.it/ssal/ ) with all the necessary information in order to setup the enviroment and test the UA. In this page you'll find also the mail address where it is possible demand the source code ! Best regards sal _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 2 11:47:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27907 for ; Wed, 2 Jul 2003 11:47:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xjoj-0000Jg-Ks for tsvwg-archive@odin.ietf.org; Wed, 02 Jul 2003 11:46:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62FkjNa001201 for tsvwg-archive@odin.ietf.org; Wed, 2 Jul 2003 11:46:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xjo8-0008NB-BN; Wed, 02 Jul 2003 11:46:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XQXx-00029T-BE for tsvwg@optimus.ietf.org; Tue, 01 Jul 2003 15:12:15 -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 NAA07703 for ; Tue, 1 Jul 2003 13:34:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XP17-0006Uu-00 for tsvwg@ietf.org; Tue, 01 Jul 2003 13:34:09 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19XP16-0006Ur-00 for tsvwg@ietf.org; Tue, 01 Jul 2003 13:34:08 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 2510E329C1; Tue, 1 Jul 2003 13:33:59 -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 637CC329BF; Tue, 1 Jul 2003 13:33:58 -0400 (EDT) Date: Tue, 1 Jul 2003 13:33:58 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: "Randall R. Stewart (home)" Cc: "'tsvwg@ietf.org'" Subject: Re: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00 In-Reply-To: <3F019E38.3020702@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 Tue, 1 Jul 2003, Randall R. Stewart (home) wrote: > 2) We have not a consensus either way on if we need to limit the number > of forward TSN's.. I had put out a proposed text change... and asked > for comments... Brian and Armando chimed in that no change was > needed.. I am open to the group opinion... there are 3 basic things > I have heard of (onlist and off): > a) No change > b) only one FWD-TSN out per RTT (I lean towards this if we do > anything) > c) send a FWD-TSN every other SACK If people feel that there is a need to reduce the number of FWD-TSNs, then I vote for option b. Note that in doing so, the timeliness of the FWD-TNSs may make PR-SCTP useless. If the forward path is lossy, then TSNs will get lost and their corresponding FWD-TSNs will get lost as well. Reducing the number of FWD-TSNs increases the number of RTTs needed to notify the peer that a TSN is being abandoned by the sender. Since the sender can bundle FWD-TSNs with outgoing data, I am not concerned about too many on the wire. ~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 Wed Jul 2 12:20:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29790 for ; Wed, 2 Jul 2003 12:20:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkKx-00048Z-0t for tsvwg-archive@odin.ietf.org; Wed, 02 Jul 2003 12:20:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62GK2ms015899 for tsvwg-archive@odin.ietf.org; Wed, 2 Jul 2003 12:20:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkKv-000486-PJ; Wed, 02 Jul 2003 12:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkKf-00047C-2b for tsvwg@optimus.ietf.org; Wed, 02 Jul 2003 12:19:45 -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 MAA29746 for ; Wed, 2 Jul 2003 12:19:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XkKc-0003Qc-00 for tsvwg@ietf.org; Wed, 02 Jul 2003 12:19:42 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[tc/vSbsvNM4klImL9ekxZIVDVvtzfz+B]) by ietf-mx with esmtp (Exim 4.12) id 19XkKb-0003QY-00 for tsvwg@ietf.org; Wed, 02 Jul 2003 12:19:42 -0400 Received: from ns.pigworks.openss7.net (IDENT:SGqxsFGjV/o2nAKXnMVNojKPR9chNbzB@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h62GJeX24535; Wed, 2 Jul 2003 10:19:40 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h62GJef23657; Wed, 2 Jul 2003 10:19:40 -0600 Date: Wed, 2 Jul 2003 10:19:40 -0600 From: "Brian F. G. Bidulock" To: "Armando L. Caro Jr." Cc: "Randall R. Stewart (home)" , "'tsvwg@ietf.org'" Subject: Re: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00 Message-ID: <20030702101940.A23557@openss7.org> Reply-To: bidulock@openss7.org References: <3F019E38.3020702@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: ; from acaro@mail.eecis.udel.edu on Tue, Jul 01, 2003 at 01:33:58PM -0400 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 h62GJeX24535 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 Armando, a) is the way to go. I would surely like to see argument here as to why the supporters of b) o= r c) think that they are necessary and limiting the number of SACKs is not. F= or example, in b) whare are not SACKs limited to every RTT? Also, in c), wh= ere are not SACKs limited to every other (current) SACK? --brian On Tue, 01 Jul 2003, Armando L. Caro Jr. wrote: > On Tue, 1 Jul 2003, Randall R. Stewart (home) wrote: >=20 > > 2) We have not a consensus either way on if we need to limit the numb= er > > of forward TSN's.. I had put out a proposed text change... and a= sked > > for comments... Brian and Armando chimed in that no change was > > needed.. I am open to the group opinion... there are 3 basic thi= ngs > > I have heard of (onlist and off): > > a) No change > > b) only one FWD-TSN out per RTT (I lean towards this if we do > > anything) > > c) send a FWD-TSN every other SACK >=20 > If people feel that there is a need to reduce the number of FWD-TSNs, t= hen > I vote for option b. Note that in doing so, the timeliness of the FWD-T= NSs > may make PR-SCTP useless. If the forward path is lossy, then TSNs will = get > lost and their corresponding FWD-TSNs will get lost as well. Reducing t= he > number of FWD-TSNs increases the number of RTTs needed to notify the pe= er > that a TSN is being abandoned by the sender. Since the sender can bundl= e > FWD-TSNs with outgoing data, I am not concerned about too many on the > wire. >=20 > ~armando >=20 > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.cis.udel.edu/~acaro | University of Delaware | > 0-- --0 >=20 >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 2 18:10:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23784 for ; Wed, 2 Jul 2003 18:10:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xpny-0000iC-65 for tsvwg-archive@odin.ietf.org; Wed, 02 Jul 2003 18:10:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62MAMnT002732 for tsvwg-archive@odin.ietf.org; Wed, 2 Jul 2003 18:10:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xpne-0000Zr-Jq; Wed, 02 Jul 2003 18:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XpnU-0000Yg-MX for tsvwg@optimus.ietf.org; Wed, 02 Jul 2003 18:09: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 SAA23429; Wed, 2 Jul 2003 18:09:45 -0400 (EDT) Message-Id: <200307022209.SAA23429@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: Wed, 02 Jul 2003 18:09:45 -0400 Subject: [Tsvwg] I-D ACTION:draft-manner-lrsvp-02.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. Title : Localized RSVP Author(s) : J. Manner et al. Filename : draft-manner-lrsvp-02.txt Pages : 17 Date : 2003-7-2 Guaranteed QoS for multimedia applications is based on reserved resources in each node on the end-to-end path. Even if the correspondent node does not support QoS, it would be useful to be able to reserve at least local resources at the access network, especially wireless link resources. Additionally, for mobile nodes the continuity of QoS is disturbed due to end-to-end signalling or slow re-reservations of resources after each handover. This draft proposes a simple enhancement to RSVP, so that initial resource reservations and re-reservations due to host mobility can be done locally in an access network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-manner-lrsvp-02.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-manner-lrsvp-02.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-manner-lrsvp-02.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-7-2181058.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-manner-lrsvp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-manner-lrsvp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2181058.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 3 00:24:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14375 for ; Thu, 3 Jul 2003 00:24:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xvde-0004br-1m for tsvwg-archive@odin.ietf.org; Thu, 03 Jul 2003 00:24:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h634O6li017715 for tsvwg-archive@odin.ietf.org; Thu, 3 Jul 2003 00:24:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XvdZ-0004ax-Mt; Thu, 03 Jul 2003 00: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 19Xvcj-0004aU-VL for tsvwg@optimus.ietf.org; Thu, 03 Jul 2003 00:23:09 -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 AAA14181 for ; Thu, 3 Jul 2003 00:23:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xvch-0002WH-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 00:23:07 -0400 Received: from relay.cosmoweb.net ([66.234.224.17] ident=hidden-user) by ietf-mx with esmtp (Exim 4.12) id 19Xvcg-0002W9-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 00:23:06 -0400 Received: from [127.0.0.1] (73-227-234-66.cosmoweb.net [66.234.227.73]) by relay.cosmoweb.net (8.11.6/8.11.6) with ESMTP id h635oN110512; Thu, 3 Jul 2003 01:50:23 -0400 Date: Thu, 03 Jul 2003 00:23:02 -0400 From: Cyrus Shaoul To: Message-Id: <20030703001702.AE37.CYRUS@ntt-at.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] VoIP and Congestive Collapes: QoS vs. Best Effort 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 TSVWG list members, After lurking for a bit, I wanted to try asking a question of the other list members. I have been reading the recent IAB draft relating to congestive collapse of VoIP traffic, called draft-iab-congestion-00.txt, and I wanted to see if my understanding of the issues relate to the work of the TSVWG and to the recent draft that Naotaka Morita recently submitted (draft-morita-tsvwg-pps-00.txt) As I see it, one way to compare the two is to look at the level of QoS support in the routers that are assumed. In draft-iab-congestion-00, the IAB authors assume that all nodes are not capable of Diffserv or other QoS functions, and all traffic is treated equally with best effort. Morita's draft assumes that all packet forwarding nodes support Diffserv, and have configurable PHB. (This is not currently the case, but it may be the case in the future) Another comparison is the type of communication targeted. draft-iab-congestion-00 only considers voice, which has a range of 4 to 64kpbs in most cases. In draft-morita-tsvwg-pps-00.txt, video calls and other broadband services, around 1Mps per call, are the focus. A final comparison can be made between the reactive vs. proactive natures of the solution. One of the conclusions, as I understand them, of the IAB draft is that in cases of certain specific amounts of congestion and packet loss, the application should end the call instead of using any of the remaining resources. I feel that this is a very different user experience for the one that the VoIP user expects. (Other than during emergencies, PSTN phone calls rarely terminate in mid-call due to high call volume). The Morita proposal acts like a preventative measures, and instead of reacting to congestion, it proactively prevents voice traffic from ever getting to the point of failing. By using admission control, the user can be informed of the lack of available bandwidth before the call begins, reducing the change to the standard telephone user experience. Are these two drafts trying to solve different problems? Or are they solving the same problem in different ways because they begin with different assumptions? Thanks for your time, Cyrus Cyrus Shaoul NTT Advanced Technology Corp. cyrus@ntt-at.com http://www.ntt-at.com/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 3 01:28:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16082 for ; Thu, 3 Jul 2003 01:28:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XwdY-0006DW-2a for tsvwg-archive@odin.ietf.org; Thu, 03 Jul 2003 01:28:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h635S4Ef023879 for tsvwg-archive@odin.ietf.org; Thu, 3 Jul 2003 01:28:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XwdU-0006CC-FP; Thu, 03 Jul 2003 01: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 19Xwd4-00069i-Aq for tsvwg@optimus.ietf.org; Thu, 03 Jul 2003 01:27:34 -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 BAA16041 for ; Thu, 3 Jul 2003 01:27:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xwd1-000306-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 01:27:31 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19Xwd0-000303-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 01:27:30 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h635RUe3061621; Wed, 2 Jul 2003 22:27:30 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200307030527.h635RUe3061621@cougar.icir.org> To: Cyrus Shaoul cc: tsvwg@ietf.org From: Sally Floyd Subject: Re: [Tsvwg] VoIP and Congestive Collapes: QoS vs. Best Effort Date: Wed, 02 Jul 2003 22:27:30 -0700 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: , >Are these two drafts trying to solve different problems? The two drafts are trying to solve different problems. The IAB draft, draft-iab-congestion-00.txt, is not trying to say that best-effort service is a good solution for VoIP traffic, or a better solution than some form of QoS, or anything of the kind. The IAB draft is trying to say that today some VoIP traffic in fact runs as best-effort traffic over one or more links in the best-effort Internet, and that this is likely to be the case in the near future as well, and that it is not deemed recommended behavior by the IAB for these flows to maintain their minimum sending rate in the presence of persistent, steady-state packet drop rates experienced by the flow. We will try to be more clear, in the next round of revisions, that we are not trying to say that we are recommending best-effort service as the recommended path for roll-out for VoIP. We are not recommending any roll-out path one way or another. We are observing that in fact, VoIP traffic some times ends up competing, as best-effort traffic, with other best-effort traffic in the Internet. - Sally http://www.icir.org/floyd/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 3 01:58:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16913 for ; Thu, 3 Jul 2003 01:58:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xx6Z-0007EE-8y for tsvwg-archive@odin.ietf.org; Thu, 03 Jul 2003 01:58:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h635w3bB027780 for tsvwg-archive@odin.ietf.org; Thu, 3 Jul 2003 01:58:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xx6X-0007DI-Lr; Thu, 03 Jul 2003 01:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xx6F-0007Cy-R0 for tsvwg@optimus.ietf.org; Thu, 03 Jul 2003 01:57:43 -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 BAA16892 for ; Thu, 3 Jul 2003 01:57:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xx6C-0003JI-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 01:57:40 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 19Xx6B-0003JE-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 01:57:39 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 03 Jul 2003 08:57:40 +0300 Date: Thu, 3 Jul 2003 08:57:40 +0300 (EEST) From: Jukka MJ Manner To: tsvwg@ietf.org Subject: Re: [Tsvwg] I-D ACTION:draft-manner-lrsvp-02.txt In-Reply-To: <200307022209.SAA23429@ietf.org> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all, We have updated our draft on the extension to RSVP to allow for resource signaling within an access network. The technical specification has not changed since the previous version of the draft. The main changes were editorial, e.g. better explanations here and there. We would still be very interested in hearing comments about the ideas (the concept and the technical implementation) presented in the draft. At least me and Markku Kojo will be in Vienna if anyone wants to have chat in person. Regards, Jukka On Wed, 2 Jul 2003 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Localized RSVP > Author(s) : J. Manner et al. > Filename : draft-manner-lrsvp-02.txt > Pages : 17 > Date : 2003-7-2 > > Guaranteed QoS for multimedia applications is based on reserved > resources in each node on the end-to-end path. Even if the > correspondent node does not support QoS, it would be useful to be > able to reserve at least local resources at the access network, > especially wireless link resources. Additionally, for mobile nodes > the continuity of QoS is disturbed due to end-to-end signalling or > slow re-reservations of resources after each handover. This draft > proposes a simple enhancement to RSVP, so that initial resource > reservations and re-reservations due to host mobility can be done > locally in an access network. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-manner-lrsvp-02.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-manner-lrsvp-02.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-manner-lrsvp-02.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. > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 3 08:53:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09164 for ; Thu, 3 Jul 2003 08:53:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3aG-0002kN-7U for tsvwg-archive@odin.ietf.org; Thu, 03 Jul 2003 08:53:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Cr8um010553 for tsvwg-archive@odin.ietf.org; Thu, 3 Jul 2003 08:53:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3a9-0002j8-Pk; Thu, 03 Jul 2003 08:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3a0-0002it-24 for tsvwg@optimus.ietf.org; Thu, 03 Jul 2003 08:52: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 IAA09152 for ; Thu, 3 Jul 2003 08:52:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y3Zy-00060N-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 08:52:50 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19Y3Zx-00060J-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 08:52: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 h63CqDMg012933; Thu, 3 Jul 2003 07:52:14 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F0426FD.90407@stewart.chicago.il.us> Date: Thu, 03 Jul 2003 07:52: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: loretosa@vodafone.it CC: tsvwg@ietf.org Subject: Re: [Tsvwg] SIP client over SCTP 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 Sal: I saw no way to download this code or get a copy.. and I seemed to get a LOT of adds and such when I hit this site :-< Is there any place we can get the code at to play with ?? R loretosa@vodafone.it wrote: >Hi, > >I'm developping the first SIP over SCTP User Agent in Linux. >For this I use the SIP UA KPhone, and I'm modifying it. > >A first version of SIP SCTP client ( KPhone SCTP) is ready !!! > >If you are interested, I update my home page > >( http://utenti.lycos.it/ssal/ ) > >with all the necessary information in order to setup >the enviroment and test the UA. >In this page you'll find also the mail address where >it is possible demand the source code ! > > >Best regards >sal > > >_______________________________________________ >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 Jul 3 08:54:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09190 for ; Thu, 3 Jul 2003 08:54:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3b6-0002r9-H5 for tsvwg-archive@odin.ietf.org; Thu, 03 Jul 2003 08:54:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Cs0Bv010941 for tsvwg-archive@odin.ietf.org; Thu, 3 Jul 2003 08:54:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3b6-0002qN-CA; Thu, 03 Jul 2003 08:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3aA-0002jC-Uh for tsvwg@optimus.ietf.org; Thu, 03 Jul 2003 08:53:02 -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 IAA09157 for ; Thu, 3 Jul 2003 08:53:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y3a9-00060S-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 08:53:01 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19Y3a8-00060K-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 08:53: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 h63CqTMg012936; Thu, 3 Jul 2003 07:52:29 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F04270D.2030805@stewart.chicago.il.us> Date: Thu, 03 Jul 2003 07:52:29 -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: loretosa@vodafone.it CC: tsvwg@ietf.org Subject: Re: [Tsvwg] SIP client over SCTP 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 Sal: I saw no way to download this code or get a copy.. and I seemed to get a LOT of adds and such when I hit this site :-< Is there any place we can get the code at to play with ?? R loretosa@vodafone.it wrote: >Hi, > >I'm developping the first SIP over SCTP User Agent in Linux. >For this I use the SIP UA KPhone, and I'm modifying it. > >A first version of SIP SCTP client ( KPhone SCTP) is ready !!! > >If you are interested, I update my home page > >( http://utenti.lycos.it/ssal/ ) > >with all the necessary information in order to setup >the enviroment and test the UA. >In this page you'll find also the mail address where >it is possible demand the source code ! > > >Best regards >sal > > >_______________________________________________ >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 Jul 3 13:03:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24885 for ; Thu, 3 Jul 2003 13:03:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7UB-0008A1-7W for tsvwg-archive@odin.ietf.org; Thu, 03 Jul 2003 13:03:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63H37AJ031341 for tsvwg-archive@odin.ietf.org; Thu, 3 Jul 2003 13:03:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7U5-00087r-1U; Thu, 03 Jul 2003 13: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 19Y7TH-00087I-Hj for tsvwg@optimus.ietf.org; Thu, 03 Jul 2003 13:02: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 NAA24777 for ; Thu, 3 Jul 2003 13:02:09 -0400 (EDT) From: loretosa@vodafone.it Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y7TF-0003EW-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 13:02:09 -0400 Received: from [194.185.97.41] (helo=gsp02-c08d1.vodafone.it) by ietf-mx with esmtp (Exim 4.12) id 19Y7TE-0003E0-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 13:02:08 -0400 Received: from vodafone.it (127.0.0.1) by gsp02-c08d1.vodafone.it (NPlex 5.1.046) id 3F036FBC00000763 for tsvwg@ietf.org; Thu, 3 Jul 2003 19:01:30 +0200 Date: Thu, 03 Jul 2003 19:01:28 +0200 Message-Id: Subject: Ri:Ri: [Tsvwg] SIP client over SCTP MIME-Version: 1.0 Message-Context: text-message Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: tsvwg@ietf.org 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 Hi Randal, Yes, maybe it's not a very clean web page... you're right. In any case it's impossible download the software from the site, as I've written in the message: I'll send the source code by mail on demand. best regard Sal > Sal: > > I saw no way to download this code or get a copy.. and I seemed > to get a LOT of adds and such when I hit this site :-< > > Is there any place we can get the code at to play with ?? > > R > > loretosa@vodafone.it wrote: > > >Hi, > > > >I'm developping the first SIP over SCTP User Agent in Linux. > >For this I use the SIP UA KPhone, and I'm modifying it. > > > >A first version of SIP SCTP client ( KPhone SCTP) is ready !!! > > > >If you are interested, I update my home page > > > >( http://utenti.lycos.it/ssal/ ) > > > >with all the necessary information in order to setup > >the enviroment and test the UA. > >In this page you'll find also the mail address where > >it is possible demand the source code ! > > > > > >Best regards > >sal > > > > > >_______________________________________________ > >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 > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 3 19:41:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26186 for ; Thu, 3 Jul 2003 19:41:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDUf-0000Sd-BW for tsvwg-archive@odin.ietf.org; Thu, 03 Jul 2003 19:28:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63NS1l4001734 for tsvwg-archive@odin.ietf.org; Thu, 3 Jul 2003 19:28:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDUe-0000Rb-MF; Thu, 03 Jul 2003 19: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 19YDTv-0000OL-V2 for tsvwg@optimus.ietf.org; Thu, 03 Jul 2003 19:27:16 -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 TAA25092 for ; Thu, 3 Jul 2003 19:27:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YDB1-0001ze-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 19:07:43 -0400 Received: from relay.cosmoweb.net ([66.234.224.17] ident=hidden-user) by ietf-mx with esmtp (Exim 4.12) id 19YDB0-0001zF-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 19:07:43 -0400 Received: from [127.0.0.1] (181-234-234-66.cosmoweb.net [66.234.234.181]) by relay.cosmoweb.net (8.11.6/8.11.6) with ESMTP id h640Z8125549; Thu, 3 Jul 2003 20:35:08 -0400 Date: Thu, 03 Jul 2003 19:07:28 -0400 From: Cyrus Shaoul To: Sally Floyd Subject: Re[2]: [Tsvwg] VoIP and Congestive Collapes: QoS vs. Best Effort Cc: tsvwg@ietf.org In-Reply-To: <200307030527.h635RUe3061621@cougar.icir.org> References: <200307030527.h635RUe3061621@cougar.icir.org> Message-Id: <20030703130502.870E.CYRUS@ntt-at.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 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 Thanks a lot for clearing this up for me. I have a follow-on thought: I think that one aspect that the two drafts do share is a need for certain applications to abide by certain guidelines (for example, calls always terminate when packet loss becomes unacceptable, or video calls never exceed or their requested bandwidth utilization after being admitted.) Do you know if there is a generic way to enforce these requirements on applications? It seems to me that if the guidelines are not enforceable, there will be a tendency to descend into the "tragedy of the Commons" in all these scenarios. (Somebody will always hack a non-compliant version that ignores packet loss, and then distribute to the Internet User it as a "SuperPhone" or something like that.) Is this part of the larger "end-to-end vs. active core" debate? Is this out of the scope of the TSVWG? Thanks again, Cyrus On Wed, 02 Jul 2003 22:27:30 -0700 Sally Floyd wrote: SF> >Are these two drafts trying to solve different problems? SF> SF> The two drafts are trying to solve different problems. SF> SF> The IAB draft, draft-iab-congestion-00.txt, is not trying to say SF> that best-effort service is a good solution for VoIP traffic, or a SF> better solution than some form of QoS, or anything of the kind. SF> The IAB draft is trying to say that today some VoIP traffic in fact SF> runs as best-effort traffic over one or more links in the best-effort SF> Internet, and that this is likely to be the case in the near future SF> as well, and that it is not deemed recommended behavior by the IAB SF> for these flows to maintain their minimum sending rate in the SF> presence of persistent, steady-state packet drop rates experienced SF> by the flow. SF> SF> We will try to be more clear, in the next round of revisions, that SF> we are not trying to say that we are recommending best-effort service SF> as the recommended path for roll-out for VoIP. We are not recommending SF> any roll-out path one way or another. We are observing that in fact, SF> VoIP traffic some times ends up competing, as best-effort traffic, SF> with other best-effort traffic in the Internet. SF> SF> - Sally SF> http://www.icir.org/floyd/ SF> SF> SF> SF> SF> _______________________________________________ SF> tsvwg mailing list SF> tsvwg@ietf.org SF> https://www1.ietf.org/mailman/listinfo/tsvwg Cyrus Shaoul CEO Tomigaia Inc. http://www.tomigaia.com/ cyrus@tomigaia.com 646-645-6881 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 3 19:45:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22979 for ; Thu, 3 Jul 2003 19:24:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDQp-00005j-Of for tsvwg-archive@odin.ietf.org; Thu, 03 Jul 2003 19:24:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63NO3h4000346 for tsvwg-archive@odin.ietf.org; Thu, 3 Jul 2003 19:24:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDQo-0008WA-4l; Thu, 03 Jul 2003 19:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDQX-0008Uh-8P for tsvwg@optimus.ietf.org; Thu, 03 Jul 2003 19:23:45 -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 TAA22120 for ; Thu, 3 Jul 2003 19:23:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YDQU-0003mC-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 19:23:42 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19YDQT-0003lc-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 19:23:41 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h63NNde3072011; Thu, 3 Jul 2003 16:23:39 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200307032323.h63NNde3072011@cougar.icir.org> To: Cyrus Shaoul cc: tsvwg@ietf.org, Ratul Mahajan From: Sally Floyd Subject: Re: Re[2]: [Tsvwg] VoIP and Congestive Collapes: QoS vs. Best Effort Date: Thu, 03 Jul 2003 16:23:39 -0700 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 a lot for clearing this up for me. I have a follow-on thought: I >think that one aspect that the two drafts do share is a need for certain >applications to abide by certain guidelines (for example, calls always >terminate when packet loss becomes unacceptable, or video calls never >exceed or their requested bandwidth utilization after being admitted.) > >Do you know if there is a generic way to enforce these requirements on >applications? It seems to me that if the guidelines are not enforceable, >there will be a tendency to descend into the "tragedy of the Commons" in >all these scenarios. (Somebody will always hack a non-compliant version >that ignores packet loss, and then distribute to the Internet User it as >a "SuperPhone" or something like that.) Is this part of the larger >"end-to-end vs. active core" debate? Is this out of the scope of the >TSVWG? I agree that the network itself has to offer incentives for flows to use end-to-end congestion control (or more precisely, mechanisms for discouraging flows traversing congested paths from not using end-to-end congestion control.) This argument was given in a paper with Kevin Fall on "Promoting the Use of End-to-End Congestion Control in the Internet" ("http://www.icir.org/floyd/end2end-paper.html"), and a router mechanism was proposed in a paper with Ratul Mahajan on "Controlling High-Bandwidth Flows at the Congested Router" (http://www.cs.washington.edu/homes/ratul/red-pd/). A related paper on controlling aggregates from flash crowds or DDoS attacks is a paper on "Controlling High Bandwidth Aggregates in the Network", with a number of coauthors, available from "http://www.icir.org/pushback/". Ratul and I now have an internet-draft-in-progress, not yet submitted, on "Router Primitives for Protection Against High-Bandwidth Flows and Aggregates" ("http://www.icir.org/floyd/papers/draft-flows-00c.txt"). Any feedback on this would be appreciated. This draft is intended to be rather generic, and to encourage the practical deployment of any such mechanisms in routers, so that the Internet community can learn more from the deployment of such mechanisms. (The current draft doesn't consider the specific case of VoIP traffic, but that could easily be added.) - Sally http://www.icir.org/floyd/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 3 20:20:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28139 for ; Thu, 3 Jul 2003 20:20:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YEJ5-0005OP-0A for tsvwg-archive@odin.ietf.org; Thu, 03 Jul 2003 20:20:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h640K6vh020719 for tsvwg-archive@odin.ietf.org; Thu, 3 Jul 2003 20:20:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YEIz-0005NA-RJ; Thu, 03 Jul 2003 20:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YEIl-0005MW-IN for tsvwg@optimus.ietf.org; Thu, 03 Jul 2003 20:19: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 UAA28116 for ; Thu, 3 Jul 2003 20:19:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YEIj-0005yG-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 20:19:45 -0400 Received: from relay.cosmoweb.net ([66.234.224.17] ident=hidden-user) by ietf-mx with esmtp (Exim 4.12) id 19YEIi-0005yC-00 for tsvwg@ietf.org; Thu, 03 Jul 2003 20:19:44 -0400 Received: from [127.0.0.1] (181-234-234-66.cosmoweb.net [66.234.234.181]) by relay.cosmoweb.net (8.11.6/8.11.6) with ESMTP id h641lD125784; Thu, 3 Jul 2003 21:47:13 -0400 Date: Thu, 03 Jul 2003 20:19:30 -0400 From: Cyrus Shaoul To: tsvwg@ietf.org Subject: Re[4]: [Tsvwg] VoIP and Congestive Collapes: QoS vs. Best Effort Cc: Ratul Mahajan In-Reply-To: <200307032323.h63NNde3072011@cougar.icir.org> References: <200307032323.h63NNde3072011@cougar.icir.org> Message-Id: <20030703201709.A1A9.CYRUS@ntt-at.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 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 Sally, I will read all of the documents you pointed to, and try to post any feedback to this list. Thanks, Cyrus On Thu, 03 Jul 2003 16:23:39 -0700 Sally Floyd wrote: SF> >Thanks a lot for clearing this up for me. I have a follow-on thought: I SF> >think that one aspect that the two drafts do share is a need for certain SF> >applications to abide by certain guidelines (for example, calls always SF> >terminate when packet loss becomes unacceptable, or video calls never SF> >exceed or their requested bandwidth utilization after being admitted.) SF> > SF> >Do you know if there is a generic way to enforce these requirements on SF> >applications? It seems to me that if the guidelines are not enforceable, SF> >there will be a tendency to descend into the "tragedy of the Commons" in SF> >all these scenarios. (Somebody will always hack a non-compliant version SF> >that ignores packet loss, and then distribute to the Internet User it as SF> >a "SuperPhone" or something like that.) Is this part of the larger SF> >"end-to-end vs. active core" debate? Is this out of the scope of the SF> >TSVWG? SF> SF> I agree that the network itself has to offer incentives for flows SF> to use end-to-end congestion control (or more precisely, mechanisms SF> for discouraging flows traversing congested paths from not using SF> end-to-end congestion control.) This argument was given in a paper SF> with Kevin Fall on "Promoting the Use of End-to-End Congestion SF> Control in the Internet" ("http://www.icir.org/floyd/end2end-paper.html"), SF> and a router mechanism was proposed in a paper with Ratul Mahajan SF> on "Controlling High-Bandwidth Flows at the Congested Router" SF> (http://www.cs.washington.edu/homes/ratul/red-pd/). A related paper SF> on controlling aggregates from flash crowds or DDoS attacks is a SF> paper on "Controlling High Bandwidth Aggregates in the Network", SF> with a number of coauthors, available from "http://www.icir.org/pushback/". SF> SF> Ratul and I now have an internet-draft-in-progress, not yet submitted, SF> on "Router Primitives for Protection Against High-Bandwidth Flows SF> and Aggregates" ("http://www.icir.org/floyd/papers/draft-flows-00c.txt"). SF> Any feedback on this would be appreciated. This draft is intended SF> to be rather generic, and to encourage the practical deployment of SF> any such mechanisms in routers, so that the Internet community can SF> learn more from the deployment of such mechanisms. (The current SF> draft doesn't consider the specific case of VoIP traffic, but that SF> could easily be added.) SF> SF> - Sally SF> http://www.icir.org/floyd/ Cyrus Shaoul NTT Advanced Technology Corp. cyrus@ntt-at.com http://www.ntt-at.com/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 10 21:24:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29255 for ; Thu, 10 Jul 2003 21:24:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19amdv-0003Hp-CF for tsvwg-archive@odin.ietf.org; Thu, 10 Jul 2003 21:24:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6B1OBQO012627 for tsvwg-archive@odin.ietf.org; Thu, 10 Jul 2003 21:24:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19amdk-0003EN-Rs; Thu, 10 Jul 2003 21:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19amdL-0003Dx-4J for tsvwg@optimus.ietf.org; Thu, 10 Jul 2003 21:23:36 -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 VAA29247 for ; Thu, 10 Jul 2003 21:23:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19amdI-000124-00 for tsvwg@ietf.org; Thu, 10 Jul 2003 21:23:32 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 19amdH-00011x-00 for tsvwg@ietf.org; Thu, 10 Jul 2003 21:23:31 -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 h6B1NG1R025450; Fri, 11 Jul 2003 10:23:16 +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 h6B1NF8E013371; Fri, 11 Jul 2003 10:23:16 +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 h6B1NFeH020749; Fri, 11 Jul 2003 10:23:15 +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 KAA01808; Fri, 11 Jul 2003 10:23:14 +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 KAA09337; Fri, 11 Jul 2003 10:23:14 +0900 (JST) Message-Id: <5.1.1.9.2.20030711101238.041f7dd8@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr3 Date: Fri, 11 Jul 2003 10:23:52 +0900 To: Sally Floyd , Cyrus Shaoul From: "MORITA, Naotaka" Subject: Re: Re[2]: [Tsvwg] VoIP and Congestive Collapes: QoS vs. Best Effort Cc: tsvwg@ietf.org, Ratul Mahajan In-Reply-To: <200307032323.h63NNde3072011@cougar.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; 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 Sally, I have quickly reviewed the relevant documents. My understanding is that your point is how to coordinate best effort traffic regardless of TCP or UDP. This is to avoid useless usage of the Internet. One way is to impose self-control mechanism to each terminal to reduce or to terminate the session as is descirbed in IAB's concern. Another way is to detect over-usage flows or aggregates at routers to get rid of useless ones. It seems reactive control and assumes single traffic class, i.e., best effort. My point as is proposed in the following draft is a kind of preventative control or admission control. http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-00.txt The similarity is to rely on terminals behavior. Naotaka At 16:23 03/07/03 -0700, Sally Floyd wrote: > >Thanks a lot for clearing this up for me. I have a follow-on thought: I > >think that one aspect that the two drafts do share is a need for certain > >applications to abide by certain guidelines (for example, calls always > >terminate when packet loss becomes unacceptable, or video calls never > >exceed or their requested bandwidth utilization after being admitted.) > > > >Do you know if there is a generic way to enforce these requirements on > >applications? It seems to me that if the guidelines are not enforceable, > >there will be a tendency to descend into the "tragedy of the Commons" in > >all these scenarios. (Somebody will always hack a non-compliant version > >that ignores packet loss, and then distribute to the Internet User it as > >a "SuperPhone" or something like that.) Is this part of the larger > >"end-to-end vs. active core" debate? Is this out of the scope of the > >TSVWG? > >I agree that the network itself has to offer incentives for flows >to use end-to-end congestion control (or more precisely, mechanisms >for discouraging flows traversing congested paths from not using >end-to-end congestion control.) This argument was given in a paper >with Kevin Fall on "Promoting the Use of End-to-End Congestion >Control in the Internet" ("http://www.icir.org/floyd/end2end-paper.html"), >and a router mechanism was proposed in a paper with Ratul Mahajan >on "Controlling High-Bandwidth Flows at the Congested Router" >(http://www.cs.washington.edu/homes/ratul/red-pd/). A related paper >on controlling aggregates from flash crowds or DDoS attacks is a >paper on "Controlling High Bandwidth Aggregates in the Network", >with a number of coauthors, available from "http://www.icir.org/pushback/". > >Ratul and I now have an internet-draft-in-progress, not yet submitted, >on "Router Primitives for Protection Against High-Bandwidth Flows >and Aggregates" ("http://www.icir.org/floyd/papers/draft-flows-00c.txt"). >Any feedback on this would be appreciated. This draft is intended >to be rather generic, and to encourage the practical deployment of >any such mechanisms in routers, so that the Internet community can >learn more from the deployment of such mechanisms. (The current >draft doesn't consider the specific case of VoIP traffic, but that >could easily be added.) > >- Sally >http://www.icir.org/floyd/ > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg ---------------------------------- 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 Fri Jul 11 04:17:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20387 for ; Fri, 11 Jul 2003 04:17:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19at5Z-0002DW-UC for tsvwg-archive@odin.ietf.org; Fri, 11 Jul 2003 04:17:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6B8H9dh008468 for tsvwg-archive@odin.ietf.org; Fri, 11 Jul 2003 04:17:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19at5S-00029S-2U; Fri, 11 Jul 2003 04:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19at5C-000286-LZ for tsvwg@optimus.ietf.org; Fri, 11 Jul 2003 04:16:46 -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 EAA20367 for ; Fri, 11 Jul 2003 04:16:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19at59-0003Ov-00 for tsvwg@ietf.org; Fri, 11 Jul 2003 04:16:43 -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 19at58-0003Oo-00 for tsvwg@ietf.org; Fri, 11 Jul 2003 04:16:42 -0400 Received: from esealnt613.al.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 h6B8GfIi011330 for ; Fri, 11 Jul 2003 10:16:41 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XJQB23; Fri, 11 Jul 2003 10:16:41 +0200 Received: from res0010384da36.ericsson.com (rac161pc.edd.ericsson.se [164.48.123.161]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id KAA02817 for ; Fri, 11 Jul 2003 10:16:39 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030711101645.02f7cde8@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 11 Jul 2003 10:17:18 +0200 To: tsvwg@ietf.org From: Reiner Ludwig Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Tsvwg] Issues with draft-blanton-dsack-use-02 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, Sourabh Ladha from UDEL is working with us over the summer looking into ways of adding Eifel to SCTP. In this context we have taken a closer look at the current proposals for spurious retransmit detection schemes. Here are some issues we found with draft-blanton-dsack-use-02 ... A detection scheme that is intended to serve as the basis for reversing cc state should not declare an event a spurious retransmit if, in fact, it was not. This seemed to be the WG consensus after discussions about earlier versions of the Eifel detection algorithm. For that reason the final Eifel detection algorithm was extended by step (5) which is motivated in Section 3.3 of RFC3522 ("Timeout due to loss of all ACKs"). With this extension, we believe that the Eifel detection algorithm is reliable, i.e., we are not aware of any case where it would declare an event a spurious retransmit if, in fact, it was not. [The price for that is that now we have some rare cases where spurious retransmits can occur that are *not* detected by Eifel.] It seems that draft-blanton-dsack-use-02 is not that reliable since we think that we found the following cases where the algorithm will declare an event a spurious retransmit if, in fact, it was not: 1. "Timeout due to loss of all ACKs", see Section 3.3 of RFC3522. 2. Segment N is lost, the ACK for the retransmit of N is lost, and the second retransmit of N goes fine (the segment and the ACK for it) arrives. 3. Segment N is lost, and the retransmit of N is duplicated in the network. Comments? ///Reiner & Sourabh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 11 12:31:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05092 for ; Fri, 11 Jul 2003 12:31:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0nb-00086E-6E for tsvwg-archive@odin.ietf.org; Fri, 11 Jul 2003 12:31:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BGV7Z2031129 for tsvwg-archive@odin.ietf.org; Fri, 11 Jul 2003 12:31:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0nV-00084g-18; Fri, 11 Jul 2003 12:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0mn-00083b-Q2 for tsvwg@optimus.ietf.org; Fri, 11 Jul 2003 12:30: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 MAA05036 for ; Fri, 11 Jul 2003 12:30:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b0ml-0006vK-00 for tsvwg@ietf.org; Fri, 11 Jul 2003 12:30:15 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 19b0mk-0006uw-00 for tsvwg@ietf.org; Fri, 11 Jul 2003 12:30:15 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id B33A76BAEE for ; Fri, 11 Jul 2003 12:29:42 -0400 (EDT) Received: from lawyers.ir.bbn.com (lawyers.grc.nasa.gov [139.88.122.87]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h6BGTehP021970; Fri, 11 Jul 2003 12:29:41 -0400 (EDT) Received: by lawyers.ir.bbn.com (Postfix, from userid 9076) id A63696B2C3; Fri, 11 Jul 2003 12:25:12 -0400 (EDT) To: Reiner Ludwig Cc: tsvwg@ietf.org, "Ethan Blanton" From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Re: [Tsvwg] Issues with draft-blanton-dsack-use-02 In-Reply-To: <5.2.0.9.0.20030711101645.02f7cde8@mailhost.eed.ericsson.se> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Dreams Date: Fri, 11 Jul 2003 12:25:11 -0400 Message-Id: <20030711162512.A63696B2C3@lawyers.ir.bbn.com> Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > It seems that draft-blanton-dsack-use-02 is not that reliable > since we think that we found the following cases where the > algorithm will declare an event a spurious retransmit if, in fact, > it was not: > > 1. "Timeout due to loss of all ACKs", see Section 3.3 of RFC3522. Ah, yes. So, this can be easily special cased as something like: if everything is retransmitted and we get DSACK for everything then we need to reduce cwnd. (The wording needs careful crafting, but that spirit, anyway.) > 2. Segment N is lost, the ACK for the retransmit of N is lost, and > the second retransmit of N goes fine (the segment and the ACK > for it) arrives. > > 3. Segment N is lost, and the retransmit of N is duplicated in the > network. I believe that long ago when we coded this algorithm in ns that Ethan and I talked about these (and, I bet there are others). The document is definately missing discussion that should be there, though. It seems that if we cannot accept these sort of cases (pathologies, IMO) then we cannot use DSACK for this purpose. That is, the DSACK signal is fundementally weak in some respects and so these sorts of cases are inevitable. And, note, that at least for case (3) the document offers *some* protection. If the sender notices a DSACK for something that was not retransmitted then it takes the conservative assuption that since the network is duplicating segments the DSACK signal is not to be believed. So, the question really is... can we accept these sorts of cases or not? If we cannot accept these cases then DSACK (and duplicate TSN notification in SCTP) is pretty much useless for reverting congestion control state. Opinions? My own hit is that things like 2 & 3 are pathalogical and should not be deal breakers for DSACK-based schemes for this purpose. 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 Fri Jul 11 13:03:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06108 for ; Fri, 11 Jul 2003 13:03:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1IX-0002Oo-9T for tsvwg-archive@odin.ietf.org; Fri, 11 Jul 2003 13:03:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BH35Qt009218 for tsvwg-archive@odin.ietf.org; Fri, 11 Jul 2003 13:03:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1IT-0002OZ-4G; Fri, 11 Jul 2003 13: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 19b1IC-0002N3-6w for tsvwg@optimus.ietf.org; Fri, 11 Jul 2003 13:02:44 -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 NAA06057 for ; Fri, 11 Jul 2003 13:02:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b1IA-0007Dh-00 for tsvwg@ietf.org; Fri, 11 Jul 2003 13:02:42 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19b1I9-0007De-00 for tsvwg@ietf.org; Fri, 11 Jul 2003 13:02:41 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id A5F77329B9; Fri, 11 Jul 2003 13:02:40 -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 C2A4832968; Fri, 11 Jul 2003 13:02:39 -0400 (EDT) Date: Fri, 11 Jul 2003 13:02:39 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Cc: Mark Allman , Reiner Ludwig , Ethan Blanton Subject: Re: [Tsvwg] Issues with draft-blanton-dsack-use-02 In-Reply-To: <20030711162512.A63696B2C3@lawyers.ir.bbn.com> 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: , I think I agree with Mark... Item 1 can be handled by a special case. Item 2 seems like a corner case to me. Item 3... I would expect that if the network duplicates one segment, the network will duplicate others. The sender can detect that the network is duplicating segments, and decide to not use DSACKs. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 On Fri, 11 Jul 2003, Mark Allman wrote: > > > It seems that draft-blanton-dsack-use-02 is not that reliable > > since we think that we found the following cases where the > > algorithm will declare an event a spurious retransmit if, in fact, > > it was not: > > > > 1. "Timeout due to loss of all ACKs", see Section 3.3 of RFC3522. > > Ah, yes. So, this can be easily special cased as something like: if > everything is retransmitted and we get DSACK for everything then we > need to reduce cwnd. (The wording needs careful crafting, but that > spirit, anyway.) > > > 2. Segment N is lost, the ACK for the retransmit of N is lost, and > > the second retransmit of N goes fine (the segment and the ACK > > for it) arrives. > > > > 3. Segment N is lost, and the retransmit of N is duplicated in the > > network. > > I believe that long ago when we coded this algorithm in ns that > Ethan and I talked about these (and, I bet there are others). The > document is definately missing discussion that should be there, > though. > > It seems that if we cannot accept these sort of cases (pathologies, > IMO) then we cannot use DSACK for this purpose. That is, the DSACK > signal is fundementally weak in some respects and so these sorts of > cases are inevitable. And, note, that at least for case (3) the > document offers *some* protection. If the sender notices a DSACK > for something that was not retransmitted then it takes the > conservative assuption that since the network is duplicating > segments the DSACK signal is not to be believed. > > So, the question really is... can we accept these sorts of cases or > not? If we cannot accept these cases then DSACK (and duplicate TSN > notification in SCTP) is pretty much useless for reverting > congestion control state. Opinions? > > My own hit is that things like 2 & 3 are pathalogical and should not > be deal breakers for DSACK-based schemes for this purpose. > > allman > > > -- > Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 11 14:17:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08926 for ; Fri, 11 Jul 2003 14:17:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b2SB-00089x-GO for tsvwg-archive@odin.ietf.org; Fri, 11 Jul 2003 14:17:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BIH787031359 for tsvwg-archive@odin.ietf.org; Fri, 11 Jul 2003 14:17:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b2S6-00089c-5F; Fri, 11 Jul 2003 14:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b2Rq-00089H-AW for tsvwg@optimus.ietf.org; Fri, 11 Jul 2003 14:16:46 -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 OAA08873 for ; Fri, 11 Jul 2003 14:16:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b2Rn-0000Ku-00 for tsvwg@ietf.org; Fri, 11 Jul 2003 14:16:43 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19b2Rn-0000Kr-00 for tsvwg@ietf.org; Fri, 11 Jul 2003 14:16:43 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id E16D6329EA; Fri, 11 Jul 2003 14:16:42 -0400 (EDT) Received: from louie.udel.edu (louie.udel.edu [128.4.40.12]) by mail.eecis.udel.edu (Postfix) with ESMTP id 079FC329E9; Fri, 11 Jul 2003 14:16:42 -0400 (EDT) Date: Fri, 11 Jul 2003 14:16:41 -0400 (EDT) From: Sourabh Ladha X-X-Sender: To: "Armando L. Caro Jr." Cc: , Mark Allman , Reiner Ludwig , Ethan Blanton Subject: Re: [Tsvwg] Issues with draft-blanton-dsack-use-02 In-Reply-To: Message-ID: X-Spam-Status: No, hits=-3.4 required=6.0 tests=DEPT_RCVD,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > Item 2 seems like a corner case to me. It may be..though note that in the example we gave the ACK for the first retransmit does not necessarily have to be lost. In general the case can be described that the second retransmit got triggered before the ACK for the first retransmit arrived. I wonder if SCTP multihoming with diverse paths (retransmissions going to alternate(s)) could make this case less pathological? > Item 3... I would expect that if the network duplicates one segment, the > network will duplicate others. The sender can detect that the network is > duplicating segments, and decide to not use DSACKs. Well, in SCTP (multihomed endpoints) retransmissions SHOULD go via alternate path. If the alternate path is duplicating packets then the sender may never be able to realize that it is detecting losses as spurious retransmits (i.e. the sort of protection currently in the given in the draft is rendered useless). I think Mark very well noted in the mail that DSACKs alone are weak signals and the draft notes that timestamp option may futher be used in conjunction to refine the algorithm for network duplication scenarios. -Sourabh > ~armando > > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.cis.udel.edu/~acaro | University of Delaware | > 0-- --0 > > On Fri, 11 Jul 2003, Mark Allman wrote: > > > > > > It seems that draft-blanton-dsack-use-02 is not that reliable > > > since we think that we found the following cases where the > > > algorithm will declare an event a spurious retransmit if, in fact, > > > it was not: > > > > > > 1. "Timeout due to loss of all ACKs", see Section 3.3 of RFC3522. > > > > Ah, yes. So, this can be easily special cased as something like: if > > everything is retransmitted and we get DSACK for everything then we > > need to reduce cwnd. (The wording needs careful crafting, but that > > spirit, anyway.) > > > > > 2. Segment N is lost, the ACK for the retransmit of N is lost, and > > > the second retransmit of N goes fine (the segment and the ACK > > > for it) arrives. > > > > > > 3. Segment N is lost, and the retransmit of N is duplicated in the > > > network. > > > > I believe that long ago when we coded this algorithm in ns that > > Ethan and I talked about these (and, I bet there are others). The > > document is definately missing discussion that should be there, > > though. > > > > It seems that if we cannot accept these sort of cases (pathologies, > > IMO) then we cannot use DSACK for this purpose. That is, the DSACK > > signal is fundementally weak in some respects and so these sorts of > > cases are inevitable. And, note, that at least for case (3) the > > document offers *some* protection. If the sender notices a DSACK > > for something that was not retransmitted then it takes the > > conservative assuption that since the network is duplicating > > segments the DSACK signal is not to be believed. > > > > So, the question really is... can we accept these sorts of cases or > > not? If we cannot accept these cases then DSACK (and duplicate TSN > > notification in SCTP) is pretty much useless for reverting > > congestion control state. Opinions? > > > > My own hit is that things like 2 & 3 are pathalogical and should not > > be deal breakers for DSACK-based schemes for this purpose. > > > > allman > > > > > > -- > > Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg > > > > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 11 14:47:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10023 for ; Fri, 11 Jul 2003 14:47:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b2vE-00012N-LA for tsvwg-archive@odin.ietf.org; Fri, 11 Jul 2003 14:47:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BIl8eE003981 for tsvwg-archive@odin.ietf.org; Fri, 11 Jul 2003 14:47:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b2v7-00011G-LW; Fri, 11 Jul 2003 14:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b2uW-00010D-MC for tsvwg@optimus.ietf.org; Fri, 11 Jul 2003 14:46:24 -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 OAA09999 for ; Fri, 11 Jul 2003 14:46:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b2uT-0000bJ-00 for tsvwg@ietf.org; Fri, 11 Jul 2003 14:46:22 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19b2uT-0000bG-00 for tsvwg@ietf.org; Fri, 11 Jul 2003 14:46:21 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 36875329EE; Fri, 11 Jul 2003 14:46:21 -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 635223299E; Fri, 11 Jul 2003 14:46:20 -0400 (EDT) Date: Fri, 11 Jul 2003 14:46:20 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Sourabh Ladha Cc: , Mark Allman , Reiner Ludwig , Ethan Blanton Subject: Re: [Tsvwg] Issues with draft-blanton-dsack-use-02 In-Reply-To: Message-ID: X-Spam-Status: No, hits=-5.3 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,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 Fri, 11 Jul 2003, Sourabh Ladha wrote: > > Item 2 seems like a corner case to me. > > It may be..though note that in the example we gave the ACK > for the first retransmit does not necessarily have to be lost. In general > the case can be described that the second retransmit got triggered before > the ACK for the first retransmit arrived. I wonder if SCTP > multihoming with diverse paths (retransmissions going to alternate(s)) > could make this case less pathological? It may be less pathological with a multihomed SCTP association. However, what's the loss in making a mistake on an alternate path? The cwnd of alternate paths generally stays close to 2 MTU due to cwnd degradation (no matter which algorithm you go with: RFC2960 or imp guide v8). > > Item 3... I would expect that if the network duplicates one segment, the > > network will duplicate others. The sender can detect that the network is > > duplicating segments, and decide to not use DSACKs. > > Well, in SCTP (multihomed endpoints) retransmissions SHOULD go via > alternate path. If the alternate path is duplicating packets then > the sender may never be able to realize that it is detecting losses as > spurious retransmits (i.e. the sort of protection currently in the given > in the draft is rendered useless). Ok, this is true... > I think Mark very well noted in the mail that DSACKs alone are > weak signals and the draft notes that timestamp option may futher be used in > conjunction to refine the algorithm for network duplication scenarios. I agree. ~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 Sun Jul 13 09:21:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19898 for ; Sun, 13 Jul 2003 09:21:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bgmm-0006vS-QZ for tsvwg-archive@odin.ietf.org; Sun, 13 Jul 2003 09:21:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DDL4KH026599 for tsvwg-archive@odin.ietf.org; Sun, 13 Jul 2003 09:21:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bgmk-0006uj-4p; Sun, 13 Jul 2003 09:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bgmO-0006u2-Lq for tsvwg@optimus.ietf.org; Sun, 13 Jul 2003 09:20:40 -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 JAA19848 for ; Sun, 13 Jul 2003 09:20:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bgmM-00049I-00 for tsvwg@ietf.org; Sun, 13 Jul 2003 09:20:38 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19bgmM-00049F-00 for tsvwg@ietf.org; Sun, 13 Jul 2003 09:20:38 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h6DDKYe3085237; Sun, 13 Jul 2003 06:20:37 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200307131320.h6DDKYe3085237@cougar.icir.org> To: "MORITA, Naotaka" cc: tsvwg@ietf.org From: Sally Floyd Subject: Re: Re[2]: [Tsvwg] VoIP and Congestive Collapes: QoS vs. Best Effort Date: Sun, 13 Jul 2003 06:20:34 -0700 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: , >My point as is proposed in the following draft is >a kind of preventative control or admission control. >http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-00.txt Thanks for the pointer. We are planning to add a brief section in the document with pointers to efforts towards QoS in the Internet (though the draft only addresses that traffic that might be competing directly with best-effort traffic on some congested link). - Sally _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sun Jul 13 09:34:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20627 for ; Sun, 13 Jul 2003 09:34:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bgzJ-0007Fi-EW for tsvwg-archive@odin.ietf.org; Sun, 13 Jul 2003 09:34:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DDY1Sw027854 for tsvwg-archive@odin.ietf.org; Sun, 13 Jul 2003 09:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bgzI-0007ES-N8; Sun, 13 Jul 2003 09:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bgyw-0007ED-HT for tsvwg@optimus.ietf.org; Sun, 13 Jul 2003 09:33:38 -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 JAA20572 for ; Sun, 13 Jul 2003 09:33:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bgyu-0004KJ-00 for tsvwg@ietf.org; Sun, 13 Jul 2003 09:33:36 -0400 Received: from [64.233.207.24] (helo=pop-6.dnv.wideopenwest.com) by ietf-mx with esmtp (Exim 4.12) id 19bgyt-0004Jq-00 for tsvwg@ietf.org; Sun, 13 Jul 2003 09:33:36 -0400 Received: from lawyers.ir.bbn.com (d233-64-125-235.clv.wideopenwest.com [64.233.235.125]) by pop-6.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h6DDWwR24084; Sun, 13 Jul 2003 08:32:58 -0500 Received: by lawyers.ir.bbn.com (Postfix, from userid 9076) id CE9CE6B2C3; Sun, 13 Jul 2003 09:32:39 -0400 (EDT) To: Sourabh Ladha From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: "Armando L. Caro Jr." , tsvwg@ietf.org, Reiner Ludwig , Ethan Blanton Subject: Re: [Tsvwg] Issues with draft-blanton-dsack-use-02 In-Reply-To: Organization: BBN Technologies/NASA GRC Song-of-the-Day: Dreams Date: Sun, 13 Jul 2003 09:32:39 -0400 Message-Id: <20030713133239.CE9CE6B2C3@lawyers.ir.bbn.com> Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > > Item 2 seems like a corner case to me. > > It may be..though note that in the example we gave the ACK for the > first retransmit does not necessarily have to be lost. In general > the case can be described that the second retransmit got triggered > before the ACK for the first retransmit arrived. I wonder if SCTP > multihoming with diverse paths (retransmissions going to > alternate(s)) could make this case less pathological? If you consider the loss rate to be independent in the two directions (or, independent on two paths for SCTP) then even a high loss rate would yield quite low occurances of hitting the case you mentioned. Say the loss rate was 10% in both directions. Now, we have a 1% chance of falling into this situation. That seems pathological to me. Now, if you broaden things to say that excessive delay imposed on either the retransmit or the corresponding ACK can also cause us to fall into this situation (which I agree with) that may increase the chances. But, I have no good idea how to quantify the chances of that. (My gut says that the chances of getting bit by this remain low.) I'd be interested in hearing if others think that issues 2 & 3 are showstoppers for this sort of DSACK use (reverting CC on mistakes). 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 Jul 15 05:32:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10071 for ; Tue, 15 Jul 2003 05:32:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMAG-0002ix-Bv for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 05:32:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9W4VQ010467 for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 05:32:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMAD-0002iB-Cj; Tue, 15 Jul 2003 05:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM9Q-0002eU-Np for tsvwg@optimus.ietf.org; Tue, 15 Jul 2003 05:31: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 FAA09981 for ; Tue, 15 Jul 2003 05:31:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cM9N-0007l7-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 05:31:09 -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 19cM9M-0007l4-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 05:31:08 -0400 Received: from esealnt611.al.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 h6F9V9Ii000610 for ; Tue, 15 Jul 2003 11:31:09 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 3S6JBKDZ; Tue, 15 Jul 2003 11:33:57 +0200 Received: from ericsson.com (dhcp4-155.eed.ericsson.se [164.48.140.155]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id LAA29613 for ; Tue, 15 Jul 2003 11:31:08 +0200 (MET DST) Message-ID: <3F13C98E.5030609@ericsson.com> Date: Tue, 15 Jul 2003 11:29:50 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] SCTP Timestamps 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 been thinking about timestamps a la RFC 1323 for SCTP. We see a number of compelling uses: - Allowing for better and more frequent RTT measurements - Resolving the "path ambiguity" in a multihomed association: If an ACK arrives for a chunk that has been retransmitted one or more times on alternating paths, it is not possible to safely determine which destination the ACK should be credited to (this is briefly mentioned in section 8.2 of RFC 2960). This may result in resetting the wrong error counter (delaying the detection of an inactive path), or in unfair behavior if the congestion window of the wrong path is adapted as a result of the ACK. - Resolving the retransmission ambiguity, i.e. enabling the sender to determine whether an ACK refers to the original transmission or a retransmission of a chunk. This is a necessary precondition for implementing the Eifel algorithm for SCTP (which we are currently looking at). It seems to me there is a pretty strong case for having timestamps in SCTP. Unfortunately there are no provisions for a timestamp option similar to TCP's in the SCTP common header. There has been a proposal (first brought up by Armando, I believe) to introduce a timestamp chunk. This is fine for doing RTT measurements, but for the latter two cases mentioned above, it would require that the timestamp chunk is always bundled with the data chunk it is referring to. My question is how such a "mandatory bundling" is viewed in the community. In some ways it seems to be a break with existing SCTP "philosophy", since so far all chunk types are "self contained", and there is no known case of mandatory bundling. Is it desirable to use new chunk types as a replacement for TCP-like per-packet options? There is also the very practical problem of fragmentation. If we want to avoid possible refragmentation of data chunks, we would have to at least reserve room for the timestamp chunk in each packet (this could be negotiated at connection setup). What happens if we want to introduce further per-packet information in the future? Stephan. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jul 15 06:32:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13182 for ; Tue, 15 Jul 2003 06:32:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cN6K-0005wg-Hj for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 06:32:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FAW4u8022848 for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 06:32:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cN6I-0005vl-7h; Tue, 15 Jul 2003 06:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cN64-0005vL-H4 for tsvwg@optimus.ietf.org; Tue, 15 Jul 2003 06:31:48 -0400 Received: from mail-n.franken.de (postfix@mail-n.franken.de [193.175.24.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13146 for ; Tue, 15 Jul 2003 06:31:41 -0400 (EDT) Received: from lurchi.franken.de (powerbook.ietf57.telekom.at [81.160.140.223]) by mail-n.franken.de (Postfix) with ESMTP id 7BD73245CD; Tue, 15 Jul 2003 12:25:03 +0200 (CEST) Date: Tue, 15 Jul 2003 12:23:32 +0200 Subject: Re: [Tsvwg] SCTP Timestamps Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: tsvwg@ietf.org To: Stephan Baucke From: Michael Tuexen In-Reply-To: <3F13C98E.5030609@ericsson.com> Message-Id: <62929D5C-B6AE-11D7-8328-0030654C1AB6@lurchi.franken.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 Stephan, I'm not sure if you want per packet info or per DATA chunk info? In case of per packet info you could define a new chunk and have it in the packets. In case of per DATA chunk info there is the possibility of defining a new EXT_DATA chunk which is like a DATA chunk but also holds the additional information. Both ways require an extension of the protocol. Best regards Michael On Tuesday, Jul 15, 2003, at 11:29 Europe/Berlin, Stephan Baucke wrote: > Hi all, > > we have been thinking about timestamps a la RFC 1323 for SCTP. We see > a number of compelling uses: > > - Allowing for better and more frequent RTT measurements > > - Resolving the "path ambiguity" in a multihomed association: If an > ACK arrives for a chunk that has been retransmitted one or more times > on alternating paths, it is not possible to safely determine which > destination the ACK should be credited to (this is briefly mentioned > in section 8.2 of RFC 2960). This may result in resetting the wrong > error counter (delaying the detection of an inactive path), or in > unfair behavior if the congestion window of the wrong path is adapted > as a result of the ACK. > > - Resolving the retransmission ambiguity, i.e. enabling the sender to > determine whether an ACK refers to the original transmission or a > retransmission of a chunk. This is a necessary precondition for > implementing the Eifel algorithm for SCTP (which we are currently > looking at). > > > It seems to me there is a pretty strong case for having timestamps in > SCTP. Unfortunately there are no provisions for a timestamp option > similar to TCP's in the SCTP common header. There has been a proposal > (first brought up by Armando, I believe) to introduce a timestamp > chunk. This is fine for doing RTT measurements, but for the latter two > cases mentioned above, it would require that the timestamp chunk is > always bundled with the data chunk it is referring to. > > My question is how such a "mandatory bundling" is viewed in the > community. In some ways it seems to be a break with existing SCTP > "philosophy", since so far all chunk types are "self contained", and > there is no known case of mandatory bundling. Is it desirable to use > new chunk types as a replacement for TCP-like per-packet options? > There is also the very practical problem of fragmentation. If we want > to avoid possible refragmentation of data chunks, we would have to at > least reserve room for the timestamp chunk in each packet (this could > be negotiated at connection setup). What happens if we want to > introduce further per-packet information in the future? > > Stephan. > > > _______________________________________________ > 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 Tue Jul 15 07:39:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15112 for ; Tue, 15 Jul 2003 07:39:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cO9B-0000jW-JI for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 07:39:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FBd5QJ002817 for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 07:39:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cO97-0000ig-3u; Tue, 15 Jul 2003 07:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cO90-0000iS-1M for tsvwg@optimus.ietf.org; Tue, 15 Jul 2003 07:38:54 -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 HAA15069 for ; Tue, 15 Jul 2003 07:38:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cO8t-0000yu-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 07:38:47 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[wvFWdCgCF/ldv+DU+7SAl3zdl2uL+gEF]) by ietf-mx with esmtp (Exim 4.12) id 19cO8H-0000xu-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 07:38:09 -0400 Received: from ns.pigworks.openss7.net (IDENT:MM/wS1O0XxSEM67habpuiWIUoO+DodcE@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h6FBbpP02462; Tue, 15 Jul 2003 05:37:51 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h6FBbpw05593; Tue, 15 Jul 2003 05:37:51 -0600 Date: Tue, 15 Jul 2003 05:37:50 -0600 From: "Brian F. G. Bidulock" To: Stephan Baucke Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps Message-ID: <20030715053750.E1007@openss7.org> Reply-To: bidulock@openss7.org References: <3F13C98E.5030609@ericsson.com> 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: <3F13C98E.5030609@ericsson.com>; from stephan.baucke@ericsson.com on Tue, Jul 15, 2003 at 11:29:50AM +0200 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 h6FBbpP02462 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 Stephan, "Better and more frequent RTT measurements"? Better how? More frequent? Not significantly so, except perhaps during special (read: rare) anomalies I would think. Clear the wrong error counter? RFC 2960 says: If this ambiguity is undesirable, the transmitter may choose not to clear the error counter if the last chunk was a retransmission. Where is the congestion window of the wrong path adapted as a result of an ACK? I think this could only be as a result of some really strange situation. Besides, not crediting a destination cwnd for retransmitted packets would be more conservative than crediting, and is therefore, permitted. The same applies, if you don't like possibly crediting the wrong destination for the retransmitted packet, don't credit any destination for a retransmitted packet. It shouldn't really matter, some destination got dinged really bad for slipping a RTO in the first place. This exponential back off far overwhelms any meager linear growth from a few retransmitted packets. "Unfair behavior"? Fairness between paths is not of consideration. Congestion fairness between TCP connections and SCTP associations is. Only the primary gets credited when all is well and the other paths suck slow start, even if heartbeats show superb RTT. How fair is that? What do you mean "refragmentation [sic] of data chunks"? Once fragmentation of data is made into data chunks, they cannot be re-fragmented. See RFC 2960 Section 6.9: Note: Once a message is fragmented it cannot be re-fragmented. Instead if the PMTU has been reached, then IP fragmentation must be used. ... Perhaps Eifel an TSN wrap on Googleplex-bytes-per-second paths might be reasons for timestamps, but the above don't sound like justifications. If you want to take a really accurate RTT measurement in SCTP, send a heartbeat and place whatever timestamps and identifiers you want in the heartbeat data. I find sending a heartbeat just after Path.Max.Retrans has been exceeded to be quite useful for quickly restoring paths to which you were simply too cruel, and particularly when Path.Max.Retrans is set to 0. --brian On Tue, 15 Jul 2003, Stephan Baucke wrote: > Hi all, >=20 > we have been thinking about timestamps a la RFC 1323 for SCTP. We see a= =20 > number of compelling uses: >=20 > - Allowing for better and more frequent RTT measurements >=20 > - Resolving the "path ambiguity" in a multihomed association: If an ACK= =20 > arrives for a chunk that has been retransmitted one or more times on=20 > alternating paths, it is not possible to safely determine which=20 > destination the ACK should be credited to (this is briefly mentioned in= =20 > section 8.2 of RFC 2960). This may result in resetting the wrong error=20 > counter (delaying the detection of an inactive path), or in unfair=20 > behavior if the congestion window of the wrong path is adapted as a=20 > result of the ACK. >=20 > - Resolving the retransmission ambiguity, i.e. enabling the sender to=20 > determine whether an ACK refers to the original transmission or a=20 > retransmission of a chunk. This is a necessary precondition for=20 > implementing the Eifel algorithm for SCTP (which we are currently=20 > looking at). >=20 >=20 > It seems to me there is a pretty strong case for having timestamps in=20 > SCTP. Unfortunately there are no provisions for a timestamp option=20 > similar to TCP's in the SCTP common header. There has been a proposal=20 > (first brought up by Armando, I believe) to introduce a timestamp chunk= .=20 > This is fine for doing RTT measurements, but for the latter two cases=20 > mentioned above, it would require that the timestamp chunk is always=20 > bundled with the data chunk it is referring to. >=20 > My question is how such a "mandatory bundling" is viewed in the=20 > community. In some ways it seems to be a break with existing SCTP=20 > "philosophy", since so far all chunk types are "self contained", and=20 > there is no known case of mandatory bundling. Is it desirable to use ne= w=20 > chunk types as a replacement for TCP-like per-packet options? There is=20 > also the very practical problem of fragmentation. If we want to avoid=20 > possible refragmentation of data chunks, we would have to at least=20 > reserve room for the timestamp chunk in each packet (this could be=20 > negotiated at connection setup). What happens if we want to introduce=20 > further per-packet information in the future? >=20 > Stephan. >=20 >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jul 15 07:54:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15468 for ; Tue, 15 Jul 2003 07:54:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cONe-0001Kd-B4 for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 07:54:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FBs23r005084 for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 07:54:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cONd-0001JC-9U; Tue, 15 Jul 2003 07:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cON3-0001Iv-K2 for tsvwg@optimus.ietf.org; Tue, 15 Jul 2003 07:53:25 -0400 Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15458 for ; Tue, 15 Jul 2003 07:53:20 -0400 (EDT) Received: from chiimc01.npac.com ([10.32.90.4]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id h6FBlqN11801 for ; Tue, 15 Jul 2003 11:47:52 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jul 2003 06:50:36 -0500 Message-ID: <982243CBE3E73F42B950A4AD6CCE4FEE066F35@stntexch02> From: "Peterson, Jon" To: "'tsvwg@ietf.org'" Date: Tue, 15 Jul 2003 06:47:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Tsvwg] agenda for 57th IETF TSVWG meeting 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: , Transport Area WG (tsvwg) Friday, July 18 at 0900-1130 ============================= CHAIRS: Allison Mankin Jon Peterson 0900 Charter Discussion (chairs) 0910 General Area Review (chairs) 0925 Fast TCP (Cheng Jin) 0950 Gbit TCP (Sally Floyd) 1010 NewReno to PS (Sally Floyd) 1030 Eifel Response (Reiner Ludwig) 1045 MH-PHB (Naotaka Morita) 1100 Update on PR-SCTP (Randall Stewart) 1115 Update on F-RTO (Psi Sarolahti) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jul 15 09:15:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17505 for ; Tue, 15 Jul 2003 09:15:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cPe7-00057D-U0 for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 09:15:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FDF7ee019657 for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 09:15:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cPe1-00056G-KF; Tue, 15 Jul 2003 09:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cPdW-000556-3G for tsvwg@optimus.ietf.org; Tue, 15 Jul 2003 09:14: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 JAA17490 for ; Tue, 15 Jul 2003 09:14:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cPdU-0001pU-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 09:14:28 -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 19cPdJ-0001nK-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 09:14:17 -0400 Received: from esealnt613.al.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 h6FDDeGJ021642 for ; Tue, 15 Jul 2003 15:13:40 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XKLRMY; Tue, 15 Jul 2003 15:13:40 +0200 Received: from ericsson.com (dhcp4-155.eed.ericsson.se [164.48.140.155]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id PAA29325 for ; Tue, 15 Jul 2003 15:13:38 +0200 (MET DST) Message-ID: <3F13FDB4.6050903@ericsson.com> Date: Tue, 15 Jul 2003 15:12:20 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps References: <3F13C98E.5030609@ericsson.com> <20030715053750.E1007@openss7.org> In-Reply-To: <20030715053750.E1007@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: > "Better and more frequent RTT measurements"? > > Better how? More frequent? Not significantly so, except > perhaps during special (read: rare) anomalies I would think. Timestamps would enable us to do RTTM (RTT measurement on every packet), as described in RFC 1323. Together with an appropriate timer calculation, this has the potential for an RTO that more accurately follows the RTT. Also, since timestamps resolve the retransmission ambiguity, we don't have to use Karn's algorithm. Karn's algorithm together with SCTP's retransmission policy has been shown to cause an overly conservative RTO in certain multihomed scenarios (see http://www.cis.udel.edu/~acaro/papers/2003.milcom.acaro.pdf) > Clear the wrong error counter? RFC 2960 says: > > If this ambiguity is undesirable, the transmitter may choose > not to clear the error counter if the last chunk was a > retransmission. This helps, but can result in a premature failure detection on the secondary path (which is usually only used for retransmissions). > Where is the congestion window of the wrong path adapted as a > result of an ACK? If an ACK is credited to a wrong path, the CWND on that path will be falsely increased where it should be decreased. > I think this could only be as a result of some really strange > situation. Consider the following example: 1) Chunk A is sent over the primary path 2) A spurious timeout occurs on the primary path 3) Chunk A is retransmitted over the secondary path 4) The packet is lost on the secondary path 5) Finally, the SACK arrives for the original transmission over the pirmary path According to RFC 2960, the SACK will be credited to the secondary path, since that's where the last retransmission took place. So, we will increase its congestion window where we should really halve it or set it to <=2*MTU, since a packet loss occured on that path. > Besides, not crediting a destination cwnd for > retransmitted packets would be more conservative than > crediting, and is therefore, permitted. The same applies, if > you don't like possibly crediting the wrong destination for > the retransmitted packet, don't credit any destination for a > retransmitted packet. We would still fail to reduce the cwnd on one path. > "Unfair behavior"? > > Fairness between paths is not of consideration. Congestion > fairness between TCP connections and SCTP associations is. Of course I was referring to the latter case. > What do you mean "refragmentation [sic] of data chunks"? > > Once fragmentation of data is made into data chunks, they > cannot be re-fragmented. See RFC 2960 Section 6.9: > > Note: Once a message is fragmented it cannot be re-fragmented. > Instead if the PMTU has been reached, then IP fragmentation must be > used. ... Yes. That's why we would run into problems if we were to use new chunk types as per-packet options without reserving space for them in every packet, regardless whether the option is actually used in all packets or only a part of them. > Perhaps Eifel an TSN wrap on Googleplex-bytes-per-second paths > might be reasons for timestamps, but the above don't sound > like justifications. > > If you want to take a really accurate RTT measurement in SCTP, > send a heartbeat and place whatever timestamps and identifiers > you want in the heartbeat data. Heartbeats might be too infrequent for some scenarios. Stephan. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jul 15 09:17:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17594 for ; Tue, 15 Jul 2003 09:17:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cPfx-0005JM-26 for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 09:17:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FDH1rW020409 for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 09:17:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cPfw-0005J5-Q0; Tue, 15 Jul 2003 09:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cPfX-0005Gu-4X for tsvwg@optimus.ietf.org; Tue, 15 Jul 2003 09:16:35 -0400 Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17539 for ; Tue, 15 Jul 2003 09:16:29 -0400 (EDT) From: ladha@mail.eecis.udel.edu Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 1728532A8C; Tue, 15 Jul 2003 09:16:32 -0400 (EDT) Received: from webmail.eecis.udel.edu (dbacks.acad.ece.udel.edu [128.4.60.14]) by mail.eecis.udel.edu (Postfix) with SMTP id 43FCD32A8B; Tue, 15 Jul 2003 09:16:31 -0400 (EDT) Received: from 212.117.81.29 (SquirrelMail authenticated user ladha) by webmail.eecis.udel.edu with HTTP; Tue, 15 Jul 2003 09:16:31 -0400 (EDT) Message-ID: <25643.212.117.81.29.1058274991.squirrel@webmail.eecis.udel.edu> In-Reply-To: <20030715053750.E1007@openss7.org> References: <3F13C98E.5030609@ericsson.com> <20030715053750.E1007@openss7.org> Date: Tue, 15 Jul 2003 09:16:31 -0400 (EDT) Subject: Re: [Tsvwg] SCTP Timestamps To: bidulock@openss7.org Cc: "Stephan Baucke" , tsvwg@ietf.org User-Agent: SquirrelMail/1.4.0 X-Priority: 3 Importance: Normal X-Spam-Status: No, hits=-1.2 required=6.0 tests=DEPT_RCVD,IN_REP_TO,NO_REAL_NAME,PRIORITY_NO_NAME, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05,USER_AGENT 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="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, > "Better and more frequent RTT measurements"? > > Better how? More frequent? Not significantly so, except > perhaps during special (read: rare) anomalies I would think. I hope that you know the answer to "More Frequent?". As far as better is concerned, I think this has been argued before on the list as well as in research papers. You can probably look for RTTM in RFC1323 and Phil Karn's 1987 paper which brings out the Retransmission-Ambuiguity problem and on the other side Allman's 1999 SIGCOMM paper. I wonder if you are also questioning timestamps in TCP ? > Clear the wrong error counter? RFC 2960 says: > > If this ambiguity is undesirable, the transmitter may choose ^^^^^^^^^ > not to clear the error counter if the last chunk was a > retransmission. I thought the point was that with timestamps you can avoid this ambuiguity. > Where is the congestion window of the wrong path adapted as a > result of an ACK? > > I think this could only be as a result of some really strange > situation. Besides, not crediting a destination cwnd for > retransmitted packets would be more conservative than > crediting, and is therefore, permitted. The same applies, if > you don't like possibly crediting the wrong destination for > the retransmitted packet, don't credit any destination for a > retransmitted packet. It shouldn't really matter, some > destination got dinged really bad for slipping a RTO in the > first place. This exponential back off far overwhelms any > meager linear growth from a few retransmitted packets. > > "Unfair behavior"? > > Fairness between paths is not of consideration. Congestion > fairness between TCP connections and SCTP associations is. > Only the primary gets credited when all is well and the other > paths suck slow start, even if heartbeats show superb RTT. > How fair is that? I do not think Stephan's meant or even mentioned "fairness between paths". I believe he meant that the "Retransmission-Ambuiguity" may cause the wrong destination to be credited for cwnd. A simplistic situation is: If you have a timeout and retransmit on the alternate, then you do not know on the reciept of an ACK if it corresponds to the retransmission or the original (which may have got delayed). Try adapting this to cwnd crediting as well and you will see what Stephan referred to. I believe you can find some action related to this at http://www.cis.udel.edu/~iyengar/publications/ (papers: [1] Making SCTP More Robust to Changeover [2] SCTP Congestion Window Overgrowth During Changeover) > What do you mean "refragmentation [sic] of data chunks"? > > Once fragmentation of data is made into data chunks, they > cannot be re-fragmented. See RFC 2960 Section 6.9: > > Note: Once a message is fragmented it cannot be re-fragmented. > Instead if the PMTU has been reached, then IP fragmentation must be > used. ... I agree. Maybe the issue was that for mandatory bundling of timestamp chunks one will have to take into consideration the association-PMTU as well as the timestamp-chunk size before fragmenting. -Sourabh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jul 15 12:54:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26791 for ; Tue, 15 Jul 2003 12:54:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cT42-0007rK-QE for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 12:54:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FGs624030179 for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 12:54:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cT3x-0007oA-5b; Tue, 15 Jul 2003 12:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cT3W-0007ns-4W for tsvwg@optimus.ietf.org; Tue, 15 Jul 2003 12:53:34 -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 MAA26776 for ; Tue, 15 Jul 2003 12:53:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cT3U-0003ij-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 12:53:32 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19cT3J-0003iU-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 12:53:21 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 91B3532AB8; Tue, 15 Jul 2003 12:52:56 -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 901A5328A4; Tue, 15 Jul 2003 12:52:55 -0400 (EDT) Date: Tue, 15 Jul 2003 12:52:55 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Stephan Baucke Cc: Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: <3F13C98E.5030609@ericsson.com> 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 Tue, 15 Jul 2003, Stephan Baucke wrote: > My question is how such a "mandatory bundling" is viewed in the > community. In some ways it seems to be a break with existing SCTP > "philosophy", since so far all chunk types are "self contained", and > there is no known case of mandatory bundling. First, I don't see a need to make it mandatory. The sender can choose to bundle timestamps with all packets containing data and/or sack chunks. If the sender chooses not to include timestamps, then the sender must follow the conservative behavior anytime an ambiguous scenario arises. Second, I think the ECNE and CWR chunks are examples of chunk types that, if used, need to be in every packet. The sender simply needs to reserve space for these chunks. ~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 Tue Jul 15 13:32:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27604 for ; Tue, 15 Jul 2003 13:32:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cTen-0000zY-77 for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 13:32:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FHW5ex003797 for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 13:32:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cTej-0000yU-KF; Tue, 15 Jul 2003 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cTdo-0000tl-Uv for tsvwg@optimus.ietf.org; Tue, 15 Jul 2003 13:31: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 NAA27561 for ; Tue, 15 Jul 2003 13:31:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cTdm-00041F-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 13:31:02 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19cTdc-00041B-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 13:30:52 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 5713832AB9; Tue, 15 Jul 2003 13:30:47 -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 2C31A32AB8; Tue, 15 Jul 2003 13:30:46 -0400 (EDT) Date: Tue, 15 Jul 2003 13:30:46 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Stephan Baucke Cc: , Janardhan Iyengar Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: <3F13FDB4.6050903@ericsson.com> 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 Tue, 15 Jul 2003, Stephan Baucke wrote: > Brian F. G. Bidulock wrote: > > > "Better and more frequent RTT measurements"? > > > > Better how? More frequent? Not significantly so, except > > perhaps during special (read: rare) anomalies I would think. > > Timestamps would enable us to do RTTM (RTT measurement on every packet), > as described in RFC 1323. Together with an appropriate timer > calculation, this has the potential for an RTO that more accurately > follows the RTT. "Together with an appropriate timer calculation" is an important clause. As mentioned in RFC2960, Mark Allman and Vern Paxson show that measuring RTTs more frequently than once per RTT does not yield any significant benefit. Also, if measurements are made more often, RTO.Alpha and RTO.Beta should be adjusted, but it is still an open question how to adjust the RTO calculation. Allman, M. and Paxson, V., "On Estimating End-to-End Network Path Properties", Proc. SIGCOMM'99, 1999. But with multihoming, timestamps can be useful for alternate paths as you allude to below. > Also, since timestamps resolve the retransmission > ambiguity, we don't have to use Karn's algorithm. Karn's algorithm > together with SCTP's retransmission policy has been shown to cause an > overly conservative RTO in certain multihomed scenarios (see > http://www.cis.udel.edu/~acaro/papers/2003.milcom.acaro.pdf) Also, see http://www.cis.udel.edu/~acaro/papers/2003.icon.acaro.pdf or the full tech report http://www.cis.udel.edu/~acaro/papers/2003.TR2003-05.acaro.pdf > > Clear the wrong error counter? RFC 2960 says: > > > > If this ambiguity is undesirable, the transmitter may choose > > not to clear the error counter if the last chunk was a > > retransmission. > > This helps, but can result in a premature failure detection on the > secondary path (which is usually only used for retransmissions). Yes. Also the point is, if we can eliminate the ambiguity to improve performance, then we should. Should we not?? > > Where is the congestion window of the wrong path adapted as a > > result of an ACK? > > If an ACK is credited to a wrong path, the CWND on that path will be > falsely increased where it should be decreased. Timestamps may help alleviate this problem, but I think the SFR-CACC algorithm is a better solution. The SFR-CACC algorithm requires changes only at the sender side without extra bits on the wire. See: http://www.cis.udel.edu/~acaro/papers/2003.spects.iyengar.pdf http://www.cis.udel.edu/~acaro/papers/2002.sci.iyengar.pdf Jana Iyengar has also made more progress with the algorithm to prevent the same issue from occuring with cycling changeovers. Plus, the improved algorithm is actually simpler. Unfortunately, he doesn't have any documents yet which explain the modified algorithm. > > I think this could only be as a result of some really strange > > situation. > > Consider the following example: > 1) Chunk A is sent over the primary path > 2) A spurious timeout occurs on the primary path > 3) Chunk A is retransmitted over the secondary path > 4) The packet is lost on the secondary path > 5) Finally, the SACK arrives for the original transmission over the > pirmary path > > According to RFC 2960, the SACK will be credited to the secondary path, > since that's where the last retransmission took place. So, we will > increase its congestion window where we should really halve it or set it > to <=2*MTU, since a packet loss occured on that path. Your scenario is very similar to the example scenario which Jana uses, except his scenario involves a changeover which causes spurious fast retransmits. > > Besides, not crediting a destination cwnd for > > retransmitted packets would be more conservative than > > crediting, and is therefore, permitted. The same applies, if > > you don't like possibly crediting the wrong destination for > > the retransmitted packet, don't credit any destination for a > > retransmitted packet. > > We would still fail to reduce the cwnd on one path. Yes, that's right. The CACC problem causes spurious retransmits on the alternate/new path and incorrect cwnd growth on the alternate/new path ...even if the retransmissions on the alternate/new path are lost! > > "Unfair behavior"? > > > > Fairness between paths is not of consideration. Congestion > > fairness between TCP connections and SCTP associations is. > > Of course I was referring to the latter case. Obviously, incorrectly increasing the cwnd as described above is not fair to TCP, TCP-friendly, Internet-friendly, or whatever you want to call it. > Yes. That's why we would run into problems if we were to use new chunk > types as per-packet options without reserving space for them in every > packet, regardless whether the option is actually used in all packets or > only a part of them. I am not sure I understand the problem here. I know there is some inefficiency with reserving space for control chunks, but since timestamps will be essentially in every packet... what's the problem? > > Perhaps Eifel an TSN wrap on Googleplex-bytes-per-second paths > > might be reasons for timestamps, but the above don't sound > > like justifications. > > > > If you want to take a really accurate RTT measurement in SCTP, > > send a heartbeat and place whatever timestamps and identifiers > > you want in the heartbeat data. > > Heartbeats might be too infrequent for some scenarios. Yes. You _could_ decrease the HB.interval, but then the sender would introduce more "useless" packets on the wire... which I don't particularly like. ~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 Tue Jul 15 14:00:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28064 for ; Tue, 15 Jul 2003 14:00:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cU5r-0002AN-Ud for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 14:00:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FI03Hm008288 for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 14:00:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cU5p-00029W-Mn; Tue, 15 Jul 2003 14: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 19cU57-00026U-O1 for tsvwg@optimus.ietf.org; Tue, 15 Jul 2003 13:59: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 NAA28035 for ; Tue, 15 Jul 2003 13:59:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cU55-0004Ac-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 13:59:15 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19cU4u-0004AT-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 13:59:04 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 4CA0432A90; Tue, 15 Jul 2003 13:58:44 -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 6E76732ABF; Tue, 15 Jul 2003 13:58:43 -0400 (EDT) Date: Tue, 15 Jul 2003 13:58:24 -0400 (EDT) From: Sourabh Ladha X-X-Sender: To: "Armando L. Caro Jr." Cc: Stephan Baucke , Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: Message-ID: X-Spam-Status: No, hits=-3.4 required=6.0 tests=DEPT_RCVD,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > On Tue, 15 Jul 2003, Stephan Baucke wrote: > > > My question is how such a "mandatory bundling" is viewed in the > > community. In some ways it seems to be a break with existing SCTP > > "philosophy", since so far all chunk types are "self contained", and > > there is no known case of mandatory bundling. > > First, I don't see a need to make it mandatory. The sender can choose to > bundle timestamps with all packets containing data and/or sack chunks. If > the sender chooses not to include timestamps, then the sender must follow > the conservative behavior anytime an ambiguous scenario arises. Of course if adopted, the timestamp chunk parameter will have to be defined to be negotiated in the INIT/INIT-ACK. By mandatory the reference was that if both endpoints agree on timestamp then the timestamp chunk MUST be bundled with all packets containing DATA/SACK chunk(s). Your clarification below addresses that concern, I think. > Second, I think the ECNE and CWR chunks are examples of chunk types that, > if used, need to be in every packet. The sender simply needs to reserve > space for these chunks. > -Sourabh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jul 15 15:27:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01289 for ; Tue, 15 Jul 2003 15:27:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVS9-00061l-M1 for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 15:27:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FJR9a3023165 for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 15:27:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVS1-00060p-6b; Tue, 15 Jul 2003 15:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cVRO-0005yt-Bc for tsvwg@optimus.ietf.org; Tue, 15 Jul 2003 15:26: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 PAA01228 for ; Tue, 15 Jul 2003 15:26:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cVRN-0004kf-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 15:26:21 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19cVR7-0004jf-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 15:26:05 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 6FDC832AF2; Tue, 15 Jul 2003 15:22:28 -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 87AFF32AF0; Tue, 15 Jul 2003 15:22:27 -0400 (EDT) Date: Tue, 15 Jul 2003 15:22:27 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Stephan Baucke Cc: , Janardhan Iyengar Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: 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: , In a private discussion with Sourabh, he pointed out to me that the CACC algorithm will not solve the problem presented below by Stephan. Although the side effects of the scenario are similar, the CACC relies on Gap Ack information to solve the problem. My mistake... So I take back what I say, and agree that timestamps are a good solution. Sorry for the confusion. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 On Tue, 15 Jul 2003, Armando L. Caro Jr. wrote: > > > Where is the congestion window of the wrong path adapted as a > > > result of an ACK? > > > > If an ACK is credited to a wrong path, the CWND on that path will be > > falsely increased where it should be decreased. > > Timestamps may help alleviate this problem, but I think the SFR-CACC > algorithm is a better solution. The SFR-CACC algorithm requires > changes only at the sender side without extra bits on the wire. > > See: > http://www.cis.udel.edu/~acaro/papers/2003.spects.iyengar.pdf > http://www.cis.udel.edu/~acaro/papers/2002.sci.iyengar.pdf > > Jana Iyengar has also made more progress with the algorithm to prevent the > same issue from occuring with cycling changeovers. Plus, the improved > algorithm is actually simpler. Unfortunately, he doesn't have any > documents yet which explain the modified algorithm. > > > > I think this could only be as a result of some really strange > > > situation. > > > > Consider the following example: > > 1) Chunk A is sent over the primary path > > 2) A spurious timeout occurs on the primary path > > 3) Chunk A is retransmitted over the secondary path > > 4) The packet is lost on the secondary path > > 5) Finally, the SACK arrives for the original transmission over the > > pirmary path > > > > According to RFC 2960, the SACK will be credited to the secondary path, > > since that's where the last retransmission took place. So, we will > > increase its congestion window where we should really halve it or set it > > to <=2*MTU, since a packet loss occured on that path. > > Your scenario is very similar to the example scenario which Jana uses, > except his scenario involves a changeover which causes spurious fast > retransmits. > > > > Besides, not crediting a destination cwnd for > > > retransmitted packets would be more conservative than > > > crediting, and is therefore, permitted. The same applies, if > > > you don't like possibly crediting the wrong destination for > > > the retransmitted packet, don't credit any destination for a > > > retransmitted packet. > > > > We would still fail to reduce the cwnd on one path. > > Yes, that's right. The CACC problem causes spurious retransmits on the > alternate/new path and incorrect cwnd growth on the alternate/new path > ...even if the retransmissions on the alternate/new path are lost! > > > > "Unfair behavior"? > > > > > > Fairness between paths is not of consideration. Congestion > > > fairness between TCP connections and SCTP associations is. > > > > Of course I was referring to the latter case. > > Obviously, incorrectly increasing the cwnd as described above is not fair > to TCP, TCP-friendly, Internet-friendly, or whatever you want to call it. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jul 15 18:41:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09478 for ; Tue, 15 Jul 2003 18:41:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cYTr-0006zk-2Y for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 18:41:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FMf7iF026887 for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 18:41:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cYTl-0006zY-1f; Tue, 15 Jul 2003 18:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cYTH-0006zA-Q2 for tsvwg@optimus.ietf.org; Tue, 15 Jul 2003 18:40:31 -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 SAA09422 for ; Tue, 15 Jul 2003 18:40:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cYTE-0006cz-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 18:40:28 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19cYT4-0006cO-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 18:40:18 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h6FMdksn018734; Tue, 15 Jul 2003 15:39:46 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h6FMcx9d001738; Tue, 15 Jul 2003 17:38:59 -0500 Message-ID: <3F148362.3048EE5@motorola.com> Date: Tue, 15 Jul 2003 17:42:42 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sourabh Ladha CC: "Armando L. Caro Jr." , Stephan Baucke , tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Pls see me comments below... Sourabh Ladha wrote: > > > On Tue, 15 Jul 2003, Stephan Baucke wrote: > > > > > My question is how such a "mandatory bundling" is viewed in the > > > community. In some ways it seems to be a break with existing SCTP > > > "philosophy", since so far all chunk types are "self contained", and > > > there is no known case of mandatory bundling. > > > > First, I don't see a need to make it mandatory. The sender can choose to > > bundle timestamps with all packets containing data and/or sack chunks. If > > the sender chooses not to include timestamps, then the sender must follow > > the conservative behavior anytime an ambiguous scenario arises. > > Of course if adopted, the timestamp chunk parameter will have to be > defined to be negotiated in the INIT/INIT-ACK. By mandatory the reference > was that if both endpoints agree on timestamp then the timestamp chunk > MUST be bundled with all packets containing DATA/SACK chunk(s). Your > clarification below addresses that concern, I think. Whenever I see a "MUST" used (or being suggested to be used) in the spec, I'd like to understand what would be the error handling strategy if this "MUST" is violated. Since you are suggesting a "MUST" clause here, would you immediately severe the communication with a peer that had agreed to use timestamp feature but you subsequently receive a packet from it without the timestamp chunk bundled? If your answer is "yes", then I'd guess that you somehow must view this missing timestamp as an unrecoverable protocol error which can do potential harm to your endpoint or the network if not stopping the communication right away. But this is not obvious to me, so please explain. If your answer is "no", then I'd question why you want to use a "MUST" here. Another question: since the timestamp information (however it would be defined for your purposes) seems to only have local significance to the data sender. If so, this info can be kept opaque to the peer/receiver. Since the SCTP heartbeat (it has been clarified that the HB can be sent at different frequency or even "manually" triggered by the ULP whenever one is needed) has the capability to carry and return an opaque data blob, I don't see why you need to define a new timestamp chunk? > > Second, I think the ECNE and CWR chunks are examples of chunk types that, > > if used, need to be in every packet. The sender simply needs to reserve > > space for these chunks. To reserve room for control chunks is part of the SCTP fragmentation code present today in *every* implementation that supports fragmentation. So this should not be a problem and should add no complexity. -Qiaobing > > > > -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 Tue Jul 15 19:38:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11396 for ; Tue, 15 Jul 2003 19:38:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cZMw-00011B-MB for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 19:38:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FNc240003875 for tsvwg-archive@odin.ietf.org; Tue, 15 Jul 2003 19:38:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cZMu-0000zP-QO; Tue, 15 Jul 2003 19:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cZMr-0000yy-AR for tsvwg@optimus.ietf.org; Tue, 15 Jul 2003 19:37: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 TAA11381 for ; Tue, 15 Jul 2003 19:37:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cZMp-0007DA-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 19:37:55 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19cZMf-0007Cu-00 for tsvwg@ietf.org; Tue, 15 Jul 2003 19:37:45 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id E66F92457CB; Tue, 15 Jul 2003 19:37:14 -0400 (EDT) Date: Tue, 15 Jul 2003 18:37:08 -0500 From: Caitlin Bestler Subject: Re: [Tsvwg] SCTP Timestamps To: Stephan Baucke Cc: tsvwg@ietf.org X-Priority: 3 In-Reply-To: <3F13C98E.5030609@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 2.0 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tuesday, July 15, 2003, stephan.baucke@ericsson.com wrote: >My question is how such a "mandatory bundling" is viewed in the >community. In some ways it seems to be a break with existing >SCTP "philosophy", since so far all chunk types are "self >contained", and there is no known case of mandatory bundling. >Is it desirable to use new chunk types as a replacement for >TCP-like per-packet options? There is also the very practical >problem of fragmentation. If we want to avoid possible >refragmentation of data chunks, we would have to at least >reserve room for the timestamp chunk in each packet (this could >be negotiated at connection setup). What happens if we want to >introduce further per-packet information in the future? With RDMAP/DDP over SCTP requiring that such a chunk be included in *every* packet would guarantee that it was included in none. The effective PMTU is reported to the DDP layer, which is then responsible for segmenting DDP messages to conform with the PMTU. It is unlikely that anyone would configure their stack to accept a reduction in the data carrying PMTU for a protocol that involves bulk data transfer. But there would be frequent times when such a chunk could piggy-back "for free" in an SCTP packet that was ready to ship but not full. While not as useful as time information included in every packet, it is more likely to be provided. I would recomend allowing the sending stack to apply its own criteria as to when to slip one in, and then simply have the receiving side determine whatever it can from the data actually provided. If complete info has to be provided, fine, you haven't lost anything. If partial info can be useful, allowing the sender to include it on a "standby" basis could be a better solution. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 04:42:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21281 for ; Wed, 16 Jul 2003 04:42:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chrQ-0002us-RI for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 04:42:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G8g4R7011172 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 04: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 19chrM-0002ty-BW; Wed, 16 Jul 2003 04:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chqz-0002tV-E8 for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 04:41:37 -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 EAA21254 for ; Wed, 16 Jul 2003 04:41:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19chqu-0004iY-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 04:41:32 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19chqe-0004iU-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 04:41:16 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h6G8eqe3016101 for ; Wed, 16 Jul 2003 01:40:52 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200307160840.h6G8eqe3016101@cougar.icir.org> To: tsvwg@ietf.org From: Sally Floyd Date: Wed, 16 Jul 2003 01:40:52 -0700 Subject: [Tsvwg] viewgraphs for the tsvwg meeting 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 am giving two presentations at the tsvwg meeting, and my viewgraphs are on-line, just FYI. The talks are on: HighSpeed TCP for Large Congestion Windows http://www.icir.org/floyd/talks/hstcp-Jul03.pdf and: Moving NewReno from Experimental to Proposed Standard? http://www.icir.org/floyd/talks/newreno-Jul03.pdf - Sally http://www.icir.org/floyd/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 05:25:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22769 for ; Wed, 16 Jul 2003 05:25:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciX2-0005EB-Fl for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 05:25:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G9P4hT020089 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 05:25:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ciWz-0005DG-5o; Wed, 16 Jul 2003 05: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 19ciWW-0005Cq-3G for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 05:24:32 -0400 Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22727 for ; Wed, 16 Jul 2003 05:24:26 -0400 (EDT) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 1B8B232A5C; Wed, 16 Jul 2003 05:24:30 -0400 (EDT) Received: from louie.udel.edu (louie.udel.edu [128.4.40.12]) by mail.eecis.udel.edu (Postfix) with ESMTP id 5E44732A5B; Wed, 16 Jul 2003 05:24:29 -0400 (EDT) Date: Wed, 16 Jul 2003 05:24:29 -0400 (EDT) From: Sourabh Ladha X-X-Sender: To: Qiaobing Xie Cc: "Armando L. Caro Jr." , Stephan Baucke , Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: <3F148362.3048EE5@motorola.com> Message-ID: X-Spam-Status: No, hits=-2.8 required=6.0 tests=DEPT_RCVD,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_08_13, 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: , > Whenever I see a "MUST" used (or being suggested to be used) in the > spec, I'd like to understand what would be the error handling strategy > if this "MUST" is violated. Since you are suggesting a "MUST" clause > here, would you immediately severe the communication with a peer that > had agreed to use timestamp feature but you subsequently receive a > packet from it without the timestamp chunk bundled? If your answer is > "yes", then I'd guess that you somehow must view this missing timestamp > as an unrecoverable protocol error which can do potential harm to your > endpoint or the network if not stopping the communication right away. > But this is not obvious to me, so please explain. If your answer is > "no", then I'd question why you want to use a "MUST" here. Hi Qiaobing, My answer would be "no"..I did not mean the spec MUST while writing the email :(. However I am glad that you brought it up, since it would be interesting, and maybe relevant for timestamps, to know what you all had thought of ECNE and CWR bundling rules. (The spec does not mention these 2 chunks in detail). > > Another question: since the timestamp information (however it would be > defined for your purposes) seems to only have local significance to the > data sender. If so, this info can be kept opaque to the peer/receiver. > Since the SCTP heartbeat (it has been clarified that the HB can be sent > at different frequency or even "manually" triggered by the ULP whenever > one is needed) has the capability to carry and return an opaque data > blob, I don't see why you need to define a new timestamp chunk? I remember earlier having thought of using HB's for timestamp purposes. The problem is that while timestamp information is useful for the sender, it does requires intelligence at the reciever. I.E. The reciever will have to be aware which timestamp to echo (e.x. In case a duplicate chunk, in case of delayed SACKS, etc [please see rfc1323). And so the need for defining a timestamp chunk. -Sourabh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 06:07:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23831 for ; Wed, 16 Jul 2003 06:07:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjBi-00077m-FB for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 06:07:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GA76mU027375 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 06:07:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjBd-00075M-I6; Wed, 16 Jul 2003 06:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjBY-00074n-9d for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 06:06:56 -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 GAA23819 for ; Wed, 16 Jul 2003 06:06:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cjBU-0005Pr-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 06:06:52 -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 19cjBJ-0005Pf-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 06:06:41 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6GA6BGJ007963 for ; Wed, 16 Jul 2003 12:06:11 +0200 (MEST) 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 NW4W75Q4; Wed, 16 Jul 2003 12:06:10 +0200 Received: from ericsson.com (dhcp4-155.eed.ericsson.se [164.48.140.155]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id MAA08326 for ; Wed, 16 Jul 2003 12:06:10 +0200 (MET DST) Message-ID: <3F15233E.2070005@ericsson.com> Date: Wed, 16 Jul 2003 12:04:46 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps 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 Armando L. Caro Jr. wrote: >>My question is how such a "mandatory bundling" is viewed in the >>community. In some ways it seems to be a break with existing SCTP >>"philosophy", since so far all chunk types are "self contained", and >>there is no known case of mandatory bundling. > > First, I don't see a need to make it mandatory. The sender can choose to > bundle timestamps with all packets containing data and/or sack chunks. If > the sender chooses not to include timestamps, then the sender must follow > the conservative behavior anytime an ambiguous scenario arises. > > Second, I think the ECNE and CWR chunks are examples of chunk types that, > if used, need to be in every packet. The sender simply needs to reserve > space for these chunks. Good point, I didn't think of ECNE/CWR. Shouldn't this be in the implementer's guide? I mean, if an option is negotiated at startup time that may later take away room in packets containing data chunks, this must be taken into account when calculating the available room for data chunks (and when reporting the MULPDU to protocols such as DDP?). _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 06:14:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23960 for ; Wed, 16 Jul 2003 06:14:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjIQ-0007Wa-Ew for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 06:14:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GAE2Fd028893 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 06: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 19cjIP-0007Vt-4P; Wed, 16 Jul 2003 06:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjHy-0007VZ-NY for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 06:13:34 -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 GAA23945 for ; Wed, 16 Jul 2003 06:13:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cjHu-0005Rs-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 06:13:31 -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 19cjHj-0005Rg-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 06:13:20 -0400 Received: from esealnt612.al.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 h6GACxIi000800; Wed, 16 Jul 2003 12:12:59 +0200 (MEST) 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 NW4W76YG; Wed, 16 Jul 2003 12:12:59 +0200 Received: from ericsson.com (dhcp4-155.eed.ericsson.se [164.48.140.155]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id MAA10228; Wed, 16 Jul 2003 12:12:58 +0200 (MET DST) Message-ID: <3F1524D6.70804@ericsson.com> Date: Wed, 16 Jul 2003 12:11:34 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org CC: Janardhan Iyengar Subject: Re: [Tsvwg] SCTP Timestamps 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 Armando L. Caro Jr. wrote: >>Timestamps would enable us to do RTTM (RTT measurement on every packet), >>as described in RFC 1323. Together with an appropriate timer >>calculation, this has the potential for an RTO that more accurately >>follows the RTT. > > "Together with an appropriate timer calculation" is an important clause. Yes :-) >>Yes. That's why we would run into problems if we were to use new chunk >>types as per-packet options without reserving space for them in every >>packet, regardless whether the option is actually used in all packets or >>only a part of them. > > I am not sure I understand the problem here. I know there is some > inefficiency with reserving space for control chunks, but since timestamps > will be essentially in every packet... what's the problem? Hm, ECNE/CWR chunks will not be in every packet. Has the issue of reserving room for those been addressed? I'm also thinking about more per-packet options that might be introduced in the future; should each of them be allowed to take away some more room? _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 06:19:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24111 for ; Wed, 16 Jul 2003 06:19:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjNH-0007vc-4L for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 06:19:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GAJ31q030470 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 06:19:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjNF-0007rc-HD; Wed, 16 Jul 2003 06:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjMn-0007p0-5s for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 06:18: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 GAA24055 for ; Wed, 16 Jul 2003 06:18:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cjMj-0005Vt-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 06:18:29 -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 19cjMY-0005Vo-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 06:18:18 -0400 Received: from esealnt610.al.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 h6GAIEIi001877 for ; Wed, 16 Jul 2003 12:18:14 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 366CCXK2; Wed, 16 Jul 2003 12:18:23 +0200 Received: from ericsson.com (dhcp4-155.eed.ericsson.se [164.48.140.155]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id MAA11520 for ; Wed, 16 Jul 2003 12:18:13 +0200 (MET DST) Message-ID: <3F152610.4090608@ericsson.com> Date: Wed, 16 Jul 2003 12:16:48 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps 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: >>My question is how such a "mandatory bundling" is viewed in the >>community. In some ways it seems to be a break with existing >>SCTP "philosophy", since so far all chunk types are "self >>contained", and there is no known case of mandatory bundling. >>Is it desirable to use new chunk types as a replacement for >>TCP-like per-packet options? There is also the very practical >>problem of fragmentation. If we want to avoid possible >>refragmentation of data chunks, we would have to at least >>reserve room for the timestamp chunk in each packet (this could >>be negotiated at connection setup). What happens if we want to >>introduce further per-packet information in the future? > > With RDMAP/DDP over SCTP requiring that such a chunk be included > in *every* packet would guarantee that it was included in none. > > The effective PMTU is reported to the DDP layer, which is then > responsible for segmenting DDP messages to conform with the > PMTU. It is unlikely that anyone would configure their stack > to accept a reduction in the data carrying PMTU for a protocol > that involves bulk data transfer. Caitlin, I'm not that familiar with RDDP, but my understanding is that the LLP (in this case SCTP) reports the MULPDU to DDP. Besides a small loss in efficiency due to increased overhead, is there any problem with taking control chunks into account when calculating the MULPDU? How is this handled if TCP (where options also take away from the MULPDU) is used as the LLP? Stephan. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 07:55:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26732 for ; Wed, 16 Jul 2003 07:55:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cksD-0005u1-8V for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 07:55:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GBt5hQ022683 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 07:55:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cks9-0005th-S7; Wed, 16 Jul 2003 07:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ckrV-0005tE-IT for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 07:54: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 HAA26713 for ; Wed, 16 Jul 2003 07:54:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ckrU-0006Lc-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 07:54:20 -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 19ckrJ-0006LX-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 07:54:09 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6GBrmGJ027817 for ; Wed, 16 Jul 2003 13:53:48 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 366CDJT6; Wed, 16 Jul 2003 13:53:57 +0200 Received: from ericsson.com (dhcp4-155.eed.ericsson.se [164.48.140.155]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id NAA07307 for ; Wed, 16 Jul 2003 13:53:45 +0200 (MET DST) Message-ID: <3F153C74.3090406@ericsson.com> Date: Wed, 16 Jul 2003 13:52:20 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps References: <3F15233E.2070005@ericsson.com> In-Reply-To: <3F15233E.2070005@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >>> My question is how such a "mandatory bundling" is viewed in the >>> community. In some ways it seems to be a break with existing SCTP >>> "philosophy", since so far all chunk types are "self contained", and >>> there is no known case of mandatory bundling. >> >> >> First, I don't see a need to make it mandatory. The sender can choose to >> bundle timestamps with all packets containing data and/or sack chunks. If >> the sender chooses not to include timestamps, then the sender must follow >> the conservative behavior anytime an ambiguous scenario arises. >> >> Second, I think the ECNE and CWR chunks are examples of chunk types that, >> if used, need to be in every packet. The sender simply needs to reserve >> space for these chunks. > > Good point, I didn't think of ECNE/CWR. Shouldn't this be in the > implementer's guide? I mean, if an option is negotiated at startup time > that may later take away room in packets containing data chunks, this > must be taken into account when calculating the available room for data > chunks (and when reporting the MULPDU to protocols such as DDP?). As Sourabh just pointed out to me, the ECNE/CWR chunks in fact do *not* have to be bundled with any other chunk, since they contain a TSN that acts as a pointer to the packet where the CE bit was originally set. So this is not a precedent for "mandatory bundling" either. Another idea: Couldn't we use the same method for timestamps, i.e. the timestamp chunk would contain the TSN of a chunk in the packet that this timestamp is referring to? Stephan. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 09:53:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00278 for ; Wed, 16 Jul 2003 09:53:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmiL-00047d-Sz for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 09:53:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GDr1wn015829 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 09:53:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmiK-00046V-Es; Wed, 16 Jul 2003 09:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmhS-00040a-8N for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 09:52:06 -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 JAA00225 for ; Wed, 16 Jul 2003 09:52:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cmhQ-0007Id-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 09:52:04 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 19cmhF-0007IN-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 09:51:53 -0400 Received: from melkki.cs.Helsinki.FI (melkki.cs.helsinki.fi [::ffff:128.214.48.122]) (IDENT: root, AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 16 Jul 2003 16:51:26 +0300 Received: from melkki.cs.Helsinki.FI (localhost [127.0.0.1]) by melkki.cs.Helsinki.FI (8.12.8p1/8.12.8) with ESMTP id h6GDpQ3t015527; Wed, 16 Jul 2003 16:51:26 +0300 Received: from localhost (sarolaht@localhost) by melkki.cs.Helsinki.FI (8.12.8p1/8.12.8/Submit) with ESMTP id h6GDpPoh015523; Wed, 16 Jul 2003 16:51:25 +0300 X-Authentication-Warning: melkki.cs.Helsinki.FI: sarolaht owned process doing -bs Date: Wed, 16 Jul 2003 16:51:25 +0300 (EEST) From: Pasi Sarolahti To: Stephan Baucke cc: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: <3F13FDB4.6050903@ericsson.com> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I believe that timestamps are useful as an option for SCTP, but there might be cases where the user would not like to use them due to additional overhead (like with some telnet-kind of application protocol with small payloads). Just a quick note below inline, FWIW On Tue, 15 Jul 2003, Stephan Baucke wrote: > Timestamps would enable us to do RTTM (RTT measurement on every packet), > as described in RFC 1323. Together with an appropriate timer > calculation, this has the potential for an RTO that more accurately > follows the RTT. Timestamps are not a requirement for this. If the sender stores the transmission times of segments, it can measure RTT for every non-retransmitted segment. This is a small overhead to the sender's TCP/SCTP control data, but few bytes per segment should not be a problem for modern computers. The retransmission ambiguity exists, but unless retransmissions are very frequent, I wouldn't think it's too bad a problem. > Also, since timestamps resolve the retransmission > ambiguity, we don't have to use Karn's algorithm. Karn's algorithm > together with SCTP's retransmission policy has been shown to cause an > overly conservative RTO in certain multihomed scenarios (see > http://www.cis.udel.edu/~acaro/papers/2003.milcom.acaro.pdf) [Sorry, I can't read the paper right now, but will do it as soon as possible] Was overly conservative RTO due to Karn's algorithm or due to only one RTT sample per round-trip? Thanks, - Pasi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 11:41:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06400 for ; Wed, 16 Jul 2003 11:41:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coOv-0002ky-23 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 11:41:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GFf5vl010589 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 11:41:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coOq-0002k2-QE; Wed, 16 Jul 2003 11:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coOh-0002jn-LB for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 11:40:51 -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 LAA06385 for ; Wed, 16 Jul 2003 11:40:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19coOg-0000b5-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 11:40:50 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19coOV-0000an-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 11:40:39 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 3E9EB32915; Wed, 16 Jul 2003 11:40:09 -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 73566328A1; Wed, 16 Jul 2003 11:40:08 -0400 (EDT) Date: Wed, 16 Jul 2003 11:40:08 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Sourabh Ladha Cc: Qiaobing Xie , Stephan Baucke , Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: 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 Wed, 16 Jul 2003, Sourabh Ladha wrote: > I remember earlier having thought of using HB's for timestamp purposes. > The problem is that while timestamp information is useful for the sender, it > does requires intelligence at the reciever. I.E. The reciever will have to > be aware which timestamp to echo (e.x. In case a duplicate chunk, in case of > delayed SACKS, etc [please see rfc1323). And so the need for defining a > timestamp chunk. Two more points why HBs may not work well: 1. The sender would send HBs in almost every packet, which could make the failure detection algorithm trickier. 2. If data transmission is bi-directional, then a packet which has SACK and DATA chunks will need two HBs. On the other hand, a single Timestamp chunk is needed since it has a "timestamp" and "timestamp echo" field. ~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 Wed Jul 16 11:43:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06457 for ; Wed, 16 Jul 2003 11:43:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coQn-0002re-Qk for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 11:43:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GFh1I0010983 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 11:43:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coQn-0002r3-MX; Wed, 16 Jul 2003 11:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coQO-0002qW-5I for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 11:42:36 -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 LAA06436 for ; Wed, 16 Jul 2003 11:42:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19coQN-0000bq-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 11:42:35 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19coQC-0000bj-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 11:42:24 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 8440E32915; Wed, 16 Jul 2003 11:42:19 -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 C0E8B328A1; Wed, 16 Jul 2003 11:42:18 -0400 (EDT) Date: Wed, 16 Jul 2003 11:42:18 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Stephan Baucke Cc: Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: <3F1524D6.70804@ericsson.com> 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 Wed, 16 Jul 2003, Stephan Baucke wrote: > Hm, ECNE/CWR chunks will not be in every packet. Has the issue of > reserving room for those been addressed? I'm also thinking about more > per-packet options that might be introduced in the future; should each > of them be allowed to take away some more room? That's a tricky situation. It is really an implementation issue, but it probably makes sense to reserve room for chunks that must be bundled. Others which are self contained don't have to be bundled if they don't fit. ~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 Wed Jul 16 11:51:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06689 for ; Wed, 16 Jul 2003 11:51:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coYa-0003Ii-Ti for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 11:51:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GFp4dF012670 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 11:51:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coYX-0003HV-HU; Wed, 16 Jul 2003 11:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coYT-0003HD-C1 for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 11:50: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 LAA06645 for ; Wed, 16 Jul 2003 11:50:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19coYP-0000h4-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 11:50:53 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19coYE-0000h1-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 11:50:42 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id BC67632915; Wed, 16 Jul 2003 11:50:37 -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 E4AA83292B; Wed, 16 Jul 2003 11:50:36 -0400 (EDT) Date: Wed, 16 Jul 2003 11:50:36 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Stephan Baucke Cc: Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: <3F153C74.3090406@ericsson.com> Message-ID: X-Spam-Status: No, hits=-5.3 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,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 Wed, 16 Jul 2003, Stephan Baucke wrote: > As Sourabh just pointed out to me, the ECNE/CWR chunks in fact do *not* > have to be bundled with any other chunk, since they contain a TSN that > acts as a pointer to the packet where the CE bit was originally set. So > this is not a precedent for "mandatory bundling" either. > > Another idea: Couldn't we use the same method for timestamps, i.e. the > timestamp chunk would contain the TSN of a chunk in the packet that this > timestamp is referring to? You could, but that would make the chunk significantly larger. The TSN info would be needed for the timestamp and timestamp echo. Also, the TSN info would have to be a range of timestamps. So the resulting timestamp chunk would be something like: ------------------ | TIMESTAMP Header | ------------------ | timestamp | ------------------ | Start TSN | ------------------ | End TSN | ------------------ | timestamp echo | ------------------ | Start TSN | ------------------ | End TSN | ------------------ That's a total of 28 bytes! Or, you could break them up and have a timestamp chunk and timestamp echo chunk. But then 4 bytes are wasted in packets that bundle both, which may happen often with bi-directional data. ~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 Wed Jul 16 11:54:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06756 for ; Wed, 16 Jul 2003 11:54:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cobR-0003V7-Lq for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 11:54:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GFs1gF013441 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 11:54:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cobR-0003Ug-Db; Wed, 16 Jul 2003 11:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cobD-0003UD-GM for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 11:53: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 LAA06748 for ; Wed, 16 Jul 2003 11:53:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cobC-0000iA-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 11:53:46 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19cob1-0000i7-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 11:53:35 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 6746A32952; Wed, 16 Jul 2003 11:53:27 -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 9BC5C328A1; Wed, 16 Jul 2003 11:53:26 -0400 (EDT) Date: Wed, 16 Jul 2003 11:53:26 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Pasi Sarolahti Cc: Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: Message-ID: X-Spam-Status: No, hits=-4.2 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,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 Wed, 16 Jul 2003, Pasi Sarolahti wrote: > Was overly conservative RTO due to Karn's algorithm or due to only one RTT > sample per round-trip? Karn's algorithm (specifically in multihomed SCTP associations). ~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 Wed Jul 16 12:20:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07382 for ; Wed, 16 Jul 2003 12:20:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cp0d-0005AF-22 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 12:20:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GGK3WO019845 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 12:20:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cp0b-00059u-Ti; Wed, 16 Jul 2003 12:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cp0O-000598-Pn for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 12:19:48 -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 MAA07368 for ; Wed, 16 Jul 2003 12:19:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cp0N-0000tl-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 12:19:47 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19cp0C-0000tX-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 12:19:36 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id C7AE02459D4; Wed, 16 Jul 2003 12:19:07 -0400 (EDT) Date: Wed, 16 Jul 2003 11:18:59 -0500 From: Caitlin Bestler Subject: Re: [Tsvwg] SCTP Timestamps To: Stephan Baucke Cc: tsvwg@ietf.org X-Priority: 3 In-Reply-To: <3F152610.4090608@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 2.0 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wednesday, July 16, 2003, stephan.baucke@ericsson.com wrote: >I'm not that familiar with RDDP, but my understanding is that the LLP >(in this case SCTP) reports the MULPDU to DDP. Besides a small loss in >efficiency due to increased overhead, is there any problem with taking >control chunks into account when calculating the MULPDU? How is this >handled if TCP (where options also take away from the MULPDU) is used as >the LLP? Yes, the DDP layer can account for this overhead. But it would be to the DDP applications advantage to refuse the option rather than to reduce its effective bandwidth. DDP applications are generally concerned with bulk data transfer. I believe that SCTP is far superior to TCP for DDP. But there is already an issue that at first glance the overhead of SCTP appears larger (it isn't when you understand that it can be shared across multiple streams). But I would not want to make those statistics appear worse by adding "just one more option". I would certainly *not* enable such a chunk by default (because I wouldn't want it to be part of my benchmark statistics). At the tail end of a given exchange, however, there will always be a message that needs to be sent without delay. For DDP it is the tail segment of an Untagged Message. It would be highly probable that those packets would have room for a "standby" Data Chunk with the additional data you desired. I suspect this would be true for *many* applications, and you may find stacks willing to support opportunistic low-priority sending of Data Chunks. The only thing unique is that the Data Chunk is being filled in at placement time, not when it is placed in the queue. My suggestion is to allow that type of strategy to supply the data you want on an opportunistic basis, because there will be data transfer applications that will resist yielding any of their bandwidth when asked to do so on *every* packet. And it would be very easy for them to insist on a stack that at least pretended not to know what this option was, especially since they would have no incentive to upgrade to such an option. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 12:56:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08459 for ; Wed, 16 Jul 2003 12:56:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cpZU-0006yc-J2 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 12:56:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GGu4tq026814 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 12:56:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cpZS-0006xj-EN; Wed, 16 Jul 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 19cpZL-0006xO-CX for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 12:55: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 MAA08440 for ; Wed, 16 Jul 2003 12:55:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cpZJ-00019r-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 12:55:53 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx with esmtp (Exim 4.12) id 19cpZ8-00019g-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 12:55:43 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA24162; Wed, 16 Jul 2003 09:55:03 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id JAA26896; Wed, 16 Jul 2003 09:55:02 -0700 (PDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h6GGrZx20479; Wed, 16 Jul 2003 09:53:35 -0700 (PDT) Received: from XCH-NW-03.nw.nos.boeing.com ([192.42.226.68]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Wed, 16 Jul 2003 09:53:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] SCTP Timestamps Date: Wed, 16 Jul 2003 09:53:33 -0700 Message-ID: Thread-Topic: [Tsvwg] SCTP Timestamps Thread-Index: AcNLsQeJSaK22O8QSje/r/T7N0gxQwABV+Kw From: "Duke, Martin" To: "Armando L. Caro Jr." , "Sourabh Ladha" Cc: "Qiaobing Xie" , "Stephan Baucke" , X-OriginalArrivalTime: 16 Jul 2003 16:53:33.0960 (UTC) FILETIME=[CB142080:01C34BBA] 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 > On Wed, 16 Jul 2003, Sourabh Ladha wrote: >=20 > > I remember earlier having thought of using HB's for=20 > timestamp purposes. > > The problem is that while timestamp information is useful=20 > for the sender, it > > does requires intelligence at the reciever. I.E. The=20 > reciever will have to > > be aware which timestamp to echo (e.x. In case a duplicate=20 > chunk, in case of > > delayed SACKS, etc [please see rfc1323). And so the need=20 > for defining a > > timestamp chunk. I'm not sure the concerns in RFC 1323 apply here. There are two cases = where the most recent=20 received timestamp isn't sent. I would summarize them as follows: A) To capture the delayed ACK timer in the RTT measurement, ack the 1st = unacknowledged packet: since HEARTBEAT-ACKs have a 1:1 relationship to = HEARTBEATs, this isn't really relevant. If you like, one could delay = the HB-ACK by the maximum delayed ACK time (500 ms), or add it at the = measuring endpoint. B) If there's a "hole" in sequence numbers, assume congestion and echo = an old timestamp to be conservative: The value of this is arguable in = any case, but as HBs don't have sequence numbers anyway there's no way = for the receiver to detect a "hole." You'll still get an accurate = measurement of the RTT, rather than an inflated one produced in an = effort to be "conservative." C) DATA that is previously fully acknowledged: some argue that this is = actually a bug in the RFC, but either way, I'm not convinced that this = can cause a significant problem with HBs. A HB duplicated in the = network and long-delayed might trigger a single extremely high = measurement, but this is a pathological case, and will hardly have = catastrophic effects. Then Armando wrote: > Two more points why HBs may not work well: >=20 > 1. The sender would send HBs in almost every packet, which=20 > could make the > failure detection algorithm trickier. >=20 > 2. If data transmission is bi-directional, then a packet=20 > which has SACK > and DATA chunks will need two HBs. On the other hand, a=20 > single Timestamp > chunk is needed since it has a "timestamp" and "timestamp echo" field. >=20 > ~armando >=20 1) There will have to be a change to the treatment of HBs sent out = bundled with DATA. It's probably impractical to have a timer running = for each one, and to wait 30sec (or whatever) for the timer to expire. = However, we want to keep these features for testing paths that aren't = busy, so I would suggest that the timer is not run for HBs bundled with = data; the data being sent on that path is fully adequate for testing the = path for failure. 2) Assuming the MTU is ~1500 bytes, you're talking about a 12? Byte HB = and 12 byte HB-ACK, vs. a 10 byte TS. So it's a 0.7% vs. 1.6% overhead, = whereas using HBs requires no negotiation and stack modifications only = on the side that wishes to do the measuring. I think this outweighs a = few bytes of overhead. -Martin _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 13:37:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09667 for ; Wed, 16 Jul 2003 13:37:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqD9-0000ce-Kb for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 13:37:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GHb32T002386 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 13:37:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqD7-0000ar-Lc; Wed, 16 Jul 2003 13:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqCt-0000aF-D1 for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 13:36: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 NAA09645 for ; Wed, 16 Jul 2003 13:36:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cqCr-0001UT-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 13:36:45 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19cqCg-0001Tu-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 13:36:34 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 7348032AC8; Wed, 16 Jul 2003 13:34:42 -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 6DFDC32A9D; Wed, 16 Jul 2003 13:34:41 -0400 (EDT) Date: Wed, 16 Jul 2003 13:34:41 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: "Duke, Martin" Cc: Sourabh Ladha , Qiaobing Xie , Stephan Baucke , Subject: RE: [Tsvwg] SCTP Timestamps In-Reply-To: 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,SUPERLONG_LINE,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: , Martin, You present some valid points (I especially like argument 1), but there is still one problem. If the overloaded functionality of HBs are used without negotiation, then the receiver will not delay HB-ACKs. Since HBs would be bundled with each packet containing DATA chunks, the result will be similar to that of turning off the delayed ack algorithm for SACKs. I do like the idea of sender only changes. To avoid the above problem, the HBs can be bundled every other packet to avoid so many HB-ACKs. Like I said above, I like your argument 1. I was also thinking about something like this... bundled HBs don't need timers or state, and if lost the sender doesn't care. Since DATA is bundled with the HBs, the data would also be lost and that would help towards failure detection. At the same time, HBs can still go to idle destinations the same way. These HBs have timers and contribute towards failure detection. All this works fine for gathering more RTT measurements for alternate paths, but more complexity is needed to solve the problem that Stephan and Sourabh brought up. They want a more robust method of detecting spurious retransmits. HBs could be used, but the sender has to do more work at putting the puzzle together. Since negotiation would not used, the receiver may not bundle HB-ACKs with SACKs. Thus, it may not always be possible to correlate timestamps in HB-ACKs with newly acked TSNs in SACKs. Also, if HBs are bundled with every other packet, then not all spurious retransmits can be detected with equal accuracy. Some TSNs will not have timestamps. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 On Wed, 16 Jul 2003, Duke, Martin wrote: > > On Wed, 16 Jul 2003, Sourabh Ladha wrote: > > > > > I remember earlier having thought of using HB's for > > timestamp purposes. > > > The problem is that while timestamp information is useful > > for the sender, it > > > does requires intelligence at the reciever. I.E. The > > reciever will have to > > > be aware which timestamp to echo (e.x. In case a duplicate > > chunk, in case of > > > delayed SACKS, etc [please see rfc1323). And so the need > > for defining a > > > timestamp chunk. > > I'm not sure the concerns in RFC 1323 apply here. There are two cases where the most recent > received timestamp isn't sent. I would summarize them as follows: > > A) To capture the delayed ACK timer in the RTT measurement, ack the 1st unacknowledged packet: since HEARTBEAT-ACKs have a 1:1 relationship to HEARTBEATs, this isn't really relevant. If you like, one could delay the HB-ACK by the maximum delayed ACK time (500 ms), or add it at the measuring endpoint. > > B) If there's a "hole" in sequence numbers, assume congestion and echo an old timestamp to be conservative: The value of this is arguable in any case, but as HBs don't have sequence numbers anyway there's no way for the receiver to detect a "hole." You'll still get an accurate measurement of the RTT, rather than an inflated one produced in an effort to be "conservative." > > C) DATA that is previously fully acknowledged: some argue that this is actually a bug in the RFC, but either way, I'm not convinced that this can cause a significant problem with HBs. A HB duplicated in the network and long-delayed might trigger a single extremely high measurement, but this is a pathological case, and will hardly have catastrophic effects. > > Then Armando wrote: > > Two more points why HBs may not work well: > > > > 1. The sender would send HBs in almost every packet, which > > could make the > > failure detection algorithm trickier. > > > > 2. If data transmission is bi-directional, then a packet > > which has SACK > > and DATA chunks will need two HBs. On the other hand, a > > single Timestamp > > chunk is needed since it has a "timestamp" and "timestamp echo" field. > > > > ~armando > > > > 1) There will have to be a change to the treatment of HBs sent out > bundled with DATA. It's probably impractical to have a timer running > for each one, and to wait 30sec (or whatever) for the timer to expire. > However, we want to keep these features for testing paths that aren't > busy, so I would suggest that the timer is not run for HBs bundled > with data; the data being sent on that path is fully adequate for > testing the path for failure. > > 2) Assuming the MTU is ~1500 bytes, you're talking about a 12? Byte HB > and 12 byte HB-ACK, vs. a 10 byte TS. So it's a 0.7% vs. 1.6% > overhead, whereas using HBs requires no negotiation and stack > modifications only on the side that wishes to do the measuring. I > think this outweighs a few bytes of overhead. > > -Martin > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 14:05:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10787 for ; Wed, 16 Jul 2003 14:05:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqeG-0002a6-2z for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 14:05:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GI54he009916 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 14:05:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqeC-0002Zn-VM; Wed, 16 Jul 2003 14:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqdz-0002Wv-6m for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 14:04: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 OAA10765 for ; Wed, 16 Jul 2003 14:04:42 -0400 (EDT) From: Ivan.Arias-Rodriguez@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cqdw-0001m7-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 14:04:44 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19cqdl-0001lw-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 14:04:34 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6GI43k28718 for ; Wed, 16 Jul 2003 21:04:03 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Jul 2003 21:04:03 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 21:04:02 +0300 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 21:04:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] SCTP Timestamps Date: Wed, 16 Jul 2003 21:04:00 +0300 Message-ID: Thread-Topic: [Tsvwg] SCTP Timestamps Thread-Index: AcNLwOuFb5wWVrjaR3qXS7lwEitxvgAAKzHQ To: , Cc: , , , X-OriginalArrivalTime: 16 Jul 2003 18:04:00.0809 (UTC) FILETIME=[A27A1990:01C34BC4] 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 Hi all! I have been following this topic and I have one comment or two... > From: ext Armando L. Caro Jr. [mailto:acaro@mail.eecis.udel.edu] > Sent: Wednesday, 16 July, 2003 20:35 ... > All this works fine for gathering more RTT measurements for alternate > paths, but more complexity is needed to solve the problem=20 > that Stephan and > Sourabh brought up. They want a more robust method of=20 > detecting spurious > retransmits. HBs could be used, but the sender has to do more work at > putting the puzzle together. Since negotiation would not used, the > receiver may not bundle HB-ACKs with SACKs. Thus, it may not always be > possible to correlate timestamps in HB-ACKs with newly acked TSNs in But... The HB-ACK itself acts as the SACK, you don't need the SACK at = all... I'm not sure whether I'm missing anything... :-/ You might include in the HB information the TSN, and the time when it = was sent, as it has been already said. That uniquely identifies the = HB-ACK when it arrives as having been produced after the reception of = one specific DATA chunk... So you send your DATA+HB and wait for either the SACK or the HB-ACK. = Any of these (or better, both in the same datagram) will tell you about = the reception of the DATA chunk. I think this might be a way to solve the problem... The cost, however, = would be 16-20 bytes per DATA chunk (depending on how many bytes takes = the time information). In any case 4 more bytes (the ones of the = Heartbeat Information header) than using a special chunk... You could always include, let's say, the last 24 bits of the TSN plus 8 = bits (or less) indicating how many times you have already retransmitted = this TSN, instead of including the time value. This would also uniquely = identify the HB-ACK... Now that I think about this, a specific chunk = might use the Chunk Flags for this, so only 8 extra bytes would be = needed... Or even better, you don't need at all to include the TSN inside the HB, = just an unique identifier, as in the IP header... BR Iv=E1n Arias Rodr=EDguez > SACKs. Also, if HBs are bundled with every other packet, then not all > spurious retransmits can be detected with equal accuracy.=20 > Some TSNs will > not have timestamps. >=20 > ~armando >=20 > 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 Wed Jul 16 14:19:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11183 for ; Wed, 16 Jul 2003 14:19:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqrn-0003Ol-Lp for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 14:19:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GIJ3Xg013045 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 14:19:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqrm-0003OI-Br; Wed, 16 Jul 2003 14:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqrX-0003Nt-2X for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 14:18:51 -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 OAA11152 for ; Wed, 16 Jul 2003 14:18:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cqrP-0001tT-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 14:18:39 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19cqr0-0001tG-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 14:18:14 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 4337E32917; Wed, 16 Jul 2003 14:18:04 -0400 (EDT) Received: from louie.udel.edu (louie.udel.edu [128.4.40.12]) by mail.eecis.udel.edu (Postfix) with ESMTP id 83B5D328BC; Wed, 16 Jul 2003 14:18:03 -0400 (EDT) Date: Wed, 16 Jul 2003 14:18:03 -0400 (EDT) From: Sourabh Ladha X-X-Sender: To: Caitlin Bestler Cc: Stephan Baucke , Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: Message-ID: X-Spam-Status: No, hits=-3.4 required=6.0 tests=DEPT_RCVD,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03, USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Caitlin, > My suggestion is to allow that type of strategy to supply the data > you want on an opportunistic basis, because there will be data > transfer applications that will resist yielding any of their > bandwidth when asked to do so on *every* packet. And it would > be very easy for them to insist on a stack that at least pretended > not to know what this option was, especially since they would have > no incentive to upgrade to such an option. > While what you say regarding overheads and bulk data transfer is indeed true, much of the purpose of timestamps is lost if we can only send them on an *oppurtunistic basis* (see some of the motivations listed in the first email by Stephan). Personally, I think the best which can be done is to disable timestamps if an app/stack feels that it can achieve better throughput by doing so. -Sourabh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 14:22:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11292 for ; Wed, 16 Jul 2003 14:22:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cquf-0003r8-Mf for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 14:22:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GIM1S2014792 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 14:22:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cquf-0003qT-3m; Wed, 16 Jul 2003 14: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 19cquH-0003q9-Mq for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 14:21:38 -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 OAA11267 for ; Wed, 16 Jul 2003 14:21:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cquA-0001vP-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 14:21:30 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19cqtk-0001vF-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 14:21:04 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 11F6532956; Wed, 16 Jul 2003 14:20:53 -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 818AC32917; Wed, 16 Jul 2003 14:20:51 -0400 (EDT) Date: Wed, 16 Jul 2003 14:20:51 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Cc: , , , , Subject: RE: [Tsvwg] SCTP Timestamps In-Reply-To: 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,SUPERLONG_LINE,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="X-UNKNOWN" 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 Hei Ivan!! Yes, you are right. The HB-ACK becomes like another SACK. I like these ideas. Since the information contained in the HB is actually sender implementation specific, each implementation can embed what ever info they find most useful. It's up to that implementation to be effecient with overhead tradeoffs. I guess the only concern left is avoiding too many HB-ACKs on the wire. I'm not sure how much Eifel detection will by affected by reducing the number of bundled HBs. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 On Wed, 16 Jul 2003 Ivan.Arias-Rodriguez@nokia.com wrote: > Hi all! > > I have been following this topic and I have one comment or two... > > > From: ext Armando L. Caro Jr. [mailto:acaro@mail.eecis.udel.edu] > > Sent: Wednesday, 16 July, 2003 20:35 > > ... > > > All this works fine for gathering more RTT measurements for alternate > > paths, but more complexity is needed to solve the problem > > that Stephan and > > Sourabh brought up. They want a more robust method of > > detecting spurious > > retransmits. HBs could be used, but the sender has to do more work at > > putting the puzzle together. Since negotiation would not used, the > > receiver may not bundle HB-ACKs with SACKs. Thus, it may not always be > > possible to correlate timestamps in HB-ACKs with newly acked TSNs in > > But... The HB-ACK itself acts as the SACK, you don't need the SACK at al= l... I'm not sure whether I'm missing anything... :-/ > > You might include in the HB information the TSN, and the time when it wa= s sent, as it has been already said. That uniquely identifies the HB-ACK wh= en it arrives as having been produced after the reception of one specific D= ATA chunk... > > So you send your DATA+HB and wait for either the SACK or the HB-ACK. Any= of these (or better, both in the same datagram) will tell you about the re= ception of the DATA chunk. > > I think this might be a way to solve the problem... The cost, however, w= ould be 16-20 bytes per DATA chunk (depending on how many bytes takes the t= ime information). In any case 4 more bytes (the ones of the Heartbeat Infor= mation header) than using a special chunk... > > You could always include, let's say, the last 24 bits of the TSN plus 8 = bits (or less) indicating how many times you have already retransmitted thi= s TSN, instead of including the time value. This would also uniquely identi= fy the HB-ACK... Now that I think about this, a specific chunk might use th= e Chunk Flags for this, so only 8 extra bytes would be needed... > > Or even better, you don't need at all to include the TSN inside the HB, = just an unique identifier, as in the IP header... > > BR Iv=E1n Arias Rodr=EDguez > > > SACKs. Also, if HBs are bundled with every other packet, then not all > > spurious retransmits can be detected with equal accuracy. > > Some TSNs will > > not have timestamps. > > > > ~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 Wed Jul 16 14:46:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12198 for ; Wed, 16 Jul 2003 14:46:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crHv-0005eS-EQ for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 14:46:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GIk3nm021670 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 14:46:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crHu-0005bw-GK; Wed, 16 Jul 2003 14: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 19crHj-0005bH-7G for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 14:45:51 -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 OAA12170 for ; Wed, 16 Jul 2003 14:45:46 -0400 (EDT) From: Ivan.Arias-Rodriguez@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crHg-00027u-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 14:45:48 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19crHV-00027d-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 14:45:37 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6GIjWk27983 for ; Wed, 16 Jul 2003 21:45:32 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Jul 2003 21:45:31 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 21:45:31 +0300 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 21:45:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] SCTP Timestamps Date: Wed, 16 Jul 2003 21:45:30 +0300 Message-ID: Thread-Topic: [Tsvwg] SCTP Timestamps Thread-Index: AcNLxwBEactoWlGmQOKwb6uF5lYnsAAADGzw To: Cc: , , , , X-OriginalArrivalTime: 16 Jul 2003 18:45:31.0114 (UTC) FILETIME=[6ED07CA0:01C34BCA] 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 > -----Original Message----- > From: ext Armando L. Caro Jr. [mailto:acaro@mail.eecis.udel.edu] > Sent: Wednesday, 16 July, 2003 21:21 >=20 > Hei Ivan!! Hola Armando! See my comments below... > Yes, you are right. The HB-ACK becomes like another SACK. I like these > ideas. Since the information contained in the HB is actually sender > implementation specific, each implementation can embed what=20 > ever info they > find most useful. It's up to that implementation to be effecient with > overhead tradeoffs. Exactly, but I would say that a 12 bytes HB would make it... I don't = think you should include anything else but a 32-bit identifier of the HB = sent... At the sender you can keep all the needed information in order to make = sense out of a received HB-ACK, such as TSNs included in the datagram = and time sent... > I guess the only concern left is avoiding too many HB-ACKs on=20 > the wire. > I'm not sure how much Eifel detection will by affected by reducing the > number of bundled HBs. Well... You only need one HB per datagram, not per DATA chunk. But they = are still 12 bytes you have to be ready to reserve in every packet = sent... Or... no, maybe not... You are already reserve 16 bytes for the SACK chunk. So, if you don't = need to include the SACK, let's say that the HB travels "for free". Moreover, I'm wondering if including such "timestamp HB" only when = retransmitting something would be enough... This might make things more = difficult to the data sender, since the peer could send the SACK and = then the HB-ACK in a separate datagram, and the HB might even get lost = and then... :-/ But probably this situation won't be worse than the = current problem about losing a SACK... Also the SACK might come before the HB-ACK, so the sender should wait = for some time before being sure that the HB-ACK won't arrive --> the = SACK acknowledged the original datagram sent and not the retransmission = (unless the HB-ACK was lost, of course). In the most common case you would be able to include a HB in every = other datagram (when you don't include the SACK). If only one peer is = sending data, then everything is perfect, you always have space... Of = course, if there are TSNs lost, you might include SACKs in every = datagram and then you won't be able to include HBs... However, in this = case the SACK will be longer than 16 bytes, so you have the problem of = space anyway and maybe you don't lack 12 bytes to put your HB inside the = datagram, but have MTU-(16+12) extra bytes ... :-/ My 0.02$ BR Iv=E1n Arias Rodr=EDguez > ~armando >=20 > 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 Wed Jul 16 14:55:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12581 for ; Wed, 16 Jul 2003 14:55:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crQd-0006PA-CM for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 14:55:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GIt3kj024598 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 14:55:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crQc-0006Ny-3w; Wed, 16 Jul 2003 14:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crQW-0006NU-9d for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 14:54:56 -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 OAA12563 for ; Wed, 16 Jul 2003 14:54:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crQT-0002Ck-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 14:54:53 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19crQI-0002Cd-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 14:54:42 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id B977232967; Wed, 16 Jul 2003 14:54:37 -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 EE1CA32956; Wed, 16 Jul 2003 14:54:36 -0400 (EDT) Date: Wed, 16 Jul 2003 14:54:36 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Cc: , , , , Subject: RE: [Tsvwg] SCTP Timestamps In-Reply-To: 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 Wed, 16 Jul 2003 Ivan.Arias-Rodriguez@nokia.com wrote: > > I guess the only concern left is avoiding too many HB-ACKs on > > the wire. > > I'm not sure how much Eifel detection will by affected by reducing the > > number of bundled HBs. > > Well... You only need one HB per datagram, not per DATA chunk. > But they are still 12 bytes you have to be ready to reserve in every > packet sent... Or... no, maybe not... Althogh packet reservation is an issue, that is not what my concern was about. If a HB is included in each packet that contains DATA chunks, then the receiver will send HB-ACKs for each of these packets. Thus, the point of the delayed sack algorithm is lost. ~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 Wed Jul 16 14:59:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12751 for ; Wed, 16 Jul 2003 14:59:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crUU-0006wM-6F for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 14:59:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GIx2et026669 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 14:59:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crUT-0006vO-Eu; Wed, 16 Jul 2003 14:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crUB-0006v2-J2 for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 14:58:43 -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 OAA12740 for ; Wed, 16 Jul 2003 14:58:38 -0400 (EDT) From: Ivan.Arias-Rodriguez@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crU8-0002Ft-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 14:58:40 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19crTx-0002Fq-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 14:58:29 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6GIwNk05148 for ; Wed, 16 Jul 2003 21:58:23 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Jul 2003 21:58:23 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 21:58:23 +0300 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 21:58:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] SCTP Timestamps Date: Wed, 16 Jul 2003 21:58:22 +0300 Message-ID: Thread-Topic: [Tsvwg] SCTP Timestamps Thread-Index: AcNLyj2c/5PO1qV0QW6PZRbVxyv2AwAAFJlw To: , Cc: , , , X-OriginalArrivalTime: 16 Jul 2003 18:58:22.0944 (UTC) FILETIME=[3ADC6600:01C34BCC] 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, > -----Original Message----- > From: ext Sourabh Ladha [mailto:ladha@mail.eecis.udel.edu] > Sent: Wednesday, 16 July, 2003 21:44 >=20 > > Yes, you are right. The HB-ACK becomes like another SACK. I=20 > like these > > ideas. Since the information contained in the HB is actually sender > > implementation specific, each implementation can embed what=20 > ever info they > > find most useful. It's up to that implementation to be=20 > effecient with > > overhead tradeoffs. >=20 > I do not agree at all if this is a "clean" way to proceed if=20 > a timestamp > information per packet is required. The cost that you incur by > this is a whole new definition of SACK, HB-ACK and rules=20 > associated with > these. (For example you would still need SACKs along with=20 > HB-ACKs if an > out of order, duplicate chunk is recieved) Hmm... Why? SACK will still be a SACK, and HB-ACK will still be what it = was... The only thing is that you know you sent the HB together with some = number of TSNs. If you receive the HB-ACK it means that the peer got the = datagram, and thus he also got the DATA chunks... Of course you won't do anything you normally do when receiving the SACK = before you actually do that... As I have said in a mail I have just sent, the problem will arise when = the peer doesn't bundle the SACK and HB-ACK and the SACK arrives and the = HB-ACK does not... But at the same point, not bundling the SACK and the = HB-ACK chunks in the same datagram might even be a plus sometimes: if = the problem wasn't a lost DATA but a lost SACK, the HB-ACK might = "survive" and still reach the data sender... Probably only including the HB when retransmitting (also, in this = situation I think you don't need to include a SACK normally and thus you = can use its 16 bytes) and hoping the peer not sending the SACK and = HB-ACK in different datagrams and that only the HB-ACK is lost, would be = enough... However, if you are retransmitting, that might mean that it is = more likely that packets get lost in the way (even in the return = path)... > I still think if needed an optional timestamp chunk is the=20 > best way to go > if such an information is required. That might be optimal, but think that being compatible with current = SCTP implementations is a big plus... Maybe you even want to have both = solutions to the problem... :-/ BR Iv=E1n Arias Rodr=EDguez > -Sourabh >=20 >=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 15:02:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12851 for ; Wed, 16 Jul 2003 15:02:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crXO-00078H-8K for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 15:02:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GJ2298027405 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 15:02:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crXN-00077M-La; Wed, 16 Jul 2003 15:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crX6-000778-Jn for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 15:01:44 -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 PAA12837 for ; Wed, 16 Jul 2003 15:01:39 -0400 (EDT) From: Ivan.Arias-Rodriguez@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crX3-0002JQ-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 15:01:41 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19crWs-0002JK-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 15:01:30 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6GJ1Ok07468 for ; Wed, 16 Jul 2003 22:01:24 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Jul 2003 22:01:24 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 22:01:24 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 22:01:23 +0300 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 22:01:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] SCTP Timestamps Date: Wed, 16 Jul 2003 22:01:22 +0300 Message-ID: Thread-Topic: [Tsvwg] SCTP Timestamps Thread-Index: AcNLy7Z3rEHWQhWFQxez2lKclAE1TgAAKqIw To: Cc: , , , , X-OriginalArrivalTime: 16 Jul 2003 19:01:23.0413 (UTC) FILETIME=[A66DC850:01C34BCC] 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 > -----Original Message----- > From: ext Armando L. Caro Jr. [mailto:acaro@mail.eecis.udel.edu] > Sent: Wednesday, 16 July, 2003 21:55 >=20 > On Wed, 16 Jul 2003 Ivan.Arias-Rodriguez@nokia.com wrote: >=20 > > > I guess the only concern left is avoiding too many HB-ACKs on > > > the wire. > > > I'm not sure how much Eifel detection will by affected by=20 > reducing the > > > number of bundled HBs. > > > > Well... You only need one HB per datagram, not per DATA chunk. > > But they are still 12 bytes you have to be ready to reserve in every > > packet sent... Or... no, maybe not... >=20 > Althogh packet reservation is an issue, that is not what my=20 > concern was > about. If a HB is included in each packet that contains DATA=20 > chunks, then > the receiver will send HB-ACKs for each of these packets.=20 > Thus, the point > of the delayed sack algorithm is lost. Yep, you are right... :-( Do you think it would be enough just including the HB when = retransmitting? BR Iv=E1n Arias Rodr=EDguez > ~armando >=20 > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.cis.udel.edu/~acaro | University of Delaware | > 0-- --0 >=20 >=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 15:23:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14600 for ; Wed, 16 Jul 2003 15:23:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crrk-00006v-BV for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 15:23:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GJN4wf000346 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 15:23:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crrg-00005Q-IS; Wed, 16 Jul 2003 15:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crr3-0008W0-VR for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 15:22: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 PAA14555 for ; Wed, 16 Jul 2003 15:22:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crr2-0002Uc-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 15:22:20 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19crqs-0002UX-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 15:22:10 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 6ED2732A37; Wed, 16 Jul 2003 15:21:55 -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 8B87D3296C; Wed, 16 Jul 2003 15:21:54 -0400 (EDT) Date: Wed, 16 Jul 2003 15:21:54 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Cc: , , , , Subject: RE: [Tsvwg] SCTP Timestamps In-Reply-To: Message-ID: X-Spam-Status: No, hits=-4.2 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,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 Wed, 16 Jul 2003 Ivan.Arias-Rodriguez@nokia.com wrote: > Do you think it would be enough just including the HB when > retransmitting? Since there is no guarantee that the HB-ACK will be bundled with a SACK, it may get ambiguious for the sender. When a SACK arrives without a HB-ACK, the sender doesn't know if the SACK is (1) for the original transmission, (2) for a retransmission but the HB-ACK is on the way, or (3) for a retransmission but the HB-ACK was lost. ~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 Wed Jul 16 15:28:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14688 for ; Wed, 16 Jul 2003 15:28:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crwX-0000S7-So for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 15:28:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GJS1vW001661 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 15:28:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crwW-0000Qg-OQ; Wed, 16 Jul 2003 15: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 19crw8-0000PH-1E for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 15:27:36 -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 PAA14673 for ; Wed, 16 Jul 2003 15:27:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crw6-0002VU-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 15:27:34 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19crvv-0002VR-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 15:27:23 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id D388D32A45; Wed, 16 Jul 2003 15:27:18 -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 85CCF32A37; Wed, 16 Jul 2003 15:27:17 -0400 (EDT) Date: Wed, 16 Jul 2003 15:27:17 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Sourabh Ladha Cc: , , , , Subject: RE: [Tsvwg] SCTP Timestamps In-Reply-To: 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_02_03,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Wed, 16 Jul 2003, Sourabh Ladha wrote: > I do not agree at all if this is a "clean" way to proceed if a timestamp > information per packet is required. The cost that you incur by > this is a whole new definition of SACK, HB-ACK and rules associated with > these. (For example you would still need SACKs along with HB-ACKs if an > out of order, duplicate chunk is recieved) > > I still think if needed an optional timestamp chunk is the best way to go > if such an information is required. Like I said, using HBs is good enough for gathering more RTT measurements on alternate paths, but _may_ not be good enough for Eifel detection. I think that using HBs would be almost as good as the timestamp chunk if we could figure out how to solve the HB-ACKing every packet problem. I do agree that an optional timestamp chunk is the best way, because the timestamp is guaranteed to be bundled. However, if we can get most of the gains with just the HBs, that would be a big plus. It's always nice when only one end has to be modified to get the improvment. ~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 Wed Jul 16 15:30:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14760 for ; Wed, 16 Jul 2003 15:30:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cryU-0000Yb-B9 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 15:30:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GJU2Pv002133 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 15:30:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cryT-0000Xf-Jq; Wed, 16 Jul 2003 15:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cryQ-0000XM-JX for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 15:29: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 PAA14757 for ; Wed, 16 Jul 2003 15:29:54 -0400 (EDT) From: Ivan.Arias-Rodriguez@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cryP-0002YO-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 15:29:57 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19cryE-0002Y3-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 15:29:46 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6GJTDk25397 for ; Wed, 16 Jul 2003 22:29:13 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Jul 2003 22:29:12 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 22:29:12 +0300 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 22:29:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] SCTP Timestamps Date: Wed, 16 Jul 2003 22:29:11 +0300 Message-ID: Thread-Topic: [Tsvwg] SCTP Timestamps Thread-Index: AcNLz4Y5mWwYtnFXSpGv/AgrKzfVgQAACXBA To: Cc: , , , , X-OriginalArrivalTime: 16 Jul 2003 19:29:12.0460 (UTC) FILETIME=[894224C0:01C34BD0] 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 > -----Original Message----- > From: ext Armando L. Caro Jr. [mailto:acaro@mail.eecis.udel.edu] > Sent: Wednesday, 16 July, 2003 22:22 >=20 > On Wed, 16 Jul 2003 Ivan.Arias-Rodriguez@nokia.com wrote: >=20 > > Do you think it would be enough just including the HB when > > retransmitting? >=20 > Since there is no guarantee that the HB-ACK will be bundled=20 > with a SACK, > it may get ambiguious for the sender. When a SACK arrives without a > HB-ACK, the sender doesn't know if the SACK is (1) for the original > transmission, (2) for a retransmission but the HB-ACK is on=20 > the way, or > (3) for a retransmission but the HB-ACK was lost. Yes... The point would be that when being in (2) you should wait for a = while before you consider that you are either in (3) or (1). Since you must bundle the control chunk (i.e., HB) before the DATA = ones, (2) might not be that common because the HB-ACK should be sent = before the SACK (or maybe some implementation will not)... :-/ BR Iv=E1n Arias Rodr=EDguez > ~armando >=20 > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.cis.udel.edu/~acaro | University of Delaware | > 0-- --0 >=20 >=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 15:32:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12197 for ; Wed, 16 Jul 2003 14:46:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crHv-0005eE-D6 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 14:46:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GIk3lS021664 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 14:46:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crHt-0005bd-Fn; Wed, 16 Jul 2003 14:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crGw-0005aV-5Q for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 14:45:02 -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 OAA12140 for ; Wed, 16 Jul 2003 14:44:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crGt-00027I-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 14:44:59 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19crGi-00024w-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 14:44:48 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 9B2D732967; Wed, 16 Jul 2003 14:44:06 -0400 (EDT) Received: from louie.udel.edu (louie.udel.edu [128.4.40.12]) by mail.eecis.udel.edu (Postfix) with ESMTP id B31C332965; Wed, 16 Jul 2003 14:44:05 -0400 (EDT) Date: Wed, 16 Jul 2003 14:44:05 -0400 (EDT) From: Sourabh Ladha X-X-Sender: To: "Armando L. Caro Jr." Cc: , , , , Subject: RE: [Tsvwg] SCTP Timestamps In-Reply-To: Message-ID: X-Spam-Status: No, hits=-3.4 required=6.0 tests=DEPT_RCVD,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03, USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > Yes, you are right. The HB-ACK becomes like another SACK. I like these > ideas. Since the information contained in the HB is actually sender > implementation specific, each implementation can embed what ever info they > find most useful. It's up to that implementation to be effecient with > overhead tradeoffs. I do not agree at all if this is a "clean" way to proceed if a timestamp information per packet is required. The cost that you incur by this is a whole new definition of SACK, HB-ACK and rules associated with these. (For example you would still need SACKs along with HB-ACKs if an out of order, duplicate chunk is recieved) I still think if needed an optional timestamp chunk is the best way to go if such an information is required. -Sourabh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 16:16:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15704 for ; Wed, 16 Jul 2003 16:16:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19csh2-0002xv-0C for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 16:16:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GKG37m011380 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 16:16:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19csgz-0002wi-9H; Wed, 16 Jul 2003 16: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 19csgu-0002wP-FZ for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 16:15:56 -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 QAA15656 for ; Wed, 16 Jul 2003 16:15:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19csgs-0002nk-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 16:15:54 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19csgi-0002kS-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 16:15:44 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id C785D245A3E; Wed, 16 Jul 2003 16:13:44 -0400 (EDT) Date: Wed, 16 Jul 2003 15:13:36 -0500 From: Caitlin Bestler Subject: Re: [Tsvwg] SCTP Timestamps To: Sourabh Ladha Cc: Stephan Baucke , tsvwg@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 2.0 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wednesday, July 16, 2003, ladha@mail.eecis.udel.edu wrote: >Caitlin, > >> My suggestion is to allow that type of strategy to supply the data >> you want on an opportunistic basis, because there will be data >> transfer applications that will resist yielding any of their >> bandwidth when asked to do so on *every* packet. And it would >> be very easy for them to insist on a stack that at least pretended >> not to know what this option was, especially since they would have >> no incentive to upgrade to such an option. >> > >While what you say regarding overheads and bulk data transfer >is indeed true, much of the purpose of timestamps is lost if we >can only send them on an *oppurtunistic basis* (see some of the >motivations listed in the first email by Stephan). Personally, >I think the best which can be done is to disable timestamps if >an app/stack feels that it can achieve better throughput by >doing so. > There are some assumptions being made here that I am not following. If I am following the thread, the purpose of timestamping is to allow frequent ongoing measurement of the RTT along each path. Further, knowing the current RTT for each path, it will be possible to disambiguate certain Acks. This leads to better decisions on when to shift paths and/or do a fast retransmit. Is that correct? If so, why is timestamp data required in every packet? MPEG transport maintains a distributed clock over unreliable jittered networks even in the face of frequent packet drops. I am not following why a timestamp must *always* be present to allow measurements to be made accurately. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 16:38:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16602 for ; Wed, 16 Jul 2003 16:38:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ct2J-0004C9-Cf for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 16:38:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GKc3jJ016118 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 16:38:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ct2H-0004Br-HF; Wed, 16 Jul 2003 16:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ct1M-0003xq-PH for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 16:37: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 QAA16586 for ; Wed, 16 Jul 2003 16:37:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ct1K-00030n-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 16:37:02 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19ct1A-0002zx-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 16:36:52 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 8F90D32A37; Wed, 16 Jul 2003 16:35:29 -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 C56973297D; Wed, 16 Jul 2003 16:35:28 -0400 (EDT) Date: Wed, 16 Jul 2003 16:35:28 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Caitlin Bestler Cc: Sourabh Ladha , Stephan Baucke , Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: 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: , Caitlin, There are actually 2 motivations for timestamps. The original motivation was to be get rid of Karn's algorithm and be to use retransmissions for RTT estimation. This purpose does not need timestamps in every single packet, but the more the better. The second motivation was to use timestamps for Eifel detection. A spurious timeout retransmit can be detected if the retransmitted TSN gets acked with a timestamp earlier than the timestamp bundled with the retransmission. This purpose does require a timestamp in each packet (I think). ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 On Wed, 16 Jul 2003, Caitlin Bestler wrote: > There are some assumptions being made here that I am not following. > > If I am following the thread, the purpose of timestamping is to > allow frequent ongoing measurement of the RTT along each path. > Further, knowing the current RTT for each path, it will be > possible to disambiguate certain Acks. This leads to better > decisions on when to shift paths and/or do a fast retransmit. > > Is that correct? > > If so, why is timestamp data required in every packet? > > MPEG transport maintains a distributed clock over unreliable > jittered networks even in the face of frequent packet drops. > I am not following why a timestamp must *always* be present > to allow measurements to be made accurately. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 16:58:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17123 for ; Wed, 16 Jul 2003 16:58:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ctLe-00054h-MF for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 16:58:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GKw2aW019503 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 16:58:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ctLd-00053n-7i; Wed, 16 Jul 2003 16:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ctLF-00053N-PF for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 16:57:37 -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 QAA17108 for ; Wed, 16 Jul 2003 16:57:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ctLD-0003Cd-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 16:57:35 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19ctL3-0003CY-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 16:57:25 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 7E4583297D; Wed, 16 Jul 2003 16:57:20 -0400 (EDT) Received: from louie.udel.edu (louie.udel.edu [128.4.40.12]) by mail.eecis.udel.edu (Postfix) with ESMTP id B51E232977; Wed, 16 Jul 2003 16:57:19 -0400 (EDT) Date: Wed, 16 Jul 2003 16:57:19 -0400 (EDT) From: Sourabh Ladha X-X-Sender: To: "Armando L. Caro Jr." Cc: Caitlin Bestler , Stephan Baucke , Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: Message-ID: X-Spam-Status: No, hits=-3.4 required=6.0 tests=DEPT_RCVD,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > There are actually 2 motivations for timestamps. > > The original motivation was to be get rid of Karn's algorithm and be to > use retransmissions for RTT estimation. This purpose does not need > timestamps in every single packet, but the more the better. > > The second motivation was to use timestamps for Eifel detection. A > spurious timeout retransmit can be detected if the retransmitted TSN gets > acked with a timestamp earlier than the timestamp bundled with the > retransmission. This purpose does require a timestamp in each packet (I > think). > Another motivation for having timestamp per packet or maybe just for retransmissions (either way may require you to have room reserved for timestamp chunk in every packet) was to allow correct crediting of cwnd (i.e. in particular avoid congestion window overgrowth) by eliminating "retransmission ambuiguity". -Sourabh > > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.cis.udel.edu/~acaro | University of Delaware | > 0-- --0 > > On Wed, 16 Jul 2003, Caitlin Bestler wrote: > > > There are some assumptions being made here that I am not following. > > > > If I am following the thread, the purpose of timestamping is to > > allow frequent ongoing measurement of the RTT along each path. > > Further, knowing the current RTT for each path, it will be > > possible to disambiguate certain Acks. This leads to better > > decisions on when to shift paths and/or do a fast retransmit. > > > > Is that correct? > > > > If so, why is timestamp data required in every packet? > > > > MPEG transport maintains a distributed clock over unreliable > > jittered networks even in the face of frequent packet drops. > > I am not following why a timestamp must *always* be present > > to allow measurements to be made accurately. > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 17:14:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17942 for ; Wed, 16 Jul 2003 17:14:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ctb7-0006Lx-Iy for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 17:14:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GLE15q024419 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 17:14:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ctb6-0006Ky-Fy; Wed, 16 Jul 2003 17: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 19ctaC-0006GY-RB for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 17:13: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 RAA17893 for ; Wed, 16 Jul 2003 17:12:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ctaA-0003T0-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 17:13:02 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx with esmtp (Exim 4.12) id 19ctZz-0003Sq-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 17:12:51 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id QAA00927; Wed, 16 Jul 2003 16:12:28 -0500 (CDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id QAA29997; Wed, 16 Jul 2003 16:12:27 -0500 (CDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h6GL3Av24895; Wed, 16 Jul 2003 14:03:10 -0700 (PDT) Received: from XCH-NW-03.nw.nos.boeing.com ([192.42.226.68]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Wed, 16 Jul 2003 14:02:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] SCTP Timestamps Date: Wed, 16 Jul 2003 14:02:14 -0700 Message-ID: Thread-Topic: [Tsvwg] SCTP Timestamps Thread-Index: AcNL0QGsXIqYppcjR8Olo/DjxCl2mAACWQsg From: "Duke, Martin" To: "Armando L. Caro Jr." , "Sourabh Ladha" Cc: , X-OriginalArrivalTime: 16 Jul 2003 21:02:14.0659 (UTC) FILETIME=[88821D30:01C34BDD] 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 > From: Armando L. Caro Jr. [mailto:acaro@mail.eecis.udel.edu] >=20 > Like I said, using HBs is good enough for gathering more RTT=20 > measurements > on alternate paths, but _may_ not be good enough for Eifel=20 > detection. I > think that using HBs would be almost as good as the timestamp=20 > chunk if we > could figure out how to solve the HB-ACKing every packet problem. I do > agree that an optional timestamp chunk is the best way, because the > timestamp is guaranteed to be bundled. However, if we can get=20 > most of the > gains with just the HBs, that would be a big plus. It's=20 > always nice when > only one end has to be modified to get the improvment. >=20 > ~armando We seem to be trying to solve multiple problems with one fix, although = their needs diverge somewhat. 1) More frequent RTT measurements (more often than 1/cwnd): obviously = does not require every packet to have a HB, as Caitlin points out. 2) Allow RTT measurements on retransmissions: HB only required on = retransmissions. 3) Detect spurious timeouts by specifying if original or retransmission = was ACKed: There's no need to be perfect here. First, on multihomed = connections the ACK will normally come along the same path as the DATA, = allowing some differentiation. Second, only initial transmissions = require HB; if a HB-ACK comes back for it, you can restore the initial = cwnd. If you don't like a HB-ACK after every packet, there's a = tradeoff: more packet density or less assurance of Eifel detection? It = would be an interesting study to see the dynamics of this tradeoff in = different loss or delay environments. I think HBs are superior to a new TS option for several reasons: A) A cooperative peer will wait long enough to bundle its HB-ACKs with = SACK. An uncooperative peer will flood the network with separate = HB-ACKs. With timestamps, a cooperative peer will behave as with HBs, = but an uncooperative peer will do nothing. B) If the peer turns out to flood the network, the sender can even = adjust the frequency of HBs to compensate. C) 100% reliable detection of spurious timeouts is unnecessary. D) Changes to the stack (limited to one side) are quite minimal: = eliminate the HB timer for timestamp-related heartbeats, store the = mapping of TSNs to timestamps, possibly do some dynamic rate control, = possibly add 500ms to RTT measurements to take delayed ACKs into = account. And they're entirely borne by the measuring endpoint. The = peer has no choice but to comply if they are conforming to the = specification. That said, messing with SACK to avoid duplication with HB-ACK is a bad = idea in my opinion. It requires changes in the peer implementation and = may open up a whole range of unforeseen consequences. Martin _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 18:09:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20336 for ; Wed, 16 Jul 2003 18:09:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cuSQ-0001Me-9X for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 18:09:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GM96CS005238 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 18:09:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cuSL-0001Lg-9T; Wed, 16 Jul 2003 18:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cuRa-0001KN-2A for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 18:08:14 -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 SAA20197 for ; Wed, 16 Jul 2003 18:08:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cuRX-00042O-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 18:08:11 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19cuRM-000424-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 18:08:00 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id A53F03297A; Wed, 16 Jul 2003 18:06:44 -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 BBD383294A; Wed, 16 Jul 2003 18:06:43 -0400 (EDT) Date: Wed, 16 Jul 2003 18:06:43 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: "Duke, Martin" Cc: Sourabh Ladha , , Subject: RE: [Tsvwg] SCTP Timestamps In-Reply-To: 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 Wed, 16 Jul 2003, Duke, Martin wrote: > We seem to be trying to solve multiple problems with one fix, although > their needs diverge somewhat. > > 1) More frequent RTT measurements (more often than 1/cwnd): obviously > does not require every packet to have a HB, as Caitlin points out. This is not a problem in my opinion. More frequent RTT measurements has not been shown to be necessary or even useful. > 2) Allow RTT measurements on retransmissions: HB only required on > retransmissions. As I mentioned in a reply to Ivan... Unless HBs are bundled with SACKs, this technique doesn't work without heuristics. To make sure the peer bundles HBs with SACKs, you might as well use Timestamp chunks. > 3) Detect spurious timeouts by specifying if original or > retransmission was ACKed: There's no need to be perfect here. Nobody is talking about being perfect, but we would like to have _some_ accuracy. > First, on multihomed connections the ACK will normally come along the > same path as the DATA, allowing some differentiation. No, you don't know that. SACKs are sent to the IP address from which data was sent, which means that the receiver may use a different return path. Imagine the following: +- A1 B1 -+ Host A | | Host B +- A2 B2 -+ Data may be sent from A1 to B1, but sacks may be sent B2 to A1. That follows the specs rules, but doesn't have the same return path. > Second, only initial transmissions require HB; if a HB-ACK comes back > for it, you can restore the initial cwnd. Maybe it doesn't matter, but what if the first retransmission spuriously times out. > If you don't like a HB-ACK after every packet, there's a tradeoff: > more packet density or less assurance of Eifel detection? Well, sending HBs with every other packet brings down the detection to at most 50%. Not very good. What is good enough? 90%? So send HBs with 9 of 10 packets. I don't think I want to go down that road. > I think HBs are superior to a new TS option for several reasons: > > A) A cooperative peer will wait long enough to bundle its HB-ACKs with > SACK. An uncooperative peer will flood the network with separate > HB-ACKs. With timestamps, a cooperative peer will behave as with HBs, > but an uncooperative peer will do nothing. How can a peer be cooperative without negotiation? And if there is negotiation, then why not use timestamps? (I assume we all agree that if negotiation is used, then timestamps are the best way to go.) > B) If the peer turns out to flood the network, the sender can even > adjust the frequency of HBs to compensate. How does the sender know when the peer is flooding the network? > C) 100% reliable detection of spurious timeouts is unnecessary. Maybe not, but then what is necessary? The purpose of timestamps is to move away from heuristics for robustness. But the HB idea seems to add more heuristics. > D) Changes to the stack (limited to one side) are quite minimal: > eliminate the HB timer for timestamp-related heartbeats, store the > mapping of TSNs to timestamps, possibly do some dynamic rate control, > possibly add 500ms to RTT measurements to take delayed ACKs into > account. And they're entirely borne by the measuring endpoint. The > peer has no choice but to comply if they are conforming to the > specification. All these changes are fine, but I don't feel that it adds robustness to Eifel detection. The only way I can see to add robustness is to bundle timestamp echos with sacks... doesn't matter if they are HB-ACKs or Timestamp chunks. > That said, messing with SACK to avoid duplication with HB-ACK is a bad > idea in my opinion. It requires changes in the peer implementation > and may open up a whole range of unforeseen consequences. Hmmm... I don't follow this point. Are you arguing against your previous arguments? HB-ACK seems to be morphing into SACK with a timestamp. Is it not? ~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 Wed Jul 16 18:11:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20528 for ; Wed, 16 Jul 2003 18:11:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cuUI-0001Sr-5u for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 18:11:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GMB24m005611 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 18:11:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cuUI-0001SP-2J; Wed, 16 Jul 2003 18:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cuTw-0001Rz-VR for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 18:10:41 -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 SAA20441 for ; Wed, 16 Jul 2003 18:10:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cuTu-00043U-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 18:10:38 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19cuTj-00043B-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 18:10:27 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 39845244F97; Wed, 16 Jul 2003 18:09:58 -0400 (EDT) Date: Wed, 16 Jul 2003 17:09:50 -0500 From: Caitlin Bestler Subject: Re: [Tsvwg] SCTP Timestamps To: "Armando L. Caro Jr." Cc: Sourabh Ladha , Stephan Baucke , tsvwg@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 2.0 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wednesday, July 16, 2003, acaro@mail.eecis.udel.edu wrote: >The second motivation was to use timestamps for Eifel >detection. A spurious timeout retransmit can be detected if the >retransmitted TSN gets acked with a timestamp earlier than the >timestamp bundled with the retransmission. This purpose does >require a timestamp in each packet (I think). It is still possible to infer a possible timestamp range for when a packet was sent by interpolation from earlier and later packets, particularly if the reception time of each packet is captured for use by SCTP. This is especially true for sustained transmits of large messages that span multiple SCTP packets (which is precisely when it would be valuable to omit the timing data). If we assume that for the duration of a "sustained transmit" that the sender will be paced by the congestion and buffer windows then the timing of each packet becomes very predictable on a statistical basis. These aren't necessarily easy algorithms to work out, but they can be *implemented* cheaply. Video on Demand projects had very simple firmware algorithms to recover an MPEG Transport clock even when transmitted over a heavily jittered ATM network. The recovery algorithm could even be simple enough to be done in hardware or 8-bit processors. I am not certain that this is worthwhile, but the assumption a packet without a timestamp was a complete mystery kind of leapt out at me. MPEG Transport systems survive quite well on periodic timestamps, and they have much more precise timing requirements. Recovering an imputed clock with sufficient resolution to differentiate between two possible acks of the same TSN should be quite doable. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 19:16:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22258 for ; Wed, 16 Jul 2003 19:16:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cvVF-0004xn-U7 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 19:16:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GNG5Oi019059 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 19: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 19cvVB-0004we-OP; Wed, 16 Jul 2003 19: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 19cvUq-0004wP-QJ for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 19:15: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 TAA22249 for ; Wed, 16 Jul 2003 19:15:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cvUp-0004Xl-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 19:15:39 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19cvUe-0004Xg-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 19:15:28 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h6GNEvgq006878; Wed, 16 Jul 2003 16:14:58 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h6GNEt9d022903; Wed, 16 Jul 2003 18:14:55 -0500 Message-ID: <3F15DD55.39422F59@motorola.com> Date: Wed, 16 Jul 2003 18:18:45 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sourabh Ladha CC: "Armando L. Caro Jr." , Ivan.Arias-Rodriguez@nokia.com, martin.duke@boeing.com, stephan.baucke@ericsson.com, tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit With a new optional chunk, you still need to pay the cost for adding negotiation at init, new procedures, changes to the receiver for using this feature. This IMO would cost even more. -Qiaobing Sourabh Ladha wrote: > > > Yes, you are right. The HB-ACK becomes like another SACK. I like these > > ideas. Since the information contained in the HB is actually sender > > implementation specific, each implementation can embed what ever info they > > find most useful. It's up to that implementation to be effecient with > > overhead tradeoffs. > > I do not agree at all if this is a "clean" way to proceed if a timestamp > information per packet is required. The cost that you incur by > this is a whole new definition of SACK, HB-ACK and rules associated with > these. (For example you would still need SACKs along with HB-ACKs if an > out of order, duplicate chunk is recieved) > > I still think if needed an optional timestamp chunk is the best way to go > if such an information is required. > > -Sourabh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 19:19:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22341 for ; Wed, 16 Jul 2003 19:19:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cvY4-00053x-Vs for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 19:19:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GNJ03n019437 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 19:19:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cvY4-00053O-MM; Wed, 16 Jul 2003 19:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cvXq-00053A-IV for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 19:18:46 -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 TAA22322 for ; Wed, 16 Jul 2003 19:18:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cvXo-0004YS-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 19:18:45 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19cvXe-0004YO-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 19:18:34 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h6GNIAvG023818; Wed, 16 Jul 2003 16:18:11 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h6GNI89d025046; Wed, 16 Jul 2003 18:18:08 -0500 Message-ID: <3F15DE16.8CC97302@motorola.com> Date: Wed, 16 Jul 2003 18:21:58 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Armando L. Caro Jr." CC: Ivan.Arias-Rodriguez@nokia.com, martin.duke@boeing.com, ladha@mail.eecis.udel.edu, stephan.baucke@ericsson.com, tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Armando, Would the alternative approach (i.e., introducing a new timestamp and echo chunk) change this situation? I seem to see no difference. Maybe I missed something. -Qiaobing "Armando L. Caro Jr." wrote: > > On Wed, 16 Jul 2003 Ivan.Arias-Rodriguez@nokia.com wrote: > > > > I guess the only concern left is avoiding too many HB-ACKs on > > > the wire. > > > I'm not sure how much Eifel detection will by affected by reducing the > > > number of bundled HBs. > > > > Well... You only need one HB per datagram, not per DATA chunk. > > But they are still 12 bytes you have to be ready to reserve in every > > packet sent... Or... no, maybe not... > > Althogh packet reservation is an issue, that is not what my concern was > about. If a HB is included in each packet that contains DATA chunks, then > the receiver will send HB-ACKs for each of these packets. Thus, the point > of the delayed sack algorithm is lost. > > ~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 Wed Jul 16 22:39:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27374 for ; Wed, 16 Jul 2003 22:39:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cyFX-0005gY-Ok for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 22:12:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H2C3Bf021849 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 22: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 19cyFV-0005gI-9D; Wed, 16 Jul 2003 22:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cyEq-0005fw-8w for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 22:11: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 WAA26353 for ; Wed, 16 Jul 2003 22:11:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cyEn-0005zC-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 22:11:17 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19cyEc-0005yu-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 22:11:06 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 5F4B232B16; Wed, 16 Jul 2003 22:10:46 -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 6908A32B15; Wed, 16 Jul 2003 22:10:45 -0400 (EDT) Date: Wed, 16 Jul 2003 22:10:45 -0400 (EDT) From: Janardhan Iyengar X-X-Sender: To: Qiaobing Xie Cc: Sourabh Ladha , "Armando L. Caro Jr." , , , , Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: <3F15DD55.39422F59@motorola.com> Message-ID: X-Spam-Status: No, hits=-5.3 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,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: , Hi all, I just got through the entire thread; an attempt to consolidate broadly the solutions being discussed - there seem to be two possibilities: 1. Negotiation during association setup. Upside: Timestamps option can be negotiated. Downside: Receiver knowledge required; new chunk types required (TS, TS-ECHO). 2. No negotiation during setup. Upside: Sender-side mods only; use existing chunk types (HB, HB-ACK). Downside: Possible increased traffic on return path; heuristics required to detect spurious retransmits. As far as either of these solutions is concerned, the overhead of reserving space in datagrams for either Timestamps or HBs exists; the sender has to take into consideration space needed for either a TS or HB chunk when fragmenting user data. IMHO, the difference in bit overhead between the two options is trivial. In fact, if negotiation is done, the sender can fragment data accordingly, i.e, reserve space or not in the datagram. Given that space is available in the datagram, the sender has to figure out reliable mechanisms of using HB-ACK information to reliably infer spurious retransmits. Since the receiver's response is not known for certain, the sender may have to use heuristics to infer this information. I'm not certain why a TS option was not proposed, given that it exists for TCP (maybe because of packetization problems?). This point biases my view, because it seems to me that a TS chunk can have uses beyond the immediate Eifel algorithm on hand. (I may be wrong here; but not having a TS option seems like removing an option that has existed with TCP; I do not see a replacement in SCTP). Further, if a TS chunk is used for Eifel, the sender _may_ be certain about the response from the receiver, _possibly_ free from ambiguity. I am leaning towards specifying a TS option; I do not think that option negotiation at setup should become a bottleneck. At the same time, Ivan's comment also seems appropriate that it is a good idea to have an inference mechanism in case the receiver does not recognize the TS option. So, maybe two algorithms should be considered. In case of purely sender-side mods, I have a thought in mind: On detection of a loss through an RTO, the sender sends a HB bundled with the next three datagrams that are sent. These HBs can carry whatever information is required by the sender to disambiguate the HB-ACKs from one another, and other timing information as well. If the sender receives alternating SACKs and HB-ACKs or SACKs bundled with HBs, the sender should be able to infer that the SACKs received were for rtxs. Three HBs (or half cwnd) may be good enough in the face of loss on the return path. Of course, this is another heuristic. Caitlin's point about Video on Demand servers sounds interesting, but I have a feeling that the solution needs more accurate time measurements in the kernel. I'm in no capacity to comment on the complexity involved here. Maybe somebody more capable could comment? Comments? (I apologize for the lack of brevity) regards, jana On Wed, 16 Jul 2003, Qiaobing Xie wrote: > 7bit > MIME-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > 7bit > > With a new optional chunk, you still need to pay the cost for adding > negotiation at init, new procedures, changes to the receiver for using > this feature. This IMO would cost even more. > > -Qiaobing > > Sourabh Ladha wrote: > > > > > Yes, you are right. The HB-ACK becomes like another SACK. I like these > > > ideas. Since the information contained in the HB is actually sender > > > implementation specific, each implementation can embed what ever info they > > > find most useful. It's up to that implementation to be effecient with > > > overhead tradeoffs. > > > > I do not agree at all if this is a "clean" way to proceed if a timestamp > > information per packet is required. The cost that you incur by > > this is a whole new definition of SACK, HB-ACK and rules associated with > > these. (For example you would still need SACKs along with HB-ACKs if an > > out of order, duplicate chunk is recieved) > > > > I still think if needed an optional timestamp chunk is the best way to go > > if such an information is required. > > > > -Sourabh > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > ----------------------------------------------------------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab University of Delaware ----------------------------------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 23:23:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28859 for ; Wed, 16 Jul 2003 23:23:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19czMH-0000QS-JV for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 23:23:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H3N5ll001548 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 23:23:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19czMC-0000OD-Vi; Wed, 16 Jul 2003 23:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19czLZ-0000Nf-0C for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 23:22:26 -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 XAA28813 for ; Wed, 16 Jul 2003 23:22:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19czLX-0006oz-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 23:22:19 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19czLM-0006oV-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 23:22:08 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 192A232B19; Wed, 16 Jul 2003 23:21:49 -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 221B632AA8; Wed, 16 Jul 2003 23:21:48 -0400 (EDT) Date: Wed, 16 Jul 2003 23:21:48 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Qiaobing Xie Cc: , , , , Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: <3F15DE16.8CC97302@motorola.com> 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: , Timestamps, in of itself, doesn't make a difference. The difference is when the receiver is aware of what the sender is trying to do. If the sender is aware of the timestamps (or HBs), then the receiver can be sure to bundle the timestamp echos only with SACKs. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 On Wed, 16 Jul 2003, Qiaobing Xie wrote: > Armando, > > Would the alternative approach (i.e., introducing a new timestamp and > echo chunk) change this situation? I seem to see no difference. Maybe I > missed something. > > -Qiaobing > > "Armando L. Caro Jr." wrote: > > > > On Wed, 16 Jul 2003 Ivan.Arias-Rodriguez@nokia.com wrote: > > > > > > I guess the only concern left is avoiding too many HB-ACKs on > > > > the wire. > > > > I'm not sure how much Eifel detection will by affected by reducing the > > > > number of bundled HBs. > > > > > > Well... You only need one HB per datagram, not per DATA chunk. > > > But they are still 12 bytes you have to be ready to reserve in every > > > packet sent... Or... no, maybe not... > > > > Althogh packet reservation is an issue, that is not what my concern was > > about. If a HB is included in each packet that contains DATA chunks, then > > the receiver will send HB-ACKs for each of these packets. Thus, the point > > of the delayed sack algorithm is lost. > > > > ~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 Wed Jul 16 23:30:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29110 for ; Wed, 16 Jul 2003 23:30:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19czT0-0000m0-4L for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 23:30:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H3U2Oo002965 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 23:30:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19czSz-0000l4-Bd; Wed, 16 Jul 2003 23:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19czSx-0000kh-3p for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 23:29: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 XAA29071 for ; Wed, 16 Jul 2003 23:29:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19czSv-0006v3-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 23:29:57 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[3RCn78O33u+bMSn/0Yyk9E565YjOrJn/]) by ietf-mx with esmtp (Exim 4.12) id 19czSf-0006sq-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 23:29:41 -0400 Received: from ns.pigworks.openss7.net (IDENT:FPp64bCUmdzXyk9sjDFfxPx6APjJebff@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h6H3SlP09211; Wed, 16 Jul 2003 21:28:47 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h6H3Sk009976; Wed, 16 Jul 2003 21:28:46 -0600 Date: Wed, 16 Jul 2003 21:28:46 -0600 From: "Brian F. G. Bidulock" To: "Armando L. Caro Jr." Cc: Qiaobing Xie , Ivan.Arias-Rodriguez@nokia.com, martin.duke@boeing.com, ladha@mail.eecis.udel.edu, stephan.baucke@ericsson.com, tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps Message-ID: <20030716212846.A9770@openss7.org> Reply-To: bidulock@openss7.org References: <3F15DE16.8CC97302@motorola.com> 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: ; from acaro@mail.eecis.udel.edu on Wed, Jul 16, 2003 at 11:21:48PM -0400 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 h6H3SlP09211 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 Armando, Stange. The DATA chunk might be difficult to extend without defining a new EDATA chunk that contains a TS or rather complicated bundling rules f= or bundling a some chunk containing TS with sent data, but the SACK chunk is easy to extend. There is no reason why any number of TLVs couldn't be ta= cked onto the end of a SACK. So why aggravate fragmentation and bundling on the way back? Just tack a TS TLV on the end of the SACK. Didon't someone already define a TS TLV (parameter not chunk). Just a thought. --brian On Wed, 16 Jul 2003, Armando L. Caro Jr. wrote: > Timestamps, in of itself, doesn't make a difference. The difference is > when the receiver is aware of what the sender is trying to do. If the > sender is aware of the timestamps (or HBs), then the receiver can be su= re > to bundle the timestamp echos only with SACKs. >=20 > ~armando >=20 > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.cis.udel.edu/~acaro | University of Delaware | > 0-- --0 >=20 > On Wed, 16 Jul 2003, Qiaobing Xie wrote: >=20 > > Armando, > > > > Would the alternative approach (i.e., introducing a new timestamp and > > echo chunk) change this situation? I seem to see no difference. Maybe= I > > missed something. > > > > -Qiaobing > > > > "Armando L. Caro Jr." wrote: > > > > > > On Wed, 16 Jul 2003 Ivan.Arias-Rodriguez@nokia.com wrote: > > > > > > > > I guess the only concern left is avoiding too many HB-ACKs on > > > > > the wire. > > > > > I'm not sure how much Eifel detection will by affected by reduc= ing the > > > > > number of bundled HBs. > > > > > > > > Well... You only need one HB per datagram, not per DATA chu= nk. > > > > But they are still 12 bytes you have to be ready to reserve in ev= ery > > > > packet sent... Or... no, maybe not... > > > > > > Althogh packet reservation is an issue, that is not what my concern= was > > > about. If a HB is included in each packet that contains DATA chunks= , then > > > the receiver will send HB-ACKs for each of these packets. Thus, the= point > > > of the delayed sack algorithm is lost. > > > > > > ~armando > > > > > > 0-- --0 > > > | Armando L. Caro Jr. | Protocol Engineering Lab | > > > | www.cis.udel.edu/~acaro | University of Delaware | > > > 0-- --0 > > >=20 >=20 >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 23:39:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29524 for ; Wed, 16 Jul 2003 23:39:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19czbi-0001Rv-5g for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 23:39:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H3d2wY005568 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 23:39:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19czbh-0001R3-EF; Wed, 16 Jul 2003 23:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19czbF-0001Qk-Uo for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 23:38:34 -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 XAA29481 for ; Wed, 16 Jul 2003 23:38:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19czbD-00072t-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 23:38:32 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[souNobGZ2MihRS1gdgs4jBSDFgdq6+4H]) by ietf-mx with esmtp (Exim 4.12) id 19czay-00072H-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 23:38:16 -0400 Received: from ns.pigworks.openss7.net (IDENT:eygi3YxLW3OsWwqYv7qQTut4iaKh/RLs@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h6H3c6P09497; Wed, 16 Jul 2003 21:38:06 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h6H3c6r10187; Wed, 16 Jul 2003 21:38:06 -0600 Date: Wed, 16 Jul 2003 21:38:05 -0600 From: "Brian F. G. Bidulock" To: Sourabh Ladha Cc: "Armando L. Caro Jr." , Ivan.Arias-Rodriguez@nokia.com, martin.duke@boeing.com, Qiaobing.Xie@motorola.com, stephan.baucke@ericsson.com, tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps Message-ID: <20030716213805.A10144@openss7.org> Reply-To: bidulock@openss7.org References: 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: ; from ladha@mail.eecis.udel.edu on Wed, Jul 16, 2003 at 02:44:05PM -0400 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 h6H3c6P09497 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, I agree that HEARTBEAT/ACK is not a good way to do this. Although the opaque data in the chunk looks attractive, there are rather narrow rules for the handling of HB/ACK that have a rather different purpose. SCTP relies on the HB mechanism for recovery of unavailable destinations in the multihomed environment and is also important for detection of lost ABORTs. There are some items concerning HB that was discovered in intero= p testing that showed that rather special rules were required to accomodate implementations that could not (or did not) control source address vs. th= ose that did. I think that by overloading HB/ACK for the purpose of doing more frequent RTT measurements would break the original purpose of HB/ACK: testing the availability of desintations, keeping RTO current on idle destinations, a= nd detecting lost ABORT chunks. I too would prefer to see a different chunk, (TS chunk) bundled with all outgoing packets containing DATA and use an extension of the SACK chunk t= o=20 return pertinent timestamps. (SACK is the right place to put it on the return anyways.) --brian On Wed, 16 Jul 2003, Sourabh Ladha wrote: >=20 > > Yes, you are right. The HB-ACK becomes like another SACK. I like thes= e > > ideas. Since the information contained in the HB is actually sender > > implementation specific, each implementation can embed what ever info= they > > find most useful. It's up to that implementation to be effecient with > > overhead tradeoffs. >=20 > I do not agree at all if this is a "clean" way to proceed if a timestam= p > information per packet is required. The cost that you incur by > this is a whole new definition of SACK, HB-ACK and rules associated wit= h > these. (For example you would still need SACKs along with HB-ACKs if an > out of order, duplicate chunk is recieved) >=20 > I still think if needed an optional timestamp chunk is the best way to = go > if such an information is required. >=20 >=20 > -Sourabh >=20 >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 16 23:53:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00094 for ; Wed, 16 Jul 2003 23:53:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19czpH-0002N6-0D for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 23:53:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H3r2eH009076 for tsvwg-archive@odin.ietf.org; Wed, 16 Jul 2003 23:53:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19czpF-0002MG-DV; Wed, 16 Jul 2003 23:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19czoy-0002Lp-VY for tsvwg@optimus.ietf.org; Wed, 16 Jul 2003 23:52:45 -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 XAA00067 for ; Wed, 16 Jul 2003 23:52:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19czow-0007GL-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 23:52:42 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19czom-0007GE-00 for tsvwg@ietf.org; Wed, 16 Jul 2003 23:52:32 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 3304732B17; Wed, 16 Jul 2003 23:52:28 -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 5B21532AA8; Wed, 16 Jul 2003 23:52:27 -0400 (EDT) Date: Wed, 16 Jul 2003 23:52:27 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: "Brian F. G. Bidulock" Cc: Qiaobing Xie , , , , , Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: <20030716212846.A9770@openss7.org> 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 Wed, 16 Jul 2003, Brian F. G. Bidulock wrote: > Armando, > > Stange. The DATA chunk might be difficult to extend without defining a > new EDATA chunk that contains a TS or rather complicated bundling rules for > bundling a some chunk containing TS with sent data, but the SACK chunk is > easy to extend. There is no reason why any number of TLVs couldn't be tacked > onto the end of a SACK. > > So why aggravate fragmentation and bundling on the way back? Just tack a > TS TLV on the end of the SACK. Didon't someone already define a TS TLV > (parameter not chunk). Is that legal? Also, how does it alleviate frag/bundling issues? ~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 Thu Jul 17 00:25:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01095 for ; Thu, 17 Jul 2003 00:25:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d0KJ-0003xn-8p for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 00:25:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H4P7fa015229 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 00:25:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d0KD-0003ws-WF; Thu, 17 Jul 2003 00:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d0Jf-0003wT-7B for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 00:24: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 AAA01086 for ; Thu, 17 Jul 2003 00:24:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d0Jc-0007gz-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 00:24:24 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[zrSlOqN7G0APT/GswsYOrbjmr7i2T5pT]) by ietf-mx with esmtp (Exim 4.12) id 19d0JM-0007gq-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 00:24:09 -0400 Received: from ns.pigworks.openss7.net (IDENT:6dZv4xB/dCXeafNNaLOOAGGqUiGiSNX1@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h6H4NwP10117; Wed, 16 Jul 2003 22:23:58 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h6H4NwZ10814; Wed, 16 Jul 2003 22:23:58 -0600 Date: Wed, 16 Jul 2003 22:23:58 -0600 From: "Brian F. G. Bidulock" To: "Armando L. Caro Jr." Cc: Qiaobing Xie , Ivan.Arias-Rodriguez@nokia.com, martin.duke@boeing.com, ladha@mail.eecis.udel.edu, stephan.baucke@ericsson.com, tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps Message-ID: <20030716222358.A10742@openss7.org> Reply-To: bidulock@openss7.org References: <20030716212846.A9770@openss7.org> 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: ; from acaro@mail.eecis.udel.edu on Wed, Jul 16, 2003 at 11:52:27PM -0400 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 h6H4NwP10117 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 Armando, On Wed, 16 Jul 2003, Armando L. Caro Jr. wrote: > On Wed, 16 Jul 2003, Brian F. G. Bidulock wrote: >=20 > > Armando, > > > > Stange. The DATA chunk might be difficult to extend without defining= a > > new EDATA chunk that contains a TS or rather complicated bundling rul= es for > > bundling a some chunk containing TS with sent data, but the SACK chun= k is > > easy to extend. There is no reason why any number of TLVs couldn't b= e tacked > > onto the end of a SACK. > > > > So why aggravate fragmentation and bundling on the way back? Just ta= ck a > > TS TLV on the end of the SACK. Didon't someone already define a TS T= LV > > (parameter not chunk). >=20 > Is that legal? Also, how does it alleviate frag/bundling issues? No, no, I didn't mean that it was legal now. I meant that it is quite ea= sy to extend the SACK chunk because it has an internal length (number of gaps, number of dups) that indicate the length of the content of the existing c= hunk. Anything after the last dup TSN could be pretty much ignored. Certainly an extension document would be required (one would anyway) and = a negotiation procedure for backwards compatibility. The frag bundling it solves is what to do, for example, when a TS is bund= led with the wrong SACK. Also, nowhere in 2960 does it say that two SACKs ca= n't be bundled in the same packet, although it is probably not done. Having = the value in the SACK inexhorably binds it to the SACK to which it correspond= s, extinguishing all issues as to where what is in what message with respect= to the SACK. It was just a thought. --brian >=20 > ~armando >=20 > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.cis.udel.edu/~acaro | University of Delaware | > 0-- --0 --=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 Jul 17 06:55:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29337 for ; Thu, 17 Jul 2003 06:55:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6Ph-0007jd-59 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 06:55:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HAt5kQ029713 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 06:55:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6Pe-0007il-8R; Thu, 17 Jul 2003 06:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6Ow-0007fP-4M for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 06:54:18 -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 GAA29311 for ; Thu, 17 Jul 2003 06:54:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d6Or-0004eY-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 06:54:14 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 19d6Od-0004e6-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 06:53:59 -0400 Received: from melkki.cs.Helsinki.FI (melkki.cs.helsinki.fi [::ffff:128.214.48.122]) (IDENT: root, AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 17 Jul 2003 13:52:28 +0300 Received: from melkki.cs.Helsinki.FI (localhost [127.0.0.1]) by melkki.cs.Helsinki.FI (8.12.8p1/8.12.8) with ESMTP id h6HAqS3t005525; Thu, 17 Jul 2003 13:52:28 +0300 Received: from localhost (sarolaht@localhost) by melkki.cs.Helsinki.FI (8.12.8p1/8.12.8/Submit) with ESMTP id h6HAqSjT005521; Thu, 17 Jul 2003 13:52:28 +0300 X-Authentication-Warning: melkki.cs.Helsinki.FI: sarolaht owned process doing -bs Date: Thu, 17 Jul 2003 13:52:28 +0300 (EEST) From: Pasi Sarolahti To: "Armando L. Caro Jr." cc: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, On Wed, 16 Jul 2003, Armando L. Caro Jr. wrote: > The second motivation was to use timestamps for Eifel detection. A > spurious timeout retransmit can be detected if the retransmitted TSN gets > acked with a timestamp earlier than the timestamp bundled with the > retransmission. This purpose does require a timestamp in each packet (I > think). Aside from this timestamp discussion, but since spurious RTOs were mentioned: We have proposed a scheme for detecting spurious RTOs without timestamps in draft-sarolahti-tsvwg-tcp-frto-04.txt. I solicited for comments on it in early June, but unfortunately got no answer. It would be nice to hear whether the SCTP community would find that useful. The idea in short is that after an RTO the sender would try to send some new data and check if there are acks of non-retransmitted segments arriving after that, in which case the RTO is considered to be spurious. This should work with SCTP as well as with TCP as far as I can see. I believe Markku Kojo will have a short presentation about the draft in the tsvwg meeting. Thanks, - Pasi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 17 08:29:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03475 for ; Thu, 17 Jul 2003 08:29:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d7se-0005vE-UM for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 08:29:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HCT4sY022759 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 08:29:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d7sa-0005tx-P7; Thu, 17 Jul 2003 08:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d7sP-0005tL-Ps for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 08:28: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 IAA03437 for ; Thu, 17 Jul 2003 08:28:46 -0400 (EDT) From: ladha@mail.eecis.udel.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d7sO-0005ku-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 08:28:48 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19d7sD-0005kb-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 08:28:37 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 5541A32913; Thu, 17 Jul 2003 08:27:56 -0400 (EDT) Received: from webmail.eecis.udel.edu (dbacks.acad.ece.udel.edu [128.4.60.14]) by mail.eecis.udel.edu (Postfix) with SMTP id 77E3232986; Thu, 17 Jul 2003 08:27:55 -0400 (EDT) Received: from 212.117.81.29 (SquirrelMail authenticated user ladha) by webmail.eecis.udel.edu with HTTP; Thu, 17 Jul 2003 08:27:55 -0400 (EDT) Message-ID: <20863.212.117.81.29.1058444875.squirrel@webmail.eecis.udel.edu> In-Reply-To: References: Date: Thu, 17 Jul 2003 08:27:55 -0400 (EDT) Subject: Re: [Tsvwg] SCTP Timestamps To: "Pasi Sarolahti" Cc: "Armando L. Caro Jr." , tsvwg@ietf.org User-Agent: SquirrelMail/1.4.0 X-Priority: 3 Importance: Normal X-Spam-Status: No, hits=-1.8 required=6.0 tests=DEPT_RCVD,IN_REP_TO,NO_REAL_NAME,PRIORITY_NO_NAME, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02,USER_AGENT 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="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: , Pasi, I had read the FRTO document some time back. On the SCTP front I was wondering if the following are applicable: * Multihoming: If the delay spike on the primary path is greater than (1 RTO(primary) + 2 RTT(alternate)), I would believe that FRTO will not be able to detect a timeout spurious. (complying with the current spec that retransmissions SHOULD go to alternate destination) * Chunk Bundling: FRTO assumes that on a timeout the sender will retransmit only one segment("I think chunk will be appropriate in SCTP terminology"). This may not be true in SCTP. If the association is multihomed and the PMTU's on the primary and alternate path differ by a factor of two or more then, then I think the sender may be able to retransmit more than one unacknowledged chunk on a timeout (bundled in a single packet). This can also be true if the app is writing small chunks such that on a timeout more than one of such chunks can be bundled in a single packet and retransmitted. I remember having noticed a couple of side effects of this which could lead FRTO to declare the timeout spurious while it was not. Comments? (Others shoot in if I missed something) A question I have is: Section 3- step 3(b): When you refer to an ACK which acknowledges data (above spurious threshhold or previously unacknowledged), do you refer to acknowledging {via cum-ack point} or {via SACK blocks} or {either of these two}? -Sourabh > -----Original Message----- > From: Pasi Sarolahti [mailto:sarolaht@cs.Helsinki.FI] > Sent: Thursday, July 17, 2003 12:52 PM > To: Armando L. Caro Jr. > Cc: tsvwg@ietf.org > Subject: Re: [Tsvwg] SCTP Timestamps > > > Hi, > > On Wed, 16 Jul 2003, Armando L. Caro Jr. wrote: > > > The second motivation was to use timestamps for Eifel detection. A > > spurious timeout retransmit can be detected if the > retransmitted TSN gets > > acked with a timestamp earlier than the timestamp bundled with the > > retransmission. This purpose does require a timestamp in > each packet (I > > think). > > Aside from this timestamp discussion, but since spurious RTOs were > mentioned: We have proposed a scheme for detecting spurious > RTOs without > timestamps in draft-sarolahti-tsvwg-tcp-frto-04.txt. I solicited for > comments on it in early June, but unfortunately got no > answer. It would be > nice to hear whether the SCTP community would find that useful. > > The idea in short is that after an RTO the sender would try > to send some > new data and check if there are acks of non-retransmitted segments > arriving after that, in which case the RTO is considered to > be spurious. > This should work with SCTP as well as with TCP as far as I can see. I > believe Markku Kojo will have a short presentation about the > draft in the > tsvwg meeting. > > Thanks, > - Pasi > > > > _______________________________________________ > 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 Jul 17 08:33:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03683 for ; Thu, 17 Jul 2003 08:33:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d7wU-0006Ak-J0 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 08:33:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HCX2nN023719 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 08:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d7wT-00069o-Q8; Thu, 17 Jul 2003 08:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d7wO-00069U-PF for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 08:32:56 -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 IAA03638 for ; Thu, 17 Jul 2003 08:32:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d7wN-0005oH-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 08:32: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 19d7wC-0005o4-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 08:32:44 -0400 Received: from esealnt611.al.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 h6HCWcIi000545 for ; Thu, 17 Jul 2003 14:32:38 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 3S6JRWG5; Thu, 17 Jul 2003 14:35:33 +0200 Received: from ericsson.com (dhcp4-155.eed.ericsson.se [164.48.140.155]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id OAA23335 for ; Thu, 17 Jul 2003 14:32:37 +0200 (MET DST) Message-ID: <3F16970B.6080901@ericsson.com> Date: Thu, 17 Jul 2003 14:31:07 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps 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 Armando L. Caro Jr. wrote: >>Another idea: Couldn't we use the same method for timestamps, i.e. the >>timestamp chunk would contain the TSN of a chunk in the packet that this >>timestamp is referring to? > > You could, but that would make the chunk significantly larger. The TSN > info would be needed for the timestamp and timestamp echo. Also, the TSN > info would have to be a range of timestamps. So the resulting timestamp > chunk would be something like: You could probably get away with just one TSN, analog to the ECNW/CWR chunks. But I admit that this solution isn't ideal anyway for Eifel or the disambiguating of retransmissions; e.g. it gets difficult if the timestamp chunk is sent separately and gets lost or reordered in relation to the corresponding data packet. Stephan. > ------------------ > | TIMESTAMP Header | > ------------------ > | timestamp | > ------------------ > | Start TSN | > ------------------ > | End TSN | > ------------------ > | timestamp echo | > ------------------ > | Start TSN | > ------------------ > | End TSN | > ------------------ > > That's a total of 28 bytes! Or, you could break them up and have a > timestamp chunk and timestamp echo chunk. But then 4 bytes are wasted in > packets that bundle both, which may happen often with bi-directional data. > > ~armando _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 17 08:43:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04078 for ; Thu, 17 Jul 2003 08:43:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d86B-0006xc-Qt for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 08:43:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HCh3a3026750 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 08:43:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d868-0006rm-Qc; Thu, 17 Jul 2003 08:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d867-0006rb-Ke for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 08:42: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 IAA04068 for ; Thu, 17 Jul 2003 08:42:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d866-0005vV-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 08:42:58 -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 19d85v-0005vS-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 08:42:47 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6HCgfGJ026546 for ; Thu, 17 Jul 2003 14:42:41 +0200 (MEST) 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 NW4X1MBA; Thu, 17 Jul 2003 14:42:41 +0200 Received: from ericsson.com (dhcp4-155.eed.ericsson.se [164.48.140.155]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id OAA25371 for ; Thu, 17 Jul 2003 14:42:40 +0200 (MET DST) Message-ID: <3F169966.4020301@ericsson.com> Date: Thu, 17 Jul 2003 14:41:10 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps 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: >>I'm not that familiar with RDDP, but my understanding is that the LLP >>(in this case SCTP) reports the MULPDU to DDP. Besides a small loss in >>efficiency due to increased overhead, is there any problem with taking >>control chunks into account when calculating the MULPDU? How is this >>handled if TCP (where options also take away from the MULPDU) is used as >>the LLP? > > Yes, the DDP layer can account for this overhead. But it would be to > the DDP applications advantage to refuse the option rather than to > reduce its effective bandwidth. DDP applications are generally > concerned with bulk data transfer. I believe that SCTP is far superior > to TCP for DDP. But there is already an issue that at first glance > the overhead of SCTP appears larger (it isn't when you understand that > it can be shared across multiple streams). But I would not want to make > those statistics appear worse by adding "just one more option". > I would certainly *not* enable such a chunk by default (because I > wouldn't want it to be part of my benchmark statistics). I see your point. I think the best solution would be to simply let applications deactivate timestamps if desired. However, while the overhead may be significant for high performance bulk transfer, there are many other applications (e.g. in the signaling area) where it doesn't matter all that much. > My suggestion is to allow that type of strategy to supply the data > you want on an opportunistic basis, because there will be data > transfer applications that will resist yielding any of their > bandwidth when asked to do so on *every* packet. And it would > be very easy for them to insist on a stack that at least pretended > not to know what this option was, especially since they would have > no incentive to upgrade to such an option. Only sending the timestamp on an opportunistic basis would degrade the effectiveness of Eifel or algorithms to disambiguate the "path ambiguity". However, it may be good enough for those purposes to send timestamps with every packet that contains retransmitted chunks. Stephan. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 17 09:01:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04859 for ; Thu, 17 Jul 2003 09:01:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8Nb-00083t-TE for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 09:01:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HD136O030957 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 09:01:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8NY-00082U-TT; Thu, 17 Jul 2003 09:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8NE-0007yB-AP for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 09:00:41 -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 JAA04792 for ; Thu, 17 Jul 2003 09:00:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d8NC-0006Bk-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 09:00:38 -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 19d8N2-0006BT-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 09:00:28 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6HD06GJ000456 for ; Thu, 17 Jul 2003 15:00:06 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 3S6JR7T4; Thu, 17 Jul 2003 15:03:01 +0200 Received: from ericsson.com (dhcp4-155.eed.ericsson.se [164.48.140.155]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id PAA29702 for ; Thu, 17 Jul 2003 15:00:05 +0200 (MET DST) Message-ID: <3F169D7C.1030905@ericsson.com> Date: Thu, 17 Jul 2003 14:58:36 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps 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: >>The second motivation was to use timestamps for Eifel >>detection. A spurious timeout retransmit can be detected if the >>retransmitted TSN gets acked with a timestamp earlier than the >>timestamp bundled with the retransmission. This purpose does >>require a timestamp in each packet (I think). > > It is still possible to infer a possible timestamp range for > when a packet was sent by interpolation from earlier and later > packets, particularly if the reception time of each packet is > captured for use by SCTP. The algorithms for the disambiguation of retransmissions are meant to counter problems caused by anomalies such as sudden delay spikes, packet reordering or, in the case of SCTP, retransmissions alternating between paths with different RTTs and separate path estimators. I believe it is next to impossible to "guess" the timestamps with a good hitrate under those conditions. Stephan. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 17 09:11:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05382 for ; Thu, 17 Jul 2003 09:11:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8XG-0000dg-Ar for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 09:11:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HDB2Gg002428 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 09:11:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8XF-0000aX-7w; Thu, 17 Jul 2003 09:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8WU-0000Zf-HN for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 09:10:14 -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 JAA05318 for ; Thu, 17 Jul 2003 09:10:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d8WS-0006Il-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 09:10:13 -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 19d8WH-0006IC-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 09:10:02 -0400 Received: from esealnt612.al.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 h6HD9EIi007440 for ; Thu, 17 Jul 2003 15:09:14 +0200 (MEST) 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 NW4X1R1W; Thu, 17 Jul 2003 15:09:14 +0200 Received: from ericsson.com (dhcp4-155.eed.ericsson.se [164.48.140.155]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id PAA02003 for ; Thu, 17 Jul 2003 15:09:13 +0200 (MET DST) Message-ID: <3F169F9F.50605@ericsson.com> Date: Thu, 17 Jul 2003 15:07:43 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps 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: > There are some assumptions being made here that I am not following. > > If I am following the thread, the purpose of timestamping is to > allow frequent ongoing measurement of the RTT along each path. > Further, knowing the current RTT for each path, it will be > possible to disambiguate certain Acks. This leads to better > decisions on when to shift paths and/or do a fast retransmit. > > Is that correct? Caitlin, getting better knowledge of the RTT is only one of the aspects. Eifel basically works by marking packets and ACKs in a way that allows the sender to distiguish whether an ACK refers to the original transmission or a retransmission. For things like disambiguating the path the chunk being acknowledged was sent over, it needs to be able to identify which (re)transmission it was. > If so, why is timestamp data required in every packet? > > MPEG transport maintains a distributed clock over unreliable > jittered networks even in the face of frequent packet drops. > I am not following why a timestamp must *always* be present > to allow measurements to be made accurately. It's not really about maintaining a common clock. There are other possible ways to achieve the goals mentioned above (e.g. marking packets with dedicated flags), but the timestamps have worked out nicely for TCP, and seem attractive to me because they can be used to solve several problems. Stephan. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 17 10:19:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08717 for ; Thu, 17 Jul 2003 10:19:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d9b4-0003mx-KW for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 10:19:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HEJ2wq014508 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 10:19:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d9b3-0003jc-5v; Thu, 17 Jul 2003 10:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d9aY-0003ft-HQ for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 10:18: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 KAA08680 for ; Thu, 17 Jul 2003 10:18:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d9aW-0006jS-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 10:18:28 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19d9aL-0006jK-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 10:18:17 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 56447245C28; Thu, 17 Jul 2003 10:17:45 -0400 (EDT) Date: Thu, 17 Jul 2003 09:17:36 -0500 From: Caitlin Bestler Subject: Re: [Tsvwg] SCTP Timestamps To: Stephan Baucke Cc: tsvwg@ietf.org X-Priority: 3 In-Reply-To: <3F169966.4020301@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 2.0 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thursday, July 17, 2003, stephan.baucke@ericsson.com wrote: >Only sending the timestamp on an opportunistic basis would degrade the >effectiveness of Eifel or algorithms to disambiguate the "path >ambiguity". However, it may be good enough for those purposes to send >timestamps with every packet that contains retransmitted chunks. The chunk size was already determined on the first transmit. There won't be any more room on the retransmit. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 17 10:24:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08922 for ; Thu, 17 Jul 2003 10:24:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d9ft-00049L-UV for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 10:24:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HEO1Kq015913 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 10:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d9ft-00047u-0l; Thu, 17 Jul 2003 10: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 19d9fS-00047d-J4 for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 10:23:34 -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 KAA08901 for ; Thu, 17 Jul 2003 10:23:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d9fQ-0006lK-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 10:23:32 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19d9fF-0006l6-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 10:23:21 -0400 Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 2B23A245234; Thu, 17 Jul 2003 10:22:52 -0400 (EDT) Date: Thu, 17 Jul 2003 09:22:43 -0500 From: Caitlin Bestler Subject: Re: [Tsvwg] SCTP Timestamps To: Stephan Baucke Cc: tsvwg@ietf.org X-Priority: 3 In-Reply-To: <3F169D7C.1030905@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 2.0 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thursday, July 17, 2003, stephan.baucke@ericsson.com wrote: >The algorithms for the disambiguation of retransmissions >are meant to counter problems caused by anomalies such as >sudden delay spikes, packet reordering or, in the case of >SCTP, retransmissions alternating between paths with >different RTTs and separate path estimators. I believe it >is next to impossible to "guess" the timestamps with a >good hitrate under those conditions. You don't need to predict them. But you could easily detect that they are out of the predictable range for a retransmit-free stable path. That is, you could once a history on the path was established. For sporadic traffic this type of approach would indeed be ineffective, but it is when you are transferring on a sustained basis that you will be most concerned about not inserting timestamps. Adding a small timestamp to sporadic traffic will seldom be objectionable. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 17 12:03:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12509 for ; Thu, 17 Jul 2003 12:03:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dBDm-0002HS-Kg for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 12:03:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HG36A6008746 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 12:03:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dBDh-0002FG-NF; Thu, 17 Jul 2003 12: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 19dBD7-0002BO-H2 for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 12:02: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 MAA12469 for ; Thu, 17 Jul 2003 12:02:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dBD4-0007QG-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 12:02:22 -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 19dBCt-0007Q7-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 12:02:11 -0400 Received: from esealnt613.al.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 h6HG22Ii010286 for ; Thu, 17 Jul 2003 18:02:02 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XK7PNF; Thu, 17 Jul 2003 18:02:01 +0200 Received: from res0010384da36.ericsson.com (rac170pc.edd.ericsson.se [164.48.123.170]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id SAA12675 for ; Thu, 17 Jul 2003 18:01:59 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030717163118.027f4290@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 17 Jul 2003 16:43:26 +0200 To: tsvwg@ietf.org From: Reiner Ludwig Subject: Re: [Tsvwg] Issues with draft-blanton-dsack-use-02 In-Reply-To: <20030711162512.A63696B2C3@lawyers.ir.bbn.com> References: <5.2.0.9.0.20030711101645.02f7cde8@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 18:25 11.07.2003, Mark Allman wrote: > > 2. Segment N is lost, the ACK for the retransmit of N is lost, and > > the second retransmit of N goes fine (the segment and the ACK > > for it) arrives. > > > > 3. Segment N is lost, and the retransmit of N is duplicated in the > > network. > >[...] > >So, the question really is... can we accept these sorts of cases or >not? If we cannot accept these cases then DSACK (and duplicate TSN >notification in SCTP) is pretty much useless for reverting >congestion control state. Opinions? > >My own hit is that things like 2 & 3 are pathalogical and should not >be deal breakers for DSACK-based schemes for this purpose. Since there hasn't been much traffic on this, here is my hit ... I think that issue 3 is well taken care off in the current I-D. But, I think that issue 2 needs to be addressed. With issue 2 we again have the retransmission ambiguity problem: the sender can't tell whether the DSACK corresponds to the 1st or the 2nd retransmit, and hence shouldn't make any conclusions. So, in general dsack-use should be disabled once the second retransmit of the oldest outstanding segment has been sent. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 17 12:16:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12702 for ; Thu, 17 Jul 2003 12:16:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dBQL-00037n-U3 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 12:16:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HGG51p011989 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 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 19dBQI-00036N-68; Thu, 17 Jul 2003 12:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dBPJ-00032h-Eo for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 12:15:01 -0400 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12683 for ; Thu, 17 Jul 2003 12:14:56 -0400 (EDT) Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h6GM0MWB016696; Wed, 16 Jul 2003 15:00:22 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h6GM0J9d007913; Wed, 16 Jul 2003 17:00:19 -0500 Message-ID: <3F15CBD9.5A3E484A@motorola.com> Date: Wed, 16 Jul 2003 17:04:09 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Armando L. Caro Jr." CC: Stephan Baucke , tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It really IS an implementation issue and has already been addressed since the very first implementation (and I'd guess each of the existing impls does the same... just in its own different way). For example, in the open source user-land ref impl as I remember it, there are two queues; one for pending control chunks and the other for pending user messages. Whenever an outgoing packet is being formed, the bundling and fragmentation code will always first include all the pending control chunks and then figure out how much room is still left for user data. In the calculation, it always count in the data chunk header, SCTP header, and IP header... It is tricky code... one of the focal points the early debugging excitement :-) -Qiaobing "Armando L. Caro Jr." wrote: > > On Wed, 16 Jul 2003, Stephan Baucke wrote: > > > Hm, ECNE/CWR chunks will not be in every packet. Has the issue of > > reserving room for those been addressed? I'm also thinking about more > > per-packet options that might be introduced in the future; should each > > of them be allowed to take away some more room? > > That's a tricky situation. It is really an implementation issue, but it > probably makes sense to reserve room for chunks that must be bundled. > Others which are self contained don't have to be bundled if they don't > fit. > > ~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 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 17 12:36:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13253 for ; Thu, 17 Jul 2003 12:36:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dBje-0003rx-UU for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 12:36:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HGa2GY014863 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 12:36:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dBjd-0003qu-FE; Thu, 17 Jul 2003 12: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 19dBio-0003nc-6a for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 12:35:10 -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 MAA13204 for ; Thu, 17 Jul 2003 12:35:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dBim-0007ah-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 12:35:08 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19dBic-0007aW-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 12:34:58 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 4C04232993; Thu, 17 Jul 2003 12:34:36 -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 7DEF13298B; Thu, 17 Jul 2003 12:34:35 -0400 (EDT) Date: Thu, 17 Jul 2003 12:34:35 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Reiner Ludwig Cc: Subject: Re: [Tsvwg] Issues with draft-blanton-dsack-use-02 In-Reply-To: <5.2.0.9.0.20030717163118.027f4290@mailhost.eed.ericsson.se> 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, 17 Jul 2003, Reiner Ludwig wrote: > Since there hasn't been much traffic on this, here is my hit ... > > I think that issue 3 is well taken care off in the current I-D. > > But, I think that issue 2 needs to be addressed. With issue 2 we again have > the retransmission ambiguity problem: the sender can't tell whether the > DSACK corresponds to the 1st or the 2nd retransmit, and hence shouldn't > make any conclusions. > > So, in general dsack-use should be disabled once the second retransmit of > the oldest outstanding segment has been sent. That makes sense. I suppose this problem started the idea of using timestamps instead? ~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 Thu Jul 17 14:44:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17319 for ; Thu, 17 Jul 2003 14:44:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDjh-0001z0-Bp for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 14:44:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HIiDHL007592 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 14:44:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDjV-0001xf-D9; Thu, 17 Jul 2003 14:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDik-0001wX-09 for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 14:43:14 -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 OAA17276 for ; Thu, 17 Jul 2003 14:43:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dDih-0000bm-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 14:43:11 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19dDiW-0000bA-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 14:43:00 -0400 Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 4.14) id 19dDgo-000LCa-8c; Thu, 17 Jul 2003 18:41:14 +0000 To: tsvwg@ietf.org Subject: [Tsvwg] updated agenda for 57th IETF TSVWG meeting Cc: mankin@psg.com, jon.peterson@neustar.biz Reply-To: mankin@psg.com Date: Thu, 17 Jul 2003 11:41:13 -0700 From: Allison Mankin Message-Id: 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: , Transport Area WG (tsvwg) Friday, July 18 at 0900-1130 ============================= CHAIRS: Allison Mankin Jon Peterson 0900 Charter Discussion (chairs) 0910 General Area Review (chairs) 0925 Fast TCP (Steven Low/Cheng Jin) draft-jin-wei-low-tcp-fast-00.txt 0955 Highspeed TCP (Sally Floyd) draft-floyd-tcp-highspeed-03.txt 1015 NewReno to PS (Sally Floyd) draft-ietf-tsvwg-newreno-00.txt 1030 Eifel Response (Reiner Ludwig) draft-ietf-tsvwg-tcp-eifel-response-03.txt 1045 MH-PHB (Naotaka Morita) draft-morita-tsvwg-pps-00.txt 1100 Update on PR-SCTP (TBD) draft-ietf-tsvwg-prsctp-00.txt 1115 Update on F-RTO (Markku Kojo) draft-sarolahti-tsvwg-tcp-frto-04.txt _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 17 14:53:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17595 for ; Thu, 17 Jul 2003 14:53:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDsD-0002Xm-Kr for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 14:53:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HIr1JO009774 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 14:53:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDsD-0002Wt-2q; Thu, 17 Jul 2003 14:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDsB-0002Wi-PQ for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 14:53: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 OAA17576 for ; Thu, 17 Jul 2003 14:52:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dDs8-0000gI-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 14:52:56 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19dDrs-0000gE-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 14:52:40 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h6HIqWWB021199; Thu, 17 Jul 2003 11:52:33 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h6HIqU9d025071; Thu, 17 Jul 2003 13:52:30 -0500 Message-ID: <3F16F159.34FC8B4C@motorola.com> Date: Thu, 17 Jul 2003 13:56:25 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Armando L. Caro Jr." CC: "Duke, Martin" , Sourabh Ladha , Ivan.Arias-Rodriguez@nokia.com, tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I haven't gone thru the all the mails in this thread. My apology if my comments below overlap with others. "Armando L. Caro Jr." wrote: ... > > A) A cooperative peer will wait long enough to bundle its HB-ACKs with > > SACK. An uncooperative peer will flood the network with separate > > HB-ACKs. With timestamps, a cooperative peer will behave as with HBs, > > but an uncooperative peer will do nothing. > > How can a peer be cooperative without negotiation? And if there is > negotiation, then why not use timestamps? (I assume we all agree that if > negotiation is used, then timestamps are the best way to go.) In the current SCTP, normally an endpoint will not receive a HB with an outbound SACK pending. So, we could simply add the following rule to get the behavior you want without negotiation: When an endpoint receives a HB while having received data pending for ack, the endpoint should delay sending its HB-ACK till the SACK is sent and the HB-ACK should be bundled with SACK. Would this solve the problem? > > C) 100% reliable detection of spurious timeouts is unnecessary. > > Maybe not, but then what is necessary? The purpose of timestamps is to > move away from heuristics for robustness. But the HB idea seems to add > more heuristics. I've heard that 50% detection is not good enough and 100% is unnecessary (and in practice unachievable), and 90% may be about right... This sounds all too speculative to me. Are there any real world data from the field or simulation that shows what's the performance gain vs. various percentage of detection? Or these are just theoretical speculations? Also, there seem to be other efforts to address spurious timeouts (e.g., D-SACK and two other methods mentioned in this thread). Is there a comparison study on them? Or, are we going to build them all into TCP and SCTP? :-) regards, -Qiaobing _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 17 15:10:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18671 for ; Thu, 17 Jul 2003 15:10:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dE8h-0003dR-PK for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 15:10:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HJA3Cj013966 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 15:10:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dE8g-0003cT-2O; Thu, 17 Jul 2003 15:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dE7n-0003TJ-Ie for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 15:09: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 PAA18531 for ; Thu, 17 Jul 2003 15:09:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dE7k-0000lT-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 15:09:04 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19dE7Z-0000lQ-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 15:08:53 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h6HJ8YWB001135; Thu, 17 Jul 2003 12:08:34 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h6HJ8V9d004305; Thu, 17 Jul 2003 14:08:32 -0500 Message-ID: <3F16F51B.416E909C@motorola.com> Date: Thu, 17 Jul 2003 14:12:27 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: bidulock@openss7.org CC: Sourabh Ladha , "Armando L. Caro Jr." , Ivan.Arias-Rodriguez@nokia.com, martin.duke@boeing.com, stephan.baucke@ericsson.com, tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps References: <20030716213805.A10144@openss7.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate.mot.com id h6HJ8YWB001135 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 Brian, You made a good point and you convinced me that a separate TS chunk is cleaner if this feature is really worthwhile to add. -Qiaobing "Brian F. G. Bidulock" wrote: >=20 > Sourabh, >=20 > I agree that HEARTBEAT/ACK is not a good way to do this. Although the > opaque data in the chunk looks attractive, there are rather narrow rule= s > for the handling of HB/ACK that have a rather different purpose. SCTP > relies on the HB mechanism for recovery of unavailable destinations in > the multihomed environment and is also important for detection of lost > ABORTs. There are some items concerning HB that was discovered in inte= rop > testing that showed that rather special rules were required to accomoda= te > implementations that could not (or did not) control source address vs. = those > that did. >=20 > I think that by overloading HB/ACK for the purpose of doing more freque= nt > RTT measurements would break the original purpose of HB/ACK: testing th= e > availability of desintations, keeping RTO current on idle destinations,= and > detecting lost ABORT chunks. >=20 > I too would prefer to see a different chunk, (TS chunk) bundled with al= l > outgoing packets containing DATA and use an extension of the SACK chunk= to > return pertinent timestamps. (SACK is the right place to put it on the > return anyways.) >=20 > --brian >=20 > On Wed, 16 Jul 2003, Sourabh Ladha wrote: >=20 > > > > > Yes, you are right. The HB-ACK becomes like another SACK. I like th= ese > > > ideas. Since the information contained in the HB is actually sender > > > implementation specific, each implementation can embed what ever in= fo they > > > find most useful. It's up to that implementation to be effecient wi= th > > > overhead tradeoffs. > > > > I do not agree at all if this is a "clean" way to proceed if a timest= amp > > information per packet is required. The cost that you incur by > > this is a whole new definition of SACK, HB-ACK and rules associated w= ith > > these. (For example you would still need SACKs along with HB-ACKs if = an > > out of order, duplicate chunk is recieved) > > > > I still think if needed an optional timestamp chunk is the best way t= o go > > if such an information is required. > > > > > > -Sourabh > > > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg >=20 > -- > Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 > bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 > http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 > =A6 Therefore all progress depends on the =A6 > =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 17 16:07:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20719 for ; Thu, 17 Jul 2003 16:07:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dF1v-0005r7-4a for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 16:07:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HK77CD022503 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 16:07:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dF1p-0005oV-5J; Thu, 17 Jul 2003 16:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dF1Z-0005jy-Gn for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 16:06:46 -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 QAA20706 for ; Thu, 17 Jul 2003 16:06:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dF1X-00013j-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 16:06:43 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[5/QmaEN6IEowxiU3cnWmX2z0RisMG63K]) by ietf-mx with esmtp (Exim 4.12) id 19dF1H-00013P-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 16:06:28 -0400 Received: from ns.pigworks.openss7.net (IDENT:zkI+XAPCjXXfI6CITDQhDMGUIvhA3d6x@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h6HK5uP26533; Thu, 17 Jul 2003 14:05:56 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h6HK5un25456; Thu, 17 Jul 2003 14:05:56 -0600 Date: Thu, 17 Jul 2003 14:05:55 -0600 From: "Brian F. G. Bidulock" To: Qiaobing Xie Cc: "Armando L. Caro Jr." , "Duke, Martin" , Sourabh Ladha , Ivan.Arias-Rodriguez@nokia.com, tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps Message-ID: <20030717140555.A25067@openss7.org> Reply-To: bidulock@openss7.org References: <3F16F159.34FC8B4C@motorola.com> 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: <3F16F159.34FC8B4C@motorola.com>; from Qiaobing.Xie@motorola.com on Thu, Jul 17, 2003 at 01:56:25PM -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 h6HK5uP26533 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 Qiaobing, On Thu, 17 Jul 2003, Qiaobing Xie wrote: > I haven't gone thru the all the mails in this thread. My apology if my > comments below overlap with others. >=20 > "Armando L. Caro Jr." wrote: > ... > > > A) A cooperative peer will wait long enough to bundle its HB-ACKs w= ith > > > SACK. An uncooperative peer will flood the network with separate > > > HB-ACKs. With timestamps, a cooperative peer will behave as with H= Bs, > > > but an uncooperative peer will do nothing. > >=20 > > How can a peer be cooperative without negotiation? And if there is > > negotiation, then why not use timestamps? (I assume we all agree that= if > > negotiation is used, then timestamps are the best way to go.) >=20 > In the current SCTP, normally an endpoint will not receive a HB with an > outbound SACK pending. So, we could simply add the following rule to ge= t > the behavior you want without negotiation: >=20 > When an endpoint receives a HB while having received data pending=20 > for ack, the endpoint should delay sending its HB-ACK till the=20 > SACK is sent and the HB-ACK should be bundled with SACK. >=20 > Would this solve the problem? Would the above not result in delaying ALL HEARTBEAT-ACK chunks? When you delay that HEARTBEAT-ACK chunk, cannot an RTO can occur because the HEARTBEAT-ACK is lost? Currently the HEARTBEAT-ACK is sent to the source address in the HEARTBEAT, and the RFC says to send any bundled DATA to that address too. Will this not result in sending DATA to the wrong address (not the primary) most of the time? Will not HEARTBEAT-ACK= s sent testing idle or failed destinations also have to wait when data acknowledgement is pending for heartbeat acknowledgement? There is no way for the receive to know the difference between a normal HEARTBEAT and a timestamp HEARTBEAT, is there? The difference lies in the opaque data. Please consider using a new chunk to avoid breaking the current heartbeat mechanism. --brian >=20 > > > C) 100% reliable detection of spurious timeouts is unnecessary. > >=20 > > Maybe not, but then what is necessary? The purpose of timestamps is t= o > > move away from heuristics for robustness. But the HB idea seems to ad= d > > more heuristics. >=20 > I've heard that 50% detection is not good enough and 100% is unnecessar= y > (and in practice unachievable), and 90% may be about right... This > sounds all too speculative to me. Are there any real world data from th= e > field or simulation that shows what's the performance gain vs. various > percentage of detection? Or these are just theoretical speculations?=20 >=20 > Also, there seem to be other efforts to address spurious timeouts (e.g.= , > D-SACK and two other methods mentioned in this thread). Is there a > comparison study on them? Or, are we going to build them all into TCP > and SCTP? :-) >=20 > regards, > -Qiaobing >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 17 20:34:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28502 for ; Thu, 17 Jul 2003 20:34:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dJCH-0007ab-Bz for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 20:34:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I0Y5CT029161 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 20:34:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dJCD-0007Za-2V; Thu, 17 Jul 2003 20:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dJBL-0007ZK-QB for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 20:33: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 UAA28476 for ; Thu, 17 Jul 2003 20:33:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dJBJ-0002r5-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 20:33:05 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 19dJB8-0002qs-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 20:32:55 -0400 Received: from cs.helsinki.fi ([::ffff:81.160.15.84]) (AUTH: PLAIN gurtov, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.cs.helsinki.fi with esmtp; Fri, 18 Jul 2003 03:32:34 +0300 Message-ID: <3F174046.6020405@cs.helsinki.fi> Date: Thu, 17 Jul 2003 17:33:10 -0700 From: Andrei Gurtov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org, Reiner Ludwig Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Slides for Eifel Response in Vienna IETF 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 Slides for the presentation on Eifel Response in the TSVWG meeting in Vienna IETF are available at: http://www.cs.helsinki.fi/u/gurtov/reiner/eifel_alg_ietf57.pdf http://www.cs.helsinki.fi/u/gurtov/reiner/eifel_alg_ietf57.ppt Also of possible interest is: A. Gurtov, R. Ludwig, Responding to Spurious Timeouts in TCP, IEEE INFOCOM'03, March 2003. http://www.cs.helsinki.fi/u/gurtov/papers/resp.html Reiner&Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 17 22:51:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01240 for ; Thu, 17 Jul 2003 22:51:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dLKt-0003Sw-8l for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 22:51:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I2p79k013284 for tsvwg-archive@odin.ietf.org; Thu, 17 Jul 2003 22:51:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dLKn-0003RV-SR; Thu, 17 Jul 2003 22:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dLJr-0003Pf-DH for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 22:50:03 -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 WAA01214 for ; Thu, 17 Jul 2003 22:49:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dLJn-0003lj-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 22:50:00 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 19dLJd-0003lf-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 22:49:49 -0400 Received: from phys-ha1mpka.eng.sun.com ([129.146.14.50]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6I2nTQY005078 for ; Thu, 17 Jul 2003 20:49:29 -0600 (MDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by phys-ha1mpka.eng.sun.com (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id TAA14161 for ; Thu, 17 Jul 2003 19:49:28 -0700 (PDT) Message-ID: <3F176037.8090100@sun.com> Date: Thu, 17 Jul 2003 19:49:27 -0700 From: Kacheong Poon User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2.1) Gecko/20030313 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps References: <3F16F159.34FC8B4C@motorola.com> In-Reply-To: <3F16F159.34FC8B4C@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Qiaobing Xie wrote: > I've heard that 50% detection is not good enough and 100% is unnecessary > (and in practice unachievable), and 90% may be about right... This > sounds all too speculative to me. Are there any real world data from the > field or simulation that shows what's the performance gain vs. various > percentage of detection? Or these are just theoretical speculations? > > Also, there seem to be other efforts to address spurious timeouts (e.g., > D-SACK and two other methods mentioned in this thread). Is there a > comparison study on them? Or, are we going to build them all into TCP > and SCTP? :-) I also want to know why can't (since nobody in this thread even mentioned it) the duplicate TSN be used to detect spurious retransmission. It is already specified in the standard and does not require any new chunk be defined. The draw back is not 100% reliable and it is "slower" to detect the problem. Is there a fundamental issue with it such that people in this discussion want a new chunk to be defined? --- K. Poon. kacheong.poon@sun.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 18 00:05:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03120 for ; Fri, 18 Jul 2003 00:05:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dMUX-0005nl-Rz for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 00:05:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I459Xn022287 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 00:05:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dMUP-0005mh-K7; Fri, 18 Jul 2003 00:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dMTU-0005lh-VN for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 00:04:05 -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 AAA03084 for ; Fri, 18 Jul 2003 00:04:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dMTS-0004Jj-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 00:04:02 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19dMTH-0004JZ-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 00:03:52 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id A4700329BB; Fri, 18 Jul 2003 00:03:32 -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 DD8FB329BA; Fri, 18 Jul 2003 00:03:31 -0400 (EDT) Date: Fri, 18 Jul 2003 00:03:31 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Kacheong Poon Cc: Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: <3F176037.8090100@sun.com> 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, 17 Jul 2003, Kacheong Poon wrote: > I also want to know why can't (since nobody in this thread even > mentioned it) the duplicate TSN be used to detect spurious > retransmission. It is already specified in the standard and does > not require any new chunk be defined. The draw back is not 100% > reliable and it is "slower" to detect the problem. Is there a > fundamental issue with it such that people in this discussion want > a new chunk to be defined? From what I understand, timestamps can provide a more robust method of detection. ~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 Fri Jul 18 03:54:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21400 for ; Fri, 18 Jul 2003 03:54:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQ45-00088b-Hd for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 03:54:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I7s5PU031282 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 03:54:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQ41-00087S-NU; Fri, 18 Jul 2003 03:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQ32-00086Q-Rj for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 03:53: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 DAA21375 for ; Fri, 18 Jul 2003 03:52:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dQ30-00069C-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 03:52:58 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[CvppwxAs4lZHUasQwdZ4uty7xMTATu2I]) by ietf-mx with esmtp (Exim 4.12) id 19dQ2k-000697-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 03:52:42 -0400 Received: from ns.pigworks.openss7.net (IDENT:5AzJbqOGVCkqGwP2OvIe/dOnqr0rKPEv@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h6I7qXP05586; Fri, 18 Jul 2003 01:52:33 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h6I7qWU03895; Fri, 18 Jul 2003 01:52:32 -0600 Date: Fri, 18 Jul 2003 01:52:32 -0600 From: "Brian F. G. Bidulock" To: "Armando L. Caro Jr." Cc: Kacheong Poon , tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps Message-ID: <20030718015232.C3547@openss7.org> Reply-To: bidulock@openss7.org References: <3F176037.8090100@sun.com> 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: ; from acaro@mail.eecis.udel.edu on Fri, Jul 18, 2003 at 12:03:31AM -0400 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 h6I7qXP05586 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 Armando, What is not robust about the receiver indicating that it received something multiple times? The receiver is in the best position to determine when a spurious retransmission has occured at the sender (because it receives multiple copies). I think that is more robust than timestamps that may or may not be included, might get lost, misbundled, associated with the wrong ack, etc. With duplicates, the receiver says "I already received this TSN". I agree with Kacheong here, but I disagree that it is slower. In the RFC receiving duplicates is reason for immediate SACK (whereas timestamps would not). Therefore, the dup TSNs are, I believe, faster, in that the duplicate TSN report is immediate under most situations. (See 6.2 RFC 2960). Furthermore, the duplicate TSN mechanism is already exists, and is already used to determine that a spurious restransmission has occurred, possibly due to a lost SACK return path (the most obvious cause of persistent spurious retransmissions). Can someone back up the statement of timestamps being "more robust"? The statement doesn't seem to withstand any scrutiny... --brian On Fri, 18 Jul 2003, Armando L. Caro Jr. wrote: > On Thu, 17 Jul 2003, Kacheong Poon wrote: >=20 > > I also want to know why can't (since nobody in this thread even > > mentioned it) the duplicate TSN be used to detect spurious > > retransmission. It is already specified in the standard and does > > not require any new chunk be defined. The draw back is not 100% > > reliable and it is "slower" to detect the problem. Is there a > > fundamental issue with it such that people in this discussion want > > a new chunk to be defined? >=20 > >From what I understand, timestamps can provide a more robust method of > detection. >=20 > ~armando >=20 > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.cis.udel.edu/~acaro | University of Delaware | > 0-- --0 >=20 >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 18 04:29:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22742 for ; Fri, 18 Jul 2003 04:29:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQbw-0001hC-0V for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 04:29:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I8T37o006517 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 04:29:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQbu-0001gt-2W; Fri, 18 Jul 2003 04:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQbE-0001gG-Tu for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 04:28: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 EAA22730 for ; Fri, 18 Jul 2003 04:28:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dQb9-0006RW-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 04:28:15 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 19dQay-0006RT-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 04:28:04 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h6I8Rxw27297 for ; Fri, 18 Jul 2003 10:27:59 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h6I8Rwl01505 for ; Fri, 18 Jul 2003 10:27:58 +0200 (MEST) Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id KAA21917 for ; Fri, 18 Jul 2003 10:27:57 +0200 (MET DST) Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id <3945KZ6W>; Fri, 18 Jul 2003 10:27:22 +0200 Message-ID: From: Schruefer Wolfgang To: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps Date: Fri, 18 Jul 2003 10:26:18 +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: , Dear all, I will suggest an alternative solution, how to enable a sender to determine whether an ACK refers to the original transmission or a retransmission of a chunk. My thought is to sacrifice one of the unused bits in the Chunk Flags field of the DATA and SACK chunks to solve the problem. The clue is that the value of this bit from the DATA chunk should be echoed by the receiver in the SACK chunk. A feature negotiation at association setup is not necessary, because the sender recognises early if the feature is supported by the peer or not. A scenario may run like this (let me just call this new bit Mirror Bit or M-bit): - A sender sets the M-bit at any value when a DATA chunk is transmitted for the first time and stores the value together with the timestamp. - In the SACK the receiver mirrors the M-bit for the DATA chunk with TSN == Cumulative TSN Ack. - When the sender recognises that the M-bit is not echoed correctly (for not retransmitted DATA), it knows that the peer does not support this feature. - When the sender needs to retransmit the DATA for the first time it toggles the M-bit and stores the retransmission time. - For up to one retransmission the sender can 100% resolve the chunk where a SACK refers to. - When there is a need for further retransmissions I see three alternatives: ** The M-bit is toggled again and the sender assumes that the DATA chunk sent two RTO earlier was lost. ** The M-bit remains identical in all retransmissions (but e.g. a SACK for this DATA chunk may not be used any more for RTT calculation). ** We use two Chunk Flag Bits to mark the last four transmissions. Is this a way worth while to think about? Wolfgang Dear all, following the Timestamp discussion I asked myself whether there is a need to transmit any timestamp and if there are no cheaper solution. What we need in my understanding is a solution for the problem Stephan described at the beginning of the thread: Resolving the retransmission ambiguity, i.e. enabling the sender to determine whether an ACK refers to the original transmission or a retransmission of a chunk. This implies resolving a "path ambiguity" and allowing better and more frequent RTT measurements. My thought is to sacrifice one (or two) bit(s) of the unused DATA and SACK Chunk Flags Bits to solve this problem. The clue is that this bit should be echoed by the receiver in the SACK Chunk Flags. Let me just call this bit Mirror Bit or M-bit. A scenario may run like this: - A sender sets the M-bit at any value when a DATA chunk is transmitted for the first time and stores the value together with the timestamp. - The receiver mirrors the bit for the DATA chunk with TSN == Cumulative TSN Ack. - When the sender recognises that the M-bit is not echoed correctly (for not retransmitted DATA), it knows that the peer does not support this feature. I think a feature negotiation at association setup is therefore not necessary. - When the sender needs to retransmit the DATA for the first time it toggles the M-bit and stores the retransmission time. - Up to now the sender can always resolve the chunk where a SACK refers to. - When there is a need for further retransmissions I see three alternatives: ** The M-bit is toggled again and the sender assumes that the DATA chunk sent two RTO before was lost. ** The M-bit remains identical in all retransmissions (but e.g. a SACK for this DATA chunk may not be used any more for RTT calculation). ** We use two Chunk Flag Bits to mark the last four transmissions. Is this a way worth to think further? Wolfgang Viele Gruesse Wolfgang Schruefer Siemens ICN CP D NP A8 TEL: +49 89 722-61646 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 18 04:51:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23546 for ; Fri, 18 Jul 2003 04:51:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQxE-0002pP-1N for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 04:51:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I8p453010833 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 04:51:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQxC-0002oS-1J; Fri, 18 Jul 2003 04:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQwG-0002mH-9r for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 04:50: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 EAA23510 for ; Fri, 18 Jul 2003 04:50:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dQwD-0006ci-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 04:50:01 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19dQvx-0006bL-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 04:49:45 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h6I8lEe3047823 for ; Fri, 18 Jul 2003 01:47:14 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200307180847.h6I8lEe3047823@cougar.icir.org> To: tsvwg@ietf.org From: Sally Floyd Date: Fri, 18 Jul 2003 01:47:14 -0700 Subject: [Tsvwg] the outstanding issues to track for taking NewReno to 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: , From the tsvwg meeting at the IETF, now in progress, here are the issues to track (in the next week) for WG Last Call, for the NewReno TCP: * Add a note to the section on "Implementation issues for the data sender" saying that the sender might want a separate flag to record whether it is in the Fast Recovery procedure, for robustness with window updates and out-of-order acks. * Add an implementation note about taking care of sequence wrap. * Address the issue raised by Andrei Gurtov about whether packets are sent in response to dup acks in those cases when Fast Recovery is not invoked (because of bugfix). - Sally _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 18 04:57:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23668 for ; Fri, 18 Jul 2003 04:57:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dR30-00035U-Vk for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 04:57:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I8v2X1011864 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 04:57:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dR2z-000353-I4; Fri, 18 Jul 2003 04: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 19dR28-00033d-JZ for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 04:56: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 EAA23641 for ; Fri, 18 Jul 2003 04:56:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dR25-0006fG-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 04:56:05 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[XdPalieP7eKRKX8mtAD++nBlRtvsl/6r]) by ietf-mx with esmtp (Exim 4.12) id 19dR1p-0006fA-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 04:55:49 -0400 Received: from ns.pigworks.openss7.net (IDENT:mc3Xn39g70uZlO/2ROBGMOhUjp8sKzQD@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h6I8tPP06697; Fri, 18 Jul 2003 02:55:25 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h6I8tOr05058; Fri, 18 Jul 2003 02:55:24 -0600 Date: Fri, 18 Jul 2003 02:55:24 -0600 From: "Brian F. G. Bidulock" To: Schruefer Wolfgang Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps Message-ID: <20030718025524.B4954@openss7.org> Reply-To: bidulock@openss7.org References: 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: ; from wolfgang.schruefer@siemens.com on Fri, Jul 18, 2003 at 10:26:18AM +0200 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 h6I8tPP06697 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 Wolfgang, What about the packet that contains: RTx (2) DATA RTx (2) DATA RTx (1) DATA New DATA New DATA from two separate retransmissions. What about when the spurious retransmissions are before the Cummulative Ack point (due to loss of SACKs)? Won't these M-bit indications be lost? Doesn't sound better than existing dup TSN reports in SACKs. --brian On Fri, 18 Jul 2003, Schruefer Wolfgang wrote: > Dear all, >=20 > I will suggest an alternative solution, how to enable a sender to deter= mine > whether an ACK refers to the original transmission or a retransmission = of a > chunk. >=20 > My thought is to sacrifice one of the unused bits in the Chunk Flags fi= eld > of the DATA and SACK chunks to solve the problem. The clue is that the = value > of this bit from the DATA chunk should be echoed by the receiver in the= SACK > chunk. A feature negotiation at association setup is not necessary, bec= ause > the sender recognises early if the feature is supported by the peer or = not. >=20 >=20 > A scenario may run like this (let me just call this new bit Mirror Bit = or > M-bit):=20 >=20 > - A sender sets the M-bit at any value when a DATA chunk is transmitted= for > the first time and stores the value together with the timestamp. >=20 > - In the SACK the receiver mirrors the M-bit for the DATA chunk with TS= N =3D=3D > Cumulative TSN Ack. >=20 > - When the sender recognises that the M-bit is not echoed correctly (fo= r not > retransmitted DATA), it knows that the peer does not support this featu= re.=20 >=20 > - When the sender needs to retransmit the DATA for the first time it to= ggles > the M-bit and stores the retransmission time. >=20 > - For up to one retransmission the sender can 100% resolve the chunk wh= ere a > SACK refers to. >=20 > - When there is a need for further retransmissions I see three alternat= ives: > ** The M-bit is toggled again and the sender assumes that the DATA chun= k > sent two RTO earlier was lost. ** The M-bit remains identical in all > retransmissions (but e.g. a SACK for this DATA chunk may not be used an= y > more for RTT calculation). ** We use two Chunk Flag Bits to mark the l= ast > four transmissions. >=20 >=20 > Is this a way worth while to think about? >=20 > Wolfgang >=20 --=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 Fri Jul 18 05:02:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23777 for ; Fri, 18 Jul 2003 05:02:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dR7q-0003LE-LY for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 05:02:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I922vB012815 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 05:02:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dR7p-0003JO-9r; Fri, 18 Jul 2003 05:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dR7C-0003Ik-Oh for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 05:01: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 FAA23753 for ; Fri, 18 Jul 2003 05:01:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dR79-0006he-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 05:01:19 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19dR6z-0006hT-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 05:01:09 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 3DCF732A3B; Fri, 18 Jul 2003 05:00:50 -0400 (EDT) Received: from louie.udel.edu (louie.udel.edu [128.4.40.12]) by mail.eecis.udel.edu (Postfix) with ESMTP id 7816132A1A; Fri, 18 Jul 2003 05:00:49 -0400 (EDT) Date: Fri, 18 Jul 2003 05:00:49 -0400 (EDT) From: Sourabh Ladha X-X-Sender: To: Kacheong Poon Cc: Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: <3F176037.8090100@sun.com> Message-ID: X-Spam-Status: No, hits=-3.4 required=6.0 tests=DEPT_RCVD,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > > I also want to know why can't (since nobody in this thread even > mentioned it) the duplicate TSN be used to detect spurious > retransmission. It is already specified in the standard and does > not require any new chunk be defined. The draw back is not 100% > reliable and it is "slower" to detect the problem. Is there a > fundamental issue with it such that people in this discussion want > a new chunk to be defined? > From some of the emails I have seen in this thread, it seems folks have the wrong impression that timestamps are being proposed for "Eifel purpose". I would like to clarify and REPEAT myself again that we were NOT discussing timestamps for Eifel purposes. Eifel happens to be ONE of the possible mechanisms which can use timestamps. -Sourabh > > --- > > K. Poon. > kacheong.poon@sun.com > > > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 18 05:05:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23908 for ; Fri, 18 Jul 2003 05:05:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRAk-0003jM-RL for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 05:05:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I952j9014302 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 05:05:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRAk-0003hv-4q; Fri, 18 Jul 2003 05:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRA9-0003hR-OS for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 05:04: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 FAA23886 for ; Fri, 18 Jul 2003 05:04:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dRA6-0006kY-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 05:04:22 -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 19dR9v-0006jx-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 05:04:11 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6I93ZGJ022530 for ; Fri, 18 Jul 2003 11:03:35 +0200 (MEST) 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 NW4XJWZX; Fri, 18 Jul 2003 11:03:35 +0200 Received: from ericsson.com (dhcp4-155.eed.ericsson.se [164.48.140.155]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id LAA21434 for ; Fri, 18 Jul 2003 11:03:34 +0200 (MET DST) Message-ID: <3F17B786.3070107@ericsson.com> Date: Fri, 18 Jul 2003 11:01:58 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps References: <3F16F159.34FC8B4C@motorola.com> <3F176037.8090100@sun.com> In-Reply-To: <3F176037.8090100@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kacheong Poon wrote: > I also want to know why can't (since nobody in this thread even > mentioned it) the duplicate TSN be used to detect spurious > retransmission. It is already specified in the standard and does > not require any new chunk be defined. The draw back is not 100% > reliable and it is "slower" to detect the problem. Is there a > fundamental issue with it such that people in this discussion want > a new chunk to be defined? You have already mentioned one of the reasons: Detection of spurious retransmissions using DSACK only works "after the fact", whereas something like Eifel detects it early enough to avoid a go-back-n-like behavior after a spurious timeout (also see RFC 3522). Also, DSACKs do not address the other issues mentioned in this thread, such as the "path ambiguity" and RTTM. Note that DSACKs are still useful and may be combined with Eifel; I think there is a compelling case for introducing optional timestamps even if DSACKs are already utilized. Stephan. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 18 05:24:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24336 for ; Fri, 18 Jul 2003 05:24:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRT7-0004Zs-Mb for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 05:24:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I9O199017592 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 05:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRT6-0004Yz-V4; Fri, 18 Jul 2003 05:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRST-0004V7-L0 for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 05:23: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 FAA24284 for ; Fri, 18 Jul 2003 05:23:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dRSQ-0006w9-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 05:23: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 19dRSE-0006vz-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 05:23:07 -0400 Received: from esealnt610.al.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 h6I9N2Ii020330 for ; Fri, 18 Jul 2003 11:23:02 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 366CP9NG; Fri, 18 Jul 2003 11:23:19 +0200 Received: from ericsson.com (dhcp4-155.eed.ericsson.se [164.48.140.155]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id LAA26439 for ; Fri, 18 Jul 2003 11:23:01 +0200 (MET DST) Message-ID: <3F17BC16.2080003@ericsson.com> Date: Fri, 18 Jul 2003 11:21:26 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps References: <3F176037.8090100@sun.com> <20030718015232.C3547@openss7.org> In-Reply-To: <20030718015232.C3547@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: > What is not robust about the receiver indicating that it received > something multiple times? The receiver is in the best position to > determine when a spurious retransmission has occured at the sender > (because it receives multiple copies). > > I think that is more robust than timestamps that may or may not be > included, might get lost, misbundled, associated with the wrong ack, > etc. Well, this is what I was hoping to get out of this disucssion: A good way to do timestamps without those problems :-) > With duplicates, the receiver says "I already received this TSN". > I agree with Kacheong here, but I disagree that it is slower. In > the RFC receiving duplicates is reason for immediate SACK (whereas > timestamps would not). Therefore, the dup TSNs are, I believe, > faster, in that the duplicate TSN report is immediate under most > situations. (See 6.2 RFC 2960). The problem is that with DSACKs the sender is usually only notified after he has already spuriously retransmitted all packets he erroneously considered lost. With timestamps, the sender can tell that a spurious retransmission happened from the first new ACK. This way unnecessary go-back-n retransmissions can be avoided in many cases. Please see RFC 3522 for more. > Furthermore, the duplicate TSN mechanism is already exists, and is > already used to determine that a spurious restransmission has > occurred, possibly due to a lost SACK return path (the most obvious > cause of persistent spurious retransmissions). > > Can someone back up the statement of timestamps being "more robust"? For one, the DSACK method is more sensitive to ACK losses. Stephan. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 18 05:27:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24407 for ; Fri, 18 Jul 2003 05:27:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRW2-0004jX-Bl for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 05:27:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I9R21V018182 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 05:27:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRW1-0004iP-RQ; Fri, 18 Jul 2003 05:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRVO-0004gl-Fi for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 05:26: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 FAA24374 for ; Fri, 18 Jul 2003 05:26:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dRVL-0006ye-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 05:26:19 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19dRVA-0006yZ-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 05:26:08 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 320D432A3B; Fri, 18 Jul 2003 05:26:05 -0400 (EDT) Received: from louie.udel.edu (louie.udel.edu [128.4.40.12]) by mail.eecis.udel.edu (Postfix) with ESMTP id 5E6BE32A44; Fri, 18 Jul 2003 05:26:04 -0400 (EDT) Date: Fri, 18 Jul 2003 05:26:04 -0400 (EDT) From: Sourabh Ladha X-X-Sender: To: "Brian F. G. Bidulock" Cc: "Armando L. Caro Jr." , Kacheong Poon , Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: <20030718015232.C3547@openss7.org> Message-ID: X-Spam-Status: No, hits=-3.7 required=6.0 tests=DEPT_RCVD,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, 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: , > > What is not robust about the receiver indicating that it received > determine when a spurious retransmission has occured at the sender > (because it receives multiple copies). > > I think that is more robust than timestamps that may or may not be > included, might get lost, misbundled, associated with the wrong ack, > etc. > > With duplicates, the receiver says "I already received this TSN". > I agree with Kacheong here, but I disagree that it is slower. In > the RFC receiving duplicates is reason for immediate SACK (whereas > timestamps would not). Therefore, the dup TSNs are, I believe, > faster, in that the duplicate TSN report is immediate under most > situations. (See 6.2 RFC 2960). > > Furthermore, the duplicate TSN mechanism is already exists, and is > already used to determine that a spurious restransmission has > occurred, possibly due to a lost SACK return path (the most obvious > cause of persistent spurious retransmissions). hmm..What about packet reordering, packet duplication, delay spikes..we seem to be missing some basic causes of spurious retransmissions. > > Can someone back up the statement of timestamps being "more robust"? First, we seem to be using the terms Eifel and timestamps in the same context. This is a fundamental flaw. Are you asking the motivation behind timestamps or are you asking how Eifel using timestamps is more robust than the dup-tsn detection. I would guess the second..from the top of my head, I can think of a few advantages of Eifel over dup-tsn detection. * the dup-tsn notification comes much late in the game. You cannot avoid a GoBackN (which is one of the motivations anyway for having a spurious retransmission detection scheme) if you had a spurious timeout. (I believe RFC3522 will have more details on these). Eifel will be able to detect possibly on the arrival of the first acceptable ACK if the retransmission was spurious. * the dup-tsn detection is sensitive to ACK loss: if you lost the ACK carrying the duptsn you possibly fail the detection. * the duptsn notification is less robust to packet duplication (in particular for SCTP). I remember Reiner and I had noted this in some of the previous emails on a different thread: If the SCTP association is multihomed and the alternate path is duplicating packets then with the dup-tsn detection scheme coupled with a response algorithm may end up making an SCTP non-responsive to congestion. -Sourabh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 18 05:33:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24767 for ; Fri, 18 Jul 2003 05:33:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRbq-0005PF-2H for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 05:33:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I9X2Rk020739 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 05:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRbo-0005Mu-QD; Fri, 18 Jul 2003 05:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRb6-0005MA-Nu for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 05:32:16 -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 FAA24709 for ; Fri, 18 Jul 2003 05:32:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dRb3-00073t-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 05:32:13 -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 19dRas-00073q-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 05:32:02 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6I9VwGJ028030 for ; Fri, 18 Jul 2003 11:31:58 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 3S6JX7QM; Fri, 18 Jul 2003 11:34:55 +0200 Received: from ericsson.com (dhcp4-155.eed.ericsson.se [164.48.140.155]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id LAA28942 for ; Fri, 18 Jul 2003 11:31:57 +0200 (MET DST) Message-ID: <3F17BE2D.7010508@ericsson.com> Date: Fri, 18 Jul 2003 11:30:21 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps 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 Wolfgang, this is indeed another way to resolve the retransmission ambiguity (in fact the first proposal of the Eifel algorithm for TCP used this method). The questions are whether (1) there are header bits available for this and (2) whether losing the additional benefits of timestamps (RTTM and the ability to distinguish not only between original transmission and retransmission, but between an arbitrary number of consecutive retransmissions as well) is a serious concern. Stephan. Schruefer Wolfgang wrote: > Dear all, > > I will suggest an alternative solution, how to enable a sender to > determine whether an ACK refers to the original transmission or a > retransmission of a chunk. > > My thought is to sacrifice one of the unused bits in the Chunk Flags > field of the DATA and SACK chunks to solve the problem. The clue is > that the value of this bit from the DATA chunk should be echoed by > the receiver in the SACK chunk. A feature negotiation at association > setup is not necessary, because the sender recognises early if the > feature is supported by the peer or not. > > > A scenario may run like this (let me just call this new bit Mirror > Bit or M-bit): > > - A sender sets the M-bit at any value when a DATA chunk is > transmitted for the first time and stores the value together with the > timestamp. > > - In the SACK the receiver mirrors the M-bit for the DATA chunk with > TSN == Cumulative TSN Ack. > > - When the sender recognises that the M-bit is not echoed correctly > (for not retransmitted DATA), it knows that the peer does not support > this feature. > > - When the sender needs to retransmit the DATA for the first time it > toggles the M-bit and stores the retransmission time. > > - For up to one retransmission the sender can 100% resolve the chunk > where a SACK refers to. > > - When there is a need for further retransmissions I see three > alternatives: ** The M-bit is toggled again and the sender assumes > that the DATA chunk sent two RTO earlier was lost. ** The M-bit > remains identical in all retransmissions (but e.g. a SACK for this > DATA chunk may not be used any more for RTT calculation). ** We use > two Chunk Flag Bits to mark the last four transmissions. > > > Is this a way worth while to think about? > > Wolfgang > > > > > > > > > > > > Dear all, > > following the Timestamp discussion I asked myself whether there is a > need to transmit any timestamp and if there are no cheaper solution. > What we need in my understanding is a solution for the problem > Stephan described at the beginning of the thread: > > Resolving the retransmission ambiguity, i.e. enabling the sender to > determine whether an ACK refers to the original transmission or a > retransmission of a chunk. This implies resolving a "path ambiguity" > and allowing better and more frequent RTT measurements. > > My thought is to sacrifice one (or two) bit(s) of the unused DATA and > SACK Chunk Flags Bits to solve this problem. The clue is that this > bit should be echoed by the receiver in the SACK Chunk Flags. Let me > just call this bit Mirror Bit or M-bit. > > > A scenario may run like this: - A sender sets the M-bit at any value > when a DATA chunk is transmitted for the first time and stores the > value together with the timestamp. > > - The receiver mirrors the bit for the DATA chunk with TSN == > Cumulative TSN Ack. > > - When the sender recognises that the M-bit is not echoed correctly > (for not retransmitted DATA), it knows that the peer does not support > this feature. I think a feature negotiation at association setup is > therefore not necessary. > > - When the sender needs to retransmit the DATA for the first time it > toggles the M-bit and stores the retransmission time. > > - Up to now the sender can always resolve the chunk where a SACK > refers to. > > - When there is a need for further retransmissions I see three > alternatives: ** The M-bit is toggled again and the sender assumes > that the DATA chunk sent two RTO before was lost. ** The M-bit > remains identical in all retransmissions (but e.g. a SACK for this > DATA chunk may not be used any more for RTT calculation). ** We use > two Chunk Flag Bits to mark the last four transmissions. > > > Is this a way worth to think further? > > Wolfgang > > > Viele Gruesse Wolfgang Schruefer > > Siemens ICN CP D NP A8 TEL: +49 89 722-61646 > > > _______________________________________________ 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 Fri Jul 18 05:39:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25065 for ; Fri, 18 Jul 2003 05:39:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRhd-0005yx-2p for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 05:39:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I9d1dG022989 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 05:39:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRhc-0005xw-Ck; Fri, 18 Jul 2003 05:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRgr-0005wq-P2 for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 05:38:13 -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 FAA25026 for ; Fri, 18 Jul 2003 05:38:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dRgo-00076g-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 05:38:10 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 19dRgd-00075y-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 05:37:59 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h6I9aVY09712; Fri, 18 Jul 2003 11:36:31 +0200 (MEST) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h6I9aUq12194; Fri, 18 Jul 2003 11:36:30 +0200 (MEST) Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA29365; Fri, 18 Jul 2003 11:35:22 +0200 (MET DST) Received: by mchh248e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jul 2003 11:35:55 +0200 Message-ID: From: Schruefer Wolfgang To: "'bidulock@openss7.org'" Cc: tsvwg@ietf.org Subject: AW: [Tsvwg] SCTP Timestamps Date: Fri, 18 Jul 2003 11:35:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" 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 Brian, yes, it is normal that M-bit indications a lost, but why do you care = about spurious retransmissions older than Cumulative Ack Point? In my implementation I would not care because RTT measurement is done = only for the DATA chunk at the Cumulative Ack Point. I think it is better than dup TSN reports, because these arrive = delayed. Wolfgang =20 > Von: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Gesendet: Freitag, 18. Juli 2003 10:55 >=20 > Wolfgang, >=20 > What about the packet that contains: >=20 > RTx (2) DATA RTx (2) DATA RTx (1) DATA New DATA New DATA >=20 > from two separate retransmissions. >=20 > What about when the spurious retransmissions are before the > Cummulative Ack point (due to loss of SACKs)? Won't these > M-bit indications be lost? >=20 > Doesn't sound better than existing dup TSN reports in SACKs. >=20 > --brian >=20 > On Fri, 18 Jul 2003, Schruefer Wolfgang wrote: >=20 > > Dear all, > >=20 > > I will suggest an alternative solution, how to enable a=20 > sender to determine > > whether an ACK refers to the original transmission or a=20 > retransmission of a > > chunk. > >=20 > > My thought is to sacrifice one of the unused bits in the=20 > Chunk Flags field > > of the DATA and SACK chunks to solve the problem. The clue=20 > is that the value > > of this bit from the DATA chunk should be echoed by the=20 > receiver in the SACK > > chunk. A feature negotiation at association setup is not=20 > necessary, because > > the sender recognises early if the feature is supported by=20 > the peer or not. > >=20 > >=20 > > A scenario may run like this (let me just call this new bit=20 > Mirror Bit or > > M-bit):=20 > >=20 > > - A sender sets the M-bit at any value when a DATA chunk is=20 > transmitted for > > the first time and stores the value together with the timestamp. > >=20 > > - In the SACK the receiver mirrors the M-bit for the DATA=20 > chunk with TSN =3D=3D > > Cumulative TSN Ack. > >=20 > > - When the sender recognises that the M-bit is not echoed=20 > correctly (for not > > retransmitted DATA), it knows that the peer does not=20 > support this feature.=20 > >=20 > > - When the sender needs to retransmit the DATA for the=20 > first time it toggles > > the M-bit and stores the retransmission time. > >=20 > > - For up to one retransmission the sender can 100% resolve=20 > the chunk where a > > SACK refers to. > >=20 > > - When there is a need for further retransmissions I see=20 > three alternatives: > > ** The M-bit is toggled again and the sender assumes that=20 > the DATA chunk > > sent two RTO earlier was lost. ** The M-bit remains=20 > identical in all > > retransmissions (but e.g. a SACK for this DATA chunk may=20 > not be used any > > more for RTT calculation). ** We use two Chunk Flag Bits=20 > to mark the last > > four transmissions. > >=20 > >=20 > > Is this a way worth while to think about? > >=20 > > Wolfgang > >=20 >=20 > --=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 >=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 18 06:08:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25715 for ; Fri, 18 Jul 2003 06:08:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dS9m-0007PV-0o for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 06:08:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IA85ko028479 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 06: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 19dS9h-0007OQ-MQ; Fri, 18 Jul 2003 06:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dS9A-0007FI-FJ for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 06:07: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 GAA25692 for ; Fri, 18 Jul 2003 06:07:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dS96-0007LK-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 06:07:24 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 19dS8v-0007LE-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 06:07:13 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h6IA73116296; Fri, 18 Jul 2003 12:07:03 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h6IA72q13588; Fri, 18 Jul 2003 12:07:02 +0200 (MEST) Received: from mchh274e.demchh201e.icn.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id MAA13159; Fri, 18 Jul 2003 12:07:01 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Fri, 18 Jul 2003 12:06:26 +0200 Message-ID: From: Schruefer Wolfgang To: "'Stephan Baucke'" , tsvwg@ietf.org Subject: AW: [Tsvwg] SCTP Timestamps Date: Fri, 18 Jul 2003 12:06:22 +0200 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: , Stephan, please see my comments below... Wolfgang > Von: Stephan Baucke > > this is indeed another way to resolve the retransmission > ambiguity (in > fact the first proposal of the Eifel algorithm for TCP used this > method). The questions are whether (1) there are header bits > available > for this I can not judge if this is a feature worth to sacrifice a bit, but there are 5 unused Bits in the DATA chunk header... > and (2) whether losing the additional benefits of timestamps > (RTTM Why do we loose RTTM? The timestamps (transmission and retransmission) are stored locally. > and the ability to distinguish not only between original > transmission and retransmission, but between an arbitrary number of > consecutive retransmissions as well Here I doubt that it makes sense to enhance the communication if more than one retransmission is needed for a significant number of packets. ) is a serious concern. > > Stephan. > > > Schruefer Wolfgang wrote: > > > Dear all, > > > > I will suggest an alternative solution, how to enable a sender to > > determine whether an ACK refers to the original transmission or a > > retransmission of a chunk. > > > > My thought is to sacrifice one of the unused bits in the Chunk Flags > > field of the DATA and SACK chunks to solve the problem. The clue is > > that the value of this bit from the DATA chunk should be echoed by > > the receiver in the SACK chunk. A feature negotiation at association > > setup is not necessary, because the sender recognises early if the > > feature is supported by the peer or not. > > > > > > A scenario may run like this (let me just call this new bit Mirror > > Bit or M-bit): > > > > - A sender sets the M-bit at any value when a DATA chunk is > > transmitted for the first time and stores the value > together with the > > timestamp. > > > > - In the SACK the receiver mirrors the M-bit for the DATA chunk with > > TSN == Cumulative TSN Ack. > > > > - When the sender recognises that the M-bit is not echoed correctly > > (for not retransmitted DATA), it knows that the peer does > not support > > this feature. > > > > - When the sender needs to retransmit the DATA for the first time it > > toggles the M-bit and stores the retransmission time. > > > > - For up to one retransmission the sender can 100% resolve the chunk > > where a SACK refers to. > > > > - When there is a need for further retransmissions I see three > > alternatives: ** The M-bit is toggled again and the sender assumes > > that the DATA chunk sent two RTO earlier was lost. ** The M-bit > > remains identical in all retransmissions (but e.g. a SACK for this > > DATA chunk may not be used any more for RTT calculation). ** We use > > two Chunk Flag Bits to mark the last four transmissions. > > > > > > Is this a way worth while to think about? > > > > Wolfgang > > > > > > > > > > > > > > > > > > > > > > > > Dear all, > > > > following the Timestamp discussion I asked myself whether there is a > > need to transmit any timestamp and if there are no cheaper solution. > > What we need in my understanding is a solution for the problem > > Stephan described at the beginning of the thread: > > > > Resolving the retransmission ambiguity, i.e. enabling the sender to > > determine whether an ACK refers to the original transmission or a > > retransmission of a chunk. This implies resolving a "path ambiguity" > > and allowing better and more frequent RTT measurements. > > > > My thought is to sacrifice one (or two) bit(s) of the > unused DATA and > > SACK Chunk Flags Bits to solve this problem. The clue is that this > > bit should be echoed by the receiver in the SACK Chunk Flags. Let me > > just call this bit Mirror Bit or M-bit. > > > > > > A scenario may run like this: - A sender sets the M-bit at any value > > when a DATA chunk is transmitted for the first time and stores the > > value together with the timestamp. > > > > - The receiver mirrors the bit for the DATA chunk with TSN == > > Cumulative TSN Ack. > > > > - When the sender recognises that the M-bit is not echoed correctly > > (for not retransmitted DATA), it knows that the peer does > not support > > this feature. I think a feature negotiation at association setup is > > therefore not necessary. > > > > - When the sender needs to retransmit the DATA for the first time it > > toggles the M-bit and stores the retransmission time. > > > > - Up to now the sender can always resolve the chunk where a SACK > > refers to. > > > > - When there is a need for further retransmissions I see three > > alternatives: ** The M-bit is toggled again and the sender assumes > > that the DATA chunk sent two RTO before was lost. ** The M-bit > > remains identical in all retransmissions (but e.g. a SACK for this > > DATA chunk may not be used any more for RTT calculation). ** We use > > two Chunk Flag Bits to mark the last four transmissions. > > > > > > Is this a way worth to think further? > > > > Wolfgang > > > > > > Viele Gruesse Wolfgang Schruefer > > > > Siemens ICN CP D NP A8 TEL: +49 89 722-61646 > > > > > > _______________________________________________ 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 > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 18 06:22:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24769 for ; Fri, 18 Jul 2003 05:33:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRbq-0005PE-21 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 05:33:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I9X2YY020738 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 05:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRbp-0005Ng-CX; Fri, 18 Jul 2003 05:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRbn-0005Mg-D6 for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 05:32: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 FAA24726 for ; Fri, 18 Jul 2003 05:32:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dRbj-00074B-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 05:32:55 -0400 Received: from eve.icir.org.ietf57.telekom.at ([81.160.150.208] helo=eve.cs.ucl.ac.uk) by ietf-mx with esmtp (Exim 4.12) id 19dRbT-000744-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 05:32:40 -0400 Received: from eve.cs.ucl.ac.uk (localhost [127.0.0.1]) by eve.cs.ucl.ac.uk (8.12.9/8.12.2) with ESMTP id h6I9WTcG009148 for ; Fri, 18 Jul 2003 10:32:29 +0100 (BST) From: Mark Handley To: tsvwg@ietf.org Date: Fri, 18 Jul 2003 10:32:29 +0100 Message-ID: <9147.1058520749@eve.cs.ucl.ac.uk> Subject: [Tsvwg] High-speed 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: , In followup to today's TSVWG meeting, here's some suggested boilerplate text for the High-speed TCP Experimental RFC: The proposals in this document are experimental. We believe they are safe for deployment in the current Internet, but they do not represent a consensus that this is the best method for high-speed congestion control. In particular, we note that alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals. Cheers, Mark _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 18 06:41:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26382 for ; Fri, 18 Jul 2003 06:41:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSff-0000WN-Of for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 06:41:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IAf3u9001997 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 06:41:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSfe-0000VN-8T; Fri, 18 Jul 2003 06:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSev-0000V0-QN for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 06:40: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 GAA26337 for ; Fri, 18 Jul 2003 06:40:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dSer-0007dN-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 06:40:13 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[lC1t6JN9E7gjjIaJNkSkUzMlQYMW8OlR]) by ietf-mx with esmtp (Exim 4.12) id 19dSec-0007dC-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 06:39:58 -0400 Received: from ns.pigworks.openss7.net (IDENT:DdiHxGJ8Pa79PWvdJeBr4nx1XEiP6/o8@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h6IAdXP09004; Fri, 18 Jul 2003 04:39:33 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h6IAdXS07323; Fri, 18 Jul 2003 04:39:33 -0600 Date: Fri, 18 Jul 2003 04:39:32 -0600 From: "Brian F. G. Bidulock" To: Sourabh Ladha Cc: "Armando L. Caro Jr." , Kacheong Poon , tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps Message-ID: <20030718043932.B5448@openss7.org> Reply-To: bidulock@openss7.org References: <20030718015232.C3547@openss7.org> 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: ; from ladha@mail.eecis.udel.edu on Fri, Jul 18, 2003 at 05:26:04AM -0400 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 h6IAdXP09004 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, On Fri, 18 Jul 2003, Sourabh Ladha wrote: > > > > What is not robust about the receiver indicating that it received > > determine when a spurious retransmission has occured at the sender > > (because it receives multiple copies). > > > > I think that is more robust than timestamps that may or may not be > > included, might get lost, misbundled, associated with the wrong ack, > > etc. > > > > With duplicates, the receiver says "I already received this TSN". > > I agree with Kacheong here, but I disagree that it is slower. In > > the RFC receiving duplicates is reason for immediate SACK (whereas > > timestamps would not). Therefore, the dup TSNs are, I believe, > > faster, in that the duplicate TSN report is immediate under most > > situations. (See 6.2 RFC 2960). > > > > Furthermore, the duplicate TSN mechanism is already exists, and is > > already used to determine that a spurious restransmission has > > occurred, possibly due to a lost SACK return path (the most obvious > > cause of persistent spurious retransmissions). >=20 > hmm..What about packet reordering, packet duplication, delay spikes..we > seem to be missing some basic causes of spurious retransmissions. I didn't mean that it couldn't be used for those, it just isn't at the moment. 2960 mentions the more obvious, most injurious to SCTP (blindly sending SACKs to a dead destination address that never receives DATA and never suffers a timeout except at slower HEARTBEAT intervals.) >=20 > > > > Can someone back up the statement of timestamps being "more robust"? >=20 > First, we seem to be using the terms Eifel and timestamps in the same > context. This is a fundamental flaw. Are you asking the motivation behi= nd > timestamps or are you asking how Eifel using timestamps is more robust > than the dup-tsn detection. >=20 > I would guess the second..from the top of my head, I can think of a > few advantages of Eifel over dup-tsn detection. >=20 > * the dup-tsn notification comes much late in the game. You cannot avoi= d a > GoBackN (which is one of the motivations anyway for having a spurious > retransmission detection scheme) if you had a spurious timeout. (I beli= eve > RFC3522 will have more details on these). Eifel will be able to detect > possibly on the arrival of the first acceptable ACK if the retransmissi= on > was spurious. Ok. I see that. But I would say that it is "possible" that timestamps wi= ll detect faster, and not necessarily always or even often and certainly not obviously the case. >=20 > * the dup-tsn detection is sensitive to ACK loss: if you lost the ACK > carrying the duptsn you possibly fail the detection. Lost ACKs can cause Eifel to fail detection on timestamps too. >=20 > * the duptsn notification is less robust to packet duplication (in > particular for SCTP). I remember Reiner and I had noted this in some of > the previous emails on a different thread: If the SCTP association is > multihomed and the alternate path is duplicating packets then with the > dup-tsn detection scheme coupled with a response algorithm may end up > making an SCTP non-responsive to congestion. Duplicating network paths are easy to detect: a TSN cannot have more dup-TSns that it was retransmitted. --brian >=20 >=20 > -Sourabh >=20 --=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 Fri Jul 18 07:45:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27528 for ; Fri, 18 Jul 2003 07:45:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dTfg-0002gB-0y for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 07:45:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IBj8nD010281 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 07:45:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dTfZ-0002f4-L5; Fri, 18 Jul 2003 07: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 19dTer-0002dr-5R for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 07: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 HAA27519 for ; Fri, 18 Jul 2003 07:44:15 -0400 (EDT) From: ladha@mail.eecis.udel.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dTeq-0000F2-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 07:44:16 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19dTef-0000Ez-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 07:44:05 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 69597328F2; Fri, 18 Jul 2003 07:43:45 -0400 (EDT) Received: from webmail.eecis.udel.edu (dbacks.acad.ece.udel.edu [128.4.60.14]) by mail.eecis.udel.edu (Postfix) with SMTP id 9C89532893; Fri, 18 Jul 2003 07:43:44 -0400 (EDT) Received: from 212.117.81.29 (SquirrelMail authenticated user ladha) by webmail.eecis.udel.edu with HTTP; Fri, 18 Jul 2003 07:43:44 -0400 (EDT) Message-ID: <23303.212.117.81.29.1058528624.squirrel@webmail.eecis.udel.edu> In-Reply-To: References: Date: Fri, 18 Jul 2003 07:43:44 -0400 (EDT) Subject: Re: AW: [Tsvwg] SCTP Timestamps To: "Schruefer Wolfgang" Cc: "'Stephan Baucke'" , tsvwg@ietf.org User-Agent: SquirrelMail/1.4.0 X-Priority: 3 Importance: Normal X-Spam-Status: No, hits=-1.8 required=6.0 tests=DEPT_RCVD,IN_REP_TO,NO_REAL_NAME,PRIORITY_NO_NAME, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02,USER_AGENT 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="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: , >> and (2) whether losing the additional benefits of timestamps >> (RTTM > > Why do we loose RTTM? The timestamps (transmission and retransmission) are > stored locally. I think the whole purpose of using timestamp (even applicable for TCP) rather than storing timestamps locally for RTTM was to avoid this added state at the sender. > >> and the ability to distinguish not only between original >> transmission and retransmission, but between an arbitrary number of >> consecutive retransmissions as well > > Here I doubt that it makes sense to enhance the communication if more than > one retransmission is needed for a significant number of packets. > I think I am missing something here? I think if we do intend to "enhance communication" we do it correctly and for all possible cases we can, rather than restrict ourselves to the case of "one retransmission". Note that the consecutive retransmissions that Stephan was referring to can go on different paths (destinations). I can still think (while using retransmission bit) scenarios where an SCTP sender can break packet conservation, do congestion window overgrowth and potentially harm the network. -Sourabh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 18 10:34:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02609 for ; Fri, 18 Jul 2003 10:34:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dWJ9-0000dq-2b for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 10:34:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IEY3om002463 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 10:34:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dWJ7-0000cv-HM; Fri, 18 Jul 2003 10:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dWJ4-0000cj-BB for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 10:33: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 KAA02603 for ; Fri, 18 Jul 2003 10:33:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dWJ1-0001Lu-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 10:33:56 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 19dWIq-0001Lr-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 10:33:44 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h6IEXNN08236; Fri, 18 Jul 2003 16:33:23 +0200 (MEST) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h6IEXNS27112; Fri, 18 Jul 2003 16:33:23 +0200 (MEST) Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id QAA04138; Fri, 18 Jul 2003 16:32:14 +0200 (MET DST) Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jul 2003 16:32:47 +0200 Message-ID: From: Schruefer Wolfgang To: "'ladha@mail.eecis.udel.edu'" Cc: "'Stephan Baucke'" , tsvwg@ietf.org Subject: AW: [Tsvwg] SCTP Timestamps Date: Fri, 18 Jul 2003 16:32:46 +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: , > >> and (2) whether losing the additional benefits of timestamps > >> (RTTM > > > > Why do we loose RTTM? The timestamps (transmission and > retransmission) are > > stored locally. > > I think the whole purpose of using timestamp (even applicable for TCP) > rather than storing timestamps locally for RTTM was to avoid > this added > state at the sender. I am not sure what you mean by 'added state'. Is it that you want to avoid a locally stored timestamp and instead you store it in the network by a Timstamp ping-pong? When I compare the costs of both alternatives I can not imagine that a ping-pong is more effective (think of 4 times checksum calculation, reduced payload and net bandwith, ...). > > > > >> and the ability to distinguish not only between original > >> transmission and retransmission, but between an arbitrary number of > >> consecutive retransmissions as well > > > > Here I doubt that it makes sense to enhance the > communication if more than > > one retransmission is needed for a significant number of packets. > > > > I think I am missing something here? I think if we do intend > to "enhance > communication" we do it correctly and for all possible cases we can, > rather than restrict ourselves to the case of "one > retransmission". Note > that the consecutive retransmissions that Stephan was > referring to can go > on different paths (destinations). I can still think (while using > retransmission bit) scenarios where an SCTP sender can break packet > conservation, do congestion window overgrowth and potentially harm the > network. When I go at the beginning of the thread, Stephen showed up the problems: > - Allowing for better and more frequent RTT measurements > > - Resolving the "path ambiguity" in a multihomed association: If an ACK > arrives for a chunk that has been retransmitted one or more times on > alternating paths, it is not possible to safely determine which > destination the ACK should be credited to (this is briefly mentioned in > section 8.2 of RFC 2960). This may result in resetting the wrong error > counter (delaying the detection of an inactive path), or in unfair > behavior if the congestion window of the wrong path is adapted as a > result of the ACK. > - Resolving the retransmission ambiguity, i.e. enabling the sender to > determine whether an ACK refers to the original transmission or a > retransmission of a chunk. This is a necessary precondition for > implementing the Eifel algorithm for SCTP (which we are currently > looking at). And all of the points are enhanced significantly by implementation of the retransmission bit, because a single path failure and a single retransmission can be handled 100% correct. Also for multiple retransmissions the retransmission bit may prevent us from harming the network, because a very late SACK for an original Packet can be identified. If it is considered that one bit is not to be enough, a second bit may be used. I just wanted to express that I think for the problem of spurious retransmissions one retransmission bit seems for me to be enough. Wolfgang > > > -Sourabh > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 18 12:07:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04572 for ; Fri, 18 Jul 2003 12:07:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dXlG-0003yU-PR for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 12:07:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IG7Awv015278 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 12:07:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dXl7-0003uk-PQ; Fri, 18 Jul 2003 12:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dXki-0003rI-KU for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 12:06:36 -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 MAA04557 for ; Fri, 18 Jul 2003 12:06:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dXkh-0001s1-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 12:06:35 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19dXkW-0001rr-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 12:06:24 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id B8B2332A98; Fri, 18 Jul 2003 12:05:58 -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 44E4932A15; Fri, 18 Jul 2003 12:05:57 -0400 (EDT) Date: Fri, 18 Jul 2003 12:05:57 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Schruefer Wolfgang Cc: "'ladha@mail.eecis.udel.edu'" , "'Stephan Baucke'" , Subject: Re: AW: [Tsvwg] SCTP Timestamps In-Reply-To: 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 Fri, 18 Jul 2003, Schruefer Wolfgang wrote: > If it is considered that one bit is not to be enough, a second bit may > be used. I just wanted to express that I think for the problem of > spurious retransmissions one retransmission bit seems for me to be > enough. I disagree. Remember that if the peer SCTP endpoint has multiple destination IP addresses, each retransmission may go on a different path. So you are saying that it is enough to only be able to detect spurious retransmissions the first time, which only helps the cwnd and RTO of the primary destination. If the first retransmission spuriously times out, then we don't care according to you. We _may_ not care that the cwnd gets cut unnecessarily, because the cwnd generally stays pretty small on alternate paths. But, we DO care that the RTO is left doubled, because there isn't much traffic on an alternate path to bring that RTO down again. So the next time a timeout occurs (whether spurious or not) on that alternate path, it will take that much longer. If you are not following this argument, _please_ read at least section 3 of our paper. It's a short read. The full paper is only 5 pages. http://www.cis.udel.edu/~acaro/papers/2003.milcom.acaro.pdf ~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 Fri Jul 18 12:30:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04949 for ; Fri, 18 Jul 2003 12:30:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dY7R-0004h9-6K for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 12:30:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IGU5jU018036 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 12:30:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dY7N-0004g8-SC; Fri, 18 Jul 2003 12:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dY6k-0004fU-OJ for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 12:29: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 MAA04887 for ; Fri, 18 Jul 2003 12:29:19 -0400 (EDT) From: Yogesh.Swami@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dY6j-0001xB-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 12:29:21 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19dY6Y-0001x2-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 12:29:10 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6IGSrG11968 for ; Fri, 18 Jul 2003 11:28:53 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Jul 2003 11:28:53 -0500 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 18 Jul 2003 09:28:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] Slides for Eifel Response in Vienna IETF Date: Fri, 18 Jul 2003 11:28:50 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE016E8041@daebe004.americas.nokia.com> Thread-Topic: [Tsvwg] Slides for Eifel Response in Vienna IETF Thread-Index: AcNMxGCWXAJMsDUWRBilvQHUKWN0mAAfiagg To: , , Cc: , X-OriginalArrivalTime: 18 Jul 2003 16:28:51.0191 (UTC) FILETIME=[AC1B0870:01C34D49] 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 As I was going through these slides, I didn't even see a single mention = of DCLOR, which was the main reason why we had the discussion about = appropriate congestion response and rate halving. In fact, just a = couple of months back, most people (including Reiner Ludwig) were not = even willing to consider rate halving (I've put links to the e-mails = that were exchanged on this issues). The present DCLOR draft already does what the updated Eifel response = will do (the present draft has not even been updated with these changes = and the document is being asked for last call). Also, if I can recall, = people who engaged in the discussion that time did agree to having two = different response algorithm--one as described in the Eifel response = --03 draft, and another one which will rate halve every RTO as in DCLOR. Now, Eifel Response incorporates the work of DCLOR, and makes it look as = if they are the ones who came with this scheme in the first place (Here = is a link to Reiner's view in March about Rate Halving: = http://www1.ietf.org/mail-archive/working-groups/tsvwg/current/msg03819.h= tml). I had asked the working group chairs in the past about making = DCLOR a working group draft, but I did not receive any response. To me = all this seems a little strange, and disheartening. --yogesh=20 Please follow the thread of this e-mail for the discussion. http://www1.ietf.org/mail-archive/working-groups/tsvwg/current/msg03813.h= tml > -----Original Message----- > From: ext Andrei Gurtov [mailto:gurtov@cs.helsinki.fi] > Sent: 17 July, 2003 7:33 PM > To: tsvwg@ietf.org; Reiner Ludwig > Subject: [Tsvwg] Slides for Eifel Response in Vienna IETF >=20 >=20 >=20 > Slides for the presentation on Eifel Response in the TSVWG meeting in=20 > Vienna IETF are available at: >=20 > http://www.cs.helsinki.fi/u/gurtov/reiner/eifel_alg_ietf57.pdf > http://www.cs.helsinki.fi/u/gurtov/reiner/eifel_alg_ietf57.ppt >=20 > Also of possible interest is: >=20 > A. Gurtov, R. Ludwig, Responding to Spurious Timeouts in TCP, IEEE=20 > INFOCOM'03, March 2003. > http://www.cs.helsinki.fi/u/gurtov/papers/resp.html >=20 > Reiner&Andrei >=20 >=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 Fri Jul 18 22:50:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21322 for ; Fri, 18 Jul 2003 22:50:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dhnS-0005ya-QL for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 22:50:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6J2o67s022967 for tsvwg-archive@odin.ietf.org; Fri, 18 Jul 2003 22:50:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dhnN-0005yH-Gh; Fri, 18 Jul 2003 22:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dhmS-0005wq-TW for tsvwg@optimus.ietf.org; Fri, 18 Jul 2003 22:49: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 WAA21216 for ; Fri, 18 Jul 2003 22:49:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dhmP-0005hY-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 22:49:01 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19dhmE-0005h8-00 for tsvwg@ietf.org; Fri, 18 Jul 2003 22:48:50 -0400 Received: from phys-ha1mpka.eng.sun.com ([129.146.14.50]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6J2m1t7001273 for ; Fri, 18 Jul 2003 19:48:01 -0700 (PDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by phys-ha1mpka.eng.sun.com (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id TAA27966 for ; Fri, 18 Jul 2003 19:48:00 -0700 (PDT) Message-ID: <3F18B15F.6060307@sun.com> Date: Fri, 18 Jul 2003 19:47:59 -0700 From: Kacheong Poon User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2.1) Gecko/20030313 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps 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 I aggregate several replies into one mail to save bandwidth... Sourabh Ladha wrote: >>From some of the emails I have seen in this thread, it seems folks have > the wrong impression that timestamps are being proposed for "Eifel > purpose". > > I would like to clarify and REPEAT myself again that we were NOT > discussing timestamps for Eifel purposes. Eifel happens to be > ONE of the possible mechanisms which can use timestamps. I guess what people have said so far is that the other purposes are either not very beneficial or do not necessarily require the use of timestamp. That's why I try to concentrate on the one issue which people think "definitely" require the use of timestamp. Stephan Baucke wrote: > You have already mentioned one of the reasons: Detection of spurious > retransmissions using DSACK only works "after the fact", whereas > something like Eifel detects it early enough to avoid a go-back-n-like > behavior after a spurious timeout (also see RFC 3522). How about Pasi's F-RTO? I have read Sourabh's questions about F-RTO. But I think F-RTO can be modified, possible making use of duplicate TSN, for SCTP to address those questions. > Also, DSACKs do > not address the other issues mentioned in this thread, such as the "path > ambiguity" and RTTM. Note that DSACKs are still useful and may be > combined with Eifel; I think there is a compelling case for introducing > optional timestamps even if DSACKs are already utilized. I guess many people have pointed out that RTTM is not very crucial and there are implementation techniques which can make more RTT measurements without using timestamp. For the issue of path ambiguity, I guess we need to first understand why it happens. And can it be avoided? One case mentioned is that a retransmission takes place in an alternate path causing problem in cwnd growth. We should first ask if retransmitting using an alternate path is always a good thing. There is a reason why RFC 2960 does not require (MUST) an implementation to always retransmit using alternate path. I guess we should first decide when an alternate path be used for retransmission to minimize the path ambiguity issue. Another path ambiguity issue mentioned is changeover by the app. A "simple" way to avoid that is for the implementation to withhold sending packets before all outstanding packets to the original primary destination address have been ack'ed. This has the side effect of discouraging an app to change often. Granted, this "simple" solution prevents a lot of "experimentation" on, for example, load balancing and has obvious performance implication. But I think at this point, there is no solid proposal in making using of alternate paths other than retransmission. So I believe it is OK for now. I guess we should try to avoid the problems first before trying to find a solution, timestamp in this case, to the problems. And it seems to me that we can actually minimize the chances of the problems mentioned so far. I don't see a compelling reason to introduce a new chunk for timestamp. --- K. Poon. kacheong.poon@sun.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sun Jul 20 05:15:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15380 for ; Sun, 20 Jul 2003 05:15:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eAHf-0003v3-Sy for tsvwg-archive@odin.ietf.org; Sun, 20 Jul 2003 05:15:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6K9FBEm015065 for tsvwg-archive@odin.ietf.org; Sun, 20 Jul 2003 05:15:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eAHV-0003uA-Nx; Sun, 20 Jul 2003 05:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eAHM-0003tp-IR for tsvwg@optimus.ietf.org; Sun, 20 Jul 2003 05:14: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 FAA15374 for ; Sun, 20 Jul 2003 05:14:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eAHJ-0000pc-00 for tsvwg@ietf.org; Sun, 20 Jul 2003 05:14:49 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx with esmtp (Exim 4.12) id 19eAH8-0000pF-00 for tsvwg@ietf.org; Sun, 20 Jul 2003 05:14:38 -0400 Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 19eAGi-0006wb-00 for tsvwg@ietf.org; Sun, 20 Jul 2003 11:14:12 +0200 Received: from [80.133.132.121] (helo=ericsson.com) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 19eAGi-0006og-00; Sun, 20 Jul 2003 11:14:12 +0200 Message-ID: <3F1A5DDE.1060607@ericsson.com> Date: Sun, 20 Jul 2003 11:16:14 +0200 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps 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 >> You have already mentioned one of the reasons: Detection of >> spurious retransmissions using DSACK only works "after the fact", >> whereas something like Eifel detects it early enough to avoid a >> go-back-n-like behavior after a spurious timeout (also see RFC >> 3522). > > How about Pasi's F-RTO? I have read Sourabh's questions about F-RTO. > But I think F-RTO can be modified, possible making use of duplicate > TSN, for SCTP to address those questions. I have not really looked at F-RTO in depth, but seem to remember that it only covers part of the cases that e.g. Eifel covers (perhaps Pasi can comment on that?) >> Also, DSACKs do not address the other issues mentioned in this >> thread, such as the "path ambiguity" and RTTM. Note that DSACKs are >> still useful and may be combined with Eifel; I think there is a >> compelling case for introducing optional timestamps even if DSACKs >> are already utilized. > > I guess many people have pointed out that RTTM is not very crucial > and I am not convinced of that. While there is evidence questioning the benefits of timing every packet for modest congestion window sizes (Allman/Paxson SIGCOMM '99), there is on the other hand evidence that it can counter aliasing effects in case of large congestion windows (RFC 1323), and can help to reduce spurious timeouts in case of links with highly variant RTTs, in particular wireless links (see e.g. RFC 3481, section 4.8). Timestamps may also enable alternative RTO estimators in the future. > and there are implementation techniques which can make more RTT > measurements without using timestamp. But do these techniques also allow for the timing of retransmitted packets? This still seems important to me, especially for obtaining a better RTO on alternate paths. Without timestamps we would need some other method to disambiguate retransmissions in order to achieve this. > For the issue of path ambiguity, I guess we need to first understand > why it happens. And can it be avoided? One case mentioned is that a > retransmission takes place in an alternate path causing problem in > cwnd growth. We should first ask if retransmitting using an > alternate path is always a good thing. There is a reason why RFC 2960 > does not require (MUST) an implementation to always retransmit using > alternate path. I guess we should first decide when an alternate > path be used for retransmission to minimize the path ambiguity issue. > I guess one could reduce the probability of the "path ambiguity" by changing the SCTP retransmit policy, but nevertheless it seems sensible to me to address problems that may arise from the standard policy recommended by RFC 2960. > Another path ambiguity issue mentioned is changeover by the app. A > "simple" way to avoid that is for the implementation to withhold > sending packets before all outstanding packets to the original > primary destination address have been ack'ed. This has the side > effect of discouraging an app to change often. Granted, this > "simple" solution prevents a lot of "experimentation" on, for > example, load balancing and has obvious performance implication. But > I think at this point, there is no solid proposal in making using of > alternate paths other than retransmission. So I believe it is OK for > now. I think the performance implications would be serious. The failure detection and failover mechanism are already too conservative for some applications, and this would make them even more conservative. > I guess we should try to avoid the problems first before trying to > find a solution, timestamp in this case, to the problems. I'll try to consolidate the issues: 1) Increasing the RTT sampling frequency: Benefits are still controversial ([1] [2] [3]), could be achieved using either timestamps or implementation techniques (at the cost of additional state at the sender) 2) RTO inflation on alternate paths due to inability to time retransmissions [4]: Can be addressed by changed retransmission policy, specially timed heartbeats, timestamps, or other method to resolve the retransmission ambiguity ("retransmission bits") 3) Sequence number wrap-around within packet lifetime in high-speed networks [1]: This affects SCTP equally as TCP (both use 32-bit seq. number spaces), can be addressed by using timestamps (PAWS) 3) Incorrect congestion window growth due to crediting of SACKs to the wrong destination address or unawareness of failover [5]: Can be resolved by timestamps and/or Rhein algorithm (? not sure if these really cover the same problem space; Jana?) 4) Incorrect error counting due to crediting of SACKs to the wrong destination address: Can be addressed using timestamps or other means to resolve retransmission ambiguity (preferably for more than one retransmission) 5) Detection and/or prevention of spurious retransmissions: Detection possible using Eifel [6] (either with timestamps or new flags), Dup-TSNs [7], or F-RTO [8]. Prevention possible with Eifel and F-RTO (?) References: [1] RFC 1323 [2] RFC 3481 (and citations [45], [52], [54], [60] therein) [3] M. Allman, V. Paxson, "On Estimating End-to-End Network Path Properties", SIGCOMM'99 [4] Armando L. Caro Jr., Paul D. Amer, Randall R. Stewart, "Transport Layer Multihoming for Fault Tolerance in FCS Networks", MILCOM 2003 http://www.cis.udel.edu/~acaro/papers/2003.milcom.acaro.pdf [5] Janardhan R. Iyengar, Armando L. Caro Jr., Paul D. Amer, Gerard J. Heinz, Randall R. Stewart, "SCTP Congestion Window Overgrowth During Changeover", SCI 2002 http://www.cis.udel.edu/~acaro/papers/2002.sci.iyengar.pdf [6] RFC 3522 [7] draft-ietf-tsvwg-dsack-use-00.txt [8] draft-sarolahti-tsvwg-tcp-frto-04.txt _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sun Jul 20 22:57:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03948 for ; Sun, 20 Jul 2003 22:57:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eQrJ-0001cH-Od for tsvwg-archive@odin.ietf.org; Sun, 20 Jul 2003 22:57:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6L2v57G006176 for tsvwg-archive@odin.ietf.org; Sun, 20 Jul 2003 22:57:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eQrF-0001bV-7M; Sun, 20 Jul 2003 22: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 19eQql-0001Zt-CT for tsvwg@optimus.ietf.org; Sun, 20 Jul 2003 22:56:31 -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 WAA03923 for ; Sun, 20 Jul 2003 22:56:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eQqh-0006nq-00 for tsvwg@ietf.org; Sun, 20 Jul 2003 22:56:28 -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 19eQqX-0006nZ-00 for tsvwg@ietf.org; Sun, 20 Jul 2003 22:56:17 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6L2tnGJ028162; Mon, 21 Jul 2003 04:55:49 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 366C8K6T; Mon, 21 Jul 2003 04:56:16 +0200 Received: from res0010384da36.ericsson.com (rac163pc.edd.ericsson.se [164.48.123.163]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id EAA29136; Mon, 21 Jul 2003 04:55:45 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030718144118.027db008@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 18 Jul 2003 14:48:13 +0200 To: Mark Handley From: Reiner Ludwig Subject: Re: [Tsvwg] High-speed TCP Cc: tsvwg@ietf.org, Scott Bradner In-Reply-To: <9147.1058520749@eve.cs.ucl.ac.uk> 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 11:32 18.07.2003, Mark Handley wrote: >In followup to today's TSVWG meeting, here's some suggested >boilerplate text for the High-speed TCP Experimental RFC: > > The proposals in this document are experimental. We believe they > are safe for deployment in the current Internet, but they do not > represent a consensus that this is the best method for high-speed > congestion control. In particular, we note that alternative > experimental proposals are likely to be forthcoming, and it is not > well understood how the proposals in this document will interact > with such alternative proposals. I think this is good proposal, and I support it. Just one question: Could anybody, please, explain to me the difference between an "experimental RFC with a recommendation for deployment (with or without a boilerplate about warnings)" and a "proposed standard RFC"? Concrete example: Is the IETF recommending the deployment of the many TCP-related experimental RFCs (that don't have an explicit recommendation for deployment), or not? I tried to find the answer in RFC2026, but wasn't quite clear. Also, I hear that the standards track definition of RFC2026 might not be current IETF believe anymore. See also draft-dawkins-pstmt-twostage-00.txt ... ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Jul 21 03:18:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19818 for ; Mon, 21 Jul 2003 03:18:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eUwG-0001bC-Lr for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 03:18:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6L7ISK8006110 for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 03:18:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eUvp-0001Xm-C9; Mon, 21 Jul 2003 03:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eUvS-0001XM-Jh for tsvwg@optimus.ietf.org; Mon, 21 Jul 2003 03:17:38 -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 DAA19804 for ; Mon, 21 Jul 2003 03:17:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eUvQ-0000Wq-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 03:17:36 -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 19eUvF-0000Wi-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 03:17:25 -0400 Received: from esealnt611.al.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 h6L7H5Ii009313; Mon, 21 Jul 2003 09:17:05 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 3S6K2NNJ; Mon, 21 Jul 2003 09:20:11 +0200 Received: from res0010384da36.ericsson.com (dhcp4-221.eed.ericsson.se [164.48.140.221]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id JAA22648; Mon, 21 Jul 2003 09:17:04 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030721052341.00afb848@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 21 Jul 2003 06:11:25 +0200 To: Yogesh.Swami@nokia.com From: Reiner Ludwig Subject: RE: [Tsvwg] Slides for Eifel Response in Vienna IETF Cc: tsvwg@ietf.org In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CE016E8041@daebe004.americas .nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 18:28 18.07.2003, Yogesh.Swami@nokia.com wrote: >Now, Eifel Response incorporates the work of DCLOR, and makes it look as >if they are the ones who came with this scheme in the first place No. Not to confuse things: the "new" thing about the Eifel Response is that the stored congestion control state is decayed every RTO. A simpler version of that idea had already been part of the original proposal described in our CCR 30/1 paper. It was even included in draft-ietf-tsvwg-tcp-eifel-alg-00.txt. However, after some debate, we decided to take it out in the following revisions of the I-Ds. In further discussions, including those in which you were involved, we were again convinced to include this feature, but in a form similar to the CC state decay algorithm specified in RFC2861. Still, a typo slipped into the slides we showed at the last IETF. To be really compliant with RFC2861, the slides should have said: Every RTO (non-backed-off !!) counting from 1st Timeout: pipe_prev <- max (3/4 * pipe_prev, SMSS) instead of Every RTO (non-backed-off !!) counting from 1st Timeout: pipe_prev <- max (pipe_prev/2, SMSS) ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Jul 21 04:07:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20638 for ; Mon, 21 Jul 2003 04:07:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eVhh-0003Gw-86 for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 04:07:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6L87Tp4012579 for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 04:07:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eVhG-00038O-S8; Mon, 21 Jul 2003 04: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 19eVgR-00037b-39 for tsvwg@optimus.ietf.org; Mon, 21 Jul 2003 04:06: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 EAA20611 for ; Mon, 21 Jul 2003 04:06:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eVgO-0000p4-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 04:06:08 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 19eVgD-0000oz-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 04:05:57 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h6L85k404703; Mon, 21 Jul 2003 10:05:47 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h6L85jG15799; Mon, 21 Jul 2003 10:05:46 +0200 (MEST) Received: from mchh274e.demchh201e.icn.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id KAA20294; Mon, 21 Jul 2003 10:05:44 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Mon, 21 Jul 2003 10:05:09 +0200 Message-ID: From: Schruefer Wolfgang To: "'Armando L. Caro Jr.'" Cc: "'ladha@mail.eecis.udel.edu'" , "'Stephan Baucke'" , tsvwg@ietf.org Subject: RE: AW: [Tsvwg] SCTP Timestamps Date: Mon, 21 Jul 2003 10:05:06 +0200 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: , Armando, > > If it is considered that one bit is not to be enough, a > second bit may > > be used. I just wanted to express that I think for the problem of > > spurious retransmissions one retransmission bit seems for me to be > > enough. > > I disagree. Remember that if the peer SCTP endpoint has multiple > destination IP addresses, each retransmission may go on a > different path. > > So you are saying that it is enough to only be able to detect spurious > retransmissions the first time, which only helps the cwnd and > RTO of the > primary destination. If the first retransmission spuriously times out, > then we don't care according to you. We _may_ not care that > the cwnd gets > cut unnecessarily, because the cwnd generally stays pretty small on > alternate paths. But, we DO care that the RTO is left doubled, because > there isn't much traffic on an alternate path to bring that RTO down > again. So the next time a timeout occurs (whether spurious or > not) on that > alternate path, it will take that much longer. > > If you are not following this argument, _please_ read at > least section 3 > of our paper. It's a short read. The full paper is only 5 pages. > http://www.cis.udel.edu/~acaro/papers/2003.milcom.acaro.pdf I studied your paper with high interest, but my conclusion is that a mirrored Retransmission Flag would be a perfect solution for the scenario you describe in the paper. With the mirrored Retransmission Flag you _can_ recalculate RTO on the second path. You just can not do it for the third or further paths. And here I think that the third path (resp. the a RTO calculation for the third transmission) may not be so important to improve. Below I copied an extract from your paper, that could be witten similar for a Chunk Flag solution, but without the expense of additional overhead. >>>... Solution 3 introduces timestamps into each packet, thus allowing a sender to disambiguate original transmissions from retransmissions. By removing retransmission ambiguity, Karn's algorithm can be eliminated, and successful retransmissions on the alternate path can be used to update the RTT estimate and keep the RTO value more accurate. Solution 3 provides more samples for alternate destination(s) to update their RTT estimate at the expense of additional overhead in each packet...<<< Wolfgang _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Jul 21 10:38:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29493 for ; Mon, 21 Jul 2003 10:38:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebnH-0007Oz-CV for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 10:37:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LEbdUZ028450 for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 10:37:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebmf-0007CD-7D; Mon, 21 Jul 2003 10:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eblx-0007BH-DK for tsvwg@optimus.ietf.org; Mon, 21 Jul 2003 10:36: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 KAA29444 for ; Mon, 21 Jul 2003 10:36:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eblv-0003Mn-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 10:36:15 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19eblk-0003MY-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 10:36:04 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 0CD0B329B9; Mon, 21 Jul 2003 10:35:38 -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 18126329B3; Mon, 21 Jul 2003 10:35:37 -0400 (EDT) Date: Mon, 21 Jul 2003 10:35:37 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Schruefer Wolfgang Cc: "'ladha@mail.eecis.udel.edu'" , "'Stephan Baucke'" , Subject: RE: AW: [Tsvwg] SCTP Timestamps In-Reply-To: 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 Mon, 21 Jul 2003, Schruefer Wolfgang wrote: > > If you are not following this argument, _please_ read at > > least section 3 > > of our paper. It's a short read. The full paper is only 5 pages. > > http://www.cis.udel.edu/~acaro/papers/2003.milcom.acaro.pdf > > > I studied your paper with high interest, but my conclusion is that a > mirrored Retransmission Flag would be a perfect solution for the > scenario you describe in the paper. > > With the mirrored Retransmission Flag you _can_ recalculate RTO on the > second path. You just can not do it for the third or further paths. > And here I think that the third path (resp. the a RTO calculation for > the third transmission) may not be so important to improve. Well, your one bit solution only works if the sender follows the recommended mechanism for retransmissions. There hasn't been a consensus that retransmitting on an alternate path is always the best policy. In fact, I would argue that it isn't. I believe that for better performance without affecting failover performance, fast retransmits should go to the same destination and timeout retransmits should go to an alternate destination [1]. With such a retransmission policy, one bit would not be enough. Sure we could use 2 bits, but timestamps just seems cleaner. [1] http://www.cis.udel.edu/~acaro/papers/2003.icon.acaro.pdf ~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 Jul 21 13:25:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04570 for ; Mon, 21 Jul 2003 13:25:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eePf-0005lG-8t for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 13:25:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LHPRWh022140 for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 13:25:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eePF-0005hu-Lk; Mon, 21 Jul 2003 13: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 19eePB-0005hd-Tx for tsvwg@optimus.ietf.org; Mon, 21 Jul 2003 13:24: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 NAA04546 for ; Mon, 21 Jul 2003 13:24:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eeP0-0004qH-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 13:24:46 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 19eeOp-0004qE-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 13:24:35 -0400 Received: from melkki.cs.Helsinki.FI (melkki.cs.helsinki.fi [::ffff:128.214.48.122]) (IDENT: root, AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 21 Jul 2003 20:24:14 +0300 Received: from melkki.cs.Helsinki.FI (localhost [127.0.0.1]) by melkki.cs.Helsinki.FI (8.12.8p1/8.12.8) with ESMTP id h6LHOD3t000958; Mon, 21 Jul 2003 20:24:13 +0300 Received: from localhost (sarolaht@localhost) by melkki.cs.Helsinki.FI (8.12.8p1/8.12.8/Submit) with ESMTP id h6LHOCsS000954; Mon, 21 Jul 2003 20:24:13 +0300 X-Authentication-Warning: melkki.cs.Helsinki.FI: sarolaht owned process doing -bs Date: Mon, 21 Jul 2003 20:24:12 +0300 (EEST) From: Pasi Sarolahti To: ladha@mail.eecis.udel.edu cc: "Armando L. Caro Jr." , tsvwg@ietf.org In-Reply-To: <20863.212.117.81.29.1058444875.squirrel@webmail.eecis.udel.edu> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) 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 Sourabh, Sorry for the delayed response. I have been behind a poor network access, so my mail reactions are a bit slow currently :-) For the same reason I may not have read all the other mails in this thread. On Thu, 17 Jul 2003 ladha@mail.eecis.udel.edu wrote: > I had read the FRTO document some time back. On the SCTP front I was > wondering if the following are applicable: First, I have to be honest, we have mainly considered F-RTO as a TCP algorithm and it was only recently when we started thinking that it should apply on SCTP also. It seems that the special features of SCTP may need to be discussed a bit more than the draft currently does. Thanks for bringing up these good points, that definitely need to be addressed. Nevertheless, I'm still optimistic that the principle of F-RTO should work with SCTP, too: after an RTO, if an acknowledgement arrives for a data chunk (or segment) that was sent before the RTO, the RTO can be declared spurious. My takes on the following (Remember, I don't have much SCTP knowledge): > * Multihoming: If the delay spike on the primary path is greater than (1 > RTO(primary) + 2 RTT(alternate)), I would believe that FRTO will not be > able to detect a timeout spurious. (complying with the current spec that > retransmissions SHOULD go to alternate destination) So, the RTO retransmission goes to alternate path and ACK for the retransmission comes back from the alternate path. Then, the F-RTO sender transmits one or two chunks that were not transmitted earlier. These segments should go to primary destination, since they are not retransmissions, right? If they do, then everything goes as intended, since the segments will be queued behind other segments that were sent to the primary address. In case of spurious timeout, next ACK or SACK should acknowledge something that was not retransmitted. Maybe I missed something here? How would this go with timestamps? ACK (and tsecr) of the retransmission will arrive to the sender from the alternate destination before the ACK of the original segment, right? So Eifel would not detect a spurious RTO? > * Chunk Bundling: FRTO assumes that on a timeout the sender will > retransmit only one segment("I think chunk will be appropriate in SCTP > terminology"). This may not be true in SCTP. If the association is > multihomed and the PMTU's on the primary and alternate path differ by a > factor of two or more then, then I think the sender may be able to > retransmit more than one unacknowledged chunk on a timeout (bundled in a > single packet). This can also be true if the app is writing small chunks > such that on a timeout more than one of such chunks can be bundled in a > single packet and retransmitted. I remember having noticed a couple of > side effects of this which could lead FRTO to declare the timeout spurious > while it was not. According to the principle I gave above, only acknowledgements of data chunks (or segment) that were not transmitted after RTO should be used for declaring the RTO spurious. Chunk bundling is something I did not consider earlier, so probably this is something that needs to be explicitly stated when applying the algorithm for SCTP. I think we could add some kind of "SCTP considerations" section that would address these kind of issues, plus probably reword the algorithm description to be more clear on these. I would be interested to hear about the side effects you mention above in more detail. False positives are something we definitely want to avoid. > A question I have is: > Section 3- step 3(b): When you refer to an ACK which acknowledges data > (above spurious threshhold or previously unacknowledged), do you refer to > acknowledging {via cum-ack point} or {via SACK blocks} or {either of these > two}? either of the two. This is worth clarifying in the algorithm. Thanks for pointing it out. - Pasi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Jul 21 14:50:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06756 for ; Mon, 21 Jul 2003 14:50:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efjt-0000wd-0P for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 14:50:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LIoOke003625 for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 14:50:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efjV-0000sU-BC; Mon, 21 Jul 2003 14:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efiv-0000rl-IL for tsvwg@optimus.ietf.org; Mon, 21 Jul 2003 14:49: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 OAA06743 for ; Mon, 21 Jul 2003 14:49:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efis-0005Oc-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 14:49:22 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19efid-0005OU-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 14:49:07 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h6LImVe3081560; Mon, 21 Jul 2003 11:48:31 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200307211848.h6LImVe3081560@cougar.icir.org> To: Reiner Ludwig cc: tsvwg@ietf.org, Scott Bradner From: Sally Floyd Subject: Re: [Tsvwg] High-speed TCP Date: Mon, 21 Jul 2003 11:48:31 -0700 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: , >Just one question: Could anybody, please, explain to me the difference >between an "experimental RFC with a recommendation for deployment (with or >without a boilerplate about warnings)" and a "proposed standard RFC"? Actually, my request is not for High-speed TCP to be considered as an experimental RFC with a recommendation for deployment, but as an experimental RFC that is judged as safe for deployment, that is, that someone could deploy (in their own computer, or in their widely-distributed commercial TCP distribution) *if they wanted to*. My own view would be that the likely audience for such high-congestion-window variants of TCP is small, at the moment, and that for most TCP users it wouldn't make much different one way or another whether they used Standard or HighSpeed TCP. This would have the same formal status of NewReno TCP, RFC 2582, April 1999, which is also Experimental. At the time, in 1999, my memory is that people wanted more operational experience with NewReno before considering it for Proposed Standard (and at the time, I thought that there might also be other proposals for NewReno-type variants of TCP, for those cases where the other end was not SACK-capable, that would also be Experimental). It seems plausible to me that some major changes to TCP pass thought a period of Experimental before moving on the Proposed Standard, giving the role of TCP in the Internet. - Sally http://www.icir.org/floyd/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Jul 21 15:18:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08356 for ; Mon, 21 Jul 2003 15:18:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19egAy-0001x0-Tt for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 15:18:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LJIO3X007483 for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 15:18:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19egAb-0001qX-V0; Mon, 21 Jul 2003 15:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19egAI-0001pr-2p for tsvwg@optimus.ietf.org; Mon, 21 Jul 2003 15:17: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 PAA08311 for ; Mon, 21 Jul 2003 15:17:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19egAG-0005d7-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 15:17:40 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19egA1-0005cz-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 15:17:25 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h6LJHDe3081909; Mon, 21 Jul 2003 12:17:13 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200307211917.h6LJHDe3081909@cougar.icir.org> To: Mark Handley cc: tsvwg@ietf.org From: Sally Floyd Subject: Re: [Tsvwg] High-speed TCP Date: Mon, 21 Jul 2003 12:17:13 -0700 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: , >In followup to today's TSVWG meeting, here's some suggested >boilerplate text for the High-speed TCP Experimental RFC: > > The proposals in this document are experimental. We believe they > are safe for deployment in the current Internet, but they do not > represent a consensus that this is the best method for high-speed > congestion control. In particular, we note that alternative > experimental proposals are likely to be forthcoming, and it is not > well understood how the proposals in this document will interact > with such alternative proposals. That sounds good to me, and I will include it in a revised version that I submit later this week. The only other thing in the revision will be a paragraph later in the document saying that I don't expect HighSpeed TCP to interact any more poorly with alternative experimental proposals that would the N parallel TCP connections commonly used today in the absence of HighSpeed TCP. That is, I don't believe that a deployment of HighSpeed TCP would present any block to the later deployment of Scalable TCP, FAST TCP, XCP, or any of the other alternative experimental proposals. - Sally http://www.icir.org/floyd/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Jul 21 15:57:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09252 for ; Mon, 21 Jul 2003 15:57:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19egmk-0003P0-0c for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 15:57:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LJvPik013067 for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 15:57:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19egmL-0003Kt-Us; Mon, 21 Jul 2003 15: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 19egm8-0003Kb-OI for tsvwg@optimus.ietf.org; Mon, 21 Jul 2003 15:56:48 -0400 Received: from thebe.your-site.com (thebe.your-site.com [140.186.45.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09202 for ; Mon, 21 Jul 2003 15:56:44 -0400 (EDT) Received: from asomi.com (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id E6B512457F4; Mon, 21 Jul 2003 15:53:00 -0400 (EDT) Date: Mon, 21 Jul 2003 14:52:52 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Caitlin Bestler To: "Armando L. Caro Jr." , Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Meaning of path failure (was re SCTP Timestamps) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Monday, July 21, 2003, at 09:35 AM, Armando L. Caro Jr. wrote: >> > > Well, your one bit solution only works if the sender follows the > recommended mechanism for retransmissions. There hasn't been a > consensus > that retransmitting on an alternate path is always the best policy. In > fact, I would argue that it isn't. I believe that for better > performance > without affecting failover performance, fast retransmits should go to > the > same destination and timeout retransmits should go to an alternate > destination [1]. With such a retransmission policy, one bit would > not be enough. Sure we could use 2 bits, but timestamps just seems > cleaner. > > [1] http://www.cis.udel.edu/~acaro/papers/2003.icon.acaro.pdf > > ~armando > In the paper cited, you fault the default SCTP behavior for assuming "that loss indicates either that the destination address used is unreachable, or the destination's network path is congested." The implication is that the end-to-end algorithm is "giving up too quickly" on a path, and thereby degrading performance. As that I have seen this objection most often raised when the final hop is a mobile and/or wireless link, I am tempted to turn that question around. Isn't the real problem that the last hop is giving up on L2 delivery too quickly, and creating an L3/end-to-end problem for something that should have been handled locally? Basically, is each downstream frequency *really* a path? Or should the collective set of frequencies be viewed as a single L3 path over which there may be L2 retries? I designed a two-way CATV system to carry IP traffic through set-top decoders while I was at Zenith Electronics. Whenever the set-top needed to change frequency it would be deaf to the headend for a short period. Realizing that dropping packets during such a frequency shift would lead to very poor end-to-end performance, we simply scheduled the packet to be L2-delivered on a frequency as soon as it was known, or on all frequencies if the receiver's status was not known. We certainly do not want to begin an L2 design debate here, but I think it is a valid question -- is it a valid assumption that L2 delivery should be dealing with truly transitory problems and therefore packet loss really should be taken to as an indication that the destination address used is unreachable or the destination's network path is congested? Caitlin Bestler - cait@asomi.com - http://asomi.com/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Jul 21 17:05:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10867 for ; Mon, 21 Jul 2003 17:05:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ehqe-0006YE-ER for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 17:05:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LL5W2W025178 for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 17:05:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ehq8-0006QY-GD; Mon, 21 Jul 2003 17:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ehpF-0006Pj-9I for tsvwg@optimus.ietf.org; Mon, 21 Jul 2003 17:04:05 -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 RAA10812 for ; Mon, 21 Jul 2003 17:04:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ehpD-0006MN-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 17:04:03 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19ehox-0006MB-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 17:03: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 h6LL3be3083231; Mon, 21 Jul 2003 14:03:37 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200307212103.h6LL3be3083231@cougar.icir.org> To: mankin@psg.com, jon.peterson@neustar.biz cc: tsvwg@ietf.org From: Sally Floyd Date: Mon, 21 Jul 2003 14:03:37 -0700 Subject: [Tsvwg] draft-ietf-tsvwg-highspeed-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: , Allison and Jon - I have submitted draft-ietf-tsvwg-highspeed-00.txt and draft-ietf-tsvwg-slowstart-00.txt to the internet-drafts editor, and there are local copies on the HSTCP web page at: http://www.icir.org/floyd/hstcp.html i.e., http://www.icir.org/floyd/papers/draft-ietf-tsvwg-highspeed-00.txt http://www.icir.org/floyd/papers/draft-ietf-tsvwg-slowstart-00.txt I think these are ready for Working Group Last Call to be considered for Experimental status. - Sally -------------------------------------------------------------------- The diffs for draft-ietf-tsvwg-highspeed-00.txt are below, just FYI: -------------------------------------------------------------------- ... 32c32 < .ds *FN draft-floyd-tcp-highspeed-03 --- > .ds *FN draft-ietf-tsvwg-highspeed-00 ... 125a126,139 > Status of this Memo > .NORMRS > .LP > > The proposals in this document are experimental. We believe they > are safe for deployment in the current Internet, but they do not > represent a consensus that this is the best method for high-speed > congestion control. In particular, we note that alternative > experimental proposals are likely to be forthcoming, and it is not > well understood how the proposals in this document will interact > with such alternative proposals. > > .NORMRE > .SH 176a191,198 > Changes from draft-floyd-tcp-highspeed-03.txt: > > Added the section on "Status of this Memo". > > Added a paragraph to the end of the section on "Deployment issues > of HighSpeed TCP" about possible interactions between HighSpeed TCP > and other alternative experimental proposals. > 1204a1227,1235 > We do not believe that the deployment of HighSpeed TCP would > serve as a block to the possible deployment of alternate experimental > protocols for high-speed congestion control, such as > Scalable TCP, XCP [KHR02], or FAST TCP [JWL03]. > In particular, we don't expect HighSpeed TCP to interact > any more poorly with alternative experimental proposals that would > the N parallel TCP connections commonly used today in the absence > of HighSpeed TCP. > 1518a1550,1554 > [JWL03] Cheng Jin, David X. Wei and Steven H. Low, > FAST TCP for High-speed Long-distance Networks, > internet-draft > draft-jwl-tcp-fast-01.txt, work-in-progress, June 2003. > 1521a1558,1561 > > [KHR02] Dina Katabi, Mark Handley, and Charlie Rohrs, > Congestion Control for High Bandwidth-Delay Product Networks, > SIGCOMM 2002. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Jul 21 19:37:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14954 for ; Mon, 21 Jul 2003 19:37:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ekDe-0003bo-97 for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 19:37:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LNbQSq013868 for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 19:37:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ekDE-0003QD-Tw; Mon, 21 Jul 2003 19:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ekDA-0003Ph-Q7 for tsvwg@optimus.ietf.org; Mon, 21 Jul 2003 19:36:56 -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 TAA14946 for ; Mon, 21 Jul 2003 19:36:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ekD9-00075x-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 19:36:55 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19ekCy-00075Y-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 19:36:44 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 8160E329BD; Mon, 21 Jul 2003 19:36:05 -0400 (EDT) Received: from louie.udel.edu (louie.udel.edu [128.4.40.12]) by mail.eecis.udel.edu (Postfix) with ESMTP id BB68D329C5; Mon, 21 Jul 2003 19:36:04 -0400 (EDT) Date: Mon, 21 Jul 2003 19:36:04 -0400 (EDT) From: Sourabh Ladha X-X-Sender: To: Pasi Sarolahti Cc: "Armando L. Caro Jr." , Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) In-Reply-To: Message-ID: X-Spam-Status: No, hits=-3.4 required=6.0 tests=DEPT_RCVD,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03, USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hi Pasi, Before sending a reply for FRTO-SCTP, I would like to get a bit of clarification for Step 2 of the SACK-enhanced version of FRTO (this applies for TCP as well): " 2) The first acknowledgement after RTO arrives at the sender. a) if the cumulative ACK acknowledges all segments up to send_high stored in algorithm step 1, the TCP sender SHOULD revert to the conventional RTO recovery and it MUST set congestion window to no more than 2 * MSS. The sender does not enter step 3 of this algorithm. b) otherwise, the TCP sender MAY transmit two new segments. If the TCP sender does not transmit any previously unsent data, it MUST NOT enter step 3 of this algorithm, but revert to the conventional RTO recovery." So I believe that even on the reciept of a dup-ack (with a SACK block) an FRTO sender follows step 2(b)? If so, In the event of loss (xxlost) coupled with a delay spike (/\): A B ----------TSN101------>xxlost ----------TSN102--------------/\---> ----------TSN103--------------/\---> . . timeout ----------TSN101-------------------> <-----SACK101 (sack block: 102)---(sack generated when TSN 102 reached B) FRTO sends out TSN104 and TSN105 and enters step 3. <-----SACK101 (sack block: 103)---(sack generated when TSN 103 reached B) From your clarification of Step 3(b) below, FRTO will declare the timeout spurious on the receipt of this SACK? A false positive? -Sourabh > > Section 3- step 3(b): When you refer to an ACK which acknowledges data > > (above spurious threshhold or previously unacknowledged), do you refer to > > acknowledging {via cum-ack point} or {via SACK blocks} or {either of these > > two}? > > either of the two. This is worth clarifying in the algorithm. Thanks for > pointing it out. > > - Pasi > > > > _______________________________________________ > 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 Mon Jul 21 19:48:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15224 for ; Mon, 21 Jul 2003 19:48:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ekOH-00046r-So for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 19:48:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LNmP7d015790 for tsvwg-archive@odin.ietf.org; Mon, 21 Jul 2003 19:48:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ekNt-0003yV-KO; Mon, 21 Jul 2003 19: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 19ekNj-0003y0-13 for tsvwg@optimus.ietf.org; Mon, 21 Jul 2003 19:47:51 -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 TAA15201 for ; Mon, 21 Jul 2003 19:47:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ekNh-0007Cz-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 19:47:49 -0400 Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx with esmtp (Exim 4.12) id 19ekNR-0007CV-00 for tsvwg@ietf.org; Mon, 21 Jul 2003 19:47:38 -0400 Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250](untrusted sender)) by comcast.net (rwcrmhc13) with SMTP id <2003072123464301500dob84e> (Authid: sdawkins@comcast.net); Mon, 21 Jul 2003 23:46:43 +0000 Message-ID: <0d6801c34fe2$56af0620$0200a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: Cc: "Charles E. Perkins" References: <5.2.0.9.0.20030718144118.027db008@mailhost.eed.ericsson.se> Subject: Re: [Tsvwg] High-speed TCP Date: Mon, 21 Jul 2003 18:46:42 -0500 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 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 Dear Reiner, I'm honored that someone has tripped over our proposal, but it's just a proposal! I can say that there's some interest in looking at the standards levels - Scott Bradner is also looking at this - but 2026 is 2026 for now... ... and feedback is always welcome ... Spencer ----- Original Message ----- From: "Reiner Ludwig" To: "Mark Handley" Cc: ; "Scott Bradner" Sent: Friday, July 18, 2003 7:48 AM Subject: Re: [Tsvwg] High-speed TCP > At 11:32 18.07.2003, Mark Handley wrote: > > >In followup to today's TSVWG meeting, here's some suggested > >boilerplate text for the High-speed TCP Experimental RFC: > > > > The proposals in this document are experimental. We believe they > > are safe for deployment in the current Internet, but they do not > > represent a consensus that this is the best method for high-speed > > congestion control. In particular, we note that alternative > > experimental proposals are likely to be forthcoming, and it is not > > well understood how the proposals in this document will interact > > with such alternative proposals. > > I think this is good proposal, and I support it. > > Just one question: Could anybody, please, explain to me the difference > between an "experimental RFC with a recommendation for deployment (with or > without a boilerplate about warnings)" and a "proposed standard RFC"? > > Concrete example: Is the IETF recommending the deployment of the many > TCP-related experimental RFCs (that don't have an explicit recommendation > for deployment), or not? > > I tried to find the answer in RFC2026, but wasn't quite clear. Also, I hear > that the standards track definition of RFC2026 might not be current IETF > believe anymore. See also draft-dawkins-pstmt-twostage-00.txt ... > > ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jul 22 06:55:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09190 for ; Tue, 22 Jul 2003 06:55:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eunt-0001BU-NX for tsvwg-archive@odin.ietf.org; Tue, 22 Jul 2003 06:55:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MAtX8e004548 for tsvwg-archive@odin.ietf.org; Tue, 22 Jul 2003 06:55:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eunN-00013g-K9; Tue, 22 Jul 2003 06:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eunJ-00013E-1M for tsvwg@optimus.ietf.org; Tue, 22 Jul 2003 06:54: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 GAA09160 for ; Tue, 22 Jul 2003 06:54:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eunE-0003Vf-00 for tsvwg@ietf.org; Tue, 22 Jul 2003 06:54:52 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 19eun3-0003VN-00 for tsvwg@ietf.org; Tue, 22 Jul 2003 06:54:41 -0400 Received: from melkki.cs.Helsinki.FI (melkki.cs.helsinki.fi [::ffff:128.214.48.122]) (IDENT: root, AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 22 Jul 2003 13:53:42 +0300 Received: from melkki.cs.Helsinki.FI (localhost [127.0.0.1]) by melkki.cs.Helsinki.FI (8.12.8p1/8.12.8) with ESMTP id h6MArg3t005468; Tue, 22 Jul 2003 13:53:42 +0300 Received: from localhost (sarolaht@localhost) by melkki.cs.Helsinki.FI (8.12.8p1/8.12.8/Submit) with ESMTP id h6MArfF1005464; Tue, 22 Jul 2003 13:53:41 +0300 X-Authentication-Warning: melkki.cs.Helsinki.FI: sarolaht owned process doing -bs Date: Tue, 22 Jul 2003 13:53:41 +0300 (EEST) From: Pasi Sarolahti To: Sourabh Ladha cc: "Armando L. Caro Jr." , tsvwg@ietf.org Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) In-Reply-To: Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, On Mon, 21 Jul 2003, Sourabh Ladha wrote: [...] > So I believe that even on the reciept of a dup-ack (with a SACK block) an > FRTO sender follows step 2(b)? Yes, and it appears to be wrong, as you presented. The basic algorithm would not do this and it seems that the SACK-based variant should also wait for acknowledgement for the RTO-retransmitted segment before proceeding. > If so, In the event of loss (xxlost) coupled with a delay spike (/\): > > A B > ----------TSN101------>xxlost > ----------TSN102--------------/\---> > ----------TSN103--------------/\---> > . > . > timeout > ----------TSN101-------------------> > <-----SACK101 (sack block: 102)---(sack generated when TSN 102 reached B) > FRTO sends out TSN104 and TSN105 and enters step 3. > <-----SACK101 (sack block: 103)---(sack generated when TSN 103 reached B) > > From your clarification of Step 3(b) below, FRTO will declare the timeout > spurious on the receipt of this SACK? > > A false positive? Oops... You are right. It seems to be essential to get acknowledgement for RTO-retransmitted segment before going to step 3. The question is, should the sender wait (in step 2) until the ack arrives (or until another RTO occurs), or should it cancel F-RTO immediately on dupack. The basic algorithm in Section 2 does the latter, but I am wondering if the former is safe enough alternative. It works better if reordering occurs at the same time. Ok, now if the connection is multihomed and delay spike is longer than RTO (primary) + 2 RTT (alternative) there could be problems with this scenario. I need to think about this more, but it seems that in multihomed cases the use of F-RTO needs to limited a bit. It detects a delay spike, but it may not always detect if the first segment is lost, if the retransmission goes to different destination than the original, and the path characteristics are as shown above. However, combining with duplicate TSNs should work: F-RTO can be used to avoid unnecessary retransmissions and draft-dsack-use can be used for congestion window undoing. ..or you could use timestamps, once specified. But back to the earlier mail, wouldn't Eifel have some kind of problems in detecting a real spurious RTO if retransmissions go to alternative path such as shown above? Thanks, - Pasi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jul 22 07:04:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09331 for ; Tue, 22 Jul 2003 07:04:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19euwR-0001U4-AE for tsvwg-archive@odin.ietf.org; Tue, 22 Jul 2003 07:04:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MB4N0b005678 for tsvwg-archive@odin.ietf.org; Tue, 22 Jul 2003 07:04:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19euw5-0001OS-5G; Tue, 22 Jul 2003 07: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 19euw0-0001OD-GI for tsvwg@optimus.ietf.org; Tue, 22 Jul 2003 07:03:56 -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 HAA09320 for ; Tue, 22 Jul 2003 07:03:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19euvw-0003YM-00 for tsvwg@ietf.org; Tue, 22 Jul 2003 07:03:52 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 19euvl-0003YJ-00 for tsvwg@ietf.org; Tue, 22 Jul 2003 07:03:41 -0400 Received: from melkki.cs.Helsinki.FI (melkki.cs.helsinki.fi [::ffff:128.214.48.122]) (IDENT: root, AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 22 Jul 2003 14:03:37 +0300 Received: from melkki.cs.Helsinki.FI (localhost [127.0.0.1]) by melkki.cs.Helsinki.FI (8.12.8p1/8.12.8) with ESMTP id h6MB3b3t005637; Tue, 22 Jul 2003 14:03:37 +0300 Received: from localhost (sarolaht@localhost) by melkki.cs.Helsinki.FI (8.12.8p1/8.12.8/Submit) with ESMTP id h6MB3bbf005633; Tue, 22 Jul 2003 14:03:37 +0300 X-Authentication-Warning: melkki.cs.Helsinki.FI: sarolaht owned process doing -bs Date: Tue, 22 Jul 2003 14:03:35 +0300 (EEST) From: Pasi Sarolahti To: Stephan Baucke cc: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: <3F1A5DDE.1060607@ericsson.com> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Sun, 20 Jul 2003, Stephan Baucke wrote: > > How about Pasi's F-RTO? I have read Sourabh's questions about F-RTO. > > But I think F-RTO can be modified, possible making use of duplicate > > TSN, for SCTP to address those questions. > > I have not really looked at F-RTO in depth, but seem to remember that it > only covers part of the cases that e.g. Eifel covers (perhaps Pasi can > comment on that?) Yep. F-RTO needs to send in advance at least some bits of unsent data after the RTO retransmission, which is impossible if 1) sender/receiver window limits the transmission or 2) there are no unsent data to transmit. [For case 2) I would argue that detecting spurious RTO is not highly important, because at least the user won't see the difference.] These problems are identified in the draft, and there we listed the known tricks for overcoming them. Some of the solutions may be controversial (like sending from the tail of the retransmission queue), so we have left applying them for implementator's decision and separated them from the algorithm description. And after the examples shown by Sourabh, I believe detecting spurious RTOs with multihoming brings interesting questions for both F-RTO and Eifel that I need to study more thoroughly. - Pasi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jul 22 07:18:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09647 for ; Tue, 22 Jul 2003 07:18:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev9z-0002K6-Oo for tsvwg-archive@odin.ietf.org; Tue, 22 Jul 2003 07:18:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MBINue008909 for tsvwg-archive@odin.ietf.org; Tue, 22 Jul 2003 07:18:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev9d-0002Bh-IP; Tue, 22 Jul 2003 07:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev8s-00029S-KK for tsvwg@optimus.ietf.org; Tue, 22 Jul 2003 07:17:14 -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 HAA09637 for ; Tue, 22 Jul 2003 07:17:12 -0400 (EDT) From: ladha@mail.eecis.udel.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ev8s-0003dE-00 for tsvwg@ietf.org; Tue, 22 Jul 2003 07:17:14 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19ev8h-0003ck-00 for tsvwg@ietf.org; Tue, 22 Jul 2003 07:17:03 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id C32FE329D5; Tue, 22 Jul 2003 07:15:04 -0400 (EDT) Received: from webmail.eecis.udel.edu (dbacks.acad.ece.udel.edu [128.4.60.14]) by mail.eecis.udel.edu (Postfix) with SMTP id 09C35329D4; Tue, 22 Jul 2003 07:15:04 -0400 (EDT) Received: from 212.117.81.29 (SquirrelMail authenticated user ladha) by webmail.eecis.udel.edu with HTTP; Tue, 22 Jul 2003 07:15:04 -0400 (EDT) Message-ID: <25271.212.117.81.29.1058872504.squirrel@webmail.eecis.udel.edu> In-Reply-To: References: Date: Tue, 22 Jul 2003 07:15:04 -0400 (EDT) Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) To: "Pasi Sarolahti" Cc: "Sourabh Ladha" , "Armando L. Caro Jr." , tsvwg@ietf.org User-Agent: SquirrelMail/1.4.0 X-Priority: 3 Importance: Normal X-Spam-Status: No, hits=-1.5 required=6.0 tests=DEPT_RCVD,IN_REP_TO,NO_REAL_NAME,PRIORITY_NO_NAME, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT 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="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 Pasi, > ..or you could use timestamps, once specified. But back to the earlier > mail, wouldn't Eifel have some kind of problems in detecting a real > spurious RTO if retransmissions go to alternative path such as shown > above? You are right. I did stumble across this issue. Eifel "for TCP" if ported "as it is" to SCTP did present these cases where in a multihomed scenario (with such a setting as described in the earlier mail), Eifel did not detect a spurious timeout when it was. But the vice-versa was not true, i.e Eifel did not detect a loss as a spurious timeout. (Note that the case is less pronounced in the event of a spurious fast-retransmit). However as you also pointed out, integrating with the dup-tsn notifiation adds some robustness. Thanks, Sourabh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jul 22 08:19:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10868 for ; Tue, 22 Jul 2003 08:19:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ew6O-0004Nu-HK for tsvwg-archive@odin.ietf.org; Tue, 22 Jul 2003 08:18:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MCIi3F016832 for tsvwg-archive@odin.ietf.org; Tue, 22 Jul 2003 08:18:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ew2n-0004JU-4m; Tue, 22 Jul 2003 08:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19evyO-0004EL-W9 for tsvwg@optimus.ietf.org; Tue, 22 Jul 2003 08:10: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 IAA10733 for ; Tue, 22 Jul 2003 08:10:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19evyO-0003zJ-00 for tsvwg@ietf.org; Tue, 22 Jul 2003 08:10:28 -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 19evyD-0003yb-00 for tsvwg@ietf.org; Tue, 22 Jul 2003 08:10:17 -0400 Received: from esealnt610.al.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 h6MC9jG6018447 for ; Tue, 22 Jul 2003 14:09:45 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 366DH6MY; Tue, 22 Jul 2003 14:10:17 +0200 Received: from res0010384da36.ericsson.com (dhcp5-109.eed.ericsson.se [164.48.135.109]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id OAA15224 for ; Tue, 22 Jul 2003 14:09:44 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030722134912.04affff8@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 22 Jul 2003 14:10:26 +0200 To: tsvwg@ietf.org From: Reiner Ludwig Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Tsvwg] HS-TCP/FAST-TCP: Kind of Packet Loss? 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: , As I understand, the motivation given for HS-TCP and FAST-TCP is that since the required cwnd to fill the pipe is so high, it would require unrealistically low rates of non-congestion-related packet losses. Now, I wonder whether anybody has studied what kind of non-congestion-related packet losses we see in the target regime of 10 Gbit/s and beyond ... Do such optical fiber links still do CRC, i.e., are the non-congestion-related packet losses mostly due to packets being discarded at the link layer? Or are maybe many of such non-congestion-related packet losses due to TCP checksum errors, and thus the TCP receiver silently discarding the packet? If it was the latter, one solution could be the definition of an explicit TCP NACK that the TCP sender could use to suppress the reduction of cwnd. Clearly, this would have some security considerations, but I guess those could be fixed, e.g., with a nonce. Maybe this would be a good reason to disbale CRC on such optical fiber links. Did I miss something? ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jul 22 08:50:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11656 for ; Tue, 22 Jul 2003 08:50:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewb3-0005he-Aa for tsvwg-archive@odin.ietf.org; Tue, 22 Jul 2003 08:50:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MCoPL6021916 for tsvwg-archive@odin.ietf.org; Tue, 22 Jul 2003 08:50:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewaf-0005Zq-Rq; Tue, 22 Jul 2003 08:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewZv-0005Yt-KI for tsvwg@optimus.ietf.org; Tue, 22 Jul 2003 08:49:15 -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 IAA11507 for ; Tue, 22 Jul 2003 08:49:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ewZu-0004Ed-00 for tsvwg@ietf.org; Tue, 22 Jul 2003 08:49:14 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 19ewZj-0004Ea-00 for tsvwg@ietf.org; Tue, 22 Jul 2003 08:49:03 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h6MCmqb15721; Tue, 22 Jul 2003 14:48:52 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h6MCmp826562; Tue, 22 Jul 2003 14:48:51 +0200 (MEST) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id OAA10648; Tue, 22 Jul 2003 14:48:51 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Tue, 22 Jul 2003 14:48:15 +0200 Message-ID: From: Schruefer Wolfgang To: "'Armando L. Caro Jr.'" Cc: "'ladha@mail.eecis.udel.edu'" , "'Stephan Baucke'" , tsvwg@ietf.org Subject: RE: AW: [Tsvwg] SCTP Timestamps Date: Tue, 22 Jul 2003 14:48:14 +0200 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: , Armando, > On Mon, 21 Jul 2003, Armando L. Caro Jr. wrote: > > > > If you are not following this argument, _please_ read at > > > least section 3 > > > of our paper. It's a short read. The full paper is only 5 pages. > > > http://www.cis.udel.edu/~acaro/papers/2003.milcom.acaro.pdf > > > > > > I studied your paper with high interest, but my conclusion is that a > > mirrored Retransmission Flag would be a perfect solution for the > > scenario you describe in the paper. > > > > With the mirrored Retransmission Flag you _can_ recalculate > RTO on the > > second path. You just can not do it for the third or further paths. > > And here I think that the third path (resp. the a RTO > calculation for > > the third transmission) may not be so important to improve. > > Well, your one bit solution only works if the sender follows the > recommended mechanism for retransmissions. There hasn't been > a consensus > that retransmitting on an alternate path is always the best policy. In > fact, I would argue that it isn't. I believe that for better > performance > without affecting failover performance, fast retransmits > should go to the > same destination and timeout retransmits should go to an alternate > destination [1]. With such a retransmission policy, one bit would > not be enough. Sure we could use 2 bits, but timestamps just seems > cleaner. > > [1] http://www.cis.udel.edu/~acaro/papers/2003.icon.acaro.pdf I disagree that the one bit solution works dependent on the mechanism used for retransmission. The sender is free how to set the Bit. If you like to perform a fast retransmit on the primary path and you want accurate RTT calculation for the alternate path, just set the Bit for the transmission on the alternate path. And the Bit would again solve your problem. Please see the Mirrored Chunk Flag solution as a cheap tool for any sender to enhance the transmission for its special purpose. A timestamp solution seems over-engineered to me and I suspect it is used by TCP just because no space for a Header Flag was available (????). E.g. I can not imagine that a 12 Byte timestamp chunk would be favoured for the usage in Telephone Signaling Systems, when the average packet length is probably only 50 Bytes. Wolfgang _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jul 22 10:32:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15584 for ; Tue, 22 Jul 2003 10:32:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyBp-0000sM-Ij for tsvwg-archive@odin.ietf.org; Tue, 22 Jul 2003 10:32:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MEWTOL003354 for tsvwg-archive@odin.ietf.org; Tue, 22 Jul 2003 10:32:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyBO-0000pH-BP; Tue, 22 Jul 2003 10:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyBE-0000mT-Vp for tsvwg@optimus.ietf.org; Tue, 22 Jul 2003 10:31:53 -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 KAA15531 for ; Tue, 22 Jul 2003 10:31:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eyBC-00051F-00 for tsvwg@ietf.org; Tue, 22 Jul 2003 10:31:50 -0400 Received: from dexter.psc.edu ([128.182.61.232]) by ietf-mx with esmtp (Exim 4.12) id 19eyB1-000500-00 for tsvwg@ietf.org; Tue, 22 Jul 2003 10:31:39 -0400 Received: from dexter.psc.edu (localhost.psc.edu [127.0.0.1]) by dexter.psc.edu (8.12.9/8.12.5) with ESMTP id h6MEUXxJ014129; Tue, 22 Jul 2003 10:30:33 -0400 (EDT) Received: from localhost (jheffner@localhost) by dexter.psc.edu (8.12.9/8.12.8/Submit) with ESMTP id h6MEUXSA014126; Tue, 22 Jul 2003 10:30:33 -0400 (EDT) X-Authentication-Warning: dexter.psc.edu: jheffner owned process doing -bs Date: Tue, 22 Jul 2003 10:30:33 -0400 (EDT) From: John Heffner To: Reiner Ludwig cc: Subject: Re: [Tsvwg] HS-TCP/FAST-TCP: Kind of Packet Loss? In-Reply-To: <5.2.0.9.0.20030722134912.04affff8@mailhost.eed.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Tue, 22 Jul 2003, Reiner Ludwig wrote: > As I understand, the motivation given for HS-TCP and FAST-TCP is that since > the required cwnd to fill the pipe is so high, it would require > unrealistically low rates of non-congestion-related packet losses. > > Now, I wonder whether anybody has studied what kind of > non-congestion-related packet losses we see in the target regime of 10 > Gbit/s and beyond ... > > Do such optical fiber links still do CRC, i.e., are the > non-congestion-related packet losses mostly due to packets being discarded > at the link layer? Or are maybe many of such non-congestion-related packet > losses due to TCP checksum errors, and thus the TCP receiver silently > discarding the packet? > > If it was the latter, one solution could be the definition of an explicit > TCP NACK that the TCP sender could use to suppress the reduction of cwnd. > Clearly, this would have some security considerations, but I guess those > could be fixed, e.g., with a nonce. > > Maybe this would be a good reason to disbale CRC on such optical fiber links. > > Did I miss something? I think packet corruption is not currently the greatest problem. There are a number of other causes of packet loss, including: - intermittent flows starting up (punching holes with slow-start) - misbehaving switches - burstiness, and a small router buffer When these things cause cwnd to be halved on the order of once every few minutes, they can seriously degrade the performance of high-BDP flows. A faster response time can really help, and I think is ultimately necessary if we expect end-to-end congestion control to work in messy networks at large window sizes. -John _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jul 22 15:10:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23354 for ; Tue, 22 Jul 2003 15:10:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2WY-0004LE-6b for tsvwg-archive@odin.ietf.org; Tue, 22 Jul 2003 15:10:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MJAAuh016673 for tsvwg-archive@odin.ietf.org; Tue, 22 Jul 2003 15:10:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2WO-0004Ji-V9; Tue, 22 Jul 2003 15:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2VU-0004HF-Cf for tsvwg@optimus.ietf.org; Tue, 22 Jul 2003 15:09: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 PAA23198 for ; Tue, 22 Jul 2003 15:08:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f2VP-0006kG-00 for tsvwg@ietf.org; Tue, 22 Jul 2003 15:08:59 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 19f2VF-0006k5-00 for tsvwg@ietf.org; Tue, 22 Jul 2003 15:08:49 -0400 Received: from phys-ha1mpka.eng.sun.com ([129.146.14.50]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6MJ7sDZ006772 for ; Tue, 22 Jul 2003 12:07:54 -0700 (PDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by phys-ha1mpka.eng.sun.com (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id MAA06985 for ; Tue, 22 Jul 2003 12:07:53 -0700 (PDT) Message-ID: <3F1D8B89.40502@sun.com> Date: Tue, 22 Jul 2003 12:07:53 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2.1) Gecko/20030313 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) 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 Pasi Sarolahti wrote: > And after the examples shown by Sourabh, I believe detecting spurious > RTOs with multihoming brings interesting questions for both F-RTO and > Eifel that I need to study more thoroughly. I guess after all the discussions so far, SCTP implementors should think about not to follow what is recommended in RFC 2960, timeout retransmission to an alternate address. Just a suggestion, it seems that at least for the first timeout, the retransmission is probably better sent to the original address. And when this first retransmission is also lost leading to another timeout, SCTP should start considering using an alternate address. -- K. Poon. kacheong.poon@sun.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 23 16:43:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01924 for ; Wed, 23 Jul 2003 16:43:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fQS1-0005gq-Jx for tsvwg-archive@odin.ietf.org; Wed, 23 Jul 2003 16:43:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NKh5TA021868 for tsvwg-archive@odin.ietf.org; Wed, 23 Jul 2003 16:43:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fQRx-0005ga-Kc; Wed, 23 Jul 2003 16:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fQR8-0005gJ-He for tsvwg@optimus.ietf.org; Wed, 23 Jul 2003 16:42:10 -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 QAA01891 for ; Wed, 23 Jul 2003 16:42:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fQR6-0000bT-00 for tsvwg@ietf.org; Wed, 23 Jul 2003 16:42:08 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19fQQv-0000b6-00 for tsvwg@ietf.org; Wed, 23 Jul 2003 16:41:57 -0400 Received: from isi.edu (host174.tollo.net [206.117.6.174]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6NKfTX17951; Wed, 23 Jul 2003 13:41:30 -0700 (PDT) Message-ID: <3F1EF2F2.8020706@isi.edu> Date: Wed, 23 Jul 2003 13:41:22 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Handley CC: tsvwg@ietf.org Subject: Re: [Tsvwg] High-speed TCP References: <9147.1058520749@eve.cs.ucl.ac.uk> In-Reply-To: <9147.1058520749@eve.cs.ucl.ac.uk> X-Enigmail-Version: 0.74.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mark Handley wrote: > In followup to today's TSVWG meeting, here's some suggested > boilerplate text for the High-speed TCP Experimental RFC: > > The proposals in this document are experimental. We believe they > are safe for deployment in the current Internet, Why is this believed? The document states fairly clearly that this sort of TCP will receive a disproportionate share of a link if competing with conventional TCP. So far, the discussion seems to qualify 'safe' as 'safe in a closed environment' or 'safe if used primarily over very high speed links'. That's not particularly 'safe', since these criteria are external to the protocol. Joe _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 23 17:08:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02927 for ; Wed, 23 Jul 2003 17:08:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fQqA-00073E-Q7 for tsvwg-archive@odin.ietf.org; Wed, 23 Jul 2003 17:08:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NL82wl027070 for tsvwg-archive@odin.ietf.org; Wed, 23 Jul 2003 17:08:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fQq9-00071m-U8; Wed, 23 Jul 2003 17:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fQpi-0006wC-PP for tsvwg@optimus.ietf.org; Wed, 23 Jul 2003 17:07:34 -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 RAA02888 for ; Wed, 23 Jul 2003 17:07:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fQpg-0000os-00 for tsvwg@ietf.org; Wed, 23 Jul 2003 17:07:32 -0400 Received: from aardvark.cs.ucl.ac.uk ([128.16.11.150]) by ietf-mx with esmtp (Exim 4.12) id 19fQpV-0000o8-00 for tsvwg@ietf.org; Wed, 23 Jul 2003 17:07:22 -0400 Received: from aardvark.cs.ucl.ac.uk (localhost [127.0.0.1]) by aardvark.cs.ucl.ac.uk (8.12.8p1/8.12.8) with ESMTP id h6NL63Gc032086; Wed, 23 Jul 2003 22:06:03 +0100 (BST) (envelope-from mjh@aardvark.cs.ucl.ac.uk) From: Mark Handley X-Organisation: UCL To: Joe Touch cc: tsvwg@ietf.org Subject: Re: [Tsvwg] High-speed TCP In-reply-to: Your message of "Wed, 23 Jul 2003 13:41:22 PDT." <3F1EF2F2.8020706@isi.edu> Date: Wed, 23 Jul 2003 22:06:03 +0100 Message-ID: <32085.1058994363@aardvark.cs.ucl.ac.uk> Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , >Mark Handley wrote: >> In followup to today's TSVWG meeting, here's some suggested >> boilerplate text for the High-speed TCP Experimental RFC: >> >> The proposals in this document are experimental. We believe they >> are safe for deployment in the current Internet, > >Why is this believed? The document states fairly clearly that this sort >of TCP will receive a disproportionate share of a link if competing with >conventional TCP. Two points: - this was my suggested text, sent to the list for critique. - the opinion represented the consensus in the room at the IETF. Personally I feel it's "safe" in the sense that it will achieve a disproportionate share only under circumstances under which a conventional TCP is unable to effectively use the available bandwidth. But I'm not one of the main advocates of this particular draft, so I'm not the person to convince otherwise. Cheers, Mark _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 23 17:17:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03169 for ; Wed, 23 Jul 2003 17:17:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fQys-0007Uw-OU for tsvwg-archive@odin.ietf.org; Wed, 23 Jul 2003 17:17:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NLH2m7028787 for tsvwg-archive@odin.ietf.org; Wed, 23 Jul 2003 17:17:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fQyr-0007TZ-GK; Wed, 23 Jul 2003 17:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fQyp-0007TO-OE for tsvwg@optimus.ietf.org; Wed, 23 Jul 2003 17:16: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 RAA03163 for ; Wed, 23 Jul 2003 17:16:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fQyn-0000tG-00 for tsvwg@ietf.org; Wed, 23 Jul 2003 17:16:57 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19fQyX-0000t2-00 for tsvwg@ietf.org; Wed, 23 Jul 2003 17:16:41 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h6NLGGe3008199; Wed, 23 Jul 2003 14:16:16 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200307232116.h6NLGGe3008199@cougar.icir.org> To: John Heffner cc: tsvwg@ietf.org From: Sally Floyd Subject: Re: [Tsvwg] HS-TCP/FAST-TCP: Kind of Packet Loss? Date: Wed, 23 Jul 2003 14:16:16 -0700 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , >I think packet corruption is not currently the greatest problem. There >are a number of other causes of packet loss, including: > - intermittent flows starting up (punching holes with slow-start) > - misbehaving switches > - burstiness, and a small router buffer > >When these things cause cwnd to be halved on the order of once every few >minutes, they can seriously degrade the performance of high-BDP flows. A >faster response time can really help, and I think is ultimately necessary >if we expect end-to-end congestion control to work in messy networks at >large window sizes. Yep! I agree that packet corruption is not the motivating problem here. - Sally _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 23 17:49:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04228 for ; Wed, 23 Jul 2003 17:49:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRTt-0000kK-Fu for tsvwg-archive@odin.ietf.org; Wed, 23 Jul 2003 17:49:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NLn5Zw002868 for tsvwg-archive@odin.ietf.org; Wed, 23 Jul 2003 17: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 19fRTp-0000jQ-Qg; Wed, 23 Jul 2003 17:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRSy-0000iz-5m for tsvwg@optimus.ietf.org; Wed, 23 Jul 2003 17:48: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 RAA04162 for ; Wed, 23 Jul 2003 17:48:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fRSv-000186-00 for tsvwg@ietf.org; Wed, 23 Jul 2003 17:48:05 -0400 Received: from mathis.wv.cc.cmu.edu ([128.2.71.93] helo=zippy.psc.edu) by ietf-mx with esmtp (Exim 4.12) id 19fRSl-000183-00 for tsvwg@ietf.org; Wed, 23 Jul 2003 17:47:55 -0400 Received: from localhost (mathis@localhost) by zippy.psc.edu (8.11.6/8.11.6) with ESMTP id h6NLlTk22328; Wed, 23 Jul 2003 17:47:29 -0400 X-Authentication-Warning: zippy.psc.edu: mathis owned process doing -bs Date: Wed, 23 Jul 2003 17:47:29 -0400 (EDT) From: Matt Mathis To: Joe Touch cc: Transport WG Subject: Re: [Tsvwg] High-speed TCP In-Reply-To: <3F1EF2F2.8020706@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , There is general agreement that at very large windows (e.g. more than 1000 packets in flight) TCP is way too sensitive to packet loss, making it unreasonably difficult to get line rate on long fast networks. Fixing this excessive sensitivity to loss intrinsically requires redefining TCP friendly. It is universally understood that during any such transition there are likely to be situations where new TCP and old TCP do not play as nicely as one would hope. In the case of Sally's High-speed TCP, we understand the likely worse case bound on the unfairness. In reality, stock TCP does so poorly in most of these situations that "fairness" isn't even the point.... The real question that the WG discussed had to do with the possibility of a partial interim deployment of Sally's HS-TCP causing deployment problems for a future algorithm, such as XCP or FAST. Note the real question is not if the protocols play nicely, but if the users will play nicely. It would be a_very_bad_thing if HS-TCP proved to be very unfair to the_right_answer(TM) and at the same time came to be in wide use by innocent users (say because some large vendor shipped it turned on by default). As long as HS-TCP is off by default, it will require a certain level of user awareness to turn it on. Such users are likely to be aware of the_right_answer when it becomes available. Just a moderate level of education will be sufficient to prevent chronic problems in the (presumably small) regime where HS-TCP might have an unfair advantage over the_right_answer.... The discussion (and hummed consensus) at the WG was about balancing the value of an interim solution and various risks. Most of the worry seemed to be about risk to a future right answer, and not about current TCP. In any case the hums were not even close. Good enough? Thanks, --MM-- On Wed, 23 Jul 2003, Joe Touch wrote: > Mark Handley wrote: > > In followup to today's TSVWG meeting, here's some suggested > > boilerplate text for the High-speed TCP Experimental RFC: > > > > The proposals in this document are experimental. We believe they > > are safe for deployment in the current Internet, > > Why is this believed? The document states fairly clearly that this sort > of TCP will receive a disproportionate share of a link if competing with > conventional TCP. > > So far, the discussion seems to qualify 'safe' as 'safe in a closed > environment' or 'safe if used primarily over very high speed links'. > That's not particularly 'safe', since these criteria are external to the > protocol. > > Joe > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > -- --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 23 19:23:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07706 for ; Wed, 23 Jul 2003 19:23:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fSwr-0005N1-K8 for tsvwg-archive@odin.ietf.org; Wed, 23 Jul 2003 19:23:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NNN5Cd020639 for tsvwg-archive@odin.ietf.org; Wed, 23 Jul 2003 19:23:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fSwm-0005M4-Vo; Wed, 23 Jul 2003 19:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fSwJ-0005Ll-SG for tsvwg@optimus.ietf.org; Wed, 23 Jul 2003 19:22:31 -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 TAA07692 for ; Wed, 23 Jul 2003 19:22:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fSwI-0001fv-00 for tsvwg@ietf.org; Wed, 23 Jul 2003 19:22:30 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19fSw7-0001fs-00 for tsvwg@ietf.org; Wed, 23 Jul 2003 19:22:19 -0400 Received: from isi.edu (host174.tollo.net [206.117.6.174]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6NNLfX18357; Wed, 23 Jul 2003 16:21:41 -0700 (PDT) Message-ID: <3F1F187A.60501@isi.edu> Date: Wed, 23 Jul 2003 16:21:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matt Mathis CC: Transport WG Subject: Re: [Tsvwg] High-speed TCP References: In-Reply-To: X-Enigmail-Version: 0.74.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Matt Mathis wrote: > There is general agreement that at very large windows (e.g. more than 1000 > packets in flight) TCP is way too sensitive to packet loss, making it > unreasonably difficult to get line rate on long fast networks. > > Fixing this excessive sensitivity to loss intrinsically requires redefining TCP > friendly. It is universally understood that during any such transition there > are likely to be situations where new TCP and old TCP do not play as nicely as > one would hope. In the case of Sally's High-speed TCP, we understand the > likely worse case bound on the unfairness. In reality, stock TCP does so > poorly in most of these situations that "fairness" isn't even the point.... There are cases where it is possible that stock TCP is used over short fast links and this would be needed for longer paths. Using both on the same enterprise could cause significant unfairness, in ways that are not considered a reasonable interim step. > The real question that the WG discussed had to do with the possibility of a > partial interim deployment of Sally's HS-TCP causing deployment problems for a > future algorithm, such as XCP or FAST. Note the real question is not if the > protocols play nicely, but if the users will play nicely. > > It would be a_very_bad_thing if HS-TCP proved to be very unfair to > the_right_answer(TM) and at the same time came to be in wide use by innocent > users (say because some large vendor shipped it turned on by default). > > As long as HS-TCP is off by default, it will require a certain level of user > awareness to turn it on. Such users are likely to be aware of the_right_answer > when it becomes available. Just a moderate level of education will be > sufficient to prevent chronic problems in the (presumably small) regime where > HS-TCP might have an unfair advantage over the_right_answer.... As above, using this protocol over a HS-path might interact very badly with other streams that share part but not all of the path, e.g., conventional TCP at high speeds near the endpoints (which have a small window and no need for this sol'n). > The discussion (and hummed consensus) at the WG was about balancing the value > of an interim solution and various risks. Most of the worry seemed to be > about risk to a future right answer, and not about current TCP. In any case > the hums were not even close. > > Good enough? I'd be more comfortable with a statement that doesn't so broadly endorse experimenting with it on the Internet as a whole without some caveats, notably those which appear to be implied. I.e., - off by default - turned on only on applicable paths or environments - it is the responsibility of those using this protocol to determine whether it is affecting others, and when such effects are found, to disable it until they can be corrected These may be implicit in the concept of 'experimental', but if we're saying it's 'safe', it ought to be clear about under what conditions. Joe _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 24 17:19:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01330 for ; Thu, 24 Jul 2003 17:19:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnUG-0006bI-J1 for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 17:18:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OLIuoJ025367 for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 17:18:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnTO-0006SV-VN; Thu, 24 Jul 2003 17:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d7Nz-00040P-Ij for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 07:57: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 HAA01942 for ; Thu, 17 Jul 2003 07:57:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d7Ny-0005Tz-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 07:57:22 -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 19d7Nn-0005TR-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 07:57:11 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6HBucGJ018744; Thu, 17 Jul 2003 13:56:38 +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 366CKHVK; Thu, 17 Jul 2003 13:56:51 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <3W4FAT11>; Thu, 17 Jul 2003 13:56:38 +0200 Message-ID: <5E5172B4DE05D311B3AB0008C75DA941123CEFBE@edeacnt100.eed.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Sourabh Ladha (AC/EED)" To: "'Pasi Sarolahti'" , "Armando L. Caro Jr." Cc: tsvwg@ietf.org Subject: RE: [Tsvwg] FRTO Date: Thu, 17 Jul 2003 13:54:08 +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: , Pasi, I had read the FRTO document some time back. On the SCTP front I was wondering if the following are applicable: * Multihoming: If the delay spike on the primary path is greater than (1 RTO(primary) + 2 RTT(alternate)), I would believe that FRTO will not be able to detect a timeout spurious. (complying with the current spec that retransmissions SHOULD go to alternate destination) * Chunk Bundling: FRTO assumes that on a timeout the sender will retransmit only one segment("I think chunk will be appropriate in SCTP terminology"). This may not be true in SCTP. If the association is multihomed and the PMTU's on the primary and alternate path differ by a factor of two or more then, then I think the sender may be able to retransmit more than one unacknowledged chunk on a timeout (bundled in a single packet). This can also be true if the app is writing small chunks such that on a timeout more than one of such chunks can be bundled in a single packet and retransmitted. I remember having noticed a couple of side effects of this which could lead FRTO to declare the timeout spurious while it was not. Comments? (Others shoot in if I missed something) A question I have is: Section 3- step 3(b): When you refer to an ACK which acknowledges data (above spurious threshhold or previously unacknowledged), do you refer to acknowledging {via cum-ack point} or {via SACK blocks} or {either of these two}? -Sourabh > -----Original Message----- > From: Pasi Sarolahti [mailto:sarolaht@cs.Helsinki.FI] > Sent: Thursday, July 17, 2003 12:52 PM > To: Armando L. Caro Jr. > Cc: tsvwg@ietf.org > Subject: Re: [Tsvwg] SCTP Timestamps > > > Hi, > > On Wed, 16 Jul 2003, Armando L. Caro Jr. wrote: > > > The second motivation was to use timestamps for Eifel detection. A > > spurious timeout retransmit can be detected if the > retransmitted TSN gets > > acked with a timestamp earlier than the timestamp bundled with the > > retransmission. This purpose does require a timestamp in > each packet (I > > think). > > Aside from this timestamp discussion, but since spurious RTOs were > mentioned: We have proposed a scheme for detecting spurious > RTOs without > timestamps in draft-sarolahti-tsvwg-tcp-frto-04.txt. I solicited for > comments on it in early June, but unfortunately got no > answer. It would be > nice to hear whether the SCTP community would find that useful. > > The idea in short is that after an RTO the sender would try > to send some > new data and check if there are acks of non-retransmitted segments > arriving after that, in which case the RTO is considered to > be spurious. > This should work with SCTP as well as with TCP as far as I can see. I > believe Markku Kojo will have a short presentation about the > draft in the > tsvwg meeting. > > Thanks, > - Pasi > > > > _______________________________________________ > 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 Jul 24 17:19:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01328 for ; Thu, 24 Jul 2003 17:19:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnUG-0006bH-J2 for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 17:18:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OLIuCh025366 for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 17:18:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnTO-0006S6-1N; Thu, 24 Jul 2003 17:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d58a-0002QC-Lq for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 05:33: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 FAA26544 for ; Thu, 17 Jul 2003 05:33:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d58X-0003vk-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 05:33:17 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 19d58M-0003vf-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 05:33:06 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h6H9X2i00088 for ; Thu, 17 Jul 2003 11:33:02 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h6H9X1K11500 for ; Thu, 17 Jul 2003 11:33:01 +0200 (MEST) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA03903 for ; Thu, 17 Jul 2003 11:33:01 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Thu, 17 Jul 2003 11:32:27 +0200 Message-ID: From: Schruefer Wolfgang To: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps (a Chunk Flag alternative) Date: Thu, 17 Jul 2003 11:32:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Dear all, following the Timestamp discussion I asked myself whether there is a need to transmit any timestamp and if there are no cheaper solution. Here I will suggest a solution by using a Bit of the DATA and SACK Chunk Flags. What we need in my understanding is a solution for the problem Stephan described at the beginning of the thread: Resolving the retransmission ambiguity, i.e. enabling the sender to determine whether an ACK refers to the original transmission or a retransmission of a chunk. This implies resolving a "path ambiguity" and allowing better and more frequent RTT measurements. My thought is to sacrifice one (or two) bit(s) of the unused DATA and SACK Chunk Flags Bits to solve this problem. The clue is that this bit should be echoed by the receiver in the SACK Chunk Flags. Let me just call this bit Mirror Bit or M-bit. A scenario may run like this: - A sender sets the M-bit at any value when a DATA chunk is transmitted for the first time and stores the value together with the timestamp. - The receiver mirrors the bit for the DATA chunk with TSN == Cumulative TSN Ack. - When the sender recognises that the M-bit is not echoed correctly (for not retransmitted DATA), it knows that the peer does not support this feature. I think a feature negotiation at association setup is therefore not necessary. - When the sender needs to retransmit the DATA for the first time it toggles the M-bit and stores the retransmission time. - Up to now the sender can always resolve the chunk where a SACK refers to. - When there is a need for further retransmissions I see three alternatives: ** The M-bit is toggled again and the sender assumes that the DATA chunk sent two RTO before was lost. ** The M-bit remains identical in all retransmissions (but e.g. a SACK for this DATA chunk may not be used any more for RTT calculation). ** We use two Chunk Flag Bits to mark the last four transmissions. Is this a way worth to think further? Wolfgang _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 24 17:28:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01747 for ; Thu, 24 Jul 2003 17:28:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnck-0007J4-OM for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 17:27:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OLRgUk028077 for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 17:27:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnc5-0007Db-Er; Thu, 24 Jul 2003 17:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnbl-0007DO-TX for tsvwg@optimus.ietf.org; Thu, 24 Jul 2003 17:26:41 -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 RAA01693 for ; Thu, 24 Jul 2003 17:26:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fnbj-0002Tp-00 for tsvwg@ietf.org; Thu, 24 Jul 2003 17:26:39 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19fnbY-0002Tf-00 for tsvwg@ietf.org; Thu, 24 Jul 2003 17:26:28 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id E194B32950; Thu, 24 Jul 2003 17:26:08 -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 0D17032892; Thu, 24 Jul 2003 17:26:08 -0400 (EDT) Date: Thu, 24 Jul 2003 17:26:08 -0400 (EDT) From: Sourabh Ladha X-X-Sender: To: "Sourabh Ladha (AC/EED)" Cc: "'Pasi Sarolahti'" , "Armando L. Caro Jr." , Subject: RE: [Tsvwg] FRTO In-Reply-To: <5E5172B4DE05D311B3AB0008C75DA941123CEFBE@edeacnt100.eed.ericsson.se> Message-ID: X-Spam-Status: No, hits=-5.3 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,SUPERLONG_LINE,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: , Talk about reordering and delay spikes..I had send this email a week back (17th July) :-> -Sourabh On Thu, 17 Jul 2003, Sourabh Ladha (AC/EED) wrote: > Pasi, > > I had read the FRTO document some time back. On the SCTP front I was wondering if the following are applicable: > > * Multihoming: If the delay spike on the primary path is greater than (1 RTO(primary) + 2 RTT(alternate)), I would believe that FRTO will not be able to detect a timeout spurious. (complying with the current spec that retransmissions SHOULD go to alternate destination) > > * Chunk Bundling: FRTO assumes that on a timeout the sender will retransmit only one segment("I think chunk will be appropriate in SCTP terminology"). This may not be true in SCTP. If the association is multihomed and the PMTU's on the primary and alternate path differ by a factor of two or more then, then I think the sender may be able to retransmit more than one unacknowledged chunk on a timeout (bundled in a single packet). This can also be true if the app is writing small chunks such that on a timeout more than one of such chunks can be bundled in a single packet and retransmitted. I remember having noticed a couple of side effects of this which could lead FRTO to declare the timeout spurious while it was not. > > Comments? > (Others shoot in if I missed something) > > A question I have is: > Section 3- step 3(b): When you refer to an ACK which acknowledges data (above spurious threshhold or previously unacknowledged), do you refer to acknowledging {via cum-ack point} or {via SACK blocks} or {either of these two}? > > > -Sourabh > > > > > > -----Original Message----- > > From: Pasi Sarolahti [mailto:sarolaht@cs.Helsinki.FI] > > Sent: Thursday, July 17, 2003 12:52 PM > > To: Armando L. Caro Jr. > > Cc: tsvwg@ietf.org > > Subject: Re: [Tsvwg] SCTP Timestamps > > > > > > Hi, > > > > On Wed, 16 Jul 2003, Armando L. Caro Jr. wrote: > > > > > The second motivation was to use timestamps for Eifel detection. A > > > spurious timeout retransmit can be detected if the > > retransmitted TSN gets > > > acked with a timestamp earlier than the timestamp bundled with the > > > retransmission. This purpose does require a timestamp in > > each packet (I > > > think). > > > > Aside from this timestamp discussion, but since spurious RTOs were > > mentioned: We have proposed a scheme for detecting spurious > > RTOs without > > timestamps in draft-sarolahti-tsvwg-tcp-frto-04.txt. I solicited for > > comments on it in early June, but unfortunately got no > > answer. It would be > > nice to hear whether the SCTP community would find that useful. > > > > The idea in short is that after an RTO the sender would try > > to send some > > new data and check if there are acks of non-retransmitted segments > > arriving after that, in which case the RTO is considered to > > be spurious. > > This should work with SCTP as well as with TCP as far as I can see. I > > believe Markku Kojo will have a short presentation about the > > draft in the > > tsvwg meeting. > > > > Thanks, > > - Pasi > > > > > > > > _______________________________________________ > > 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 > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 24 17:36:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02063 for ; Thu, 24 Jul 2003 17:36:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnkU-0007hF-CE for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 17:35:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OLZgAc029568 for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 17:35:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnjp-0007bf-2N; Thu, 24 Jul 2003 17:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fniu-0007at-K4 for tsvwg@optimus.ietf.org; Thu, 24 Jul 2003 17:34: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 RAA02007 for ; Thu, 24 Jul 2003 17:33:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fnis-0002Wq-00 for tsvwg@ietf.org; Thu, 24 Jul 2003 17:34:02 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19fnih-0002Wh-00 for tsvwg@ietf.org; Thu, 24 Jul 2003 17:33:51 -0400 Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 4.14) id 19fniN-0007Qp-Pe for tsvwg@ietf.org; Thu, 24 Jul 2003 21:33:31 +0000 To: tsvwg@ietf.org Reply-To: mankin@psg.com Date: Thu, 24 Jul 2003 14:33:31 -0700 From: Allison Mankin Message-Id: Subject: [Tsvwg] Old mail 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: , Apologies for/to the old mail that just popped out - there was an even worse than usual flow of spam on the tsvwg list during IETF - what with IETF and all, it was hard for Jon and me to see that there were some real messages hiding in there. Allison _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 24 17:53:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02464 for ; Thu, 24 Jul 2003 17:53:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fo0x-0008SB-2s for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 17:52:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OLqhSr032495 for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 17:52:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fo0H-0008LZ-Jb; Thu, 24 Jul 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 19fnzr-0008L9-PA for tsvwg@optimus.ietf.org; Thu, 24 Jul 2003 17:51:35 -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 RAA02397 for ; Thu, 24 Jul 2003 17:51:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fnzp-0002cs-00 for tsvwg@ietf.org; Thu, 24 Jul 2003 17:51:33 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19fnzZ-0002cc-00 for tsvwg@ietf.org; Thu, 24 Jul 2003 17:51:17 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h6OLoqe3021017; Thu, 24 Jul 2003 14:50:52 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200307242150.h6OLoqe3021017@cougar.icir.org> To: Joe Touch cc: tsvwg@ietf.org From: Sally Floyd Subject: Re: [Tsvwg] High-speed TCP Date: Thu, 24 Jul 2003 14:50:52 -0700 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 proposals in this document are experimental. We believe they >> are safe for deployment in the current Internet, > >Why is this believed? The document states fairly clearly that this sort >of TCP will receive a disproportionate share of a link if competing with >conventional TCP. The same argument could have been made about NewReno TCP, which has been Experimental since January 1999. That is, there are scenarios where NewReno TCP receives a disproportionate share of a link if competing with then-conventional Reno TCP, in scenarios where loss events are likely to consist of multiple packets dropped from a window of data (e.g., in networks with Drop Tail queue management). This is due to Reno TCP's often abysmal performance when multiple packets are dropped from a window of data. The rough consensus at the time, as I recall, was that NewReno was considered safe for deployment in the current Internet even though NewReno flows might receive a disproportionate share of a link if competing with Reno, because we didn't want the limitations of Reno TCP to become preserved in the Internet in perpetuity. I would suggest that a similar situation occurs with HighSpeed TCP. The internet draft about HighSpeed TCP is quite explicit about the issue of relative fairness with Standard TCP, and it is not the case the HighSpeed TCP will always receive a disproportionate share of the link bandwidth when competing with Standard TCP. In the environments where Standard TCP is clearly capable of making good use of the existing link bandwidth, e.g., with packet drop rates of 10^-2 or 10^-3, HighSpeed TCP does exactly the same thing as Standard TCP. Table 5 of the draft shows how the relative fairness goes in environments with smaller packet drop rates: Packet Drop Rate P Fairness Aggregate Window Bandwidth ------------------ -------- ---------------- --------- 10^-2 1.0 24 2.8 Mbps 10^-3 1.0 76 9.1 Mbps 10^-4 2.2 383 45.9 Mbps 10^-5 4.7 2174 260.8 Mbps 10^-6 10.2 13479 1.6 Gbps 10^-7 22.1 87776 10.5 Gbps Table 5: Relative Fairness between the HighSpeed and Standard Response Functions. The arguments of the draft are that the relative fairness of 2.2 with packet drop rates of 10^-4 are not a grave concern, and that for the lower-packet-drop-rate environments with the more severe unfairness, Standard TCP doesn't do very well at making use of the available bandwidth. From the draft: "Our judgement would be that ... the benefits of the HighSpeed response function would outweigh the unfairness that would be experienced by Standard TCP in this regime." But this is being brought to the working group for the group to decide. From later email: >There are cases where it is possible that stock TCP is used over short >fast links and this would be needed for longer paths. Using both on the >same enterprise could cause significant unfairness, in ways that are not >considered a reasonable interim step. I don't believe this. Do you have any simulations or experiments to back this up? If a HighSpeed TCP and a Standard TCP were competing over a congested shared link, and the Standard TCP was over a short fast path, the Standard TCP would induce a rather high packet drop rate in the shared link, and the HighSpeed TCP would be in the space where it behaves roughly the same as Standard TCP. ... >As above, using this protocol over a HS-path might interact very badly >with other streams that share part but not all of the path, e.g., >conventional TCP at high speeds near the endpoints (which have a small >window and no need for this sol'n). Again, if a long-RTT HighSpeed TCP is competing over a congested link with a Standard TCP flow that has a small window and a short RTT, the advantage is more likely to go to the Standard TCP short-RTT flow. As is normally the case when short-RTT TCP flows compete against longer-RTT flows. ... >I'd be more comfortable with a statement that doesn't so broadly endorse >experimenting with it on the Internet as a whole without some caveats, >notably those which appear to be implied. > >I.e., > - off by default > - turned on only on applicable paths or environments > - it is the responsibility of those using this protocol to > determine whether it is affecting others, and when such effects > are found, to disable it until they can be corrected > >These may be implicit in the concept of 'experimental', but if we're >saying it's 'safe', it ought to be clear about under what conditions. Personally, I think that HighSpeed TCP is perfectly safe to be deployed on by default, for anyone/implementor who so chooses. (My own view is that HighSpeed TCP goes to great lengths to position itself on the conservative, incrementally-deployable end of the spectrum. And that HighSpeed TCP is *more* safe than the N parallel TCP connections that are often deployed in fact in its place, in the current Internet in environments where Standard TCP is not up to making good use of the available bandwidth.) But the decision rests with the working group as a whole... - Sally http://www.icir.org/floyd/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 24 18:08:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03344 for ; Thu, 24 Jul 2003 18:08:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foFN-0001Ad-Du for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 18:07:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OM7bDk004461 for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 18:07:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foEn-0000s6-3n; Thu, 24 Jul 2003 18:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foEc-0000rL-SY for tsvwg@optimus.ietf.org; Thu, 24 Jul 2003 18:06: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 SAA03207 for ; Thu, 24 Jul 2003 18:06:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19foEZ-0002kL-00 for tsvwg@ietf.org; Thu, 24 Jul 2003 18:06:47 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19foEK-0002kA-00 for tsvwg@ietf.org; Thu, 24 Jul 2003 18:06:32 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h6OM6Le3021290; Thu, 24 Jul 2003 15:06:21 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200307242206.h6OM6Le3021290@cougar.icir.org> To: Matt Mathis cc: Transport WG From: Sally Floyd Subject: Re: [Tsvwg] High-speed TCP Date: Thu, 24 Jul 2003 15:06:21 -0700 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: , >It would be a_very_bad_thing if HS-TCP proved to be very unfair to >the_right_answer(TM) and at the same time came to be in wide use by innocent >users (say because some large vendor shipped it turned on by default). > >As long as HS-TCP is off by default, it will require a certain level of user >awareness to turn it on. Such users are likely to be aware of the_right_answer >when it becomes available. Just a moderate level of education will be >sufficient to prevent chronic problems in the (presumably small) regime where >HS-TCP might have an unfair advantage over the_right_answer.... The added text in the revised version of the draft, draft-ietf-tsvwg-highspeed-00.txt, is as follows: We do not believe that the deployment of HighSpeed TCP would serve as a block to the possible deployment of alternate experimental protocols for high-speed congestion control, such as Scalable TCP, XCP [KHR02], or FAST TCP [JWL03]. In particular, we don't expect HighSpeed TCP to interact any more poorly with alternative experimental proposals that would the N parallel TCP connections commonly used today in the absence of HighSpeed TCP. I would personally expect HighSpeed TCP to interact considerably *better* with any alternate experimental protocol that would the N parallel Standard TCP connections that are in fact deployed in its place, for some arbitrary value of N. (And hopefully HighSpeed TCP would do sufficiently well at making use of the available bandwidth that people wouldn't feel the need, or the justification, to use N parallel HighSpeed TCP connections as a regular thing, for large N. Or maybe we will manage at some point to get mechanisms in routers that can take care of such issues, who knows?) - Sally http://www.icir.org/floyd/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 24 18:08:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01329 for ; Thu, 24 Jul 2003 17:19:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnUG-0006bJ-JP for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 17:18:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OLIuuf025370 for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 17:18:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnTO-0006SK-G2; Thu, 24 Jul 2003 17:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6bM-0000Vb-Uf for tsvwg@optimus.ietf.org; Thu, 17 Jul 2003 07:07: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 HAA29721 for ; Thu, 17 Jul 2003 07:07:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d6bI-0004oF-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 07:07:04 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 19d6b7-0004oC-00 for tsvwg@ietf.org; Thu, 17 Jul 2003 07:06:53 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h6HB6nj04122 for ; Thu, 17 Jul 2003 13:06:49 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h6HB6nf15933 for ; Thu, 17 Jul 2003 13:06:49 +0200 (MEST) Received: from mchh274e.demchh201e.icn.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id NAA21965 for ; Thu, 17 Jul 2003 13:06:48 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Thu, 17 Jul 2003 13:06:14 +0200 Message-ID: From: Schruefer Wolfgang To: "'tsvwg@ietf.org'" Subject: Re: [Tsvwg] SCTP Timestamps Date: Thu, 17 Jul 2003 13:06:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Dear all, following the Timestamp discussion I asked myself whether there is a need to transmit any timestamp and if there are no cheaper solution. Here I will suggest a solution by using a Bit of the DATA and SACK Chunk Flags. What we need in my understanding is a solution for the problem Stephan described at the beginning of the thread: Resolving the retransmission ambiguity, i.e. enabling the sender to determine whether an ACK refers to the original transmission or a retransmission of a chunk. This implies resolving a "path ambiguity" and allowing better and more frequent RTT measurements. My thought is to sacrifice one (or two) bit(s) of the unused DATA and SACK Chunk Flags Bits to solve this problem. The clue is that this bit should be echoed by the receiver in the SACK Chunk Flags. Let me just call this bit Mirror Bit or M-bit. A scenario may run like this: - A sender sets the M-bit at any value when a DATA chunk is transmitted for the first time and stores the value together with the timestamp. - The receiver mirrors the bit for the DATA chunk with TSN == Cumulative TSN Ack. - When the sender recognises that the M-bit is not echoed correctly (for not retransmitted DATA), it knows that the peer does not support this feature. I think a feature negotiation at association setup is therefore not necessary. - When the sender needs to retransmit the DATA for the first time it toggles the M-bit and stores the retransmission time. - Up to now the sender can always resolve the chunk where a SACK refers to. - When there is a need for further retransmissions I see three alternatives: ** The M-bit is toggled again and the sender assumes that the DATA chunk sent two RTO before was lost. ** The M-bit remains identical in all retransmissions (but e.g. a SACK for this DATA chunk may not be used any more for RTT calculation). ** We use two Chunk Flag Bits to mark the last four transmissions. Is this a way worth to think further? Wolfgang _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 24 19:15:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05648 for ; Thu, 24 Jul 2003 19:15:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fpIJ-000407-9k for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 19:14:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ONEh6h015368 for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 19:14:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fpHd-0003uk-1i; Thu, 24 Jul 2003 19:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fpHJ-0003tQ-5y for tsvwg@optimus.ietf.org; Thu, 24 Jul 2003 19:13:41 -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 TAA05612 for ; Thu, 24 Jul 2003 19:13:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fpHH-00036G-00 for tsvwg@ietf.org; Thu, 24 Jul 2003 19:13:39 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19fpH7-00035V-00 for tsvwg@ietf.org; Thu, 24 Jul 2003 19:13:29 -0400 Received: from isi.edu (240.sub-166-154-12.myvzw.com [166.154.12.240]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6ONBYX18273; Thu, 24 Jul 2003 16:11:35 -0700 (PDT) Message-ID: <3F206795.7020301@isi.edu> Date: Thu, 24 Jul 2003 16:11:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sally Floyd CC: tsvwg@ietf.org Subject: Re: [Tsvwg] High-speed TCP References: <200307242150.h6OLoqe3021017@cougar.icir.org> In-Reply-To: <200307242150.h6OLoqe3021017@cougar.icir.org> X-Enigmail-Version: 0.74.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sally Floyd wrote: >>> The proposals in this document are experimental. We believe they >>> are safe for deployment in the current Internet, >> >>Why is this believed? The document states fairly clearly that this sort >>of TCP will receive a disproportionate share of a link if competing with >>conventional TCP. > > > The same argument could have been made about NewReno TCP, which has > been Experimental since January 1999. Agreed. Note that the word "safe" does not appear in the NewReno RFC. ... > The rough consensus at > the time, as I recall, was that NewReno was considered safe for > deployment in the current Internet even though NewReno flows might > receive a disproportionate share of a link if competing with Reno, > because we didn't want the limitations of Reno TCP to become > preserved in the Internet in perpetuity. I would suggest that a > similar situation occurs with HighSpeed TCP. That may be true, but there is no corresponding recommendation of safety in the RFC. Declaring experimental protocols safe is a bit contradictory, and potentially problematic. >>From later email: > >>There are cases where it is possible that stock TCP is used over short >>fast links and this would be needed for longer paths. Using both on the >>same enterprise could cause significant unfairness, in ways that are not >>considered a reasonable interim step. > > I don't believe this. Do you have any simulations or experiments > to back this up? If a HighSpeed TCP and a Standard TCP were competing > over a congested shared link, and the Standard TCP was over a short > fast path, the Standard TCP would induce a rather high packet drop > rate in the shared link, and the HighSpeed TCP would be in the space > where it behaves roughly the same as Standard TCP. My concern is whether these cases have been tested before we make the recommendation of 'safe', rather than merely 'experimental.' The burden of proof is on the proposed protocol to in fact be safe. While my proposed scenario was indeed a thought-experiment, it would be useful if some of these typical scenarios were measured before we jumped to 'safe'. I'm comfortable with the same recommendation as NewReno. Joe _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 24 19:32:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05911 for ; Thu, 24 Jul 2003 19:32:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fpYn-0004aq-EA for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 19:31:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ONVjf1017620 for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 19:31:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fpY6-0004Ux-4L; Thu, 24 Jul 2003 19: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 19fpX8-0004PT-5H for tsvwg@optimus.ietf.org; Thu, 24 Jul 2003 19:30:02 -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 TAA05854 for ; Thu, 24 Jul 2003 19:29:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fpX6-0003Ai-00 for tsvwg@ietf.org; Thu, 24 Jul 2003 19:30:00 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19fpWq-0003AJ-00 for tsvwg@ietf.org; Thu, 24 Jul 2003 19:29:44 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h6ONSke3024464; Thu, 24 Jul 2003 16:28:46 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200307242328.h6ONSke3024464@cougar.icir.org> To: Joe Touch cc: tsvwg@ietf.org From: Sally Floyd Subject: Re: [Tsvwg] High-speed TCP Date: Thu, 24 Jul 2003 16:28:46 -0700 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: , >Agreed. Note that the word "safe" does not appear in the NewReno RFC. While the NewReno RFC didn't have that paragraph, the NewReno RFC was explicitly considered as acceptable for deployment in the public Internet. The point of Mark's proposed paragraph was to say that although there was no objection to this being deployed in the Internet, he wanted to make it clear that the WG wasn't endorsing this as "the best method for high-speed congestion control". So what if that paragraph said: "While they may be deployed in the current Internet ... " instead of: "We believe they are safe for deployment in the current Internet ... " Would that seem better to you? - Sally _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Jul 24 20:41:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07047 for ; Thu, 24 Jul 2003 20:41:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fqdb-0007CD-1G for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 20:40:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P0ekme027651 for tsvwg-archive@odin.ietf.org; Thu, 24 Jul 2003 20:40:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fqcr-00076P-Hz; Thu, 24 Jul 2003 20:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fqcA-00075m-2T for tsvwg@optimus.ietf.org; Thu, 24 Jul 2003 20:39:18 -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 UAA07033 for ; Thu, 24 Jul 2003 20:39:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fqc7-0003So-00 for tsvwg@ietf.org; Thu, 24 Jul 2003 20:39:15 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19fqbw-0003Si-00 for tsvwg@ietf.org; Thu, 24 Jul 2003 20:39:05 -0400 Received: from isi.edu (245.sub-166-154-12.myvzw.com [166.154.12.245]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6P0bVX03487; Thu, 24 Jul 2003 17:37:32 -0700 (PDT) Message-ID: <3F207BBE.4000306@isi.edu> Date: Thu, 24 Jul 2003 17:37:18 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sally Floyd CC: tsvwg@ietf.org Subject: Re: [Tsvwg] High-speed TCP References: <200307242328.h6ONSke3024464@cougar.icir.org> In-Reply-To: <200307242328.h6ONSke3024464@cougar.icir.org> X-Enigmail-Version: 0.74.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sally Floyd wrote: >>Agreed. Note that the word "safe" does not appear in the NewReno RFC. > > > While the NewReno RFC didn't have that paragraph, the NewReno RFC > was explicitly considered as acceptable for deployment in the public > Internet. The point of Mark's proposed paragraph was to say that > although there was no objection to this being deployed in the > Internet, he wanted to make it clear that the WG wasn't endorsing > this as "the best method for high-speed congestion control". > > So what if that paragraph said: > > "While they may be deployed in the current Internet ... " > > instead of: > > "We believe they are safe for deployment in the current Internet ... " > > Would that seem better to you? Until we have broader experience, yes. Joe _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 25 11:47:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09735 for ; Fri, 25 Jul 2003 11:47:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4mF-0002Jc-EG for tsvwg-archive@odin.ietf.org; Fri, 25 Jul 2003 11:46:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PFkd2g008878 for tsvwg-archive@odin.ietf.org; Fri, 25 Jul 2003 11:46:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4le-0002Fr-1K; Fri, 25 Jul 2003 11: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 19g4kg-0002El-7d for tsvwg@optimus.ietf.org; Fri, 25 Jul 2003 11:45: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 LAA09653 for ; Fri, 25 Jul 2003 11:44:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4ke-0001Hb-00 for tsvwg@ietf.org; Fri, 25 Jul 2003 11:45:00 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19g4ke-0001HU-00 for tsvwg@ietf.org; Fri, 25 Jul 2003 11:45:00 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h6PFise3032464; Fri, 25 Jul 2003 08:44:54 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200307251544.h6PFise3032464@cougar.icir.org> To: Joe Touch cc: tsvwg@ietf.org From: Sally Floyd Subject: Re: [Tsvwg] High-speed TCP Date: Fri, 25 Jul 2003 08:44:54 -0700 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 modified version of draft-floyd-tcp-highspeed-03.txt, now called draft-ietf-tsvwg-highspeed-00.txt, has already appeared in the internet-drafts repository, but I have posted a file with the list of changes to make at: http://www.icir.org/floyd/hstcp/draft-ietf-tsvwg-highspeed-00.errata The contents are given below. - Sally http://www.icir.org/floyd/ ----------------------------------------------------------------------- http://www.icir.org/floyd/hstcp/draft-ietf-tsvwg-highspeed-00.errata: ----------------------------------------------------------------------- Changes to make to draft-ietf-tsvwg-highspeed-00.txt: Change: "The proposals in this document are experimental. We believe they are safe for deployment in the current Internet, " To: "The proposals in this document are experimental. While they may be deployed in the current Internet, " _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Jul 25 15:29:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18036 for ; Fri, 25 Jul 2003 15:29:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g8Fa-0005iF-5X for tsvwg-archive@odin.ietf.org; Fri, 25 Jul 2003 15:29:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PJTAxo021949 for tsvwg-archive@odin.ietf.org; Fri, 25 Jul 2003 15:29:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g8FS-0005fO-FV; Fri, 25 Jul 2003 15:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g8FL-0005eh-Od for tsvwg@optimus.ietf.org; Fri, 25 Jul 2003 15:28:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17968; Fri, 25 Jul 2003 15:28:51 -0400 (EDT) Message-Id: <200307251928.PAA17968@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, 25 Jul 2003 15:28:50 -0400 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-slowstart-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 : Limited Slow-Start for TCP with Large Congestion Windows Author(s) : S. Floyd Filename : draft-ietf-tsvwg-slowstart-00.txt Pages : 7 Date : 2003-7-25 This note describes an optional modification for TCP's slow-start for use with TCP connections with large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender's MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter- productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link. This note describes Limited Slow-Start as an optional mechanism for limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance for TCP connections with large congestion windows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-slowstart-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-slowstart-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-slowstart-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-7-25152249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-slowstart-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-slowstart-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-25152249.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 Jul 25 15:29:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18037 for ; Fri, 25 Jul 2003 15:29:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g8Fa-0005iG-5g for tsvwg-archive@odin.ietf.org; Fri, 25 Jul 2003 15:29:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PJTAMv021950 for tsvwg-archive@odin.ietf.org; Fri, 25 Jul 2003 15:29:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g8FR-0005fD-KB; Fri, 25 Jul 2003 15:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g8FH-0005eW-F5 for tsvwg@optimus.ietf.org; Fri, 25 Jul 2003 15:28:51 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17933; Fri, 25 Jul 2003 15:28:46 -0400 (EDT) Message-Id: <200307251928.PAA17933@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, 25 Jul 2003 15:28:46 -0400 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-highspeed-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 : HighSpeed TCP for Large Congestion Windows Author(s) : S. Floyd Filename : draft-ietf-tsvwg-highspeed-00.txt Pages : 36 Date : 2003-7-25 This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the current Standard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). This is widely acknowledged as an unrealistic constraint. To address this limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-highspeed-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-highspeed-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-highspeed-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-7-25152239.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-highspeed-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-highspeed-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-25152239.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sat Jul 26 17:43:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18854 for ; Sat, 26 Jul 2003 17:43:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gWp5-00079N-MJ for tsvwg-archive@odin.ietf.org; Sat, 26 Jul 2003 17:43:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6QLhR6m027462 for tsvwg-archive@odin.ietf.org; Sat, 26 Jul 2003 17:43:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gWoe-00077l-UN; Sat, 26 Jul 2003 17:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gWoD-00076F-51 for tsvwg@optimus.ietf.org; Sat, 26 Jul 2003 17:42: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 RAA18837 for ; Sat, 26 Jul 2003 17:42:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gWoA-0005Sc-00 for tsvwg@ietf.org; Sat, 26 Jul 2003 17:42:30 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 19gWoA-0005SZ-00 for tsvwg@ietf.org; Sat, 26 Jul 2003 17:42:30 -0400 Received: from cs.helsinki.fi (onion.ICSI.Berkeley.EDU [::ffff:192.150.186.101]) (AUTH: PLAIN gurtov, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.cs.helsinki.fi with esmtp; Sun, 27 Jul 2003 00:42:28 +0300 Message-ID: <3F22F5C2.7050903@cs.helsinki.fi> Date: Sat, 26 Jul 2003 14:42:26 -0700 From: Andrei Gurtov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] reset of backoff with timestamps (RFC2988) 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 Several people have noticed that not all TCPs reset the backoff of the retransmit timer in go-back-N after a new measurement sample is collected with timestamps. This results in unnecessarily long timeouts, which is especially a problem if fast retransmits are disabled by "bugfix". RFC2988: The only case when TCP can safely take RTT samples from retransmitted segments is when the TCP timestamp option [JBB92] is employed, since the timestamp option removes the ambiguity garding which instance of the data segment triggered the acknowledgment. .... Note that after retransmitting, once a new RTT measurement is obtained (which can only happen when new data has been sent and acknowledged), the computations outlined in section 2 are performed, including the computation of RTO, which may result in "collapsing" RTO back down after it has been subject to exponential backoff (rule 5.5). The authors of RFC2988 and Sally Floyd agree that the second paragraph should also mention that a measurement can be taken earlier with timestamps. Therefore it's fine to reset the backoff when a new RTT sample is collected with timestamps. Does TSV working group feel that it is appropriate? If yes, a following correction could be submitted to RFC errata. http://www.rfc-editor.org/errata.html (which can only happen when new data has been sent and acknowledged *or if the timestamp option is used*) Sally have made a change to ns2 to reflect this update. Thanks, Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sun Jul 27 17:18:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25204 for ; Sun, 27 Jul 2003 17:18:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gsuQ-00009g-G9 for tsvwg-archive@odin.ietf.org; Sun, 27 Jul 2003 17:18:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6RLIQso000589 for tsvwg-archive@odin.ietf.org; Sun, 27 Jul 2003 17:18:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gsu1-00008X-3M; Sun, 27 Jul 2003 17:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fvxU-0002y6-MF for tsvwg@optimus.ietf.org; Fri, 25 Jul 2003 02:21:40 -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 CAA25595 for ; Fri, 25 Jul 2003 02:21:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fvxR-0005ZP-00 for tsvwg@ietf.org; Fri, 25 Jul 2003 02:21:37 -0400 Received: from web80311.mail.yahoo.com ([66.218.79.27]) by ietf-mx with smtp (Exim 4.12) id 19fvxF-0005Yp-00 for tsvwg@ietf.org; Fri, 25 Jul 2003 02:21:26 -0400 Message-ID: <20030725062036.68154.qmail@web80311.mail.yahoo.com> Received: from [66.125.226.138] by web80311.mail.yahoo.com via HTTP; Thu, 24 Jul 2003 23:20:36 PDT Date: Thu, 24 Jul 2003 23:20:36 -0700 (PDT) From: "Wilson C. Chung" Reply-To: wchung@sbcglobal.net To: tsvwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1288820232-1059114036=:65148" Subject: [Tsvwg] Status of draft-snoeren-tcp-migrate-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: , --0-1288820232-1059114036=:65148 Content-Type: text/plain; charset=us-ascii Anyone know what is the status of the following draft? draft-snoeren-tcp-migrate-00.txt submitted on TCP migration by Hari Balakrishnan and Alex Snoeren? --0-1288820232-1059114036=:65148 Content-Type: text/html; charset=us-ascii
Anyone know what is the status of the following draft?
 
draft-snoeren-tcp-migrate-00.txt
 
submitted on TCP migration by Hari Balakrishnan and Alex Snoeren?
 
--0-1288820232-1059114036=:65148-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Jul 28 19:41:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24831 for ; Mon, 28 Jul 2003 19:41:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hHcS-0001V7-1j for tsvwg-archive@odin.ietf.org; Mon, 28 Jul 2003 19:41:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SNfWo7005731 for tsvwg-archive@odin.ietf.org; Mon, 28 Jul 2003 19:41:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hHbx-0001Te-MK; Mon, 28 Jul 2003 19:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hHbB-0001Sj-1d for tsvwg@optimus.ietf.org; Mon, 28 Jul 2003 19:40:13 -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 TAA24657 for ; Mon, 28 Jul 2003 19:40:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hHb9-0000zq-00 for tsvwg@ietf.org; Mon, 28 Jul 2003 19:40:11 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 19hHb8-0000zk-00 for tsvwg@ietf.org; Mon, 28 Jul 2003 19:40:10 -0400 Received: from cs.helsinki.fi (dhcp95.icir.org [::ffff:192.150.187.95]) (AUTH: PLAIN gurtov, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.cs.helsinki.fi with esmtp; Tue, 29 Jul 2003 02:40:05 +0300 Message-ID: <3F25B467.9020609@cs.helsinki.fi> Date: Mon, 28 Jul 2003 16:40:23 -0700 From: Andrei Gurtov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] resolving the problem of unnecessary fast retransmits in go-back-N Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In go-back-N recovery TCP DUPACKs can result either from unnecessarily retransmitted packets or from a loss of a retransmitted packet. [Flo94] from RFC2892 shows that this ambiguity can cause unnecessary fast retransmits. A solution called "bugfix" in [F98] disables fast retransmits until go-back-N recovery is completed. However, because the ambiguity is not resolved, "bugfix" causes timeouts and very long recovery if packets get lost during go-back-N. The long-term solution to this problem is SACK (to prevent unnecessary retransmissions) and DSACK (to resolve the DUPACK ambiguity if unnecessary retransmissions do happen). However, most TCP connections today still do not use SACK. http://www.icir.org/floyd/sack-questions.html Until SACK is universally deployed two methods to resolve the DUPACK ambiguity might be useful. ACK-heuristic: if seq(ack_new)-seq(ack_prev)<=2 MSS then trigger fast retransmit on 3rd DUPACK This method is based on observation that to trigger a false fast retransmit, a TCP sender has to retransmit unnecessarily at least 3 adjucent packets. In this case there will be a jump in a cumulative ACK at the sender of at least three segments. Using the timestamp option: if ts_echo(ack_new) == ts (seg_una) then trigger fast retransmit on 3rd DUPACK In case of a missing segment both RFC1323 or RFC1323bis (expired update draft) require that DUPACKs echo a timestamp from the segment below the missing one. Some algorithm to detect spurious timeouts should be used before applying these tests. I'm currently running experiments in ns2 to identify any possible corner cases. For example, if ACKs get lost, a lost data segment would not be detected by the ACK-heuristic. However, if proposals work at least in common cases, using them is an improvement upon the "bugfix". Later I'll send a pointer to simulation results. Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jul 29 07:39:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19256 for ; Tue, 29 Jul 2003 07:39:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hSpB-0007f2-UA for tsvwg-archive@odin.ietf.org; Tue, 29 Jul 2003 07:39:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TBdPdJ029415 for tsvwg-archive@odin.ietf.org; Tue, 29 Jul 2003 07:39:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hSon-0007dX-9T; Tue, 29 Jul 2003 07:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hSoW-0007dI-Nb for tsvwg@optimus.ietf.org; Tue, 29 Jul 2003 07:38:44 -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 HAA19175 for ; Tue, 29 Jul 2003 07:38:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hSoW-0004a9-00 for tsvwg@ietf.org; Tue, 29 Jul 2003 07:38:44 -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 19hSoV-0004a6-00 for tsvwg@ietf.org; Tue, 29 Jul 2003 07:38:43 -0400 Received: from esealnt613.al.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 h6TBceG6002875; Tue, 29 Jul 2003 13:38:40 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XN34VL; Tue, 29 Jul 2003 13:38:40 +0200 Received: from res0010384da36.ericsson.com (dhcp5-109.eed.ericsson.se [164.48.135.109]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id NAA03643; Tue, 29 Jul 2003 13:38:39 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030729045316.024efa58@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 29 Jul 2003 13:39:23 +0200 To: Andrei Gurtov From: Reiner Ludwig Subject: Re: [Tsvwg] reset of backoff with timestamps (RFC2988) Cc: tsvwg@ietf.org In-Reply-To: <3F22F5C2.7050903@cs.helsinki.fi> 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 23:42 26.07.2003, Andrei Gurtov wrote: >Does TSV working group feel that it is appropriate? If yes, a following >correction could be submitted to RFC errata. >http://www.rfc-editor.org/errata.html > >(which can only happen when new data has been sent and acknowledged *or if >the timestamp option is used*) This sounds fine to me. I always understood the text like that, anyway. What this is saying is that the use of the TCP Timestamps option disables both parts of Karn's algorithm. That is, (1) an RTT sample can be taken from the ACK for retransmitted data, and (2) the RTO can be collapsed upon arrival of that ACK, i.e., it can be recomputed from SRTT and RTTVAR. In fact, this is how it had already been implemented in BSD4.4-Lite. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Jul 29 11:11:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25885 for ; Tue, 29 Jul 2003 11:11:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hW7w-0006Iw-Pq for tsvwg-archive@odin.ietf.org; Tue, 29 Jul 2003 11:11:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TFB0DX024228 for tsvwg-archive@odin.ietf.org; Tue, 29 Jul 2003 11:11:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hW6z-0006BB-1s; Tue, 29 Jul 2003 11:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hW6o-0006Aq-AC for tsvwg@optimus.ietf.org; Tue, 29 Jul 2003 11:09: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 LAA25844 for ; Tue, 29 Jul 2003 11:09:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hW6l-0006O2-00 for tsvwg@ietf.org; Tue, 29 Jul 2003 11:09:47 -0400 Received: from [202.97.224.98] (helo=mail.hl.cn) by ietf-mx with smtp (Exim 4.12) id 19hW6k-0006Ny-00 for tsvwg@ietf.org; Tue, 29 Jul 2003 11:09:46 -0400 Received: from mail.hl.cn([127.0.0.1]) by mail.hl.cn(AIMC 2.9.5.6) with SMTP id jm03f26bdf9; Tue, 29 Jul 2003 22:59:12 +0800 Received: from asgard.ietf.org([132.151.6.40]) by mail.hl.cn(AIMC 2.9.5.6) with SMTP id jm333f220e60; Sat, 26 Jul 2003 04:58:57 +0800 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19g8Jf-0002cj-2W for ietf-announce-list@asgard.ietf.org; Fri, 25 Jul 2003 15:33:23 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19g8FL-0002L8-Gj for all-ietf@asgard.ietf.org; Fri, 25 Jul 2003 15:28:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17968; Fri, 25 Jul 2003 15:28:51 -0400 (EDT) Message-Id: <200307251928.PAA17968@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, 25 Jul 2003 15:28:50 -0400 Precedence: bulk X-AIMC-AUTH: (null) X-AIMC-MAILFROM: owner-ietf-announce@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-slowstart-00.txt Sender: tsvwg-admin@ietf.org Errors-To: 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: , --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 : Limited Slow-Start for TCP with Large Congestion Windows Author(s) : S. Floyd Filename : draft-ietf-tsvwg-slowstart-00.txt Pages : 7 Date : 2003-7-25 This note describes an optional modification for TCP's slow-start for use with TCP connections with large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender's MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter- productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link. This note describes Limited Slow-Start as an optional mechanism for limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance for TCP connections with large congestion windows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-slowstart-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-slowstart-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-slowstart-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-7-25152249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-slowstart-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-slowstart-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-25152249.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 Jul 29 13:33:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01843 for ; Tue, 29 Jul 2003 13:33:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYLm-00044r-M0 for tsvwg-archive@odin.ietf.org; Tue, 29 Jul 2003 13:33:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6THXQCJ015650 for tsvwg-archive@odin.ietf.org; Tue, 29 Jul 2003 13:33:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYLN-00041L-K7; Tue, 29 Jul 2003 13:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYLI-000419-PK for tsvwg@optimus.ietf.org; Tue, 29 Jul 2003 13:32:56 -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 NAA01816 for ; Tue, 29 Jul 2003 13:32:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hYLG-0000Gh-00 for tsvwg@ietf.org; Tue, 29 Jul 2003 13:32:54 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 19hYLG-0000Ge-00 for tsvwg@ietf.org; Tue, 29 Jul 2003 13:32:54 -0400 Received: from cs.helsinki.fi (clam.ICSI.Berkeley.EDU [::ffff:192.150.186.141]) (AUTH: PLAIN gurtov, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.cs.helsinki.fi with esmtp; Tue, 29 Jul 2003 20:32:52 +0300 Message-ID: <3F26AFC2.5040003@cs.helsinki.fi> Date: Tue, 29 Jul 2003 10:32:50 -0700 From: Andrei Gurtov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Reiner Ludwig CC: tsvwg@ietf.org Subject: Re: [Tsvwg] reset of backoff with timestamps (RFC2988) References: <5.2.0.9.0.20030729045316.024efa58@mailhost.eed.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Reiner Ludwig wrote: > At 23:42 26.07.2003, Andrei Gurtov wrote: > >> Does TSV working group feel that it is appropriate? If yes, a >> following correction could be submitted to RFC errata. >> http://www.rfc-editor.org/errata.html >> >> (which can only happen when new data has been sent and acknowledged >> *or if the timestamp option is used*) > > > This sounds fine to me. I always understood the text like that, anyway. > > What this is saying is that the use of the TCP Timestamps option > disables both parts of Karn's algorithm. That is, (1) an RTT sample > can be taken from the ACK for retransmitted data, and (2) the RTO can > be collapsed upon arrival of that ACK, i.e., it can be recomputed from > SRTT and RTTVAR. > > In fact, this is how it had already been implemented in BSD4.4-Lite. Updating RTO and reset of the backoff counter are separate issues. For example, old ns2 code updated RTO using RTT samples from retransmitted segments, but backoff was reset only when go-back-N recovery is completed. Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Jul 30 07:21:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26955 for ; Wed, 30 Jul 2003 07:21:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hp1I-0005Jt-Ik for tsvwg-archive@odin.ietf.org; Wed, 30 Jul 2003 07:21:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UBLOJQ020411 for tsvwg-archive@odin.ietf.org; Wed, 30 Jul 2003 07:21:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hp0v-0005IR-4B; Wed, 30 Jul 2003 07: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 19hp0p-0005ID-1F for tsvwg@optimus.ietf.org; Wed, 30 Jul 2003 07:20: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 HAA26952 for ; Wed, 30 Jul 2003 07:20:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hp0o-0006tH-00 for tsvwg@ietf.org; Wed, 30 Jul 2003 07:20:54 -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 19hp0k-0006tE-00 for tsvwg@ietf.org; Wed, 30 Jul 2003 07:20:50 -0400 Received: from esealnt613.al.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 h6UBKlG6029658; Wed, 30 Jul 2003 13:20:47 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XNWHA3; Wed, 30 Jul 2003 13:20:47 +0200 Received: from res0010384da36.ericsson.com (dhcp5-109.eed.ericsson.se [164.48.135.109]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id NAA28638; Wed, 30 Jul 2003 13:20:46 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030730131206.02797a60@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 30 Jul 2003 13:21:31 +0200 To: Andrei Gurtov From: Reiner Ludwig Subject: Re: [Tsvwg] reset of backoff with timestamps (RFC2988) Cc: tsvwg@ietf.org In-Reply-To: <3F26AFC2.5040003@cs.helsinki.fi> References: <5.2.0.9.0.20030729045316.024efa58@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 19:32 29.07.2003, Andrei Gurtov wrote: >>What this is saying is that the use of the TCP Timestamps option disables >>both parts of Karn's algorithm. That is, (1) an RTT sample can be taken >>from the ACK for retransmitted data, and (2) the RTO can be collapsed >>upon arrival of that ACK, i.e., it can be recomputed from SRTT and RTTVAR. >> >>In fact, this is how it had already been implemented in BSD4.4-Lite. > >Updating RTO and reset of the backoff counter are separate issues. Exactly. That's what I wanted to say. The first half of Karn's alg. does not allow taking an RTT sample from an ACK for retransmitted data while the second part of Karn's alg. suggests to *not* collapse the RTO upon that ACK, i.e., to reuse the backed-off RTO when restarting the retransmit timer. And with timestamps none of the two parts are needed any longer. >For example, old ns2 code updated RTO using RTT samples from retransmitted >segments, but backoff was reset only when go-back-N recovery is completed. ... and that was unnecessarily conservative. We had already fixed that in our ns2 code. So, the old ns2 code was not "compliant" with the BSD4.4-Lite code. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg