From exim@www1.ietf.org Fri Aug 1 11:35: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 LAA26731 for ; Fri, 1 Aug 2003 11:35: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 19ibvr-0007js-Dg for tsvwg-archive@odin.ietf.org; Fri, 01 Aug 2003 11:35:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71FZ3R8029731 for tsvwg-archive@odin.ietf.org; Fri, 1 Aug 2003 11:35:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ibvp-0007il-Im; Fri, 01 Aug 2003 11: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 19iWir-0001oQ-S5 for tsvwg@optimus.ietf.org; Fri, 01 Aug 2003 06:01: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 GAA04188 for ; Fri, 1 Aug 2003 06:01:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iWio-0003pn-00 for tsvwg@ietf.org; Fri, 01 Aug 2003 06:01:14 -0400 Received: from mail.uk.thalesgroup.com ([194.128.85.6] helo=ntsc0033.int.rdel.co.uk) by ietf-mx with esmtp (Exim 4.12) id 19iWin-0003pi-00 for tsvwg@ietf.org; Fri, 01 Aug 2003 06:01:13 -0400 Received: from lisc0021.int.rdel.co.uk (lisc0021.int.rdel.co.uk) by ntsc0033.int.rdel.co.uk (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Fri, 1 Aug 2003 11:00:43 +0100 Received: from mail.uk.thalesgroup.com (localhost.localdomain [127.0.0.1]) by lisc0021.int.rdel.co.uk (8.11.6/8.11.6) with ESMTP id h71A0gH00839 for ; Fri, 1 Aug 2003 11:00:42 +0100 Received: from exchange.wvintenltd.com (exchange.int.rdel.co.uk [172.26.96.27]) by mail.uk.thalesgroup.com (8.11.6/8.11.6) with ESMTP id h71A0gZ00828 for ; Fri, 1 Aug 2003 11:00:42 +0100 Received: by exchange.wvintenltd.com with Internet Mail Service (5.5.2655.55) id ; Fri, 1 Aug 2003 11:02:02 +0100 Message-ID: <21CBD72DD137AE4081DA6B3482B25A7A1475F8@exchange.wvintenltd.com> From: "Long, Darren" To: "'tsvwg@ietf.org'" Date: Fri, 1 Aug 2003 11:01:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Tsvwg] The UDP-Lite Protocol - comment Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Is it not possible that the UDP-Lite header may define an arbitrary region in the packet payload for checksum protection, and not restrict this region to starting at the first byte of the payload? I don't think that the current proposed scheme offers enough flexibility, and think that this capability would make a valuable addition. Regards Darren Long THALES OPTRONICS Vicon House, Western Way Bury St. Edmunds Suffolk IP33 3SP United Kingdom Tel.: +44 (0) 1284 750599 Fax: +44 (0) 1284 750598 Web: www.wvintenltd.com This e-mail is intended solely for the above mentioned recipient and it may contain confidential or privileged information. If you have received it in error, please notify us immediately by telephone and delete the email. You must not copy, distribute, disclose or take any action in reliance on it. Whilst every reasonable precaution has been taken, Thales Optronics can not accept liability for any damage which you sustain as a result of software viruses that may be contained in, or attached to this email. -------------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Aug 4 08: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 SMTP id IAA23464 for ; Mon, 4 Aug 2003 08: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 19jeNi-0004W2-5r for tsvwg-archive@odin.ietf.org; Mon, 04 Aug 2003 08:24:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74CO65V017321 for tsvwg-archive@odin.ietf.org; Mon, 4 Aug 2003 08: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 19jeNd-0004VG-G3; Mon, 04 Aug 2003 08: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 19jeMr-0004Ub-73 for tsvwg@optimus.ietf.org; Mon, 04 Aug 2003 08:23:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23445 for ; Mon, 4 Aug 2003 08:23:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jeMq-0000ZH-00 for tsvwg@ietf.org; Mon, 04 Aug 2003 08:23:12 -0400 Received: from [67.38.193.238] (helo=stewart.chicago.il.us) by ietf-mx with esmtp (Exim 4.12) id 19jeMk-0000YP-00 for tsvwg@ietf.org; Mon, 04 Aug 2003 08:23:06 -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 h74CJAQs000841; Mon, 4 Aug 2003 07:20:27 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F2E4F3A.7020500@stewart.chicago.il.us> Date: Mon, 04 Aug 2003 07:19:06 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kacheong Poon CC: tsvwg@ietf.org Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) References: <3F1D8B89.40502@sun.com> In-Reply-To: <3F1D8B89.40502@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kacheong Poon wrote: > 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. > Kacheong: Slowly catching up on a HUGE backlog of email :-o As to the above.. I don't agree yet.. Armando has proposed such to me and I have yet to be convinced.... It may be that it is better in some cases.. but when you start factoring in real failures of a NIC you may find that your failure detection starts to be effected in a adverse way. So far I think Armando has a good point in that possibly FR's may be best NOT to send to an alternate .. but T3's I think may still be best sent to an alternate... Some of Armando's upcoming work will hopefully settle this :> [now back to catching up on the timestamp thread... and then I will comment on that :> ] R _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Aug 4 09: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 SMTP id JAA24398 for ; Mon, 4 Aug 2003 09: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 19jf5C-0005vY-Dp for tsvwg-archive@odin.ietf.org; Mon, 04 Aug 2003 09:09:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74D928u022775 for tsvwg-archive@odin.ietf.org; Mon, 4 Aug 2003 09:09:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jf5B-0005ua-1C; Mon, 04 Aug 2003 09: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 19jf4x-0005uH-6T for tsvwg@optimus.ietf.org; Mon, 04 Aug 2003 09:08:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24381 for ; Mon, 4 Aug 2003 09:08:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jf4v-0000tA-00 for tsvwg@ietf.org; Mon, 04 Aug 2003 09:08:45 -0400 Received: from [67.38.193.238] (helo=stewart.chicago.il.us) by ietf-mx with esmtp (Exim 4.12) id 19jf4p-0000sz-00 for tsvwg@ietf.org; Mon, 04 Aug 2003 09:08:39 -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 h74CZsQs000922; Mon, 4 Aug 2003 07:37:10 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F2E532A.8050601@stewart.chicago.il.us> Date: Mon, 04 Aug 2003 07:35:54 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: Sourabh Ladha , "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 References: <20030716213805.A10144@openss7.org> In-Reply-To: <20030716213805.A10144@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: A question or two below on your response here... Brian F. G. Bidulock wrote: >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 interop >testing that showed that rather special rules were required to accomodate >implementations that could not (or did not) control source address vs. those >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: > I am unclear on these three: >testing the >availability of desintations, > >keeping RTO current on idle destinations, > >and >detecting lost ABORT chunks. > > If you (as proposed by some) include a HB with every packet carrying data what about this breaks the above three items? I would think you would still get an abort if the association was down ... you would with just sending data.. You would get a RTO update on whatever path you sent upon.. idle or not.. and you could still test a destination's reachability... Now I am not yet through this thread ... and I am not convinced either way.. but I just don't get how any of the above three are broken by the HB proposal.. not sure who actually proposed it :> R >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 to >return pertinent timestamps. (SACK is the right place to put it on the >return anyways.) > >--brian > >On Wed, 16 Jul 2003, 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 >> >> > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Aug 4 10:17: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 SMTP id KAA28322 for ; Mon, 4 Aug 2003 10:17: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 19jg94-0008BW-2a for tsvwg-archive@odin.ietf.org; Mon, 04 Aug 2003 10:17:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74EH6sb031456 for tsvwg-archive@odin.ietf.org; Mon, 4 Aug 2003 10:17:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jg90-00088a-2C; Mon, 04 Aug 2003 10: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 19jg8G-00087U-39 for tsvwg@optimus.ietf.org; Mon, 04 Aug 2003 10:16:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27990 for ; Mon, 4 Aug 2003 10:16:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jg8C-0001dt-00 for tsvwg@ietf.org; Mon, 04 Aug 2003 10:16:12 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19jg8B-0001Y4-00 for tsvwg@ietf.org; Mon, 04 Aug 2003 10:16:11 -0400 Received: from yourpjfwswxkvr (12-207-182-216.client.attbi.com [12.207.182.216]) by thebe.your-site.com (Postfix) with ESMTP id 3222524585B; Mon, 4 Aug 2003 10:15:51 -0400 (EDT) From: "Caitlin Bestler" To: "Randall R. Stewart (home)" , "Kacheong Poon" Cc: Subject: RE: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) Date: Mon, 4 Aug 2003 09:13:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3F2E4F3A.7020500@stewart.chicago.il.us> Importance: Normal 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 -----Original Message----- From: tsvwg-admin@ietf.org [mailto:tsvwg-admin@ietf.org]On Behalf Of Randall R. Stewart (home) Sent: Monday, August 04, 2003 7:19 AM To: Kacheong Poon Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) Kacheong Poon wrote: > 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. > Kacheong: Slowly catching up on a HUGE backlog of email :-o As to the above.. I don't agree yet.. Armando has proposed such to me and I have yet to be convinced.... It may be that it is better in some cases.. but when you start factoring in real failures of a NIC you may find that your failure detection starts to be effected in a adverse way. So far I think Armando has a good point in that possibly FR's may be best NOT to send to an alternate .. but T3's I think may still be best sent to an alternate... Some of Armando's upcoming work will hopefully settle this :> [now back to catching up on the timestamp thread... and then I will comment on that :> ] R -------------------------------------- I think the central question here is what is the assumed characteristics of each leg of the path. The current SCTP path algorithm is optimized on the assumption that a drop represents a problem on the path attempted - congestion or failure. So is that a reasonable assumption? And more to the point, if there are special characteristics of a final hop that produce more drops, is it appropriate for them to be solved by end-to-end retransmission? At least some of the arguments for changing the path selection algorithm have cited environments where the final hop is wireless. I do not believe it is a wise strategy to correct a higher error rate over a wireless link with an end-to-end retransmit. Wirelss systems are prone to burst noise. This will be interpeted by the end-to-end flow control algorithms as severe congestion and result in excessive rate trimming. If each hop brings itself to a reasonable standard of probable delivery, and then the consensus is that a single drop probably does not represent a problem with a path, then it might be a good idea to change the algorithm. But I do not think that changing an end-to-end algorithm is a good response if the real problem is confined to a single hop. Caitlin Bestler - http://asomi.com/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Aug 4 10:42: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 SMTP id KAA00241 for ; Mon, 4 Aug 2003 10:42: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 19jgXD-0000YM-Ig for tsvwg-archive@odin.ietf.org; Mon, 04 Aug 2003 10:42:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74Eg3D7002125 for tsvwg-archive@odin.ietf.org; Mon, 4 Aug 2003 10:42:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jgXB-0000X9-Cm; Mon, 04 Aug 2003 10:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jgWT-0000W0-1H for tsvwg@optimus.ietf.org; Mon, 04 Aug 2003 10:41:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29967 for ; Mon, 4 Aug 2003 10:41:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jgHm-00021l-00 for tsvwg@ietf.org; Mon, 04 Aug 2003 10:26:06 -0400 Received: from [67.38.193.238] (helo=stewart.chicago.il.us) by ietf-mx with esmtp (Exim 4.12) id 19jgHf-0001yB-00 for tsvwg@ietf.org; Mon, 04 Aug 2003 10:25:59 -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 h74E37Qs001328; Mon, 4 Aug 2003 09:04:25 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F2E679A.1040106@stewart.chicago.il.us> Date: Mon, 04 Aug 2003 09:03:06 -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: Stephan Baucke CC: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps References: <3F1A5DDE.1060607@ericsson.com> In-Reply-To: <3F1A5DDE.1060607@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Stephan/all: Ok I have now read through this entire thread and I will use Stephan's consolidated issues to comment on things... One large META comment I have to this discussion.. One thing we were VERY careful NOT to do is to require that a Sender Bundle chunks together. It IS required that a receiver understand how to "un-bundle" chunks.. but it is NEVER required that a sender bundle chunks... This is one problem I have with the Time-stamp chunk that has been talked about so-far.. it requires in some aspects that the TS-Response be bundled with SACK's .... near as I can tell... this I do NOT like... Now it is true that most implementations that I have tested with DO bundle things together.. but if I remember right there as been one or two at past bake-offs that did NOT do any bundling... these may have changed but I hate to see such a restriction show up... i.e. that we add something that MUST be bundled... Now on to comments below :> Stephan Baucke wrote: > > 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) Yep, I would imagine that HB's can do a similar job (as mentioned by others) to estimate more often the RTT.. not that I am sure we need this... > > > 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") I think this can be solved as well by sending a HB after doing a retransmission to an alternate path... I put this in the KAME stack a while ago when Armando and I were "debating" some of the "merits" of retransmitting to the same address :> > > > 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) Hmm I do wonder about this... if I am sending 1440 bytes in each data chunk this means the 32 bit TSN space will need 1440 * 2^32 * 8(bits) to wrap... doing a bit of napkin scratch.. on a 10Gigabit ethernet thats more than 4000 seconds before a sequence wrap... would this really be an issue? > > 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?) This can be solved with a sender side algorithm.. the KAME stack includes such a solution that we developed while working on [5]. I don't see that a TS would be needed for this.. they are an alternative method.. but I don't think are required.. > > 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) Yes, a TS could do this.. but so could sending a keyed HB a key for each transmission.. lots of state by the sender and yes there is the issue of how many HB's are being sent... but I am not yet convinced about adding a TS chunk... > > > 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 (?) It seems that a TS is needed for [6] but that [7] and [8] (as you point out) also address this problem... and so I am still not convinced that we need a TS-Chunk :-0 There may even be some other method of doing an Eifel like detection with HB's and or some combination of what as been discussed in this thread.. not sure yet.. I have a lot of catching up to do.. and thinking on this.. But for the moment I don't see a compelling need for a TS-chunk yet... R > > > 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 > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Aug 4 11:28:19 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 SMTP id LAA01419 for ; Mon, 4 Aug 2003 11:28:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jgtW-00014G-MR for tsvwg-archive@odin.ietf.org; Mon, 04 Aug 2003 11:05:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74F56wu004105 for tsvwg-archive@odin.ietf.org; Mon, 4 Aug 2003 11:05:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jgtS-00011D-Sz; Mon, 04 Aug 2003 11: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 19jgsk-0000zR-DC for tsvwg@optimus.ietf.org; Mon, 04 Aug 2003 11:04:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00808 for ; Mon, 4 Aug 2003 11:04:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jgdK-0002Yo-00 for tsvwg@ietf.org; Mon, 04 Aug 2003 10:48:22 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 19jgdJ-0002YY-00 for tsvwg@ietf.org; Mon, 04 Aug 2003 10:48:21 -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 7BE3A6BA58 for ; Mon, 4 Aug 2003 10:47:39 -0400 (EDT) Received: from guns.grc.nasa.gov (guns.grc.nasa.gov [139.88.122.88]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h74ElcrE003613; Mon, 4 Aug 2003 10:47:38 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.grc.nasa.gov (Postfix) with ESMTP id 379AE3BB3CD; Mon, 4 Aug 2003 10:47:38 -0400 (EDT) To: Andrei Gurtov From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] resolving the problem of unnecessary fast retransmits in go-back-N In-Reply-To: <3F25B467.9020609@cs.helsinki.fi> Organization: BBN Technologies/NASA GRC Song-of-the-Day: My City of Ruin Date: Mon, 04 Aug 2003 10:47:38 -0400 Message-Id: <20030804144738.379AE3BB3CD@guns.grc.nasa.gov> Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , (way late, as usual ... sorry) > 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. First, I am not sure I am willing to believe that SACK is not pretty well deployed. 3 years ago I reported 40% of the web clients that hit our web server here at NASA were using SACK (and the trend was growing steadily) [All00]. I don't have good data from that server right now, but I took a quick look at a server at BBN that I have been monitoring for the last ~11 days. In that time I have seen 6545 web connections (yeah, not terribly heavy traffic) and 6183 of the remote hosts (94%) advertised SACK. That seems like pretty good deployment to me. I am not sure what that says about additional "bugfix" tricks. Do we need them? Do we not need them? The above data is not necessarily conclusive or representative. The changes would add complexity to a TCP implementation. On the other hand, not that much complexity and maybe would provide a decent enough win. But, when do we stop patching known suboptimal recovery? Etc., Etc., Etc. ?????? > 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. I am trying to wrap my head around this and cannot yet do so. Can you define "ack_new" and "ack_prev"? Are these the two ACKs before duplicate ACKs start rolling in? > 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. Timestamps are less prevalent (by default) than SACK is, I think (11% of the connection in the BBN trace described above, which is in the ballpark of what was reported in [All00], too). So, I am not sure I think this is a practical approach. [All00] Mark Allman. A Web Server's View of the Transport Layer, ACM Computer Communication Review, 30(5), October 2000. http://roland.grc.nasa.gov/~mallman/papers/webobs-ccr.ps 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 Mon Aug 4 11:32: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 SMTP id LAA01573 for ; Mon, 4 Aug 2003 11:32: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 19jhJc-0001tz-Lo for tsvwg-archive@odin.ietf.org; Mon, 04 Aug 2003 11:32:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74FW4Qc007273 for tsvwg-archive@odin.ietf.org; Mon, 4 Aug 2003 11: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 19jhJa-0001rg-Ag; Mon, 04 Aug 2003 11: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 19jhIu-0001qN-Ll for tsvwg@optimus.ietf.org; Mon, 04 Aug 2003 11:31:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01516 for ; Mon, 4 Aug 2003 11:31:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jhAW-0002tB-00 for tsvwg@ietf.org; Mon, 04 Aug 2003 11:22:40 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19jhAV-0002t8-00 for tsvwg@ietf.org; Mon, 04 Aug 2003 11:22:39 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 905AC3292F; Mon, 4 Aug 2003 11:22:39 -0400 (EDT) Received: from louie.udel.edu (louie.udel.edu [128.4.40.12]) by mail.eecis.udel.edu (Postfix) with ESMTP id CE3BB32915; Mon, 4 Aug 2003 11:22:38 -0400 (EDT) Date: Mon, 4 Aug 2003 11:22:38 -0400 (EDT) From: Sourabh Ladha X-X-Sender: To: "Randall R. Stewart (home)" Cc: Stephan Baucke , Subject: Re: [Tsvwg] SCTP Timestamps In-Reply-To: <3F2E679A.1040106@stewart.chicago.il.us> 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: , Just a minor comment. > > 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?) > > This can be solved with a sender side algorithm.. the KAME stack > includes such a solution that we developed while working on [5]. I don't > see that a TS would be needed for this.. they are an alternative > method.. but I > don't think are required.. Congestion window overgrowth caused by retransmission ambuiguity will not be solved by CACC in [5]. I believe that changeover specific cwnd overgrowth is solved by [5]. -Sourabh > > [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 > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Aug 5 09: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 JAA11051 for ; Tue, 5 Aug 2003 09: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 19k2DR-0007dx-Ei for tsvwg-archive@odin.ietf.org; Tue, 05 Aug 2003 09:51:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Dp5r1029377 for tsvwg-archive@odin.ietf.org; Tue, 5 Aug 2003 09:51:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2DO-0007dW-3f; Tue, 05 Aug 2003 09: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 19k2CS-0007cX-KI for tsvwg@optimus.ietf.org; Tue, 05 Aug 2003 09:50: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 JAA11007 for ; Tue, 5 Aug 2003 09:49:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2CQ-00023u-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 09:50:02 -0400 Received: from [67.38.193.238] (helo=stewart.chicago.il.us) by ietf-mx with esmtp (Exim 4.12) id 19k2CP-00023a-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 09:50:01 -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 h75DiZQs008752; Tue, 5 Aug 2003 08:44:38 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F2FB4C3.8010203@stewart.chicago.il.us> Date: Tue, 05 Aug 2003 08:44:35 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Armando L. Caro Jr." CC: Schruefer Wolfgang , "'ladha@mail.eecis.udel.edu'" , "'Stephan Baucke'" , tsvwg@ietf.org Subject: Re: AW: [Tsvwg] SCTP Timestamps References: In-Reply-To: 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 Armando L. Caro Jr. wrote: >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. > > Armando: A question for you, not that I support the bit approach, I don't understand why one bit is not enough. 1) I know where the primary destionation is 2) I know at any time where I last sent the chunk and if the chunk was FR'd or not Between all of these known's I don't see that more than one bit would be required to detect the FIRST retransmission no matter if it was sent to the primary or secondary.. R >[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 > > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Aug 5 09:52: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 JAA11076 for ; Tue, 5 Aug 2003 09:52: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 19k2EL-0007ln-5k for tsvwg-archive@odin.ietf.org; Tue, 05 Aug 2003 09:52:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Dq1JS029856 for tsvwg-archive@odin.ietf.org; Tue, 5 Aug 2003 09:52:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2EL-0007lS-1S; Tue, 05 Aug 2003 09: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 19k2DR-0007dl-6h for tsvwg@optimus.ietf.org; Tue, 05 Aug 2003 09:51: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 JAA11046 for ; Tue, 5 Aug 2003 09:51:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2DP-00024x-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 09:51:03 -0400 Received: from [67.38.193.238] (helo=stewart.chicago.il.us) by ietf-mx with esmtp (Exim 4.12) id 19k2DO-00024q-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 09:51:02 -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 h75DnxQs008791; Tue, 5 Aug 2003 08:50:00 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F2FB607.4070605@stewart.chicago.il.us> Date: Tue, 05 Aug 2003 08:49:59 -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: Caitlin Bestler CC: "Armando L. Caro Jr." , tsvwg@ietf.org Subject: Re: [Tsvwg] Meaning of path failure (was re SCTP Timestamps) References: In-Reply-To: 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 Caitlin Bestler wrote: > > 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: As always an interesting comment from you..( yes I have a lot of other unread email that you have sent to me .. I will get to it I promise :>) Now I understand the logic here and I have two comments... a) Being able to seperate a L2 drop for NON congestion reasons from the "default" assumption would be a nice thing.. I actually will have a proposal to put forward on this later on when I can get the cycles to clean up the drafty draft I have in the works somewhere :> b) If your example L2 environment just delivered the packet late (as I assume it must have) then what you have is a spurious retransmission.. the very thing that Eifel is trying to detect... Just a thought or two :> R > > > Caitlin Bestler - cait@asomi.com - http://asomi.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 Tue Aug 5 13: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 NAA18989 for ; Tue, 5 Aug 2003 13:02: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 19k5CI-0007Ub-05 for tsvwg-archive@odin.ietf.org; Tue, 05 Aug 2003 13:02:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75H25aC028783 for tsvwg-archive@odin.ietf.org; Tue, 5 Aug 2003 13:02:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5CD-0007TD-1O; Tue, 05 Aug 2003 13: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 19k5BO-0007Sf-IH for tsvwg@optimus.ietf.org; Tue, 05 Aug 2003 13:01: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 NAA18954 for ; Tue, 5 Aug 2003 13:01:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k5BM-0003rb-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 13:01:08 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19k5BL-0003rM-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 13:01:08 -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 h75H0V5D000928 for ; Tue, 5 Aug 2003 12:00:32 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F2FE2AF.30605@stewart.chicago.il.us> Date: Tue, 05 Aug 2003 12:00:31 -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: TSV WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] PR-SCTP updated draft Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all: I think I have now gotten all of the minor changes in to the WG last call on the PR-SCTP document. Please have a look at the html diff at: http://www.sctp.org under the RFC/internet draft tab you will find at the bottom a rfc-chgbar/diff that highlights the few changes.. Please let me know if I got everyones comments.. I would like to get this in so that we can move the document forward.. Thanks R --- Randall Stewart _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Aug 5 14: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 OAA21479 for ; Tue, 5 Aug 2003 14: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 19k6WV-00023Z-OI for tsvwg-archive@odin.ietf.org; Tue, 05 Aug 2003 14:27:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75IR3DV007899 for tsvwg-archive@odin.ietf.org; Tue, 5 Aug 2003 14:27:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k6WT-00022e-KE; Tue, 05 Aug 2003 14: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 19k6Vr-00022J-IQ for tsvwg@optimus.ietf.org; Tue, 05 Aug 2003 14:26: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 OAA21466 for ; Tue, 5 Aug 2003 14:26:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k6Vp-0004WJ-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 14:26:21 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19k6Vn-0004WG-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 14:26:19 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h75IQHC9013265; Tue, 5 Aug 2003 11:26:17 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h75IQGaQ004083; Tue, 5 Aug 2003 13:26:16 -0500 Message-ID: <3F2FF6B6.F65D52@motorola.com> Date: Tue, 05 Aug 2003 13:25:58 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Randall R. Stewart (home)" CC: TSV WG list Subject: Re: [Tsvwg] PR-SCTP updated draft References: <3F2FE2AF.30605@stewart.chicago.il.us> 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, Randy, Some minor editorial comments: 1. The new implementation note: " IMPLEMENTATION NOTE: An implementation may wish to limit the number of duplicate FORWARD TSN'S sent by either sending a duplicate FORWARD TSN every other SACK or waiting a full RTT before sending a duplicate FORWARD TSN. " may read better in the following form: " IMPLEMENTATION NOTE: An implementation may wish to limit the number of duplicate FORWARD TSN chunks it sends by either only sending a duplicate FORWARD TSN every other SACK or waiting for a full RTT before sending a duplicate FORWARD TSN. " 2. The use of "forward" and "FORWARD" is inconsistent in a couple of places. - page 12, in para C4) "number in the forwarded TSN. ..." should be "number in the FORWARD TSN. ..." - page 13, in para F2) "for generating a forward TSN to be ..." should be "for generating a FORWARD TSN to be ..." I am referring to the old page numbers in -00 here but they should be close or the same in the -01 version you are working on. -Q "Randall R. Stewart (home)" wrote: > > Hi all: > > I think I have now gotten all of the minor changes in > to the WG last call on the PR-SCTP document. Please have a > look at the html diff at: > > http://www.sctp.org > > under the RFC/internet draft tab you will find at the > bottom a rfc-chgbar/diff that highlights the few > changes.. > > Please let me know if I got everyones comments.. I would like > to get this in so that we can move the document forward.. > > Thanks > > R > --- > > Randall Stewart > > _______________________________________________ > 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 Aug 5 15:14: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 PAA24582 for ; Tue, 5 Aug 2003 15:14: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 19k7Fz-0004Ek-3G for tsvwg-archive@odin.ietf.org; Tue, 05 Aug 2003 15:14:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75JE32P016282 for tsvwg-archive@odin.ietf.org; Tue, 5 Aug 2003 15:14:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k7Fx-0004Dr-Ef; Tue, 05 Aug 2003 15: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 19k7F5-0004CG-RU for tsvwg@optimus.ietf.org; Tue, 05 Aug 2003 15:13: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 PAA24449 for ; Tue, 5 Aug 2003 15:13:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k7F4-00050R-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 15:13:06 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19k7F3-00050H-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 15:13:05 -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 h75JCT5D001777; Tue, 5 Aug 2003 14:12:29 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F30019B.5080100@stewart.chicago.il.us> Date: Tue, 05 Aug 2003 14:12:27 -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: Qiaobing Xie CC: TSV WG list Subject: Re: [Tsvwg] PR-SCTP updated draft References: <3F2FE2AF.30605@stewart.chicago.il.us> <3F2FF6B6.F65D52@motorola.com> In-Reply-To: <3F2FF6B6.F65D52@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: >Hi, Randy, > >Some minor editorial comments: > >1. The new implementation note: > >" IMPLEMENTATION NOTE: An implementation may wish to limit the > number of duplicate FORWARD TSN'S sent by either sending a > duplicate FORWARD TSN every other SACK or waiting a full RTT > before sending a duplicate FORWARD TSN. >" > >may read better in the following form: > >" IMPLEMENTATION NOTE: An implementation may wish to limit the > number of duplicate FORWARD TSN chunks it sends by either only > sending a duplicate FORWARD TSN every other SACK or waiting for > a full RTT before sending a duplicate FORWARD TSN. >" > Sound good :> > >2. The use of "forward" and "FORWARD" is inconsistent in a couple of >places. > > - page 12, in para C4) > > "number in the forwarded TSN. ..." > > should be > > "number in the FORWARD TSN. ..." > > - page 13, in para F2) > > "for generating a forward TSN to be ..." > > should be > > "for generating a FORWARD TSN to be ..." > >I am referring to the old page numbers in -00 here but they should be >close or the same in the -01 version you are working on. > Since its XML I don't have page numbers :> but thats ok.. I found them all :>> Good catchs.. I will have put up an update with these changes on the web site :> R > >-Q > >"Randall R. Stewart (home)" wrote: > > >>Hi all: >> >>I think I have now gotten all of the minor changes in >>to the WG last call on the PR-SCTP document. Please have a >>look at the html diff at: >> >>http://www.sctp.org >> >>under the RFC/internet draft tab you will find at the >>bottom a rfc-chgbar/diff that highlights the few >>changes.. >> >>Please let me know if I got everyones comments.. I would like >>to get this in so that we can move the document forward.. >> >>Thanks >> >>R >>--- >> >>Randall Stewart >> >>_______________________________________________ >>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 Tue Aug 5 16:31: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 QAA27668 for ; Tue, 5 Aug 2003 16:31: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 19k8SY-0007JO-PI for tsvwg-archive@odin.ietf.org; Tue, 05 Aug 2003 16:31:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75KV6rb028082 for tsvwg-archive@odin.ietf.org; Tue, 5 Aug 2003 16:31:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8ST-0007IB-W8; Tue, 05 Aug 2003 16: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 19k8S7-0007HP-C1 for tsvwg@optimus.ietf.org; Tue, 05 Aug 2003 16:30:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27637 for ; Tue, 5 Aug 2003 16:30:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k8S5-0005eR-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 16:30:37 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 19k8S4-0005eN-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 16:30:36 -0400 Received: from phys-ha1mpka.eng.sun.com ([129.146.14.50]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h75KUT3u001174 for ; Tue, 5 Aug 2003 14:30: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 NAA04332 for ; Tue, 5 Aug 2003 13:30:03 -0700 (PDT) Message-ID: <3F3013CB.3020505@sun.com> Date: Tue, 05 Aug 2003 13:30:03 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 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: <3F1D8B89.40502@sun.com> <3F2E4F3A.7020500@stewart.chicago.il.us> In-Reply-To: <3F2E4F3A.7020500@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Randall R. Stewart (home) wrote: > Slowly catching up on a HUGE backlog of email :-o > > As to the above.. I don't agree yet.. Armando has proposed such to me > and I have yet to be convinced.... > > It may be that it is better in some cases.. but when you start factoring in > real failures of a NIC you may find that your failure detection starts to > be effected in a adverse way. So far I think Armando has a good point > in that possibly FR's may be best NOT to send to an alternate .. but > T3's I think may still be best sent to an alternate... If I remember correctly, the fast retransmit case was discussed some time ago in either tsvwg or sctp-impl. The consensus is to retransmit to the original address. I thought every implementations is already doing this... I guess NIC failure happens very infrequently when compared to congestion and spurious timeout. I don't think it is a good suggestion to design the timeout retransmission around an uncommon case. And it seems to me that the correct way to handle a NIC failure is to use ASCONF to tell the peer to either remove those IP addresses associated with the failed NIC or to change the primary path if it is to the failed NIC. One may ask why such mechanism is not included in the original spec... -- K. Poon. kacheong.poon@sun.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Aug 5 17:34: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 RAA29492 for ; Tue, 5 Aug 2003 17:34: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 19k9RW-0001TN-Gt for tsvwg-archive@odin.ietf.org; Tue, 05 Aug 2003 17:34:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75LY6wB005638 for tsvwg-archive@odin.ietf.org; Tue, 5 Aug 2003 17:34:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k9RR-0001S3-Lf; Tue, 05 Aug 2003 17: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 19k9RJ-0001Ri-86 for tsvwg@optimus.ietf.org; Tue, 05 Aug 2003 17:33: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 RAA29481 for ; Tue, 5 Aug 2003 17:33:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k9RG-00065F-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 17:33:50 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19k9RG-00065B-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 17:33:50 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h75LXnLe000988; Tue, 5 Aug 2003 14:33:50 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h75LXnaQ014292; Tue, 5 Aug 2003 16:33:49 -0500 Message-ID: <3F3022AA.CF63147F@motorola.com> Date: Tue, 05 Aug 2003 16:33:30 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kacheong Poon CC: tsvwg@ietf.org Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) References: <3F1D8B89.40502@sun.com> <3F2E4F3A.7020500@stewart.chicago.il.us> <3F3013CB.3020505@sun.com> 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 Kacheong Poon wrote: ... > I guess NIC failure happens very infrequently when compared to > congestion and spurious timeout. ... It depends :-) For example, congestion is only a remote possibility in many (if not all) commercial telecomm networks which is THE primary use area for SCTP at present time (e.g., SIGTRAN, 3GPP). This is due to the over-provisioning of bandwidth in all such networks. However, in those types of networks, one of the key system requirements is the five 9's system availability (99.999% availability). The only way to achieve five 9's is to use fault tolerant design including redundant NICs and cabling. But those extra cost spent on redundant hardware will only be a waste if fault recovery is too slow. In such cases, retrans to alternative is very effective in speeding up fault recover. regards, -Qiaobing _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Aug 5 17:44: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 RAA29704 for ; Tue, 5 Aug 2003 17:44: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 19k9b8-0001xY-2Z for tsvwg-archive@odin.ietf.org; Tue, 05 Aug 2003 17:44:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Li2KY007497 for tsvwg-archive@odin.ietf.org; Tue, 5 Aug 2003 17:44:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k9b7-0001wo-3H; Tue, 05 Aug 2003 17: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 19k9b5-0001wd-V6 for tsvwg@optimus.ietf.org; Tue, 05 Aug 2003 17:43: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 RAA29701 for ; Tue, 5 Aug 2003 17:43:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k9b3-00068v-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 17:43:57 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 19k9b2-00068s-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 17:43:56 -0400 Received: from phys-ha1mpka.eng.sun.com ([129.146.14.50]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h75Lhu3u018172 for ; Tue, 5 Aug 2003 15:43:56 -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 OAA27811 for ; Tue, 5 Aug 2003 14:43:30 -0700 (PDT) Message-ID: <3F302502.3050904@sun.com> Date: Tue, 05 Aug 2003 14:43:30 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 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: <3F1D8B89.40502@sun.com> <3F2E4F3A.7020500@stewart.chicago.il.us> <3F3013CB.3020505@sun.com> <3F3022AA.CF63147F@motorola.com> In-Reply-To: <3F3022AA.CF63147F@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: > It depends :-) For example, congestion is only a remote possibility in > many (if not all) commercial telecomm networks which is THE primary use > area for SCTP at present time (e.g., SIGTRAN, 3GPP). This is due to the > over-provisioning of bandwidth in all such networks. However, in those > types of networks, one of the key system requirements is the five 9's > system availability (99.999% availability). The only way to achieve five > 9's is to use fault tolerant design including redundant NICs and > cabling. But those extra cost spent on redundant hardware will only be a > waste if fault recovery is too slow. In such cases, retrans to > alternative is very effective in speeding up fault recover. Then in this specific environment (well, SCTP is supposed to be a general purpose transport protocol afterall), I'd suggest those SCTP stacks to support ASCONF so that the retransmission can automatically be made to an alternate address. This seems to be a better way to handle it than relying on a "guess" of NIC failure as there is no need to guess at all. Is this a problem to have such requirement on those stacks operating in the telecomm world? My guess (we are all guessing (-:) is not... -- K. Poon. kacheong.poon@sun.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Aug 5 18:24: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 SAA01727 for ; Tue, 5 Aug 2003 18:24: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 19kAE0-00031c-42 for tsvwg-archive@odin.ietf.org; Tue, 05 Aug 2003 18:24:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75MOCVW011627 for tsvwg-archive@odin.ietf.org; Tue, 5 Aug 2003 18:24:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kADp-00030l-9p; Tue, 05 Aug 2003 18: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 19kADk-00030I-1F for tsvwg@optimus.ietf.org; Tue, 05 Aug 2003 18:23: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 SAA01717 for ; Tue, 5 Aug 2003 18:23:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kADP-0006NL-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 18:23:35 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19kADO-0006NI-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 18:23:34 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h75MNUSD025674; Tue, 5 Aug 2003 15:23:31 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h75MNUaQ017628; Tue, 5 Aug 2003 17:23:30 -0500 Message-ID: <3F302E50.1953A739@motorola.com> Date: Tue, 05 Aug 2003 17:23:12 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kacheong Poon CC: tsvwg@ietf.org Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) References: <3F1D8B89.40502@sun.com> <3F2E4F3A.7020500@stewart.chicago.il.us> <3F3013CB.3020505@sun.com> <3F3022AA.CF63147F@motorola.com> <3F302502.3050904@sun.com> 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 Kacheong Poon wrote: > > Qiaobing Xie wrote: > > > It depends :-) For example, congestion is only a remote possibility in > > many (if not all) commercial telecomm networks which is THE primary use > > area for SCTP at present time (e.g., SIGTRAN, 3GPP). This is due to the > > over-provisioning of bandwidth in all such networks. However, in those > > types of networks, one of the key system requirements is the five 9's > > system availability (99.999% availability). The only way to achieve five > > 9's is to use fault tolerant design including redundant NICs and > > cabling. But those extra cost spent on redundant hardware will only be a > > waste if fault recovery is too slow. In such cases, retrans to > > alternative is very effective in speeding up fault recover. > > Then in this specific environment (well, SCTP is supposed to > be a general purpose transport protocol afterall), I'd suggest > those SCTP stacks to support ASCONF so that the retransmission > can automatically be made to an alternate address. This seems > to be a better way to handle it than relying on a "guess" of NIC > failure as there is no need to guess at all. > > Is this a problem to have such requirement on those stacks > operating in the telecomm world? My guess (we are all guessing (-:) > is not... K. Are we **absolutely** sure that whatever we intended to solve in this discussion has to include giving up this "retrans to alternative" behavior which is so key to telecomm folks? Is there a solution that will let those folks to co-exist in this SCTP world while we are perfecting its congestion control here? I am not ready to wave the white flag yet. I'd encourage the CC perfectionists to continue work and find a solution that will satisfy the CC behaviors while not sacrificing a very real advantage of SCTP for telecom folks. Then we would have a WIN-WIN solution and I think we can do it! (I know I sound a little like a promotional speaker, my apology :) regards, -Qiaobing > > -- > > 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 Tue Aug 5 18:48: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 SAA02236 for ; Tue, 5 Aug 2003 18:48: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 19kAb4-0003nN-Ak for tsvwg-archive@odin.ietf.org; Tue, 05 Aug 2003 18:48:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Mm2og014555 for tsvwg-archive@odin.ietf.org; Tue, 5 Aug 2003 18:48:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kAb2-0003me-PZ; Tue, 05 Aug 2003 18:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kAaT-0003m4-An for tsvwg@optimus.ietf.org; Tue, 05 Aug 2003 18:47: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 SAA02196 for ; Tue, 5 Aug 2003 18:47:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kAaQ-0006T0-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 18:47:22 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19kAaP-0006Sx-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 18:47:21 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h75MlLSD008378; Tue, 5 Aug 2003 15:47:21 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h75MlLaQ001823; Tue, 5 Aug 2003 17:47:21 -0500 Message-ID: <3F3033E6.84A8F7B8@motorola.com> Date: Tue, 05 Aug 2003 17:47:02 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kacheong Poon CC: tsvwg@ietf.org Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) References: <3F1D8B89.40502@sun.com> <3F2E4F3A.7020500@stewart.chicago.il.us> <3F3013CB.3020505@sun.com> <3F3022AA.CF63147F@motorola.com> <3F302502.3050904@sun.com> 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 Kacheong Poon wrote: > ...I'd suggest > those SCTP stacks to support ASCONF so that the retransmission > can automatically be made to an alternate address. This seems > to be a better way to handle it than relying on a "guess" of NIC > failure as there is no need to guess at all. So you want to rely on an external monitor/detector mechanism at the peer endpoint that will tell the peer SCTP stack a NIC is bad and then the remote stack will do a "change primary addr" through ASCONF so that the local endpoint will start to move the traffic to an alternative dest addr? Ok, now you have no need to guess since the remote external detector is doing the "guessing" :-) But this would essentially remove most of the SCTP's auto path failure detection / recovery capabilities and take out a big chunk of SCTP's multi-homing advantage. I think this is too costly for whatever we are trying to gain here. regards, -Qiaobing _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Aug 5 19:15: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 TAA02623 for ; Tue, 5 Aug 2003 19:15: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 19kB1D-0004Vc-T8 for tsvwg-archive@odin.ietf.org; Tue, 05 Aug 2003 19:15:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75NF3vO017331 for tsvwg-archive@odin.ietf.org; Tue, 5 Aug 2003 19:15:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kB1B-0004Ul-9z; Tue, 05 Aug 2003 19: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 19kB0k-0004T5-Ej for tsvwg@optimus.ietf.org; Tue, 05 Aug 2003 19:14: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 TAA02596 for ; Tue, 5 Aug 2003 19:14:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kB0j-0006a3-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 19:14:33 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19kB0i-0006Zz-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 19:14:32 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h75NETsw009797; Tue, 5 Aug 2003 16:14:29 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h75NESaQ019565; Tue, 5 Aug 2003 18:14:28 -0500 Message-ID: <3F303A42.BF87E039@motorola.com> Date: Tue, 05 Aug 2003 18:14:10 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Randall R. Stewart (home)" CC: Caitlin Bestler , "Armando L. Caro Jr." , tsvwg@ietf.org Subject: Re: [Tsvwg] Meaning of path failure (was re SCTP Timestamps) References: <3F2FB607.4070605@stewart.chicago.il.us> 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 Both Randy and Caitlin's comments below are indeed very interesting. I wonder if we still have consensus that SCTP is still an end-to-end, L3 transport protocol. If so, I believe the reason we call it end-to-end is because we assume there is a virtual, structure-less, vairable bandwidth, end-to-end pipe underneath the L3 transport. Now, I start to see people talking about "what if the last hop of the pipe [between two SCTP ends] is of X or Y nature". To me, at layer 3 I don't see any internal structure of the L2 pipe execpt of the assumption that it is an end-to-end pipe. So where is that "last hop" people are referring to? If this virtual pipe abstraction no longer holds, then we are in a new era of layering principle. If it is still valid, then the "last hop" is invisible to SCTP and needs to remain so. And the nature of the "last hop" needs to be addressed in L2 groups (e.g., trigtran). In short, I fail to see how we could succeed by tweaking L3 SCTP to address some L2 "last hop" characteristics. regards, -Qiaobing "Randall R. Stewart (home)" wrote: > > Caitlin Bestler wrote: > > > > > 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: > > As always an interesting comment from you..( yes I have a lot of > other unread email that you have sent to me .. I will get to it I > promise :>) > > Now I understand the logic here and I have two comments... > > a) Being able to seperate a L2 drop for NON congestion reasons from the > "default" assumption would be a nice thing.. I actually will have a > proposal > to put forward on this later on when I can get the cycles to clean > up the drafty > draft I have in the works somewhere :> > > b) If your example L2 environment just delivered the packet late (as I > assume it > must have) then what you have is a spurious retransmission.. the > very thing > that Eifel is trying to detect... > > Just a thought or two :> > > R > > > > > > > Caitlin Bestler - cait@asomi.com - http://asomi.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 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Aug 5 19: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 TAA03089 for ; Tue, 5 Aug 2003 19: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 19kBFj-00053V-Rf for tsvwg-archive@odin.ietf.org; Tue, 05 Aug 2003 19:30:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75NU3Rg019413 for tsvwg-archive@odin.ietf.org; Tue, 5 Aug 2003 19:30:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kBFh-00052F-4c; Tue, 05 Aug 2003 19: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 19kBEx-00051W-H3 for tsvwg@optimus.ietf.org; Tue, 05 Aug 2003 19:29: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 TAA03073 for ; Tue, 5 Aug 2003 19:29:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kBEv-0006gf-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 19:29:13 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19kBEv-0006gH-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 19:29:13 -0400 Received: from asomi.com (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id ED3782464DA; Tue, 5 Aug 2003 19:28:52 -0400 (EDT) Date: Tue, 5 Aug 2003 18:28:37 -0500 Subject: Re: [Tsvwg] Meaning of path failure (was re SCTP Timestamps) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Randall R. Stewart (home)" , "Armando L. Caro Jr." , tsvwg@ietf.org To: Qiaobing Xie From: Caitlin Bestler In-Reply-To: <3F303A42.BF87E039@motorola.com> Message-Id: <89F77125-C79C-11D7-8B42-003065D48EE0@asomi.com> 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 On Tuesday, August 5, 2003, at 06:14 PM, Qiaobing Xie wrote: > In short, I fail to see how we could succeed by tweaking L3 SCTP to > address some L2 "last hop" characteristics. It is really a matter of what the best interpretation of the "end to end" assumption is. Most of what has been written recently emphasizes that the L2 layer should not attempt to solve L3 problems. But it strikes me that you can go too far in the opposite direction. When a given L2 hop is significantly more likely to have bursty transmission errors than the Internet as a whole, I really think we need to question whether those problems should be solved on and end-to-end basis. That is especially so if there is a suggestion that the end-to-end algorithms need to adjust because they react incorrectly to bursty noise on one hop. If a typical path does only shows frequent drops when there are failures and/or congestion, then SCTP assuming a shift in path remains the correct strategy. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Aug 5 20: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 UAA04079 for ; Tue, 5 Aug 2003 20:34: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 19kCFg-0006lC-JQ for tsvwg-archive@odin.ietf.org; Tue, 05 Aug 2003 20:34:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h760Y4E6025972 for tsvwg-archive@odin.ietf.org; Tue, 5 Aug 2003 20:34:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kCFd-0006k8-1Y; Tue, 05 Aug 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 19kCFZ-0006jx-H9 for tsvwg@optimus.ietf.org; Tue, 05 Aug 2003 20: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 UAA04066 for ; Tue, 5 Aug 2003 20:33:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kCFW-0006wv-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 20:33:55 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19kCFW-0006wp-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 20:33:54 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h760XcSD003439; Tue, 5 Aug 2003 17:33:38 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h760XbaQ006731; Tue, 5 Aug 2003 19:33:37 -0500 Message-ID: <3F304CCF.AD18F249@motorola.com> Date: Tue, 05 Aug 2003 19:33:19 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Caitlin Bestler CC: "Randall R. Stewart (home)" , "Armando L. Caro Jr." , tsvwg@ietf.org Subject: Re: [Tsvwg] Meaning of path failure (was re SCTP Timestamps) References: <89F77125-C79C-11D7-8B42-003065D48EE0@asomi.com> 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 Caitlin Bestler wrote: ... > But it strikes me that you can go too far in the opposite > direction. When a given L2 hop is significantly more likely > to have bursty transmission errors than the Internet as > a whole, I really think we need to question whether those > problems should be solved on and end-to-end basis. > > That is especially so if there is a suggestion that the > end-to-end algorithms need to adjust because they react > incorrectly to bursty noise on one hop. I *think* we are in agreement here :-) SCTP CC (as well that of TCP) is designed as an end-to-end mechanism. Therefore, I'd think any tweak on this end-to-end mechanism will by definition have an end-to-end impact through the entire pipe. So, if we can really devise a particular tweak that is "just right" to address the particular noise/burst pattern of one hop in the pipe, in all the likelihood, this tweak will be suboptimal or even adversely impact the other hops in the pipe. And this would not be good. regards, -Qiaobing _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Aug 5 21:35: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 VAA05555 for ; Tue, 5 Aug 2003 21:35: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 19kDCi-0008TQ-8l for tsvwg-archive@odin.ietf.org; Tue, 05 Aug 2003 21:35:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h761Z4Cl032569 for tsvwg-archive@odin.ietf.org; Tue, 5 Aug 2003 21:35:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kDCf-0008SY-3g; Tue, 05 Aug 2003 21: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 19kDCR-0008Rr-HD for tsvwg@optimus.ietf.org; Tue, 05 Aug 2003 21:34: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 VAA05509 for ; Tue, 5 Aug 2003 21:34:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kDCO-0007IB-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 21:34:44 -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 19kDCN-0007I8-00 for tsvwg@ietf.org; Tue, 05 Aug 2003 21:34:43 -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; Wed, 06 Aug 2003 04:34:32 +0300 Message-ID: <3F305B27.2080107@cs.helsinki.fi> Date: Tue, 05 Aug 2003 18:34:31 -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: mallman@grc.nasa.gov CC: tsvwg@ietf.org Subject: Re: [Tsvwg] resolving the problem of unnecessary fast retransmits in go-back-N References: <20030804144738.379AE3BB3CD@guns.grc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > >First, I am not sure I am willing to believe that SACK is not pretty >well deployed. 3 years ago I reported 40% of the web clients that >hit our web server here at NASA were using SACK (and the trend was >growing steadily) [All00]. I don't have good data from that server >right now, but I took a quick look at a server at BBN that I have >been monitoring for the last ~11 days. In that time I have seen >6545 web connections (yeah, not terribly heavy traffic) and 6183 of >the remote hosts (94%) advertised SACK. That seems like pretty good >deployment to me. > I don't claim to know the answer, but what data on Sally's page tells is that although many SYNs have a SACK-perm option only few SYN-ACKs have it. It may mean that either web servers are using some old OS that do not support SACK or that they don't want to bother with extra overhead of keeping SACK state. If SACK is universally deployed why would we be updating NewReno RFC? >I am not sure what that says about additional "bugfix" tricks. Do >we need them? Do we not need them? The above data is not >necessarily conclusive or representative. The changes would add >complexity to a TCP implementation. On the other hand, not that >much complexity and maybe would provide a decent enough win. But, >when do we stop patching known suboptimal recovery? Etc., Etc., >Etc. ?????? > > I'll send some scenarios next week that might motivate the need for it. I think that since implementing them is not a big deal and the NewReno draft anyway discusses the issue it might be a good place to mention them. In the current ns2 snapshot test-all-tcpOptions timeouts_newreno (shows DUPACKs due to a lost packet) test-all-newreno reno2 (shows DUPACKs due to duplicate segments ) >>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. >> >> > >I am trying to wrap my head around this and cannot yet do so. Can >you define "ack_new" and "ack_prev"? Are these the two ACKs before >duplicate ACKs start rolling in? > ack_new has the same cum ACK as DUPACKs, ack_prev is the previous ACK before DUPACKs >Timestamps are less prevalent (by default) than SACK is, I think >(11% of the connection in the BBN trace described above, which is in >the ballpark of what was reported in [All00], too). So, I am not >sure I think this is a practical approach. > Well, we did publish Eifel based on timestamps. I wouldn't be surprised if timeouts due to bugfix are far more common than spurious timeouts in the Internet. Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Aug 6 01:20: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 BAA09360 for ; Wed, 6 Aug 2003 01:20: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 19kGiS-0005gD-M3 for tsvwg-archive@odin.ietf.org; Wed, 06 Aug 2003 01:20:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h765K4w4021826 for tsvwg-archive@odin.ietf.org; Wed, 6 Aug 2003 01:20:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kGiP-0005fn-QD; Wed, 06 Aug 2003 01: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 19kGiO-0005fI-78 for tsvwg@optimus.ietf.org; Wed, 06 Aug 2003 01:20: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 BAA09354 for ; Wed, 6 Aug 2003 01:19:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kGiL-0000PA-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 01:19:57 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[VkqtCu0Gzzy7sZjxG34BHCLd5rnzbOKt]) by ietf-mx with esmtp (Exim 4.12) id 19kGiK-0000P7-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 01:19:56 -0400 Received: from ns.pigworks.openss7.net (IDENT:fs7c/JxNaI0a2G+uT7h8X4a6IQ5W64Rk@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h765JuE00883; Tue, 5 Aug 2003 23:19:56 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h765Ju124899; Tue, 5 Aug 2003 23:19:56 -0600 Date: Tue, 5 Aug 2003 23:19:55 -0600 From: "Brian F. G. Bidulock" To: Qiaobing Xie Cc: Kacheong Poon , tsvwg@ietf.org Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) Message-ID: <20030805231955.D24285@openss7.org> Reply-To: bidulock@openss7.org References: <3F1D8B89.40502@sun.com> <3F2E4F3A.7020500@stewart.chicago.il.us> <3F3013CB.3020505@sun.com> <3F3022AA.CF63147F@motorola.com> <3F302502.3050904@sun.com> <3F3033E6.84A8F7B8@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: <3F3033E6.84A8F7B8@motorola.com>; from Qiaobing.Xie@motorola.com on Tue, Aug 05, 2003 at 05:47:02PM -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 h765JuE00883 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, I agree. And please do not forget that SCTP was first designed to meet a set of requirements for transporting telephony signalling protocols. If those requirements fail to be met by SCTP, yet another transport protocol will become necessary again. --brian On Tue, 05 Aug 2003, Qiaobing Xie wrote: > Kacheong Poon wrote: >=20 > > ...I'd suggest > > those SCTP stacks to support ASCONF so that the retransmission > > can automatically be made to an alternate address. This seems > > to be a better way to handle it than relying on a "guess" of NIC > > failure as there is no need to guess at all. >=20 > So you want to rely on an external monitor/detector mechanism at the > peer endpoint that will tell the peer SCTP stack a NIC is bad and then > the remote stack will do a "change primary addr" through ASCONF so that > the local endpoint will start to move the traffic to an alternative des= t > addr? Ok, now you have no need to guess since the remote external > detector is doing the "guessing" :-) >=20 > But this would essentially remove most of the SCTP's auto path failure > detection / recovery capabilities and take out a big chunk of SCTP's > multi-homing advantage. I think this is too costly for whatever we are > trying to gain here. >=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 Wed Aug 6 05:27: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 FAA10197 for ; Wed, 6 Aug 2003 05:27: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 19kKZU-0006QF-0Z for tsvwg-archive@odin.ietf.org; Wed, 06 Aug 2003 05:27:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h769R3oY024683 for tsvwg-archive@odin.ietf.org; Wed, 6 Aug 2003 05:27:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kKZR-0006PJ-BA; Wed, 06 Aug 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 19kKYv-0006Oy-Ij for tsvwg@optimus.ietf.org; Wed, 06 Aug 2003 05:26: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 FAA10182 for ; Wed, 6 Aug 2003 05:26:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kKYs-0001Ws-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 05:26:26 -0400 Received: from ms.exp-math.uni-essen.de ([132.252.150.1] helo=pilz.exp-math.uni-essen.de) by ietf-mx with esmtp (Exim 4.12) id 19kKYp-0001Wp-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 05:26:24 -0400 Received: from gina.exp-math.uni-essen.de (gina.exp-math.uni-essen.de [132.252.150.131]) by pilz.exp-math.uni-essen.de (8.12.8/8.12.8) with ESMTP id h769QMH3027982; Wed, 6 Aug 2003 11:26:22 +0200 From: Andreas Jungmaier Organization: University Duisburg-Essen To: "Randall R. Stewart (home)" Subject: Re: [Tsvwg] PR-SCTP updated draft Date: Wed, 6 Aug 2003 11:26:33 +0200 User-Agent: KMail/1.5.2 References: <3F2FE2AF.30605@stewart.chicago.il.us> In-Reply-To: <3F2FE2AF.30605@stewart.chicago.il.us> Cc: TSVWG MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200308061126.39865.ajung@exp-math.uni-essen.de> 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 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 05 August 2003 19:00, Randall R. Stewart (home) wrote: > Hi all: > > I think I have now gotten all of the minor changes in > to the WG last call on the PR-SCTP document. Please have a > look at the html diff at: > > http://www.sctp.org > Hi Randy, Rule F5 now states: =2D -----------------------------------------------------------------------= =2D--- =465) 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). =2D -----------------------------------------------------------------------= =2D--- That is a little bit difficult to understand, I think. Maybe: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =465) If the decision to "abandon" a chunk is made, no matter how such a decision is made, the appropriate congestion adjustment MUST be made as specified in RFC2960 if the chunk would have been marked=20 for retransmission later (e.g. either by T3-Timeout or by Fast=20 Retransmit). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D works better ? Regards, Andreas =2D --=20 Dipl.-Ing. Andreas Jungmaier =20 Computer Networking Technology Group =20 University of Duisburg-Essen =20 http://www.exp-math.uni-essen.de/~ajung =20 My PGP Key-ID: D3824AC0 =20 My PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/MMnOXAsLBNOCSsARArzMAKDG7tP82MjTbY+eQUl3DI+GweDZggCgpbBM QGnrK1MXPgOACwRrK4QkTgo=3D =3DfjTY =2D----END PGP SIGNATURE----- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Aug 6 07:51: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 HAA12919 for ; Wed, 6 Aug 2003 07:51:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kMoe-0001hn-4s for tsvwg-archive@odin.ietf.org; Wed, 06 Aug 2003 07:50:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Boqqe006556 for tsvwg-archive@odin.ietf.org; Wed, 6 Aug 2003 07:50:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kMi1-0001Cv-J0; Wed, 06 Aug 2003 07: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 19kMeD-00017n-9B for tsvwg@optimus.ietf.org; Wed, 06 Aug 2003 07:40: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 HAA12544 for ; Wed, 6 Aug 2003 07:40:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kMeC-00022W-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 07:40:04 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19kMeB-00022O-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 07:40:03 -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 h76BdF5D007116; Wed, 6 Aug 2003 06:39:16 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F30E8E2.6050201@stewart.chicago.il.us> Date: Wed, 06 Aug 2003 06:39:14 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andreas Jungmaier CC: TSVWG Subject: Re: [Tsvwg] PR-SCTP updated draft References: <3F2FE2AF.30605@stewart.chicago.il.us> <200308061126.39865.ajung@exp-math.uni-essen.de> In-Reply-To: <200308061126.39865.ajung@exp-math.uni-essen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Andreas Jungmaier wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Tuesday 05 August 2003 19:00, Randall R. Stewart (home) wrote: > > >>Hi all: >> >>I think I have now gotten all of the minor changes in >>to the WG last call on the PR-SCTP document. Please have a >>look at the html diff at: >> >>http://www.sctp.org >> >> >> > >Hi Randy, > >Rule F5 now states: >- --------------------------------------------------------------------------- >F5) If a decision to "abandon" a chunk is made, no matter how such >decision is made, the appropriate congestion adjustment MUST be >made as specified in RFC2960 if the chunk later would have been >marked for retransmission (e.g. T3-Timeout or Fast Retransmit). >- --------------------------------------------------------------------------- >That is a little bit difficult to understand, I think. Maybe: >=========================================================================== >F5) If the decision to "abandon" a chunk is made, no matter how such a >decision is made, the appropriate congestion adjustment MUST be >made as specified in RFC2960 if the chunk would have been marked >for retransmission later (e.g. either by T3-Timeout or by Fast >Retransmit). >=========================================================================== >works better ? > > Sounds fine to me :> I will update it and put another version of the diff up on my web site.. R >Regards, >Andreas > >- -- >Dipl.-Ing. Andreas Jungmaier >Computer Networking Technology Group >University of Duisburg-Essen >http://www.exp-math.uni-essen.de/~ajung >My PGP Key-ID: D3824AC0 > >My PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.2 (GNU/Linux) > >iD8DBQE/MMnOXAsLBNOCSsARArzMAKDG7tP82MjTbY+eQUl3DI+GweDZggCgpbBM >QGnrK1MXPgOACwRrK4QkTgo= >=fjTY >-----END PGP SIGNATURE----- > > >_______________________________________________ >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 Wed Aug 6 07:55: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 HAA13158 for ; Wed, 6 Aug 2003 07:55: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 19kMsg-0001oN-Rm for tsvwg-archive@odin.ietf.org; Wed, 06 Aug 2003 07:55:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Bt2HS006957 for tsvwg-archive@odin.ietf.org; Wed, 6 Aug 2003 07:55:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kMsf-0001nS-34; Wed, 06 Aug 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 19kMsL-0001n3-Ri for tsvwg@optimus.ietf.org; Wed, 06 Aug 2003 07:54: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 HAA13119 for ; Wed, 6 Aug 2003 07:54:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kMsK-0002Ag-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 07:54:40 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19kMsK-0002A9-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 07:54:40 -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 h76Bs35D007208; Wed, 6 Aug 2003 06:54:04 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F30EC5B.3060504@stewart.chicago.il.us> Date: Wed, 06 Aug 2003 06:54:03 -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: Qiaobing Xie CC: Caitlin Bestler , "Armando L. Caro Jr." , tsvwg@ietf.org Subject: Re: [Tsvwg] Meaning of path failure (was re SCTP Timestamps) References: <3F2FB607.4070605@stewart.chicago.il.us> <3F303A42.BF87E039@motorola.com> In-Reply-To: <3F303A42.BF87E039@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Qiaobing: Yes, I do agree with you... but then do you think that a router sending a ICMP message that the transport protocol uses to determine path mtu is bad? I look at it not as a LAST hop .. but that at ANY point in the path a router can make a decision to either 1) drop a packet due to congestion or 2) drop a packet due to corruption In case <1> we WANT the transport protocol to react to it and reduce its sending rate. But in case <2> we would prefer the transport protcol become aware of this drop and to retransmit it (if retransmission is so desired) WITHOUT reducing its congestion rate... This in theory could be ANY hop along a routing chain.. but in most cases would be the last or next to last hop.. I am thinking satellite transmission for next to last... Now the problem as always been with reporting a corruption drop that A) A mallicious receiver could figure out that a TSN is missing and generate such a report to get the sender to avoid <1>. B) A new form of attack could be created that lets a hacker spew forth bunches of these things to "slow" down everyone else talking to a web server so he/she gets better service.. So how can a transport protocol trust the requests? SCTP of course can help in that if the router has the packet that it is deciding to drop it can return it .. and the vtag can be checked this helps in situation but what about ... The packet corruption may be at a point that the sender can't verify it? This is true.. and if so it should be tossed... The new technology we have created at cisco however is a tunneling software that does some retransmission.. and will give up on that retransmission think of it as an RLP.. but when it does give up .. its capable of sending the packet back to the sender.. I will get a draft together on this soon... I am just short of cycles right now... I have this up and running and its simulation results for working with satellites is remarkable.. you can get speeds that normaly take the disruptive PEP arpproach.. aka where you terminate the TCP/SCTP at both sides of the satellite to "fool" the end to end protocol into not realizing the long bandwidth delay by-product.. very ugly... When I present my draft I will also include some performance work I have gatherede too... R Qiaobing Xie wrote: >Both Randy and Caitlin's comments below are indeed very interesting. I >wonder if we still have consensus that SCTP is still an end-to-end, L3 >transport protocol. If so, I believe the reason we call it end-to-end is >because we assume there is a virtual, structure-less, vairable >bandwidth, end-to-end pipe underneath the L3 transport. > >Now, I start to see people talking about "what if the last hop of the >pipe [between two SCTP ends] is of X or Y nature". To me, at layer 3 I >don't see any internal structure of the L2 pipe execpt of the assumption >that it is an end-to-end pipe. So where is that "last hop" people are >referring to? > >If this virtual pipe abstraction no longer holds, then we are in a new >era of layering principle. If it is still valid, then the "last hop" is >invisible to SCTP and needs to remain so. And the nature of the "last >hop" needs to be addressed in L2 groups (e.g., trigtran). > >In short, I fail to see how we could succeed by tweaking L3 SCTP to >address some L2 "last hop" characteristics. > >regards, >-Qiaobing > >"Randall R. Stewart (home)" wrote: > > >>Caitlin Bestler wrote: >> >> >> >>>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: >> >>As always an interesting comment from you..( yes I have a lot of >>other unread email that you have sent to me .. I will get to it I >>promise :>) >> >>Now I understand the logic here and I have two comments... >> >>a) Being able to seperate a L2 drop for NON congestion reasons from the >> "default" assumption would be a nice thing.. I actually will have a >>proposal >> to put forward on this later on when I can get the cycles to clean >>up the drafty >> draft I have in the works somewhere :> >> >>b) If your example L2 environment just delivered the packet late (as I >>assume it >> must have) then what you have is a spurious retransmission.. the >>very thing >> that Eifel is trying to detect... >> >>Just a thought or two :> >> >>R >> >> >> >>>Caitlin Bestler - cait@asomi.com - http://asomi.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 >> >> > >_______________________________________________ >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 Wed Aug 6 09: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 JAA15607 for ; Wed, 6 Aug 2003 09:25: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 19kOHo-0004pv-Aw for tsvwg-archive@odin.ietf.org; Wed, 06 Aug 2003 09:25:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76DP4gi018587 for tsvwg-archive@odin.ietf.org; Wed, 6 Aug 2003 09: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 19kOHl-0004pf-HH; Wed, 06 Aug 2003 09: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 19kOHI-0004pK-Kz for tsvwg@optimus.ietf.org; Wed, 06 Aug 2003 09:24:32 -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 JAA15592 for ; Wed, 6 Aug 2003 09:24:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kOHG-0002lK-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 09:24:31 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx with esmtp (Exim 4.12) id 19kOHG-0002l5-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 09:24:30 -0400 Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250](untrusted sender)) by comcast.net (rwcrmhc12) with SMTP id <20030806132354014009nkv8e> (Authid: sdawkins@comcast.net); Wed, 6 Aug 2003 13:23:54 +0000 Message-ID: <19b001c35c1d$fc353be0$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: <89F77125-C79C-11D7-8B42-003065D48EE0@asomi.com> Subject: Re: [Tsvwg] Meaning of path failure (was re SCTP Timestamps) Date: Wed, 6 Aug 2003 08:23:54 -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 Caitlin, Re: > Most of what has been written recently emphasizes that the > L2 layer should not attempt to solve L3 problems. > > But it strikes me that you can go too far in the opposite > direction. When a given L2 hop is significantly more likely > to have bursty transmission errors than the Internet as > a whole, I really think we need to question whether those > problems should be solved on and end-to-end basis. > > That is especially so if there is a suggestion that the > end-to-end algorithms need to adjust because they react > incorrectly to bursty noise on one hop. I happen to agree (this was where TRIGTRAN ended up, oriented to first-hop wireless links because that's the link where the problem was for users in my part of the Internet). Having already agreed, "but..." One problem we ran into was, what happens if you're solving a specific problem and somebody morphs the topology underneath you? In TRIGTRAN, the focus was on wireless WAN links, but WLAN links are so cheap now that they're built into some computers by default, so the problem changed from RTO backoff when there's no coverage to path change when there's dual coverage. In TRIGTRAN, we headed off toward "last-hop" link problems just in time for people to start putting networks at the other end of the "last-hop" link, so it wasn't a last-hop link any more. The pressure was on us to beat end-to-end mechanisms, without negative impacts even in situations we hadn't anticipated. This isn't impossible, but it IS a tough sell. In the SCTP case, what happens if there are TWO problematic links on the path? You have to make sure that the two independent repair processes aren't working at cross purposes and will finish repairs at least as quickly as end-to-end mechanisms would. This isn't impossible, but it IS a tough sell. Spencer ----- Original Message ----- From: "Caitlin Bestler" To: "Qiaobing Xie" Cc: "Randall R. Stewart (home)" ; "Armando L. Caro Jr." ; Sent: Tuesday, August 05, 2003 6:28 PM Subject: Re: [Tsvwg] Meaning of path failure (was re SCTP Timestamps) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Aug 6 10:14: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 KAA17936 for ; Wed, 6 Aug 2003 10:14: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 19kP3E-0007JC-IF for tsvwg-archive@odin.ietf.org; Wed, 06 Aug 2003 10:14:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76EE4v6028092 for tsvwg-archive@odin.ietf.org; Wed, 6 Aug 2003 10:14:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kP3B-0007IL-4c; Wed, 06 Aug 2003 10: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 19kP2G-0007Hq-Ic for tsvwg@optimus.ietf.org; Wed, 06 Aug 2003 10: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 KAA17767 for ; Wed, 6 Aug 2003 10:12:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kP2E-00037H-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 10:13:02 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19kP2C-000379-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 10:13:01 -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 h76ECB5D058238; Wed, 6 Aug 2003 09:12:14 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F310CBB.1080108@stewart.chicago.il.us> Date: Wed, 06 Aug 2003 09:12:11 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kacheong Poon CC: tsvwg@ietf.org Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) References: <3F1D8B89.40502@sun.com> <3F2E4F3A.7020500@stewart.chicago.il.us> <3F3013CB.3020505@sun.com> In-Reply-To: <3F3013CB.3020505@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kacheong Poon wrote: > Randall R. Stewart (home) wrote: > >> Slowly catching up on a HUGE backlog of email :-o >> >> As to the above.. I don't agree yet.. Armando has proposed such to me >> and I have yet to be convinced.... >> >> It may be that it is better in some cases.. but when you start >> factoring in >> real failures of a NIC you may find that your failure detection >> starts to >> be effected in a adverse way. So far I think Armando has a good point >> in that possibly FR's may be best NOT to send to an alternate .. but >> T3's I think may still be best sent to an alternate... > > > If I remember correctly, the fast retransmit case was discussed > some time ago in either tsvwg or sctp-impl. The consensus is to > retransmit to the original address. I thought every implementations > is already doing this... Wow.. I must have missed that discussion or forgotten it... Armando and I have been haggling on this point for a while.. I think we now have definite proof that for FR's you should send to the original address. For Time-outs however, this is not necessarily true. Armando still has some more simulation to do in this vein and I have also asked him to take into account the failover i.e. the cases where where you are transmitting as failed. I don't see a CC problem in all of this.. at least none that I can find. If you do take a false T-3 you MAY end up retransmitting to an alternate to quickly and when the ACK's come back credit the alternate... but is this really going to happen? I think most of the times it will NOT.. aka: Primary------cwnd=N--------------> Alternate----cwnd=2Mtu----------> Now assuming N is some larger number (we have been sending a while)... and we do a encounter a delay spike that causes a false T3 on Primary.. You retransmit 1 MTU to Alternate and wait for a SACK. The SACK arrives (just a bit latter) from your false T3. You then do for the alternate If (flight-size > cwnd) { if(in-ss) cwnd += min(1 mtu, ack-size) else pba += acksize; if(pba > cwnd) cwnd += 1 MTU pba -= cwnd if(pba <=0) pba = 0 } Now in our example guess what? flight-size = 1MTU (assuming you had a full MTU or more to retran)... so the "if" would never be entered and NO cwnd advance would happen. It is hard for me to imagine a situation where you would really get the alternate above 1MTU in flight size .... so I doubt there is a problem.. in fact the real issue is the false T3 will have caused a collapse of the primary... I guess this is what Eifel attempts to fix in TCP.... So 1) I see no CC problem with the current scheme 2) We probably need to NOT retransmit FR's to an alternate 3) It is best, I think, if we schedule a HB on the alternate after a retransmission.. Armando is still working on this point but if you have any loss on the alternate you need some way of collapsing the RTO so scheduling a HB can do that to help performance.... I am anxious for Armando to get a bit further in his research and I think this will shed some additional light on the situation :> > > > I guess NIC failure happens very infrequently when compared to > congestion and spurious timeout. I don't think it is a good > suggestion to design the timeout retransmission around an uncommon > case. And it seems to me that the correct way to handle a NIC > failure is to use ASCONF to tell the peer to either remove those IP > addresses associated with the failed NIC or to change the primary > path if it is to the failed NIC. One may ask why such mechanism > is not included in the original spec... Well, we DID want both PR-SCTP and ADD-IP in the base spec... but in order to not hold things up to long we decided to do them as seperate drafts.. and it is a good thing too.. ADD-IP still needs some more work (in the security front) and PR-SCTP is now 3 years later almost done... Many implementations do have ASCONF working.. which can help in this situation... but one would need (as Qiaobing pointed out) some sort of L2 trigger to tell the peer "hey your nic card X failed" so that it could "know" to send the "set-primary" to the alternate. And of course a "generic" trigger, as yet, does not exist. Another area ripe for research... R > > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Aug 6 11:44:41 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 LAA21863 for ; Wed, 6 Aug 2003 11:44:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQSQ-0002iJ-Mz for tsvwg-archive@odin.ietf.org; Wed, 06 Aug 2003 11:44:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76FiA0l010426 for tsvwg-archive@odin.ietf.org; Wed, 6 Aug 2003 11:44:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQSH-0002ff-8Q; Wed, 06 Aug 2003 11: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 19kQRP-0002eW-NT for tsvwg@optimus.ietf.org; Wed, 06 Aug 2003 11:43: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 LAA21739 for ; Wed, 6 Aug 2003 11:43:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kQRO-0003yn-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 11:43:06 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19kQRO-0003yk-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 11:43:06 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 28CDA32A3A; Wed, 6 Aug 2003 11:43:05 -0400 (EDT) Received: from louie.udel.edu (louie.udel.edu [128.4.40.12]) by mail.eecis.udel.edu (Postfix) with ESMTP id 5DC5B32A39; Wed, 6 Aug 2003 11:43:04 -0400 (EDT) Date: Wed, 6 Aug 2003 11:43:04 -0400 (EDT) From: Sourabh Ladha X-X-Sender: To: "Randall R. Stewart (home)" Cc: Kacheong Poon , Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) In-Reply-To: <3F310CBB.1080108@stewart.chicago.il.us> Message-ID: X-Spam-Status: No, hits=-3.1 required=6.0 tests=DEPT_RCVD,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05, 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: , [snip] > I don't see a CC problem in all of this.. at least none that I can find. > If you > do take a false T-3 you MAY end up retransmitting to an alternate to quickly > and when the ACK's come back credit the alternate... but is this really > going > to happen? I think most of the times it will NOT.. > aka: > > Primary------cwnd=N--------------> > Alternate----cwnd=2Mtu----------> > > Now assuming N is some larger number (we have been sending a while)... > and we do > a encounter a delay spike that causes a false T3 on Primary.. > > You retransmit 1 MTU to Alternate and wait for a SACK. > > The SACK arrives (just a bit latter) from your false T3. You then do for the > alternate > > If (flight-size > cwnd) { > if(in-ss) > cwnd += min(1 mtu, ack-size) > else > pba += acksize; > if(pba > cwnd) > cwnd += 1 MTU > pba -= cwnd > if(pba <=0) > pba = 0 > } > > Now in our example guess what? flight-size = 1MTU (assuming you had > a full MTU or more to retran)... so the "if" would never be entered and > NO cwnd advance would happen. Randall, What you just described seems to me like a bug rather than a "feature" (Leave alone the case of spurious timeout for now). In the example you gave, the SCTP sender would probably need N roundtrips to recover after a T3 and retransmission starts off on the alternate (where N packets were in flight (consider all lost) before you hit a T3 on the primary). This seems an over conservative (read slow) behavior. I must be missing something here :-O -Sourabh > > > It is hard for me to imagine a situation where you would really get the > alternate above 1MTU in flight size .... so I doubt there is a problem.. > in fact > the real issue is the false T3 will have caused a collapse of the > primary... I guess this is what Eifel attempts to fix in TCP.... > > So > > 1) I see no CC problem with the current scheme > 2) We probably need to NOT retransmit FR's to an alternate > 3) It is best, I think, if we schedule a HB on the alternate after > a retransmission.. Armando is still working on this point but > if you have any loss on the alternate you need some way of > collapsing the RTO so scheduling a HB can do that to help > performance.... > > I am anxious for Armando to get a bit further in his research and I think > this will shed some additional light on the situation :> > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Aug 6 12:05: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 MAA22474 for ; Wed, 6 Aug 2003 12:05: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 19kQmf-0003q5-NH for tsvwg-archive@odin.ietf.org; Wed, 06 Aug 2003 12:05:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76G556c014758 for tsvwg-archive@odin.ietf.org; Wed, 6 Aug 2003 12:05:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQmb-0003pA-D6; Wed, 06 Aug 2003 12: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 19kQm0-0003oB-Hb for tsvwg@optimus.ietf.org; Wed, 06 Aug 2003 12:04: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 MAA22382 for ; Wed, 6 Aug 2003 12:04:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kQlz-00048N-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 12:04:23 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19kQlx-00047U-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 12:04:22 -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 h76G3g5D061311; Wed, 6 Aug 2003 11:03:43 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F3126DD.2010007@stewart.chicago.il.us> Date: Wed, 06 Aug 2003 11:03:41 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sourabh Ladha CC: Kacheong Poon , tsvwg@ietf.org Subject: Re: [Tsvwg] F-RTO and SCTP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sourabh Ladha wrote: >[snip] > > >>I don't see a CC problem in all of this.. at least none that I can find. >>If you >>do take a false T-3 you MAY end up retransmitting to an alternate to quickly >>and when the ACK's come back credit the alternate... but is this really >>going >>to happen? I think most of the times it will NOT.. >>aka: >> >>Primary------cwnd=N--------------> >>Alternate----cwnd=2Mtu----------> >> >>Now assuming N is some larger number (we have been sending a while)... >>and we do >>a encounter a delay spike that causes a false T3 on Primary.. >> >>You retransmit 1 MTU to Alternate and wait for a SACK. >> >>The SACK arrives (just a bit latter) from your false T3. You then do for the >>alternate >> >>If (flight-size > cwnd) { >> if(in-ss) >> cwnd += min(1 mtu, ack-size) >> else >> pba += acksize; >> if(pba > cwnd) >> cwnd += 1 MTU >> pba -= cwnd >> if(pba <=0) >> pba = 0 >>} >> >>Now in our example guess what? flight-size = 1MTU (assuming you had >>a full MTU or more to retran)... so the "if" would never be entered and >>NO cwnd advance would happen. >> >> > >Randall, > >What you just described seems to me like a bug rather than a >"feature" (Leave alone the case of spurious timeout for now). In the >example you gave, the SCTP sender would probably need N roundtrips to recover >after a T3 and retransmission starts >off on the alternate (where N packets were in flight (consider all lost) >before you hit a T3 on the primary). This seems an over conservative >(read slow) behavior. > >I must be missing something here :-O > > > > Consider for a moment a TCP sender.... At a T3-Timeout it sets cwnd = 1MTU and then retransmits the lowest un-acked packet it can. Then when the ack comes back.. it increases its cwnd and send 2 segments.. etc in slow start. For SCTP the behavior is similar... When a T3 is hit, you transmit only 1 MTU worth of data to the alternate (if there is one) and sent the original destination to 1MTU (marking all un-acked chunks for retransmission). Now when the SACK comes back for the first retran-packet, you retransmit up to 2 MTU's to the alternate... (lets assume for the moment you had N in-flight chunks where the size was N > 3 MTU) Then you wait for a SACK... when it comes you increase the cwnd of the alternate and send 3 MTUs of retranmssion... In other words.. its NO DIFFERENT than TCP when a T3 hits.. even though you are using an "alternate" path. This behavior was defined conservatively, yes, so that we would in effect look the same as TCP... one really does not know if the alternate path is diverse from the primary or not .... Its no slower than TCP is today... R _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Aug 6 12: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 MAA23784 for ; Wed, 6 Aug 2003 12: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 19kRMS-0005Zs-IF for tsvwg-archive@odin.ietf.org; Wed, 06 Aug 2003 12:42:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Gg4tP021434 for tsvwg-archive@odin.ietf.org; Wed, 6 Aug 2003 12: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 19kRMP-0005Yh-6A; Wed, 06 Aug 2003 12:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRMK-0005Xz-9X for tsvwg@optimus.ietf.org; Wed, 06 Aug 2003 12:41: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 MAA23695 for ; Wed, 6 Aug 2003 12:41:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRMI-0004S2-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 12:41:54 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19kRMI-0004Rz-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 12:41:54 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 56F5C32A41; Wed, 6 Aug 2003 12:41:54 -0400 (EDT) Received: from louie.udel.edu (louie.udel.edu [128.4.40.12]) by mail.eecis.udel.edu (Postfix) with ESMTP id 9341032A3D; Wed, 6 Aug 2003 12:41:53 -0400 (EDT) Date: Wed, 6 Aug 2003 12:41:53 -0400 (EDT) From: Sourabh Ladha X-X-Sender: To: "Randall R. Stewart (home)" Cc: Kacheong Poon , Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) In-Reply-To: <3F310CBB.1080108@stewart.chicago.il.us> 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: , [so now coming back to your example email] > I don't see a CC problem in all of this.. at least none that I can find. > If you > do take a false T-3 you MAY end up retransmitting to an alternate to quickly > and when the ACK's come back credit the alternate... but is this really > going > to happen? I think most of the times it will NOT.. > aka: > > Primary------cwnd=N--------------> > Alternate----cwnd=2Mtu----------> > > Now assuming N is some larger number (we have been sending a while)... > and we do > a encounter a delay spike that causes a false T3 on Primary.. > > You retransmit 1 MTU to Alternate and wait for a SACK. > > The SACK arrives (just a bit latter) from your false T3. You then do for the > alternate > > If (flight-size > cwnd) { > if(in-ss) > cwnd += min(1 mtu, ack-size) > else > pba += acksize; > if(pba > cwnd) > cwnd += 1 MTU > pba -= cwnd > if(pba <=0) > pba = 0 > } > > Now in our example guess what? flight-size = 1MTU (assuming you had > a full MTU or more to retran)... so the "if" would never be entered and > NO cwnd advance would happen. > > > It is hard for me to imagine a situation where you would really get the > alternate above 1MTU in flight size .... so I doubt there is a problem.. This generalization was confusing but your latter mail eats this up. > in fact > the real issue is the false T3 will have caused a collapse of the > primary... I guess this is what Eifel attempts to fix in TCP.... > So > > 1) I see no CC problem with the current scheme So the congestion window overgrowth in your example can occur (and thats a term I am using because eventually an SCTP sender will credit the alternate's cwnd for the SACK of the original). Taking your example where the primary faced a delay spike. When the SCTP sender hits a T3, it will retransmit 1MTU worth to alternate. Looking at the GoBackN, as the SACKs for the orginal now start coming in, the SCTP sender eventually starts crediting the cwnd of the alternate and pumping more retransmissions to the alternate. This is what I had refereed to as congestion window overgrowth due to retransmission ambuiguity in a previous mail. The issue was really that what if the alternate path was congested/broken (not yet detected by HB). The SCTP sender would not realize this while doing GoBackNs and pump retransmissions to the alternate. As you said Eifel's purpose was to undo the primary's state after this spurious t/o, but it may also be able to avoid this congestion window overgrowth in some cases (a +ve side effect). -Sourabh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Aug 6 15:14: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 PAA00978 for ; Wed, 6 Aug 2003 15:14: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 19kTjY-00059s-IA for tsvwg-archive@odin.ietf.org; Wed, 06 Aug 2003 15:14:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76JE41G019824 for tsvwg-archive@odin.ietf.org; Wed, 6 Aug 2003 15:14:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTjU-000583-Sv; Wed, 06 Aug 2003 15: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 19kTjI-00057i-OL for tsvwg@optimus.ietf.org; Wed, 06 Aug 2003 15:13: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 PAA00865 for ; Wed, 6 Aug 2003 15:13:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kTjH-00061i-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 15:13:47 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 19kTjG-00061Y-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 15:13:46 -0400 Received: from phys-ha1mpka.eng.sun.com ([129.146.14.50]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h76JDjfe000613 for ; Wed, 6 Aug 2003 13:13:45 -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 MAA18776 for ; Wed, 6 Aug 2003 12:13:20 -0700 (PDT) Message-ID: <3F315350.3050803@sun.com> Date: Wed, 06 Aug 2003 12:13:20 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 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: <3F1D8B89.40502@sun.com> <3F2E4F3A.7020500@stewart.chicago.il.us> <3F3013CB.3020505@sun.com> <3F3022AA.CF63147F@motorola.com> <3F302502.3050904@sun.com> <3F302E50.1953A739@motorola.com> In-Reply-To: <3F302E50.1953A739@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: > Are we **absolutely** sure that whatever we intended to solve in this > discussion has to include giving up this "retrans to alternative" > behavior which is so key to telecomm folks? Is there a solution that > will let those folks to co-exist in this SCTP world while we are > perfecting its congestion control here? I don't understand why we are giving up retransmission to an alternate address. The simple change I suggested was to do the first timeout retransmission to the original address. SCTP will still send the second timeout retransmission to an alternate address. This is a default behavior I suggested implementors to use. Having said that, it does not mean that an SCTP implementation should always follow the default behavior. It can just be a simple switch or an option to change the behavior to send the first timeout retransmission to an alternate address. > I am not ready to wave the white flag yet. I'd encourage the CC > perfectionists to continue work and find a solution that will satisfy > the CC behaviors while not sacrificing a very real advantage of SCTP for > telecom folks. Then we would have a WIN-WIN solution and I think we can > do it! (I know I sound a little like a promotional speaker, my apology > :) What I try to say is that if SCTP is a general purpose transport protocol, the default behavior should not be designed to fit in a particular kind of environment. I think you agree with that, right (-: [From another email] > So you want to rely on an external monitor/detector mechanism at the > peer endpoint that will tell the peer SCTP stack a NIC is bad and then > the remote stack will do a "change primary addr" through ASCONF so that > the local endpoint will start to move the traffic to an alternative dest > addr? Ok, now you have no need to guess since the remote external > detector is doing the "guessing" :-) I don't understand. If the NIC you are referring to above belongs to the endpoint, why is an external monitor/detector needed to tell the SCTP stack that the NIC is bad? Isn't this the job of the device driver? > But this would essentially remove most of the SCTP's auto path failure > detection / recovery capabilities and take out a big chunk of SCTP's > multi-homing advantage. I think this is too costly for whatever we are > trying to gain here. Assuming we are referring to a NIC belonging to the endpoint where the SCTP stack lives, I don't think using ASCONF will remove the auto detection/recovery capabilities of SCTP. The device driver tells the IP stack that a NIC is bad, so the IP stack does something. Isn't this kind of communication default in most OSes nowadays? If the stack also supports SCTP, then SCTP can use this info to do something. This is quite straightforward. -- 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 Aug 6 15:52: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 PAA02277 for ; Wed, 6 Aug 2003 15:52: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 19kUKK-0006lA-FU for tsvwg-archive@odin.ietf.org; Wed, 06 Aug 2003 15:52:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Jq45g025977 for tsvwg-archive@odin.ietf.org; Wed, 6 Aug 2003 15:52:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kUKH-0006kb-3Q; Wed, 06 Aug 2003 15: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 19kUJW-0006je-G7 for tsvwg@optimus.ietf.org; Wed, 06 Aug 2003 15:51: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 PAA02231 for ; Wed, 6 Aug 2003 15:51:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kUJV-0006O5-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 15:51:13 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19kUJU-0006Nn-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 15:51:12 -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 h76JoX5D080347; Wed, 6 Aug 2003 14:50:35 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F315C08.4070409@stewart.chicago.il.us> Date: Wed, 06 Aug 2003 14:50:32 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sourabh Ladha CC: Stephan Baucke , tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Timestamps References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sourabh/Stephan: I have been contemplating the timestamp issue and I am beginning to lean toward using the already defined HB for this. Could you tell me if this would work for your eifel algorithm? First Transmission ----Normal DATA-no-HB------> ----Normal HB-To-Alternate(ts/other stuff)---> T3-Timeout ---HB(ts/flag=retran#/tsn.. no other stuff)+Bundled-Data-------> If I hit another T3 ---HB(ts/flag=retran#/tsn.. no other stuff)+Bundled-Data------> Now. One of a number of things will occur. 1) The peer does NOT bundle things together... in that case a time-stamp chunk would have the same problems as a HB-ACK i.e. it would get lost in the network from say the SACK that will come back ack'ing the data. 2) A loss occurred and thus the HB-ACK will be sent right away possibly bundled with the SACK not showing any duplicates and showing gaps. 3) A loss did NOT occur and a HB-ACK will be bundled with a SACK showing a duplicate (if a duplicate is present a SACK is sent right away with no delay) 4) A loss occured and there are no gaps so the delay timer is started.. thus the HB-ACK would go stand alone.. and then a bit later the SACK would be sent based of the delay timer. Now if the HB-ACK comes bundled with a SACK showing duplicates you have detected a false retransmission. In ANY event you can always calculate the RTT since the HB has when it was sent.. .and if you are really nervous about the missing delay (200ms or whatever) you can add it in .. of course ALL HB's to alternates have this issue as well :> It seems to me that the HB/as long as bundling occurs with the HB-ACK will accomplish the same purposes... Or what is missing from this detection? Brian as pointed out that it "changes the nature of the HB" but I don't think so.. since a HB is used to: 1) Test reachablility and 2) calculate RTT's And a bundled HB like this is doing both of those... its just that by when you send it you get more information... What am I missing? R R --- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Aug 6 17:52: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 RAA06622 for ; Wed, 6 Aug 2003 17:52: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 19kWCT-0003z3-La for tsvwg-archive@odin.ietf.org; Wed, 06 Aug 2003 17:52:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Lq5nh015313 for tsvwg-archive@odin.ietf.org; Wed, 6 Aug 2003 17:52:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kWCP-0003yE-Fm; Wed, 06 Aug 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 19kWCE-0003xx-Jg for tsvwg@optimus.ietf.org; Wed, 06 Aug 2003 17:51: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 RAA06617 for ; Wed, 6 Aug 2003 17:51:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kWCB-0007at-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 17:51:47 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 19kWCB-0007ap-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 17:51:47 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h76LpiJs004402; Wed, 6 Aug 2003 14:51:44 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h76LpiaQ011848; Wed, 6 Aug 2003 16:51:44 -0500 Message-ID: <3F317863.23C24AB6@motorola.com> Date: Wed, 06 Aug 2003 16:51:31 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Randall R. Stewart (home)" CC: Kacheong Poon , tsvwg@ietf.org Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) References: <3F1D8B89.40502@sun.com> <3F2E4F3A.7020500@stewart.chicago.il.us> <3F3013CB.3020505@sun.com> <3F310CBB.1080108@stewart.chicago.il.us> 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 Randy/Armando, I don't know much detail and the scope of your ongoing discussion/analysis on this issue. But one of my concerns is that if we focus the analysis too closely to local behaviors of a single node or association we may lose our sight to the bigger picture. Here is a scenario: a multi-homed SCTP association is sharing a big area network (or just the Internet) with other TCP, UDP, SCTP, RTP traffic and is actively passing data across the network. I understand there is no mechanism in existence yet to guarantee path diversity for this multi-homed SCTP association (maybe such a mechanism will be produced by the multi-homing WG soon.. who knows). But there is nothing to prevent path diversity from naturally occurring either. So, let's assume that the association has path diversity across the network. Now at the SCTP sender suddenly gap SACKs or timeouts start to be indicated on the primary dest address. This can mean either congestion or path failure which we have no way to tell for sure. But it surely indicates *some* problem with the part of the network that the primary path crosses. Now the issue is how the sender should react. We seem to be talking about the following options: a) The "agile" approach - move retrans to the alternative at the first sign of trouble; this is the current RFC2960 recommendation. b) The "stubborn" approach - insisting on using the current addr for all trans and retrans until nothing can get through; c) something in-between - e.g., if it is FR, use the same addr, if RTO, use the alternative. The main advantage of "stubborn" over "agile" is (to my understanding at least) that the sender side CC algorithm is 1) less prone to generating spurious retrans, which translates into less wasted network bandwidth, and 2) no longer suffers from the ack ambiguity, which translates into ???... (I am still trying to understand the real benefit here). The benefits of "agile" over "stubborn" are far clearer to me: 1) as I mentioned in an earlier email, if the *some* problem is caused by an actual fault in the primary path, the fault recovery speed of the "agile" approach is much faster than the "stubborn". In fact, the "stubborn" approach degrades SCTP to TCP equivalent in terms of path failure detection latency. 2) if the *some* problem is congestion induced (maybe some one started download huge movie files or a workhorse router went down in that part of network), wouldn't it still be a very good thing that the SCTP traffic is swiftly shifted away from the congested area of the network (assuming path diversity exists here)? This not only helps the congestion condition to improve quicker in the affected area, but also lessens the impact on the data sender's throughput. Imagine that if in the future a portion of the Internet traffic can perform this type of "agile" multi-homing, how much it could benefit the network congestion recovery. IMHO, the *real* benefits of "agile" approach to both the application and the network more than justify the occasional spurious retrans and the whatever bad things caused by the ack ambiguity. I hope this wider impact is factored into your simulation and analysis. regards, -Qiaobing "Randall R. Stewart (home)" wrote: > > Kacheong Poon wrote: > > > Randall R. Stewart (home) wrote: > > > >> Slowly catching up on a HUGE backlog of email :-o > >> > >> As to the above.. I don't agree yet.. Armando has proposed such to me > >> and I have yet to be convinced.... > >> > >> It may be that it is better in some cases.. but when you start > >> factoring in > >> real failures of a NIC you may find that your failure detection > >> starts to > >> be effected in a adverse way. So far I think Armando has a good point > >> in that possibly FR's may be best NOT to send to an alternate .. but > >> T3's I think may still be best sent to an alternate... > > > > If I remember correctly, the fast retransmit case was discussed > > some time ago in either tsvwg or sctp-impl. The consensus is to > > retransmit to the original address. I thought every implementations > > is already doing this... > > Wow.. I must have missed that discussion or forgotten it... Armando > and I have been haggling on this point for a while.. > > I think we now have definite proof that for FR's you should send to > the original address. For Time-outs however, this is not necessarily > true. Armando > still has some more simulation to do in this vein and I have also asked him > to take into account the failover i.e. the cases where where you are > transmitting as failed. > > I don't see a CC problem in all of this.. at least none that I can find. > If you > do take a false T-3 you MAY end up retransmitting to an alternate to quickly > and when the ACK's come back credit the alternate... but is this really > going > to happen? I think most of the times it will NOT.. > aka: > > Primary------cwnd=N--------------> > Alternate----cwnd=2Mtu----------> > > Now assuming N is some larger number (we have been sending a while)... > and we do > a encounter a delay spike that causes a false T3 on Primary.. > > You retransmit 1 MTU to Alternate and wait for a SACK. > > The SACK arrives (just a bit latter) from your false T3. You then do for the > alternate > > If (flight-size > cwnd) { > if(in-ss) > cwnd += min(1 mtu, ack-size) > else > pba += acksize; > if(pba > cwnd) > cwnd += 1 MTU > pba -= cwnd > if(pba <=0) > pba = 0 > } > > Now in our example guess what? flight-size = 1MTU (assuming you had > a full MTU or more to retran)... so the "if" would never be entered and > NO cwnd advance would happen. > > It is hard for me to imagine a situation where you would really get the > alternate above 1MTU in flight size .... so I doubt there is a problem.. > in fact > the real issue is the false T3 will have caused a collapse of the > primary... I guess this is what Eifel attempts to fix in TCP.... > > So > > 1) I see no CC problem with the current scheme > 2) We probably need to NOT retransmit FR's to an alternate > 3) It is best, I think, if we schedule a HB on the alternate after > a retransmission.. Armando is still working on this point but > if you have any loss on the alternate you need some way of > collapsing the RTO so scheduling a HB can do that to help > performance.... > > I am anxious for Armando to get a bit further in his research and I think > this will shed some additional light on the situation :> > > > > > > > I guess NIC failure happens very infrequently when compared to > > congestion and spurious timeout. I don't think it is a good > > suggestion to design the timeout retransmission around an uncommon > > case. And it seems to me that the correct way to handle a NIC > > failure is to use ASCONF to tell the peer to either remove those IP > > addresses associated with the failed NIC or to change the primary > > path if it is to the failed NIC. One may ask why such mechanism > > is not included in the original spec... > > Well, we DID want both PR-SCTP and ADD-IP in the base spec... but in order > to not hold things up to long we decided to do them as seperate drafts.. > and it > is a good thing too.. ADD-IP still needs some more work (in the security > front) and > PR-SCTP is now 3 years later almost done... > > Many implementations do have ASCONF working.. which can help in this > situation... but one would need (as Qiaobing pointed out) some sort of > L2 trigger > to tell the peer "hey your nic card X failed" so that it could "know" to > send the > "set-primary" to the alternate. And of course a "generic" trigger, as > yet, does not > exist. Another area ripe for research... > > R > > > > > > > > > > > _______________________________________________ > 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 Wed Aug 6 18: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 SAA08734 for ; Wed, 6 Aug 2003 18:30: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 19kWnE-0005mM-R7 for tsvwg-archive@odin.ietf.org; Wed, 06 Aug 2003 18:30:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76MU4JJ022211 for tsvwg-archive@odin.ietf.org; Wed, 6 Aug 2003 18:30:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kWnB-0005lU-Uu; Wed, 06 Aug 2003 18: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 19kWmH-0005kx-2N for tsvwg@optimus.ietf.org; Wed, 06 Aug 2003 18:29: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 SAA08676 for ; Wed, 6 Aug 2003 18:28:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kWmE-00002n-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 18:29:02 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19kWmD-00002k-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 18:29:01 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h76MT1hx001729; Wed, 6 Aug 2003 15:29:01 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h76MT1aQ003243; Wed, 6 Aug 2003 17:29:01 -0500 Message-ID: <3F318120.D983756A@motorola.com> Date: Wed, 06 Aug 2003 17:28:48 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kacheong Poon CC: tsvwg@ietf.org Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) References: <3F1D8B89.40502@sun.com> <3F2E4F3A.7020500@stewart.chicago.il.us> <3F3013CB.3020505@sun.com> <3F3022AA.CF63147F@motorola.com> <3F302502.3050904@sun.com> <3F302E50.1953A739@motorola.com> <3F315350.3050803@sun.com> 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 Kacheong Poon wrote: > > Qiaobing Xie wrote: > > > Are we **absolutely** sure that whatever we intended to solve in this > > discussion has to include giving up this "retrans to alternative" > > behavior which is so key to telecomm folks? Is there a solution that > > will let those folks to co-exist in this SCTP world while we are > > perfecting its congestion control here? > > I don't understand why we are giving up retransmission to an > alternate address. The simple change I suggested was to do > the first timeout retransmission to the original address. SCTP > will still send the second timeout retransmission to an alternate > address. This is less dramatic. Assuming the sender's RTO_min = 1 sec at the time of the fault, this still adds 2 sec delay to the fault recovery which could be significant in some cases. However, does this "just one more retrans to the current addr" really help you? How? > This is a default behavior I suggested implementors to > use. Having said that, it does not mean that an SCTP implementation > should always follow the default behavior. It can just be a > simple switch or an option to change the behavior to send the > first timeout retransmission to an alternate address. But how are we going to tell people when to *not* use that optional behavior? I'd guess that having faster fault recovery is welcome by everyone. I used telecomm as an example simply because for them recovery speed becomes a vital requirement. But in reality, it will be a good thing for everyone especially for those who have already gone through the trouble of setting up multi-homing, right? > > > I am not ready to wave the white flag yet. I'd encourage the CC > > perfectionists to continue work and find a solution that will satisfy > > the CC behaviors while not sacrificing a very real advantage of SCTP for > > telecom folks. Then we would have a WIN-WIN solution and I think we can > > do it! (I know I sound a little like a promotional speaker, my apology > > :) > > What I try to say is that if SCTP is a general purpose transport > protocol, the default behavior should not be designed to fit in > a particular kind of environment. I think you agree with that, > right (-: I guess I would agree if I can understand why the current design does NOT fit general purpose (also see my other email on this topic). > > [From another email] > > > So you want to rely on an external monitor/detector mechanism at the > > peer endpoint that will tell the peer SCTP stack a NIC is bad and then > > the remote stack will do a "change primary addr" through ASCONF so that > > the local endpoint will start to move the traffic to an alternative dest > > addr? Ok, now you have no need to guess since the remote external > > detector is doing the "guessing" :-) > > I don't understand. If the NIC you are referring to above > belongs to the endpoint, why is an external monitor/detector > needed to tell the SCTP stack that the NIC is bad? Isn't this > the job of the device driver? By "external" I referred to anything outside the SCTP stack itself. Device driver is external and we have know knowledge as to how it really works to determine a NIC failure, for example. regards, -Qiaobing > > But this would essentially remove most of the SCTP's auto path failure > > detection / recovery capabilities and take out a big chunk of SCTP's > > multi-homing advantage. I think this is too costly for whatever we are > > trying to gain here. > > Assuming we are referring to a NIC belonging to the endpoint where > the SCTP stack lives, I don't think using ASCONF will remove the > auto detection/recovery capabilities of SCTP. The device driver > tells the IP stack that a NIC is bad, so the IP stack does something. > Isn't this kind of communication default in most OSes nowadays? If > the stack also supports SCTP, then SCTP can use this info to do > something. This is quite straightforward. > > -- > > 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 Wed Aug 6 18:43: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 SAA09015 for ; Wed, 6 Aug 2003 18:43: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 19kWzm-0006Ke-PN for tsvwg-archive@odin.ietf.org; Wed, 06 Aug 2003 18:43:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Mh2so024334 for tsvwg-archive@odin.ietf.org; Wed, 6 Aug 2003 18:43:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kWzl-0006Jj-5q; Wed, 06 Aug 2003 18: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 19kWz8-0006JU-Ab for tsvwg@optimus.ietf.org; Wed, 06 Aug 2003 18:42: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 SAA08984 for ; Wed, 6 Aug 2003 18:42:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kWz5-00006p-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 18:42:19 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19kWz4-00006m-00 for tsvwg@ietf.org; Wed, 06 Aug 2003 18:42:18 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h76MgFhx008938; Wed, 6 Aug 2003 15:42:15 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h76MgFaQ011395; Wed, 6 Aug 2003 17:42:15 -0500 Message-ID: <3F31843B.66DA770D@motorola.com> Date: Wed, 06 Aug 2003 17:42:03 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Randall R. Stewart (home)" CC: Caitlin Bestler , "Armando L. Caro Jr." , tsvwg@ietf.org Subject: Re: [Tsvwg] Meaning of path failure (was re SCTP Timestamps) References: <3F2FB607.4070605@stewart.chicago.il.us> <3F303A42.BF87E039@motorola.com> <3F30EC5B.3060504@stewart.chicago.il.us> 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 Randy, Your email below shows perfectly what is the right way to address this type of L2 problem - it is going to be a collaboration and interaction between L2 and L3! The router's involvement (dropping the packet) and feedback (sending back the Vtag) to L3 are the key here. The point I was trying to make in my original email was that we are unlikely to correctly address a L2 problem by tweaking L3 alone. regards, -Qiaobing "Randall R. Stewart (home)" wrote: > > Qiaobing: > > Yes, I do agree with you... but then do you think > that a router sending a ICMP message that the transport > protocol uses to determine path mtu is bad? > > I look at it not as a LAST hop .. but that at ANY point in the > path a router can make a decision to either > 1) drop a packet due to congestion > or > 2) drop a packet due to corruption > > In case <1> we WANT the transport protocol to react > to it and reduce its sending rate. But in case <2> we would > prefer the transport protcol become aware of this drop and to > retransmit it (if retransmission is so desired) WITHOUT reducing > its congestion rate... This in theory could be ANY hop along a > routing chain.. but in most cases would be the last or next to > last hop.. I am thinking satellite transmission for next to last... > > Now the problem as always been with reporting a corruption drop that > > A) A mallicious receiver could figure out that a TSN is missing and generate > such a report to get the sender to avoid <1>. > B) A new form of attack could be created that lets a hacker spew forth > bunches > of these things to "slow" down everyone else talking to a web server so > he/she gets better service.. > > So how can a transport protocol trust the requests? > > SCTP of course can help in that if the router has the packet that > it is deciding to drop it can return it .. and the vtag can be checked > this helps in situation but what about ... > > The packet corruption may be at a point that the sender can't > verify it? This is true.. and if so it should be tossed... > > The new technology we have created at cisco however is a tunneling > software that does some retransmission.. and will give up on > that retransmission think of it as an RLP.. but when it does > give up .. its capable of sending the packet back to the sender.. > > I will get a draft together on this soon... I am just short of cycles right > now... > > I have this up and running and its simulation results for working with > satellites is remarkable.. you can get speeds that normaly take the > disruptive PEP arpproach.. aka where you terminate the TCP/SCTP > at both sides of the satellite to "fool" the end to end protocol into > not realizing the long bandwidth delay by-product.. very ugly... > > When I present my draft I will also include some performance > work I have gatherede too... > > R > > Qiaobing Xie wrote: > > >Both Randy and Caitlin's comments below are indeed very interesting. I > >wonder if we still have consensus that SCTP is still an end-to-end, L3 > >transport protocol. If so, I believe the reason we call it end-to-end is > >because we assume there is a virtual, structure-less, vairable > >bandwidth, end-to-end pipe underneath the L3 transport. > > > >Now, I start to see people talking about "what if the last hop of the > >pipe [between two SCTP ends] is of X or Y nature". To me, at layer 3 I > >don't see any internal structure of the L2 pipe execpt of the assumption > >that it is an end-to-end pipe. So where is that "last hop" people are > >referring to? > > > >If this virtual pipe abstraction no longer holds, then we are in a new > >era of layering principle. If it is still valid, then the "last hop" is > >invisible to SCTP and needs to remain so. And the nature of the "last > >hop" needs to be addressed in L2 groups (e.g., trigtran). > > > >In short, I fail to see how we could succeed by tweaking L3 SCTP to > >address some L2 "last hop" characteristics. > > > >regards, > >-Qiaobing > > > >"Randall R. Stewart (home)" wrote: > > > > > >>Caitlin Bestler wrote: > >> > >> > >> > >>>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: > >> > >>As always an interesting comment from you..( yes I have a lot of > >>other unread email that you have sent to me .. I will get to it I > >>promise :>) > >> > >>Now I understand the logic here and I have two comments... > >> > >>a) Being able to seperate a L2 drop for NON congestion reasons from the > >> "default" assumption would be a nice thing.. I actually will have a > >>proposal > >> to put forward on this later on when I can get the cycles to clean > >>up the drafty > >> draft I have in the works somewhere :> > >> > >>b) If your example L2 environment just delivered the packet late (as I > >>assume it > >> must have) then what you have is a spurious retransmission.. the > >>very thing > >> that Eifel is trying to detect... > >> > >>Just a thought or two :> > >> > >>R > >> > >> > >> > >>>Caitlin Bestler - cait@asomi.com - http://asomi.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 > >> > >> > > > >_______________________________________________ > >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 Aug 7 07: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 HAA08485 for ; Thu, 7 Aug 2003 07: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 19kj6l-0000X4-FK for tsvwg-archive@odin.ietf.org; Thu, 07 Aug 2003 07:39:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77Bd3Sj002042 for tsvwg-archive@odin.ietf.org; Thu, 7 Aug 2003 07:39:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kj6j-0000Wk-JG; Thu, 07 Aug 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 19kj6S-0000WQ-Mv for tsvwg@optimus.ietf.org; Thu, 07 Aug 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 HAA08460 for ; Thu, 7 Aug 2003 07:38:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kj6R-0005BH-00 for tsvwg@ietf.org; Thu, 07 Aug 2003 07:38:44 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19kj6R-0005BE-00 for tsvwg@ietf.org; Thu, 07 Aug 2003 07:38:43 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h77BcfgM001609; Thu, 7 Aug 2003 13:38: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 QL9JV368; Thu, 7 Aug 2003 13:38: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 NAA13631; Thu, 7 Aug 2003 13:38:39 +0200 (MET DST) Message-ID: <3F323A2D.4070908@ericsson.com> Date: Thu, 07 Aug 2003 13:38: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 CC: Sourabh Ladha Subject: Re: [Tsvwg] SCTP Timestamps References: <3F315C08.4070409@stewart.chicago.il.us> In-Reply-To: <3F315C08.4070409@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Randall R. Stewart (home) wrote: > Sourabh/Stephan: > > I have been contemplating the timestamp issue and I am beginning to lean > toward using the already defined HB for this. Could you tell me if > this would work for your eifel algorithm? > > First Transmission > > ----Normal DATA-no-HB------> > > ----Normal HB-To-Alternate(ts/other stuff)---> > > T3-Timeout > > ---HB(ts/flag=retran#/tsn.. no other stuff)+Bundled-Data-------> > > If I hit another T3 > > ---HB(ts/flag=retran#/tsn.. no other stuff)+Bundled-Data------> > > Now. One of a number of things will occur. > > 1) The peer does NOT bundle things together... in that case a time-stamp > chunk > would have the same problems as a HB-ACK i.e. it would get lost in > the network from say the SACK that will come back ack'ing the data. I think this would cause a serious problem for Eifel. A SACK for a retransmission without a HB (i.e. the HB was not bundled and lost or reordered relative to the SACK) would be falsely interpreted as a SACK for the original transmission, so Eifel would wrongly assume that the timeout was spurios and undo congestion control. This is the worst case. In essence, if Eifel cannot be sure whether a SACK without HB really refers to the original transmission, it can never apply the Eifel response. > 2) A loss occurred and thus the HB-ACK will be sent right away possibly > bundled with the SACK not showing any duplicates and showing gaps. > > 3) A loss did NOT occur and a HB-ACK will be bundled with a SACK showing > a duplicate (if a duplicate is present a SACK is sent right away with > no delay) > > 4) A loss occured and there are no gaps so the delay timer is started.. > thus > the HB-ACK would go stand alone.. and then a bit later the SACK would > be sent based of the delay timer. > > Now if the HB-ACK comes bundled with a SACK showing duplicates you have > detected a false retransmission. > > In ANY event you can always calculate the RTT since the HB has when it > was sent.. .and if you are really nervous about the missing delay (200ms > or whatever) > you can add it in .. of course ALL HB's to alternates have this issue as > well :> I agree that HBs are sufficient for the RTT measurement, but unless reliably bundled, they are not sufficient to resolve the retransmission ambiguity. > It seems to me that the HB/as long as bundling occurs with the HB-ACK will > accomplish the same purposes... Or what is missing from this detection? I think some sort of startup negotiation is the best solution so that (1) both sides can be sure whether the peer is able to do the bundling, and (2) room can be reserved in a timestamp-enabled session for HBs/TSs when doing fragmentation. But if we do a negotiation, we can just as well use a new chunk type rather then overloading HBs with new functionality (and thus avoid changes to the regular HB processing). Stephan. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Aug 7 07:41: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 HAA08583 for ; Thu, 7 Aug 2003 07:41: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 19kj8g-0000ky-2m for tsvwg-archive@odin.ietf.org; Thu, 07 Aug 2003 07:41:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77Bf25R002891 for tsvwg-archive@odin.ietf.org; Thu, 7 Aug 2003 07:41:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kj8f-0000kW-Rw; Thu, 07 Aug 2003 07: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 19kj8Q-0000k0-0w for tsvwg@optimus.ietf.org; Thu, 07 Aug 2003 07:40: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 HAA08553 for ; Thu, 7 Aug 2003 07:40:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kj8P-0005CR-00 for tsvwg@ietf.org; Thu, 07 Aug 2003 07:40:45 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19kj8O-0005Bd-00 for tsvwg@ietf.org; Thu, 07 Aug 2003 07:40:44 -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 h77BdCw0000451; Thu, 7 Aug 2003 06:39:13 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F323A5F.7060102@stewart.chicago.il.us> Date: Thu, 07 Aug 2003 06:39:11 -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: Qiaobing Xie CC: Kacheong Poon , tsvwg@ietf.org, "Armando L. Caro Jr." Subject: Re: [Tsvwg] F-RTO and SCTP References: <3F1D8B89.40502@sun.com> <3F2E4F3A.7020500@stewart.chicago.il.us> <3F3013CB.3020505@sun.com> <3F310CBB.1080108@stewart.chicago.il.us> <3F317863.23C24AB6@motorola.com> In-Reply-To: <3F317863.23C24AB6@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Qiaobing: Comments below.. Qiaobing Xie wrote: >Randy/Armando, > >I don't know much detail and the scope of your ongoing >discussion/analysis on this issue. But one of my concerns is that if we >focus the analysis too closely to local behaviors of a single node or >association we may lose our sight to the bigger picture. > > There is yet a LOT of analysis to be done I think :> >Here is a scenario: a multi-homed SCTP association is sharing a big area >network (or just the Internet) with other TCP, UDP, SCTP, RTP traffic >and is actively passing data across the network. I understand there is >no mechanism in existence yet to guarantee path diversity for this >multi-homed SCTP association (maybe such a mechanism will be produced by >the multi-homing WG soon.. who knows). But there is nothing to prevent >path diversity from naturally occurring either. So, let's assume that >the association has path diversity across the network. > >Now at the SCTP sender suddenly gap SACKs or timeouts start to be >indicated on the primary dest address. This can mean either congestion >or path failure which we have no way to tell for sure. But it surely >indicates *some* problem with the part of the network that the primary >path crosses. Now the issue is how the sender should react. We seem to >be talking about the following options: > >a) The "agile" approach - move retrans to the alternative at the first >sign of trouble; this is the current RFC2960 recommendation. > >b) The "stubborn" approach - insisting on using the current addr for all >trans and retrans until nothing can get through; > >c) something in-between - e.g., if it is FR, use the same addr, if RTO, >use the alternative. > > I originally was leaning toward as Armando can attest too :> But some of his work has convinced me that may be a better choice... the reason being: 1) If you are still getting Sack's that cause you to FR then there is no chance that the far end has failed. 2) Armando's work as shown that with even a mild loss rate on the alternate (due to congestion) the switched transmission is less beneficial due to I think mainly the fact that the RTO on the alternate tends to inflate over time... since you have very little traffic going there. My solution to this was to schedule a HB right away after retransmitting to an alternate to help bring down the RTO... this helped some (as Armandos simulations show) but not as much as sticking with the original destination. However Armando never included the concept of failed destination either.. thus some more work is needed... 3) After looking at all the data, I think because <1> is true in FR case then sticking with the primary will give the app the best throughput. I do believe that retrans need to go to the alternate though... >The main advantage of "stubborn" over "agile" is (to my understanding at >least) that the sender side CC algorithm is 1) less prone to generating >spurious retrans, which translates into less wasted network bandwidth, >and 2) no longer suffers from the ack ambiguity, which translates into >???... (I am still trying to understand the real benefit here). > > I don't see how the stubborn approach gets rid of any ack ambiguity.. you still do not know if the SACK is from the retransmitted data or the original. I think the only ambiguity you may fix is for a cwnd update.. but even that I could imagine a really really long delay spike that finally gets you to move to the alternate.. and presto the ambiguity is there... I just don't see that the stubborn approach helps for the ambiguity issue :> >The benefits of "agile" over "stubborn" are far clearer to me: 1) as I >mentioned in an earlier email, if the *some* problem is caused by an >actual fault in the primary path, the fault recovery speed of the >"agile" approach is much faster than the "stubborn". In fact, the >"stubborn" approach degrades SCTP to TCP equivalent in terms of path >failure detection latency. 2) if the *some* problem is congestion >induced (maybe some one started download huge movie files or a workhorse >router went down in that part of network), wouldn't it still be a very >good thing that the SCTP traffic is swiftly shifted away from the >congested area of the network (assuming path diversity exists here)? >This not only helps the congestion condition to improve quicker in the >affected area, but also lessens the impact on the data sender's >throughput. Imagine that if in the future a portion of the Internet >traffic can perform this type of "agile" multi-homing, how much it could >benefit the network congestion recovery. > >IMHO, the *real* benefits of "agile" approach to both the application >and the network more than justify the occasional spurious retrans and >the whatever bad things caused by the ack ambiguity. I hope this wider >impact is factored into your simulation and analysis. > > We need a lot more work.. and I know Armando will get this out over the next year or so... I really think that will provide the best throughput and at the same time the best fault recovery.. R >regards, >-Qiaobing > >"Randall R. Stewart (home)" wrote: > > >>Kacheong Poon wrote: >> >> >> >>>Randall R. Stewart (home) wrote: >>> >>> >>> >>>>Slowly catching up on a HUGE backlog of email :-o >>>> >>>>As to the above.. I don't agree yet.. Armando has proposed such to me >>>>and I have yet to be convinced.... >>>> >>>>It may be that it is better in some cases.. but when you start >>>>factoring in >>>>real failures of a NIC you may find that your failure detection >>>>starts to >>>>be effected in a adverse way. So far I think Armando has a good point >>>>in that possibly FR's may be best NOT to send to an alternate .. but >>>>T3's I think may still be best sent to an alternate... >>>> >>>> >>>If I remember correctly, the fast retransmit case was discussed >>>some time ago in either tsvwg or sctp-impl. The consensus is to >>>retransmit to the original address. I thought every implementations >>>is already doing this... >>> >>> >>Wow.. I must have missed that discussion or forgotten it... Armando >>and I have been haggling on this point for a while.. >> >>I think we now have definite proof that for FR's you should send to >>the original address. For Time-outs however, this is not necessarily >>true. Armando >>still has some more simulation to do in this vein and I have also asked him >>to take into account the failover i.e. the cases where where you are >>transmitting as failed. >> >>I don't see a CC problem in all of this.. at least none that I can find. >>If you >>do take a false T-3 you MAY end up retransmitting to an alternate to quickly >>and when the ACK's come back credit the alternate... but is this really >>going >>to happen? I think most of the times it will NOT.. >>aka: >> >>Primary------cwnd=N--------------> >>Alternate----cwnd=2Mtu----------> >> >>Now assuming N is some larger number (we have been sending a while)... >>and we do >>a encounter a delay spike that causes a false T3 on Primary.. >> >>You retransmit 1 MTU to Alternate and wait for a SACK. >> >>The SACK arrives (just a bit latter) from your false T3. You then do for the >>alternate >> >>If (flight-size > cwnd) { >> if(in-ss) >> cwnd += min(1 mtu, ack-size) >> else >> pba += acksize; >> if(pba > cwnd) >> cwnd += 1 MTU >> pba -= cwnd >> if(pba <=0) >> pba = 0 >>} >> >>Now in our example guess what? flight-size = 1MTU (assuming you had >>a full MTU or more to retran)... so the "if" would never be entered and >>NO cwnd advance would happen. >> >>It is hard for me to imagine a situation where you would really get the >>alternate above 1MTU in flight size .... so I doubt there is a problem.. >>in fact >>the real issue is the false T3 will have caused a collapse of the >>primary... I guess this is what Eifel attempts to fix in TCP.... >> >>So >> >>1) I see no CC problem with the current scheme >>2) We probably need to NOT retransmit FR's to an alternate >>3) It is best, I think, if we schedule a HB on the alternate after >> a retransmission.. Armando is still working on this point but >> if you have any loss on the alternate you need some way of >> collapsing the RTO so scheduling a HB can do that to help >> performance.... >> >>I am anxious for Armando to get a bit further in his research and I think >>this will shed some additional light on the situation :> >> >> >> >>>I guess NIC failure happens very infrequently when compared to >>>congestion and spurious timeout. I don't think it is a good >>>suggestion to design the timeout retransmission around an uncommon >>>case. And it seems to me that the correct way to handle a NIC >>>failure is to use ASCONF to tell the peer to either remove those IP >>>addresses associated with the failed NIC or to change the primary >>>path if it is to the failed NIC. One may ask why such mechanism >>>is not included in the original spec... >>> >>> >>Well, we DID want both PR-SCTP and ADD-IP in the base spec... but in order >>to not hold things up to long we decided to do them as seperate drafts.. >>and it >>is a good thing too.. ADD-IP still needs some more work (in the security >>front) and >>PR-SCTP is now 3 years later almost done... >> >>Many implementations do have ASCONF working.. which can help in this >>situation... but one would need (as Qiaobing pointed out) some sort of >>L2 trigger >>to tell the peer "hey your nic card X failed" so that it could "know" to >>send the >>"set-primary" to the alternate. And of course a "generic" trigger, as >>yet, does not >>exist. Another area ripe for research... >> >>R >> >> >> >>> >>> >>> >>> >>_______________________________________________ >>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 Aug 7 09: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 JAA12428 for ; Thu, 7 Aug 2003 09: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 19klEO-0005rt-S9 for tsvwg-archive@odin.ietf.org; Thu, 07 Aug 2003 09:55:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77Dt4CF022552 for tsvwg-archive@odin.ietf.org; Thu, 7 Aug 2003 09:55:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19klEL-0005rd-VO; Thu, 07 Aug 2003 09: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 19klDU-0005r7-Ah for tsvwg@optimus.ietf.org; Thu, 07 Aug 2003 09:54: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 JAA12390 for ; Thu, 7 Aug 2003 09:54:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19klDS-0006Ae-00 for tsvwg@ietf.org; Thu, 07 Aug 2003 09:54:06 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19klDR-0006AV-00 for tsvwg@ietf.org; Thu, 07 Aug 2003 09:54:05 -0400 Received: from 192.168.0.102 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 25BD92460F0; Thu, 7 Aug 2003 09:53:41 -0400 (EDT) Date: Thu, 7 Aug 2003 08:53:31 -0500 From: Caitlin Bestler Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) To: Qiaobing Xie Cc: "Randall R. Stewart (home)" , Kacheong Poon , tsvwg@ietf.org X-Priority: 3 In-Reply-To: <3F317863.23C24AB6@motorola.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > a) The "agile" approach - move retrans to the > alternative at the first sign of trouble; this is the > current RFC2960 recommendation. > > b) The "stubborn" approach - insisting on using the > current addr for all trans and retrans until nothing > can get through; > > c) something in-between - e.g., if it is FR, use the > same addr, if RTO, use the alternative. Actually I think the "stubborn" proposals are more along the lines of "insisting on using the current addr until it is obvious that there is really a problem there". That is, multiple drops would indicate there really is congestion and the path should be abandoned. The question is whether presuming that a *single* drop indicates a problem is appropriate. But the "agile" versus "stubborn" distinction may be very close to the real distinctin: "low latency" vs. "throughput". - If your primary concern is low latency, rather than throughput, then you want to switch paths on the first problem. Not doing so will delay being able to communicate over the remaining viable path. That delay represents a period with loss of contact, which is very unacceptable for a control application. - If your primary concern is throughput then switching paths because of a single transient drop might be an overreaction. The alternate path has not been "exercised". Shifting to it will result in at least a temporary drop in throughput. On the other hand, delaying switching might be delaying a corrective response to a congestion problem. That's a distinction based upon usage, not on the target network. Which is certainly more acceptable. Just thinking out loud here, but would it be appropriate to leave this choice to the sender? The sender could easily know which mode it was in either by explicit user configuration and/or just observing. (If the pending Data Chunk queue hasn't hit empty for several seconds you are probably not being used by a "low latency" application). Note: I still believe that such an algorithm has to make sense based upon "typical" networks and should not be used to solve special L2 problems. Is there any hard research as to how often a packet is dropped for reasons that are neither equipment failure or congestion? How high of a "false positive" rate are we talking about here? Caitlin Bestler - http://asomi.com/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Aug 7 13:52: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 NAA24155 for ; Thu, 7 Aug 2003 13:52: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 19kovl-0003wB-7q for tsvwg-archive@odin.ietf.org; Thu, 07 Aug 2003 13:52:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77Hq5gH015131 for tsvwg-archive@odin.ietf.org; Thu, 7 Aug 2003 13:52:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kovi-0003vL-5a; Thu, 07 Aug 2003 13:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kova-0003tw-8N for tsvwg@optimus.ietf.org; Thu, 07 Aug 2003 13:51: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 NAA24117 for ; Thu, 7 Aug 2003 13:51:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kovX-00019B-00 for tsvwg@ietf.org; Thu, 07 Aug 2003 13:51:52 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19kovX-000197-00 for tsvwg@ietf.org; Thu, 07 Aug 2003 13:51:51 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h77HpoJ9024017; Thu, 7 Aug 2003 10:51:50 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h77HpnaQ023449; Thu, 7 Aug 2003 12:51:49 -0500 Message-ID: <3F3291B0.17353B31@motorola.com> Date: Thu, 07 Aug 2003 12:51:44 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Randall R. Stewart (home)" CC: Kacheong Poon , tsvwg@ietf.org, "Armando L. Caro Jr." Subject: Re: [Tsvwg] F-RTO and SCTP References: <3F1D8B89.40502@sun.com> <3F2E4F3A.7020500@stewart.chicago.il.us> <3F3013CB.3020505@sun.com> <3F310CBB.1080108@stewart.chicago.il.us> <3F317863.23C24AB6@motorola.com> <3F323A5F.7060102@stewart.chicago.il.us> 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 > >...2) if the *some* problem is congestion > >induced (maybe some one started download huge movie files or a workhorse > >router went down in that part of network), wouldn't it still be a very > >good thing that the SCTP traffic is swiftly shifted away from the > >congested area of the network (assuming path diversity exists here)? > >This not only helps the congestion condition to improve quicker in the > >affected area, but also lessens the impact on the data sender's > >throughput. Imagine that if in the future a portion of the Internet > >traffic can perform this type of "agile" multi-homing, how much it could > >benefit the network congestion recovery. .... > > We need a lot more work.. and I know Armando will get this out over > the next year or so... I really think that will provide the best > throughput and at the same time the best fault recovery.. One more observation along this line about CC research - The age-old TCP CC algorithm (as well as that of SCTP and the newer TFRC) is based on a simple "common sense" strategy: "hit the brake when you see the road ahead is jammed". Over the years, countless research effort has gone into figuring out when to hit the brake and how hard to hit the brake :-) But why sticking to this strategy? It is simply because that is the ONLY road known to the car driver (i.e., the TCP sender) to reach the destination! Now, SCTP's multi-homing support opens up a new dimension to the CC world - now the car driver has the knowledge of (possible) alternate routes to the same destination. Shouldn't this new dimension prompt our driver to rethink about its strategy and take full advantage of it? Or should we say "this new dimension does not fit into the age-old strategy so let's take it out"? IMHO, CC research community should start thinking about how to best benefit from multi-homing now, instead of the other way around. regards, -Qiaobing > > R > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Aug 7 16:09: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 QAA00614 for ; Thu, 7 Aug 2003 16:09: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 19kr4J-00033C-NU for tsvwg-archive@odin.ietf.org; Thu, 07 Aug 2003 16:09:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77K93ki011722 for tsvwg-archive@odin.ietf.org; Thu, 7 Aug 2003 16:09:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kr4H-000328-Jq; Thu, 07 Aug 2003 16: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 19kr3Z-00031W-IA for tsvwg@optimus.ietf.org; Thu, 07 Aug 2003 16:08: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 QAA00583 for ; Thu, 7 Aug 2003 16:08:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kr3X-0002P9-00 for tsvwg@ietf.org; Thu, 07 Aug 2003 16:08:15 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 19kr3W-0002Or-00 for tsvwg@ietf.org; Thu, 07 Aug 2003 16:08:14 -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 h77K7i4V021461 for ; Thu, 7 Aug 2003 13:07:44 -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 NAA22048 for ; Thu, 7 Aug 2003 13:07:19 -0700 (PDT) Message-ID: <3F32B176.5040100@sun.com> Date: Thu, 07 Aug 2003 13:07:18 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 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: <3F1D8B89.40502@sun.com> <3F2E4F3A.7020500@stewart.chicago.il.us> <3F3013CB.3020505@sun.com> <3F3022AA.CF63147F@motorola.com> <3F302502.3050904@sun.com> <3F302E50.1953A739@motorola.com> <3F315350.3050803@sun.com> <3F318120.D983756A@motorola.com> In-Reply-To: <3F318120.D983756A@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 don't understand why we are giving up retransmission to an >>alternate address. The simple change I suggested was to do >>the first timeout retransmission to the original address. SCTP >>will still send the second timeout retransmission to an alternate >>address. > > > This is less dramatic. Assuming the sender's RTO_min = 1 sec at the time > of the fault, this still adds 2 sec delay to the fault recovery which > could be significant in some cases. However, does this "just one more > retrans to the current addr" really help you? How? I believe the second timeout provides a very good indication that the path to the original address has some issues. The primary concerns we have are spurious timeout, congestion, NIC failure. I believe the spurious timeout issue is mostly ruled out if the the timer fires the second time. If the first retransmission is also dropped because of congestion, it will be the same to use the primary and alternate path as far as congestion control is concerned as ssthresh will not be a factor anymore. And the path must be very congested. If it is a NIC failure, I guess two tries are good enough. If SCTP retransmits to the original address in the first timeout, I believe F-RTO will work pretty well in detecting spurious timeouts without introducing new chunks or new bundling rules. To me, this is a big win for F-RTO. We don't want to keep changing rules, especially if it requires both sides to agree. F-RTO can be done on the sender side only without changing anything in RFC 2960. If we really want to speed detecting NIC failure up, the already defined ASCONF should work pretty well. As a matter of fact, it should work faster than the timeout retransmission. >>This is a default behavior I suggested implementors to >>use. Having said that, it does not mean that an SCTP implementation >>should always follow the default behavior. It can just be a >>simple switch or an option to change the behavior to send the >>first timeout retransmission to an alternate address. > > > But how are we going to tell people when to *not* use that optional > behavior? I'd guess that having faster fault recovery is welcome by > everyone. I used telecomm as an example simply because for them recovery > speed becomes a vital requirement. But in reality, it will be a good > thing for everyone especially for those who have already gone through > the trouble of setting up multi-homing, right? You are making the assumption that the alternate address is always better here. I don't believe SCTP has this knowledge. It is pretty much a guess. So I suggest people not to use this optional behavior unless they are pretty sure that their network setup supports it. For example, it may work in your telecomm network. And if I understand how you put it, the telecomm network is pretty much separated from the real Internet such that it can provide that kind of guarantees you mentioned, no congestion. So I don't see a problem for all the SCTP stacks used in that environment to change the behavior. I guess we should not provide false information to people that the alternate address is always better than the original address in the event of retransmission. Or am I missing something that you can provide such a proof that the alternate address is always better in the case of the first timeout? > I guess I would agree if I can understand why the current design does > NOT fit general purpose (also see my other email on this topic). I believe the confusion caused by retransmission to an alternate address is well discussed. The current default behavior is only guaranteed to work well in a specially designed network. In general, SCTP does not have this kind of knowledge about the network. And I believe the simple change not to use alternate address in the first timeout helps solve the majority of the confusion described with the help of F-RTO, a mechanism which does not require new chunks or bundling rules. To me, this is a very strong reason not to follow the default behavior described in RFC 2960. Well, just my $0.02 anyway. But I hope people will not spread the idea that using an alternate address is always better, unless the network is designed that way. As I mentioned earlier, there may be a proof contrary to this which I haven't seen. If it can be proved, I have no issue using the alternate address in the first timeout. > By "external" I referred to anything outside the SCTP stack itself. > Device driver is external and we have know knowledge as to how it really > works to determine a NIC failure, for example. Well, I guess you think all those products, commercial and free, which provide such kind of NIC failure detection are wrong architecturally and do not work well... -- K. Poon. kacheong.poon@sun.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Aug 7 16:32: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 QAA01538 for ; Thu, 7 Aug 2003 16:32: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 19krQY-0003yp-Tv for tsvwg-archive@odin.ietf.org; Thu, 07 Aug 2003 16:32:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77KW2Ww015292 for tsvwg-archive@odin.ietf.org; Thu, 7 Aug 2003 16:32:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19krQX-0003xt-SP; Thu, 07 Aug 2003 16: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 19krQU-0003xi-Q8 for tsvwg@optimus.ietf.org; Thu, 07 Aug 2003 16:31: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 QAA01531 for ; Thu, 7 Aug 2003 16:31:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19krQS-0002ax-00 for tsvwg@ietf.org; Thu, 07 Aug 2003 16:31:56 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19krQS-0002au-00 for tsvwg@ietf.org; Thu, 07 Aug 2003 16:31:56 -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 h77KVQgP029907 for ; Thu, 7 Aug 2003 13:31:26 -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 NAA07274 for ; Thu, 7 Aug 2003 13:31:00 -0700 (PDT) Message-ID: <3F32B704.6080004@sun.com> Date: Thu, 07 Aug 2003 13:31:00 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 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 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: > Actually I think the "stubborn" proposals are more > along the lines of "insisting on using the current addr > until it is obvious that there is really a problem > there". That is, multiple drops would indicate there > really is congestion and the path should be abandoned. > The question is whether presuming that a *single* drop > indicates a problem is appropriate. > > But the "agile" versus "stubborn" distinction may be > very close to the real distinctin: "low latency" vs. > "throughput". > > - If your primary concern is low latency, rather > than throughput, then you want to switch paths on > the first problem. Not doing so will delay being > able to communicate over the remaining viable > path. That delay represents a period with loss of > contact, which is very unacceptable for a control > application. I guess the issue here is whether using the alternate address will be better. Firstly, I believe SCTP cannot know for sure that the paths to the two different addresses do not cross. If they in fact are crossed, sending to the alternate address may have the same problem as well. I believe all SCTP knows about the alternate address is that it is reachable at the time SCTP receives the last HB-ACK. That is all. I don't know if SCTP can infer more info from that. So blindly retransmitting to an alternate address may not help in the "low latency" goal at all. > - If your primary concern is throughput then > switching paths because of a single transient drop > might be an overreaction. The alternate path has > not been "exercised". Shifting to it will result > in at least a temporary drop in throughput. > > On the other hand, delaying switching might be > delaying a corrective response to a congestion > problem. > > > That's a distinction based upon usage, not on the > target network. Which is certainly more acceptable. But the issue is if the network actually supports the claim that the above two mechanisms work as described. > Just thinking out loud here, but would it be > appropriate to leave this choice to the sender? The > sender could easily know which mode it was in either by > explicit user configuration and/or just observing. (If > the pending Data Chunk queue hasn't hit empty for > several seconds you are probably not being used by a > "low latency" application). Do you mean by the sender's SCTP code or the app code? I don't know if it works well for SCTP to determine the network usage of the app. > Note: I still believe that such an algorithm has to > make sense based upon "typical" networks and should not > be used to solve special L2 problems. Is there any > hard research as to how often a packet is dropped > for reasons that are neither equipment failure or > congestion? How high of a "false positive" rate > are we talking about here? It seems that "typical" means different things to different people. So such an algorithm may actually need to work well in "all kinds of" networks... -- K. Poon. kacheong.poon@sun.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Aug 7 18: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 SAA04879 for ; Thu, 7 Aug 2003 18:01: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 19ksok-0007g3-Gv for tsvwg-archive@odin.ietf.org; Thu, 07 Aug 2003 18:01:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77M16rk029505 for tsvwg-archive@odin.ietf.org; Thu, 7 Aug 2003 18:01:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ksog-0007f1-6p; Thu, 07 Aug 2003 18:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kso5-0007eM-I6 for tsvwg@optimus.ietf.org; Thu, 07 Aug 2003 18:00: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 SAA04848 for ; Thu, 7 Aug 2003 18:00:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kso2-0003A4-00 for tsvwg@ietf.org; Thu, 07 Aug 2003 18:00:22 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx with esmtp (Exim 4.12) id 19kso1-0003A0-00 for tsvwg@ietf.org; Thu, 07 Aug 2003 18:00:22 -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 PAA01998 for ; Thu, 7 Aug 2003 15:00:21 -0700 (PDT) Received: from slb-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 PAA20809 for ; Thu, 7 Aug 2003 15:00:20 -0700 (PDT) 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 h77Lx8500888 for ; Thu, 7 Aug 2003 14:59:08 -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); Thu, 7 Aug 2003 14:59:05 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 7 Aug 2003 14:59:05 -0700 Message-ID: Thread-Topic: Updating timestamps (ts_recent) in Linux Thread-Index: AcNdL17csxuLUJTxTwCQ0+6SwBoeng== From: "Duke, Martin" To: X-OriginalArrivalTime: 07 Aug 2003 21:59:05.0431 (UTC) FILETIME=[1E931E70:01C35D2F] Content-Transfer-Encoding: quoted-printable Subject: [Tsvwg] Updating timestamps (ts_recent) in Linux Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@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 I've heard rumors that this has been discussed before on tcp-impl, but = an extensive search found no messages on this topic, so apologies for = possibly re-treading old ground. How do people feel about the way Linux decides what timestamp to echo? Specifically, although the behavior is compliant with RFC 1323, an old = addendum to the RFC (http://www.kohala.com/start/tcplw-extensions.txt) = pointed out some odd behavior. Essentially, if the connection goes down, the subsequent retransmissions = will have later ts values. However, if an ACK was lost, the kernel = currently does not update ts_recent with these values. If the channel = comes back up and a retrans succeeds, the client will send an ack with = an ts echo equal to the old value of ts_recent. As the difference between the echo and the current time is quite large, = it=20 will result in an extremely large RTT measurement, triggering a huge = increase=20 in the RTO. In an unreliable, bursty link, such as satellites, another = outage=20 could occur shortly thereafter, and an inappropriately long timeout can = occur. The reason for the problem is that ts_recent is only updated if the = receive window moves to the right. Ideally, packets with sequence = numbers to the left of the window edge should trigger an update as well. There are certainly situations where the current Linux behavior is = terrible, but I have yet to see an explanation for why this "bug" should = not be fixed. I've heard criticisms of the document cited above as a = whole but have yet to understand why updating ts_recent more frequently = will break something. I know that BSD fixed this some time ago (Stevens = talks about it in his book). Any thoughts? Martin Duke martin.duke@boeing.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Aug 7 20:24:42 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 UAA09652 for ; Thu, 7 Aug 2003 20:24:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kv3F-0003mI-BX for tsvwg-archive@odin.ietf.org; Thu, 07 Aug 2003 20:24:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h780ODB3014488 for tsvwg-archive@odin.ietf.org; Thu, 7 Aug 2003 20:24:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kv34-0003eW-GA; Thu, 07 Aug 2003 20: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 19kuGz-0002Bl-4x for tsvwg@optimus.ietf.org; Thu, 07 Aug 2003 19:34: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 TAA08547 for ; Thu, 7 Aug 2003 19:34:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kuGx-0003hr-00 for tsvwg@ietf.org; Thu, 07 Aug 2003 19:34:19 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 19kuGw-0003ho-00 for tsvwg@ietf.org; Thu, 07 Aug 2003 19:34:18 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h77NYIPP018126; Thu, 7 Aug 2003 16:34:18 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h77NYFZr026085; Thu, 7 Aug 2003 18:34:15 -0500 Message-ID: <3F32E1F1.E94C76F6@motorola.com> Date: Thu, 07 Aug 2003 18:34:09 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kacheong Poon CC: tsvwg@ietf.org Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) References: <3F1D8B89.40502@sun.com> <3F2E4F3A.7020500@stewart.chicago.il.us> <3F3013CB.3020505@sun.com> <3F3022AA.CF63147F@motorola.com> <3F302502.3050904@sun.com> <3F302E50.1953A739@motorola.com> <3F315350.3050803@sun.com> <3F318120.D983756A@motorola.com> <3F32B176.5040100@sun.com> 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 Kacheong Poon wrote: .... > You are making the assumption that the alternate address is > always better here. I don't believe SCTP has this knowledge. > It is pretty much a guess. You emphasized this point several more times below (and did so in your another email). My comment is that the enter TCP/SCTP CC algorithm is designed around "making guesses" - or call it the "learn by experience" principle. If one rejects this principle, nothing in the CC design will hold. In our particular SCTP case here, the sender just had a "bad" experience with the primary addr and has "no or little experience" with the alternate addr. No one in his right mind will ever say he's sure that the alternate address is always better. But it is simply due to this fundamental "learn by experience" principle that the sender has a reason to favor the alternate addr ***at that particular moment***. The reasoning is not based on "always better", rather it is on the "no experience + optimistism" vs. "fresh bad experience". > So I suggest people not to use > this optional behavior unless they are pretty sure that their > network setup supports it. For example, it may work in your > telecomm network. And if I understand how you put it, the > telecomm network is pretty much separated from the real > Internet such that it can provide that kind of guarantees you > mentioned, no congestion. So I don't see a problem for all > the SCTP stacks used in that environment to change the behavior. As I said before, it's not just about telecomm. Rather, any association that has path diversity will potentially benefit. This includes associations across the Internet since there is nothing to prevent path diversity naturally occurring in the Internet. > > I guess we should not provide false information to people that > the alternate address is always better than the original > address in the event of retransmission. > ... Or am I missing something > that you can provide such a proof that the alternate address is > always better in the case of the first timeout? ditto. > > > I guess I would agree if I can understand why the current design does > > NOT fit general purpose (also see my other email on this topic). > > I believe the confusion caused by retransmission to an alternate > address is well discussed. The current default behavior is only > guaranteed to work well in a specially designed network. In > general, SCTP does not have this kind of knowledge about the network. It is quite clear that if you have path diversity you will benefit from it; But if you don't, will it hurt? This is what I wanted to understand in my question above. > And I believe the simple change not to use alternate address in the > first timeout helps solve the majority of the confusion described with > the help of F-RTO, a mechanism which does not require new chunks or > bundling rules. To me, this is a very strong reason not to follow > the default behavior described in RFC 2960. Well, just my $0.02 > anyway. But I hope people will not spread the idea that using > an alternate address is always better, unless the network is designed > that way. As I mentioned earlier, there may be a proof contrary > to this which I haven't seen. If it can be proved, I have no issue > using the alternate address in the first timeout. ditto. > > > By "external" I referred to anything outside the SCTP stack itself. > > Device driver is external and we have know knowledge as to how it really > > works to determine a NIC failure, for example. > > Well, I guess you think all those products, commercial and free, > which provide such kind of NIC failure detection are wrong > architecturally and do not work well... Nothing is wrong about using external detection. I think it's a matter of design choice. In SCTP, the design decision was made very early to make it more robust by including built-in failure detection and recovery mechanism. Now you seem to suggest remove or disallow those built-in mechanism and instead, to rely on external mechanism for failure detection. Doing so, aren't you going to make SCTP users' life harder? regards, -Qiaobing > > -- > > 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 Aug 8 03:54: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 DAA02624 for ; Fri, 8 Aug 2003 03: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 19l24Z-0006as-U3 for tsvwg-archive@odin.ietf.org; Fri, 08 Aug 2003 03:54:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h787s3Yw025346 for tsvwg-archive@odin.ietf.org; Fri, 8 Aug 2003 03:54:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l24X-0006a3-Ch; Fri, 08 Aug 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 19l24P-0006Zg-5P for tsvwg@optimus.ietf.org; Fri, 08 Aug 2003 03:53: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 DAA02621 for ; Fri, 8 Aug 2003 03:53:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l24M-0006XN-00 for tsvwg@ietf.org; Fri, 08 Aug 2003 03:53:50 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19l24L-0006XK-00 for tsvwg@ietf.org; Fri, 08 Aug 2003 03:53:49 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h787rl7W003992; Fri, 8 Aug 2003 09:53:47 +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 QL9J5JZ6; Fri, 8 Aug 2003 09:53:47 +0200 Received: from res0010384da36.ericsson.com (rac179pc.edd.ericsson.se [164.48.123.179]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id JAA18870; Fri, 8 Aug 2003 09:53:43 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030808085319.03ae9b40@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 08 Aug 2003 09:50:46 +0200 To: "Duke, Martin" From: Reiner Ludwig Subject: Re: [Tsvwg] Updating timestamps (ts_recent) in Linux Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 23:59 07.08.2003, Duke, Martin wrote: >How do people feel about the way Linux decides what timestamp to echo? > >Specifically, although the behavior is compliant with RFC 1323, an old >addendum to the RFC (http://www.kohala.com/start/tcplw-extensions.txt) >pointed out some odd behavior. I don't think that LINUX should be blamed for this behavior since afterall - as you said - it is compliant with RFC1323. One problem certainly is that various RFC1323 update attempts are floating around that suggest different TS echoing rules, and therefore different TCPs do different things here. My personal opinion is that the soon-to-be-established TCP working group needs to have a revision of RFC1323 as one of its work items, and the TS echoing rules would be one of the issues to be discussed; especially rule (B) in Section 3.4 of RFC1323. If I understand you right it is that rule (B) that is causing the headaches in your scenario. We found similar issue with that rule (B). In particular, it prevents the TCP sender from sampling the *real* RTT during loss recovery since the returning DUPACKs all carry the same old timestamp which leads to an inflated RTT. [BTW, the ns2 code is not compliant with RFC1323 in this respect! At least, rule (B) doesn't seem to be followed.] One solution would be to change rule (B) to the opposite, i.e., an ACK for an out-of-order segment should contain the timestamp from the most recently received segment. And in addition, allow the TCP sender to take RTT samples from DUPACKs as long as it has data outstanding. The latter is currently not allowed due to a rule stated in Section 3.3 of RFC1323: A TSecr value received in a segment is used to update the averaged RTT measurement only if the segment acknowledges some new data, i.e., only if it advances the left edge of the send window. These changes should also take care of the problem you describe, right? If you're interested, we have a paper in-progress that also discusses these issues. A draft of the paper is available here: http://www.cs.helsinki.fi/u/gurtov/reiner/PeakHopper_draft0207.pdf ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Aug 8 04: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 EAA03897 for ; Fri, 8 Aug 2003 04: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 19l2o7-0000n4-B7 for tsvwg-archive@odin.ietf.org; Fri, 08 Aug 2003 04:41:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h788f7KA003038 for tsvwg-archive@odin.ietf.org; Fri, 8 Aug 2003 04: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 19l2o4-0000m0-AR; Fri, 08 Aug 2003 04:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2nF-0000lb-3C for tsvwg@optimus.ietf.org; Fri, 08 Aug 2003 04: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 EAA03866 for ; Fri, 8 Aug 2003 04:40:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l2nB-0006pI-00 for tsvwg@ietf.org; Fri, 08 Aug 2003 04:40:10 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19l2nA-0006pF-00 for tsvwg@ietf.org; Fri, 08 Aug 2003 04:40:09 -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 h788e8J06614 for ; Fri, 8 Aug 2003 11:40:09 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Aug 2003 11:40:08 +0300 Received: from sahaja.research.nokia.com ([172.21.40.118]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 8 Aug 2003 11:40:08 +0300 Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) From: Pasi Sarolahti To: ext Kacheong Poon Cc: tsvwg@ietf.org In-Reply-To: <3F32B176.5040100@sun.com> References: <3F1D8B89.40502@sun.com> <3F2E4F3A.7020500@stewart.chicago.il.us> <3F3013CB.3020505@sun.com> <3F3022AA.CF63147F@motorola.com> <3F302502.3050904@sun.com> <3F302E50.1953A739@motorola.com> <3F315350.3050803@sun.com> <3F318120.D983756A@motorola.com> <3F32B176.5040100@sun.com> Content-Type: text/plain Organization: Nokia Research Center Message-Id: <1060332004.12822.70.camel@optiplex> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 08 Aug 2003 11:40:04 +0300 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2003 08:40:08.0496 (UTC) FILETIME=[AC591300:01C35D88] 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 Thu, 2003-08-07 at 23:07, ext Kacheong Poon wrote: > I believe the confusion caused by retransmission to an alternate > address is well discussed. The current default behavior is only > guaranteed to work well in a specially designed network. In > general, SCTP does not have this kind of knowledge about the network. > And I believe the simple change not to use alternate address in the > first timeout helps solve the majority of the confusion described with > the help of F-RTO, a mechanism which does not require new chunks or > bundling rules. To me, this is a very strong reason not to follow > the default behavior described in RFC 2960. Well, just my $0.02 > anyway. But I hope people will not spread the idea that using > an alternate address is always better, unless the network is designed > that way. As I mentioned earlier, there may be a proof contrary > to this which I haven't seen. If it can be proved, I have no issue > using the alternate address in the first timeout. If I understood it correctly, the first RTO (or T3) retransmission to alternate address may cause problem for F-RTO and Eifel only if the RTT of the alternate path is smaller than the RTT of the original path plus the delay spike, so that the acknowledgement of the retransmission arrives before the acknowledgements of the delayed original segments. The problem with F-RTO in setup above was that a possible loss of the originally transmitted data chunk that was later retransmitted with RTO may not be detected, if the RTO was caused by a delay spike. So, as far as I see it, in this case the unnecessary retransmissions can be avoided with F-RTO, but the congestion control decision may be incorrect (depending on what kind of congestion control is applied after detecting a spurious timeout). Hence, with 'SCTP-retransmitting-to-alternate-addr' the congestion control undoing decision should be made only after the unnecessary RTO retransmission can be confirmed with a duplicate-TSN. The benefit of F-RTO would still be that the other unnecessary retransmissions after RTO can be avoided, regardless of the characteristics of different paths. This being said, I believe the issue of whether to do the first retransmission to original or alternate address is not that important from the F-RTO standpoint, although making first retransmission to the original would make things a bit easier. Of course, the other aspects discussed here are another thing. - Pasi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Aug 8 08:31: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 IAA09112 for ; Fri, 8 Aug 2003 08:31: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 19l6Oj-0002Oo-74 for tsvwg-archive@odin.ietf.org; Fri, 08 Aug 2003 08:31:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78CV9Rw009213 for tsvwg-archive@odin.ietf.org; Fri, 8 Aug 2003 08:31:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l6Oc-0002OU-Lb; Fri, 08 Aug 2003 08: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 19l6OZ-0002NV-UW for tsvwg@optimus.ietf.org; Fri, 08 Aug 2003 08:31: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 IAA09099 for ; Fri, 8 Aug 2003 08:30:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l6OY-0000Le-00 for tsvwg@ietf.org; Fri, 08 Aug 2003 08:30:58 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19l6OX-0000LO-00 for tsvwg@ietf.org; Fri, 08 Aug 2003 08:30:58 -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 h78CULw0008587; Fri, 8 Aug 2003 07:30:22 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F3397DD.9040504@stewart.chicago.il.us> Date: Fri, 08 Aug 2003 07:30:21 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kacheong Poon CC: tsvwg@ietf.org Subject: Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps) References: <3F1D8B89.40502@sun.com> <3F2E4F3A.7020500@stewart.chicago.il.us> <3F3013CB.3020505@sun.com> <3F3022AA.CF63147F@motorola.com> <3F302502.3050904@sun.com> <3F302E50.1953A739@motorola.com> <3F315350.3050803@sun.com> <3F318120.D983756A@motorola.com> <3F32B176.5040100@sun.com> In-Reply-To: <3F32B176.5040100@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kacheong Poon wrote: >> By "external" I referred to anything outside the SCTP stack itself. >> Device driver is external and we have know knowledge as to how it really >> works to determine a NIC failure, for example. > > > Well, I guess you think all those products, commercial and free, > which provide such kind of NIC failure detection are wrong > architecturally and do not work well... Kacheong: I don't think this is what Qiaobing meant... I too have had issues with failure detection in NIC's. The problem is: 1) Some NIC support it, some don't 2) The driver generally has to do some query to see that status (active/failed etc).. 3) The driver generally does NOT send this information on outside of the driver because there is no general purpose way for it to do so. I have always thought there needed to be some "standard" ethernet or IP frame the driver could generate to report local changes to the NIC card... this would give kernel and driver developers a standard mechanism to pass on to transport protocols etc. And security on this would not be an issue.. if one comes in from the outside the driver could silently discard it... I had a proposal once and even made a driver generate such.. but I never did anything with it .. not enough cycles :-0 Oh, well.. maybe someday R --- Randall R. Stewart > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Aug 8 11: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 LAA15390 for ; Fri, 8 Aug 2003 11:39: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 19l9KZ-0002OS-OV for tsvwg-archive@odin.ietf.org; Fri, 08 Aug 2003 11:39:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78Fd3h2009160 for tsvwg-archive@odin.ietf.org; Fri, 8 Aug 2003 11:39:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l9KX-0002Mi-IB; Fri, 08 Aug 2003 11: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 19l9KL-0002MD-S4 for tsvwg@optimus.ietf.org; Fri, 08 Aug 2003 11:38: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 LAA15362 for ; Fri, 8 Aug 2003 11:38:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l9KK-0001Yu-00 for tsvwg@ietf.org; Fri, 08 Aug 2003 11:38:48 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19l9KK-0001Yr-00 for tsvwg@ietf.org; Fri, 08 Aug 2003 11:38:48 -0400 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id IAA07805; Fri, 8 Aug 2003 08:38:01 -0700 (PDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id IAA19296; Fri, 8 Aug 2003 08:38:43 -0700 (PDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h78Fbah27625; Fri, 8 Aug 2003 10:37:36 -0500 (CDT) 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); Fri, 8 Aug 2003 08:37:22 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [Tsvwg] Updating timestamps (ts_recent) in Linux Date: Fri, 8 Aug 2003 08:37:21 -0700 Message-ID: Thread-Topic: [Tsvwg] Updating timestamps (ts_recent) in Linux Thread-Index: AcNdgkUuhsEo81lhTaSuAIXH1RSLcgAPbHVw From: "Duke, Martin" To: "Reiner Ludwig" Cc: X-OriginalArrivalTime: 08 Aug 2003 15:37:22.0102 (UTC) FILETIME=[F58A3560:01C35DC2] 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: Reiner Ludwig [mailto:Reiner.Ludwig@ericsson.com] > Sent: Friday, August 08, 2003 12:51 AM > To: Duke, Martin > Cc: tsvwg@ietf.org > Subject: Re: [Tsvwg] Updating timestamps (ts_recent) in Linux >=20 > especially rule=20 > (B) in Section 3.4 of RFC1323. If I understand you right it=20 > is that rule=20 > (B) that is causing the headaches in your scenario. >=20 > We found similar issue with that rule (B). In particular, it=20 > prevents the=20 > TCP sender from sampling the *real* RTT during loss recovery=20 > since the=20 > returning DUPACKs all carry the same old timestamp which leads to an=20 > inflated RTT. Actually, it's not rule (B) but rule (2), in a sense exactly the = opposite. If a burst error wipes out a series of ACKs, the sender will = retransmit a packet to the left of Last.ACK.Sent. The current test SEG.SEQ <=3D Last.ACK.sent < SEG.SEQ + SEG.LEN will not update ts_recent with the received value. A better test is (SEG.SEQ <=3D Last.ACK.sent) && (ts_val > ts_recent) since this will allow retransmitted packets to be echoed. Of course, your problem is more prevalent in single-packet loss = situations than for burst errors. I suppose if one combines our = proposals one ends up with if (ts_val > ts_recent) ts_recent =3D ts_val and doesn't pay any attention to sequence numbers at all. As far as I can figure, these more liberal rules for echoing would = produce more truthful RTT estimates. The only counter-argument I've = heard is that it's best to be conservative, especially in the face of = packet loss and retransmission. In my opinion, however, it's best to be as accurate as possible with = the RTT, and if you wish to be conservative, do so with the way you = convert the RTT to the RTO. To do otherwise is to invite pathological = behavior in atypical but not uncommon situations. I would strongly support any effort to revise RFC 1323 along these = lines. Martin _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Aug 8 12:05: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 MAA16158 for ; Fri, 8 Aug 2003 12:05: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 19l9ji-0003gA-UH for tsvwg-archive@odin.ietf.org; Fri, 08 Aug 2003 12:05:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78G521c014143 for tsvwg-archive@odin.ietf.org; Fri, 8 Aug 2003 12: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 19l9jh-0003fK-5h; Fri, 08 Aug 2003 12: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 19l3rO-0004ga-Ur for tsvwg@optimus.ietf.org; Fri, 08 Aug 2003 05:48: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 FAA05831 for ; Fri, 8 Aug 2003 05:48:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l3rL-0007Mu-00 for tsvwg@ietf.org; Fri, 08 Aug 2003 05:48:31 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19l3rK-0007MX-00 for tsvwg@ietf.org; Fri, 08 Aug 2003 05:48:30 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 8 Aug 2003 11:24:16 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Aug 2003 11:24:16 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB58B@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: morita.naotaka@lab.ntt.co.jp Cc: tsvwg@ietf.org Date: Fri, 8 Aug 2003 11:24:15 +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 Subject: [Tsvwg] Comments on draft-morita-tsvwg-pps Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@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 Hello Naotaka, I think that pps is a good=20 idea. Having not to maintain QoS signaling=20 state in a backbone router is a pretty=20 good thing to do. Some comments on contents: Section 4 suggests two stage monitoring=20 of end-system behaviour. I agree that abuse=20 must be prevented at the source. You don't=20 talk of signaling there, but I guess it=20 could be part of a two stage monitoring=20 solution (you mention however a "declared=20 peak bit rate" - sounds like signaling=20 to me). Section 5 is about system behaviour in the=20 case of congestion. Would something like=20 an "explicit congestion notification" of=20 the backbone be useful? If end systems=20 could, as a reaction on such a congestion=20 indication, use codecs with lower bit rate=20 for their MF-H traffic, additional calls=20 may be accepted.=20 Section 7.1: I'm not a queuing expert, but=20 why would MF-M traffic see higher jitter?=20 Aren't all MF packet in the same queue and=20 those tagged as MF-M are discarded earlier?=20 The result is higher loss probability,=20 which is intended. But it shouldn't be=20 higher jitter (don't earlier losses make=20 it look like a "shorter" queue?). Section 7.4 suggests the transmitter not to=20 pause at the edge. ISPs may charge on volume=20 and customers won't be happy if their=20 terminal creates traffic while they aren't=20 active.=20 I understand the issue and I should offer=20 an alternative. Some form of signaling based=20 admission control in combination with=20 measurements? Section 7.5: The RMONMIB WG maintains some=20 drafts promoting RAQMON. I'm not familiar with=20 details, but your media monitoring server might=20 require similar functionality. If you are=20 interested: http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-framework-= 02.txt Regards, R=FCdiger R=FCdiger Geib T-Systems Systems Integration Senior Expert, Technologiezentrum Am Kavalleriesand 3, 64295 Darmstadt Germany Fon: +49 6151 832138 http://www.t-systems.com =20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Aug 11 00:24: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 AAA23568 for ; Mon, 11 Aug 2003 00:24: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 19m4E0-0000hK-8E for tsvwg-archive@odin.ietf.org; Mon, 11 Aug 2003 00:24:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7B4O4OA002678 for tsvwg-archive@odin.ietf.org; Mon, 11 Aug 2003 00:24:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m4Dx-0000h5-Aw; Mon, 11 Aug 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 19m4Dj-0000gs-30 for tsvwg@optimus.ietf.org; Mon, 11 Aug 2003 00:23: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 AAA23548 for ; Mon, 11 Aug 2003 00:23:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m4Dg-0002ja-00 for tsvwg@ietf.org; Mon, 11 Aug 2003 00:23:44 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 19m4Df-0002jX-00 for tsvwg@ietf.org; Mon, 11 Aug 2003 00:23:43 -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 h7B4Nf1R016464; Mon, 11 Aug 2003 13:23:41 +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 h7B4Ne8E024474; Mon, 11 Aug 2003 13:23:40 +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 h7B4NeeH022421; Mon, 11 Aug 2003 13:23:40 +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 NAA09224; Mon, 11 Aug 2003 13:23:39 +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 NAA04862; Mon, 11 Aug 2003 13:23:39 +0900 (JST) Message-Id: <5.1.1.9.2.20030811130226.043fc620@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: Mon, 11 Aug 2003 13:25:00 +0900 To: "Geib, Ruediger" From: "MORITA, Naotaka" Subject: Re: [Tsvwg] Comments on draft-morita-tsvwg-pps Cc: tsvwg@ietf.org In-Reply-To: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB58B@G8PQD.blf01.telek om.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tama5.ecl.ntt.co.jp id h7B4Nf1R016464 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 Ruediger, Thank you so much for your mail. At 11:24 03/08/08 +0200, Geib, Ruediger wrote: >Hello Naotaka, > >I think that pps is a good >idea. Having not to maintain QoS signaling >state in a backbone router is a pretty >good thing to do. > >Some comments on contents: > >Section 4 suggests two stage monitoring >of end-system behaviour. I agree that abuse >must be prevented at the source. You don't >talk of signaling there, but I guess it >could be part of a two stage monitoring >solution (you mention however a "declared >peak bit rate" - sounds like signaling >to me). Yes, you are correct. In order to monitor or audit the terminal behavior, I expect some signaling mechanism to initiate two stage monitoring. I am not yet clear enough whether new functions are necessary. I will provide them in the revised ID, if any. >Section 5 is about system behaviour in the >case of congestion. Would something like >an "explicit congestion notification" of >the backbone be useful? If end systems >could, as a reaction on such a congestion >indication, use codecs with lower bit rate >for their MF-H traffic, additional calls >may be accepted. In section 4, I briefly touch on the possibility of "explicit congestion notification." At this stage, just for the sake of the simplicity and being easy to depl= oyment, I concentrate on "implicit" notificaiton such as packet loss. >Section 7.1: I'm not a queuing expert, but >why would MF-M traffic see higher jitter? >Aren't all MF packet in the same queue and >those tagged as MF-M are discarded earlier? >The result is higher loss probability, >which is intended. But it shouldn't be >higher jitter (don't earlier losses make >it look like a "shorter" queue?). In case of one queue model, you are right. But, I want to see the possiblity ot two queue model. In such case, the jitter of MF-M will be higher than the MF-H. >Section 7.4 suggests the transmitter not to >pause at the edge. ISPs may charge on volume >and customers won't be happy if their >terminal creates traffic while they aren't >active. >I understand the issue and I should offer >an alternative. Some form of signaling based >admission control in combination with >measurements? There are two ways of charging. One is simply to count the number of packets. The other is to measure the session duration, and multipiled by the=20 declared rate. Personally, I think the latter is easy to implement, but depends on edge router's capability. In any case, if the transmitter suspend and resume sending packets with a= =20 long interval, it will impact on the mulplexed traffic characteristics. If such impact is great, the edge router has to terminate the media to av= oid the big fluctuation. >Section 7.5: The RMONMIB WG maintains some >drafts promoting RAQMON. I'm not familiar with >details, but your media monitoring server might >require similar functionality. If you are >interested: >http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-framework-= 02.txt Thank you so much. I will review it. One of the difference would be to audit the forward RTP flows as well as backward RTCP flows and check the copprespondence between them. Naotaka >Regards, R=1B$B=97E=1B(Biger > > >R=1B$B=97E=1B(Biger Geib >T-Systems >Systems Integration >Senior Expert, Technologiezentrum >Am Kavalleriesand 3, 64295 Darmstadt >Germany >Fon: +49 6151 832138 >http://www.t-systems.com > > >_______________________________________________ >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=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Aug 11 08: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 IAA14579 for ; Mon, 11 Aug 2003 08: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 19mCCW-0001cQ-2l for tsvwg-archive@odin.ietf.org; Mon, 11 Aug 2003 08:55:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BCt4tO006211 for tsvwg-archive@odin.ietf.org; Mon, 11 Aug 2003 08:55:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCCT-0001c3-RG; Mon, 11 Aug 2003 08: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 19mCCL-0001bk-A2 for tsvwg@optimus.ietf.org; Mon, 11 Aug 2003 08:54: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 IAA14575 for ; Mon, 11 Aug 2003 08:54:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mCCJ-0005Zt-00 for tsvwg@ietf.org; Mon, 11 Aug 2003 08:54:51 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19mCCJ-0005Zq-00 for tsvwg@ietf.org; Mon, 11 Aug 2003 08:54:51 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7BCsl7W021087; Mon, 11 Aug 2003 14:54:47 +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 QL9CPWX3; Mon, 11 Aug 2003 14:58:54 +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 OAA17722; Mon, 11 Aug 2003 14:54:46 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030811125205.02b83270@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 11 Aug 2003 14:55:33 +0200 To: "Duke, Martin" From: Reiner Ludwig Subject: RE: [Tsvwg] Updating timestamps (ts_recent) in Linux Cc: tsvwg@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 17:37 08.08.2003, Duke, Martin wrote: >I suppose if one combines our proposals one ends up with > if (ts_val > ts_recent) > ts_recent = ts_val >and doesn't pay any attention to sequence numbers at all. > >As far as I can figure, these more liberal rules for echoing would produce >more truthful RTT estimates. The only counter-argument I've heard is that >it's best to be conservative, especially in the face of packet loss and >retransmission. > In my opinion, however, it's best to be as accurate as possible > with the RTT, and if you wish to be conservative, do so with the way you > convert the RTT to the RTO. To do otherwise is to invite pathological > behavior in atypical but not uncommon situations. I basically agree, although we should hold on to the special rule that deals with delayed ACKs. Otherwise, the sender can badly underestimate the RTT, and it seems difficult to accommodate for that in the RTO calculation. That way, we would end up with: if (ts_val > ts_recent) AND ("last data arrival was acked") ts_recent = ts_val ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Aug 11 13:58: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 NAA26148 for ; Mon, 11 Aug 2003 13:58: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 19mGvm-0006Dy-QH for tsvwg-archive@odin.ietf.org; Mon, 11 Aug 2003 13:58:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BHw6Fp023890 for tsvwg-archive@odin.ietf.org; Mon, 11 Aug 2003 13:58:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGvh-0006DC-0k; Mon, 11 Aug 2003 13: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 19mGus-0006BB-1G for tsvwg@optimus.ietf.org; Mon, 11 Aug 2003 13:57: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 NAA26077 for ; Mon, 11 Aug 2003 13:57:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGup-00006N-00 for tsvwg@ietf.org; Mon, 11 Aug 2003 13:57:07 -0400 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 19mGup-00006J-00 for tsvwg@ietf.org; Mon, 11 Aug 2003 13:57:07 -0400 Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id h7BHuYo08439 for ; Mon, 11 Aug 2003 17:56:37 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 13:56:35 -0400 Message-ID: From: "Peterson, Jon" To: "'tsvwg@ietf.org'" Date: Mon, 11 Aug 2003 13:58:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Tsvwg] WGLC for draft-ietf-tsvwg-highspeed-00 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , The chairs would like to announce a two-week working group last call for comments on draft-ietf-tsvwg-highspeed-00 commencing today (Monday 8/11/03). While he author has already produced a small editorial fix to the draft (softening the text about the suitability of these experimental mechanisms for deployment) in a new version, we'd like to last call the existing text with the understanding that a modified version with the text in question (along with any other needed fixes) will be submitted before the document moves on to IESG review. Please direct any last call comments associated with the draft to this mailing list. Jon Peterson NeuStar, Inc. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Aug 12 04:42: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 EAA04936 for ; Tue, 12 Aug 2003 04:42: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 19mUis-0002ej-ON for tsvwg-archive@odin.ietf.org; Tue, 12 Aug 2003 04:41:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C8fgEe010205 for tsvwg-archive@odin.ietf.org; Tue, 12 Aug 2003 04:41:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mUiE-0002bQ-6f; Tue, 12 Aug 2003 04: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 19mUhe-0002ak-Jr for tsvwg@optimus.ietf.org; Tue, 12 Aug 2003 04:40: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 EAA04920 for ; Tue, 12 Aug 2003 04:40:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mUha-00066U-00 for tsvwg@ietf.org; Tue, 12 Aug 2003 04:40:22 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19mUhZ-00066Q-00 for tsvwg@ietf.org; Tue, 12 Aug 2003 04:40:21 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7C8eJ7W004705; Tue, 12 Aug 2003 10:40:19 +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 QXY8JXRF; Tue, 12 Aug 2003 10:40:19 +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 KAA29743; Tue, 12 Aug 2003 10:40:17 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030812102001.02682860@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 12 Aug 2003 10:40:47 +0200 To: "Duke, Martin" From: Reiner Ludwig Subject: RE: [Tsvwg] Updating timestamps (ts_recent) in Linux Cc: tsvwg@ietf.org In-Reply-To: <5.2.0.9.0.20030811125205.02b83270@mailhost.eed.ericsson.se > References: 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 14:55 11.08.2003, Reiner Ludwig wrote: >At 17:37 08.08.2003, Duke, Martin wrote: >>I suppose if one combines our proposals one ends up with >> if (ts_val > ts_recent) >> ts_recent = ts_val >>and doesn't pay any attention to sequence numbers at all. >> >>As far as I can figure, these more liberal rules for echoing would >>produce more truthful RTT estimates. The only counter-argument I've >>heard is that it's best to be conservative, especially in the face of >>packet loss and retransmission. >> In my opinion, however, it's best to be as accurate as possible >> with the RTT, and if you wish to be conservative, do so with the way you >> convert the RTT to the RTO. To do otherwise is to invite pathological >> behavior in atypical but not uncommon situations. > >I basically agree, although we should hold on to the special rule that >deals with delayed ACKs. Otherwise, the sender can badly underestimate the >RTT, and it seems difficult to accommodate for that in the RTO calculation. > >That way, we would end up with: > if (ts_val > ts_recent) AND ("last data arrival was acked") > ts_recent = ts_val I just realized that a more precise specification of what I meant is this: if (ts_val > ts_recent) AND ("an ACK or DUPACK was sent in response to the last data arrival") ts_recent = ts_val ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Aug 12 11:55: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 LAA19513 for ; Tue, 12 Aug 2003 11:55: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 19mbUN-0007xX-7j for tsvwg-archive@odin.ietf.org; Tue, 12 Aug 2003 11:55:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CFtBKV030591 for tsvwg-archive@odin.ietf.org; Tue, 12 Aug 2003 11:55:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mbUD-0007wT-4n; Tue, 12 Aug 2003 11: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 19mbTe-0007vM-Ln for tsvwg@optimus.ietf.org; Tue, 12 Aug 2003 11:54: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 LAA19451 for ; Tue, 12 Aug 2003 11:54:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mbTd-0001lA-00 for tsvwg@ietf.org; Tue, 12 Aug 2003 11:54:25 -0400 Received: from frantic-dmz.weston.bsdi.com ([206.196.54.22] helo=frantic.weston.bsdi.com) by ietf-mx with esmtp (Exim 4.12) id 19mbTc-0001ko-00 for tsvwg@ietf.org; Tue, 12 Aug 2003 11:54:24 -0400 Received: from frantic.weston.bsdi.com (localhost.BSDI.COM [127.0.0.1]) by frantic.weston.bsdi.com (8.12.5/8.12.5) with ESMTP id h7CFroOn022483; Tue, 12 Aug 2003 10:53:50 -0500 (CDT) Received: (from dab@localhost) by frantic.weston.bsdi.com (8.12.5/8.12.5/Submit) id h7CFrnIh022482; Tue, 12 Aug 2003 10:53:49 -0500 (CDT) Date: Tue, 12 Aug 2003 10:53:49 -0500 (CDT) From: David Borman Message-Id: <200308121553.h7CFrnIh022482@frantic.weston.bsdi.com> To: martin.duke@boeing.com, tsvwg@ietf.org Subject: Re: [Tsvwg] Updating timestamps (ts_recent) in Linux Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@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, Sorry that I haven't responded sooner. I've submitted the update to RFC 1323 to internet drafts again, maybe this time we can get it actually published... > Date: Thu, 7 Aug 2003 14:59:05 -0700 > From: "Duke, Martin" > Subject: [Tsvwg] Updating timestamps (ts_recent) in Linux > > I've heard rumors that this has been discussed before on tcp-impl, but an > extensive search found no messages on this topic, so apologies for possibly > re-treading old ground. > > How do people feel about the way Linux decides what timestamp to echo? > > Specifically, although the behavior is compliant with RFC 1323, an old > addendum to the RFC (http://www.kohala.com/start/tcplw-extensions.txt) > pointed out some odd behavior. These changes are in 1323.bis. > Essentially, if the connection goes down, the subsequent retransmissions > will have later ts values. However, if an ACK was lost, the kernel > currently does not update ts_recent with these values. If the channel > comes back up and a retrans succeeds, the client will send an ack with an > ts echo equal to the old value of ts_recent. > > As the difference between the echo and the current time is quite large, it > will result in an extremely large RTT measurement, triggering a huge increase > in the RTO. In an unreliable, bursty link, such as satellites, another outage > could occur shortly thereafter, and an inappropriately long timeout can occur. > > The reason for the problem is that ts_recent is only updated if the receive > window moves to the right. Ideally, packets with sequence numbers to the > left of the window edge should trigger an update as well. For copying TSval from the packet to TS.Recent, rule (2) in RFC 1323 is: SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN This attempted to only update TS.Recent when you received new data. But that causes the problem with lost ACKs. In addition, when you receive an ACK (SEG.LEN == 0), the timestamp that you receive will not be artificially inflated (since it was just generated by the remote side when it sent the ACK), so it is OK to update TS.Recent from ACK only packets (but only if TS.Recent has advanced) In 1323.bis, rule (2) is: SEG.TSval >= TSrecent and SEG.SEQ <= Last.ACK.sent This change addresses these two issues with RFC 1323: (1) It failed to update TSrecent for a retransmitted segment that resulted from a lost ACK. (2) It failed if SEG.LEN = 0. So this modified rule allows TSrecent to be updated whenever a newer TSrecent is received, except when the packet is out of order. In that case, we continue to echo the TS from the latest received packet at or to the left edge of the window. > There are certainly situations where the current Linux behavior is terrible, > but I have yet to see an explanation for why this "bug" should not be fixed. > I've heard criticisms of the document cited above as a whole but have yet to\ > understand why updating ts_recent more frequently will break something. I > know that BSD fixed this some time ago (Stevens talks about it in his book). > > Any thoughts? As a final thought, updating TSrecent more often does not mean that you can get RTT measurements more often. It continues to be the case that the only time you can get a reliable RTT measurement from timestamps is when when new data is acknowledged. That is because dup ACK packets can be spontainiously generated by the remote side to do a window update. In that case, taking an RTT measurement can be vastly over inflated. And since there is no way to reliably identify whether a received dup ACK is due to out-of-order data arriving or due to the remote side deciding to update the window, the best course of action is to only take RTT measurements when new data is acknowledged. > Martin Duke > martin.duke@boeing.com -David Borman _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Aug 12 12:53: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 MAA21287 for ; Tue, 12 Aug 2003 12:53: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 19mcOQ-0002VJ-0o for tsvwg-archive@odin.ietf.org; Tue, 12 Aug 2003 12:53:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CGr5je009606 for tsvwg-archive@odin.ietf.org; Tue, 12 Aug 2003 12:53:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcOL-0002U3-3t; Tue, 12 Aug 2003 12: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 19mcO8-0002TV-2B for tsvwg@optimus.ietf.org; Tue, 12 Aug 2003 12:52: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 MAA21267 for ; Tue, 12 Aug 2003 12:52:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mcO6-0002Br-00 for tsvwg@ietf.org; Tue, 12 Aug 2003 12:52:46 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19mcO5-0002Bo-00 for tsvwg@ietf.org; Tue, 12 Aug 2003 12:52:45 -0400 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA24862; Tue, 12 Aug 2003 09:51:59 -0700 (PDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id JAA03716; Tue, 12 Aug 2003 09:52:42 -0700 (PDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h7CGq1h05089; Tue, 12 Aug 2003 11:52:02 -0500 (CDT) 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); Tue, 12 Aug 2003 09:51:51 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [Tsvwg] Updating timestamps (ts_recent) in Linux Date: Tue, 12 Aug 2003 09:51:51 -0700 Message-ID: Thread-Topic: [Tsvwg] Updating timestamps (ts_recent) in Linux Thread-Index: AcNg6jngLzyoot9/QHWhtYPUuyvK/AABPGTg From: "Duke, Martin" To: "David Borman" , X-OriginalArrivalTime: 12 Aug 2003 16:51:51.0760 (UTC) FILETIME=[0750E500:01C360F2] 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 >=20 > As a final thought, updating TSrecent more often does not=20 > mean that you > can get RTT measurements more often. It continues to be the=20 > case that the > only time you can get a reliable RTT measurement from=20 > timestamps is when > when new data is acknowledged. That is because dup ACK packets can be > spontainiously generated by the remote side to do a window update. In > that case, taking an RTT measurement can be vastly over inflated. And > since there is no way to reliably identify whether a received dup ACK > is due to out-of-order data arriving or due to the remote=20 > side deciding > to update the window, the best course of action is to only take RTT > measurements when new data is acknowledged. > =20 > -David Borman >=20 David,=20 Thanks for the insights. I whole-heartedly agree with the revision, but I can see two corner = cases will the measurement could still be massively inflated: 1) DATA 5, ACK 37, TS 12 -------------> (has long RTO, for whatever = reason) (lost) --------------- ACK 6, ECHO 12 <------------------- DATA 37, ACK 6, ECHO 12 2) DATA 3, TS 12 --------------------> (again, long RTO) (lost) --------------- ACK 4, ECHO 12, rcv window =3D 0 <---------------------- ACK 4, ECHO 12, rcv window =3D foo I think these situations are probably rare, and am willing to live with = them, especially since it's still better than the current state of = things. What could we do to avoid them? The only thing that immediately comes = to mind is breaking the rule that an endpoint must always include a = tsval & echo if it's got the option negotiated. Perhaps, add the = algorithm if (I already acked this DATA) Do not include ts echo ?? and make sure the other side would know how to handle this. (Indeed, it = would have no choice on how to handle this-- there's no data to = manipulate!) I could see how this might cause backwards compatibility issues with = many TCP implementations, although I haven't looked to see. On the = other hand, there's something to be said for getting it right the first = (er, second) time. -Martin Duke =20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Aug 12 22:11: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 WAA06879 for ; Tue, 12 Aug 2003 22:11: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 19ml6O-0005wW-Sk for tsvwg-archive@odin.ietf.org; Tue, 12 Aug 2003 22:11:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7D2B4Oi022840 for tsvwg-archive@odin.ietf.org; Tue, 12 Aug 2003 22:11:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ml6M-0005vd-3p; Tue, 12 Aug 2003 22: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 19maQW-0005el-UR for tsvwg@optimus.ietf.org; Tue, 12 Aug 2003 10:47: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 KAA17610 for ; Tue, 12 Aug 2003 10:47:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19maQU-0001K9-00 for tsvwg@ietf.org; Tue, 12 Aug 2003 10:47:06 -0400 Received: from frantic-dmz.weston.bsdi.com ([206.196.54.22] helo=frantic.weston.bsdi.com) by ietf-mx with esmtp (Exim 4.12) id 19maQN-0001K4-00 for tsvwg@ietf.org; Tue, 12 Aug 2003 10:46:59 -0400 Received: from frantic.weston.bsdi.com (localhost.BSDI.COM [127.0.0.1]) by frantic.weston.bsdi.com (8.12.5/8.12.5) with ESMTP id h7CEk8On022391; Tue, 12 Aug 2003 09:46:08 -0500 (CDT) Received: (from dab@localhost) by frantic.weston.bsdi.com (8.12.5/8.12.5/Submit) id h7CEk8co022390; Tue, 12 Aug 2003 09:46:08 -0500 (CDT) Date: Tue, 12 Aug 2003 09:46:08 -0500 (CDT) From: David Borman Message-Id: <200308121446.h7CEk8co022390@frantic.weston.bsdi.com> To: martin.duke@boeing.com, Reiner.Ludwig@ericsson.com Subject: RE: [Tsvwg] Updating timestamps (ts_recent) in Linux Cc: tsvwg@ietf.org Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@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, I've just sent an update to RFC 1323 to internet-drafts@ietf.org. Below is a copy of the document. Getting an update published and advancing 1323 from draft to proposed is *way* overdue. Perhaps we can get any discussion done in the next couple of months, and then it can be finished up for the Minneapolis IETF meeting. -David Borman ============ Network Working Group Network Working Group Internet-Draft V. Jacobson Obsoletes: 1323 Packet Design R. Braden ISI D. Borman Wind River Systems, Inc. August 2003 TCP Extensions for High Performance Status of This Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences). Selective acknowledgments are not included in this memo. This memo updates and obsoletes RFC-1323, a Proposed Standard, with small clarifications and corrections. Network Working Group Expires February 2004 [Page 1] Internet-Draft TCP Extensions for High Performance August 2003 TABLE OF CONTENTS 1. Introduction 2 2. TCP Window Scale Option 8 3. RTTM -- Round-Trip Time Measurement 11 4. PAWS -- Protect Against Wrapped Sequence Numbers 17 5. Conclusions and Acknowledgments 24 6. References 25 APPENDIX A: Implementation Suggestions 27 APPENDIX B: Duplicates from Earlier Connection Incarnations 27 APPENDIX C: Changes from RFC-1072, RFC-1185, RFC-1323 30 APPENDIX D: Summary of Notation 32 APPENDIX E: Pseudo-code Summary 33 APPENDIX F: Event Processing 35 Security Considerations 41 Authors' Addresses 41 1. INTRODUCTION The TCP protocol [Postel81] was designed to operate reliably over almost any transmission medium regardless of transmission rate, delay, corruption, duplication, or reordering of segments. Production TCP implementations currently adapt to transfer rates in the range of 100 bps to 10**7 bps and round-trip delays in the range 1 ms to 100 seconds. Work on TCP performance has shown that TCP can work well over a variety of Internet paths, ranging from 800 Mbit/sec I/O channels to 300 bit/sec dial-up modems [Jacobson88a]. The introduction of fiber optics is resulting in ever-higher transmission speeds, and the fastest paths are moving out of the domain for which TCP was originally engineered. This memo defines a set of modest extensions to TCP to extend the domain of its application to match this increasing network capability. It is based upon and obsoletes RFC-1072 [Jacobson88b] and RFC-1185 [Jacobson90b]. There is no one-line answer to the question: "How fast can TCP go?". There are two separate kinds of issues, performance and reliability, and each depends upon different parameters. We discuss each in turn. 1.1 TCP Performance TCP performance depends not upon the transfer rate itself, but rather upon the product of the transfer rate and the round-trip delay. This "bandwidth*delay product" measures the amount of data that would "fill the pipe"; it is the buffer space required at sender and receiver to obtain maximum throughput on the TCP connection over the path, i.e., the amount of unacknowledged data that TCP must handle in order to keep the pipeline full. TCP Network Working Group Expires February 2004 [Page 2] Internet-Draft TCP Extensions for High Performance August 2003 performance problems arise when the bandwidth*delay product is large. We refer to an Internet path operating in this region as a "long, fat pipe", and a network containing this path as an "LFN" (pronounced "elephan(t)"). High-capacity packet satellite channels (e.g., DARPA's Wideband Net) are LFN's. For example, a DS1-speed satellite channel has a bandwidth*delay product of 10**6 bits or more; this corresponds to 100 outstanding TCP segments of 1200 bytes each. Terrestrial fiber-optical paths will also fall into the LFN class; for example, a cross-country delay of 30 ms at a DS3 bandwidth (45Mbps) also exceeds 10**6 bits. There are three fundamental performance problems with the current TCP over LFN paths: (1) Window Size Limit The TCP header uses a 16 bit field to report the receive window size to the sender. Therefore, the largest window that can be used is 2**16 = 65K bytes. To circumvent this problem, Section 2 of this memo defines a new TCP option, "Window Scale", to allow windows larger than 2**16. This option defines an implicit scale factor, which is used to multiply the window size value found in a TCP header to obtain the true window size. (2) Recovery from Losses Packet losses in an LFN can have a catastrophic effect on throughput. In the past, properly-operating TCP implementations would cause the data pipeline to drain with every packet loss, and require a slow-start action to recover. The Fast Retransmit and Fast Recovery algorithms [Jacobson90c] [Stevens97] were introduced, and their combined effect was to recover from one packet loss per window, without draining the pipeline. However, more than one packet loss per window typically resulted in a retransmission timeout and the resulting pipeline drain and slow start. Expanding the window size to match the capacity of an LFN results in a corresponding increase of the probability of more than one packet per window being dropped. This could have a devastating effect upon the throughput of TCP over an LFN. In addition, if a congestion control mechanism based upon some form of random dropping were introduced into gateways, randomly spaced packet drops would become common, possible increasing the probability of dropping more than one packet per window. Network Working Group Expires February 2004 [Page 3] Internet-Draft TCP Extensions for High Performance August 2003 To generalize the Fast Retransmit/Fast Recovery mechanism to handle multiple packets dropped per window, selective acknowledgments are required. Unlike the normal cumulative acknowledgments of TCP, selective acknowledgments give the sender a complete picture of which segments are queued at the receiver and which have not yet arrived. Some evidence in favor of selective acknowledgments has been published [NBS85], and selective acknowledgments have been included in a number of experimental Internet protocols -- VMTP [Cheriton88], NETBLT [Clark87], and RDP [Velten84], and proposed for OSI TP4 [NBS85]. However, in the non-LFN regime, selective acknowledgments reduce the number of packets retransmitted but do not otherwise improve performance, making their complexity of questionable value. However, selective acknowledgments have become much more important in the LFN regime. RFC-1072 defined a new TCP "SACK" option to send a selective acknowledgment. At the time that RFC-1323 was published, important technical issues still had to be worked out concerning both the format and semantics of the SACK option, so it was omitted from RFC-1323. SACK has now been published as a separate document, RFC-2018 [Mathis96]. (3) Round-Trip Measurement TCP implements reliable data delivery by retransmitting segments that are not acknowledged within some retransmission timeout (RTO) interval. Accurate dynamic determination of an appropriate RTO is essential to TCP performance. RTO is determined by estimating the mean and variance of the measured round-trip time (RTT), i.e., the time interval between sending a segment and receiving an acknowledgment for it [Jacobson88a]. Section 4 introduces a new TCP option, "Timestamps", and then defines a mechanism using this option that allows nearly every segment, including retransmissions, to be timed at negligible computational cost. We use the mnemonic RTTM (Round Trip Time Measurement) for this mechanism, to distinguish it from other uses of the Timestamps option. 1.2 TCP Reliability Now we turn from performance to reliability. High transfer rate enters TCP performance through the bandwidth*delay product. However, high transfer rate alone can threaten TCP reliability by violating the assumptions behind the TCP mechanism for duplicate detection and sequencing. Network Working Group Expires February 2004 [Page 4] Internet-Draft TCP Extensions for High Performance August 2003 An especially serious kind of error may result from an accidental reuse of TCP sequence numbers in data segments. Suppose that an "old duplicate segment", e.g., a duplicate data segment that was delayed in Internet queues, is delivered to the receiver at the wrong moment, so that its sequence numbers falls somewhere within the current window. There would be no checksum failure to warn of the error, and the result could be an undetected corruption of the data. Reception of an old duplicate ACK segment at the transmitter could be only slightly less serious: it is likely to lock up the connection so that no further progress can be made, forcing an RST on the connection. TCP reliability depends upon the existence of a bound on the lifetime of a segment: the "Maximum Segment Lifetime" or MSL. An MSL is generally required by any reliable transport protocol, since every sequence number field must be finite, and therefore any sequence number may eventually be reused. In the Internet protocol suite, the MSL bound is enforced by an IP-layer mechanism, the "Time-to-Live" or TTL field. Duplication of sequence numbers might happen in either of two ways: (1) Sequence number wrap-around on the current connection A TCP sequence number contains 32 bits. At a high enough transfer rate, the 32-bit sequence space may be "wrapped" (cycled) within the time that a segment is delayed in queues. (2) Earlier incarnation of the connection Suppose that a connection terminates, either by a proper close sequence or due to a host crash, and the same connection (i.e., using the same pair of sockets) is immediately reopened. A delayed segment from the terminated connection could fall within the current window for the new incarnation and be accepted as valid. Duplicates from earlier incarnations, Case (2), are avoided by enforcing the current fixed MSL of the TCP spec, as explained in Section 5.3 and Appendix B. However, case (1), avoiding the reuse of sequence numbers within the same connection, requires an MSL bound that depends upon the transfer rate, and at high enough rates, a new mechanism is required. More specifically, if the maximum effective bandwidth at which TCP is able to transmit over a particular path is B bytes per second, then the following constraint must be satisfied for error-free operation: Network Working Group Expires February 2004 [Page 5] Internet-Draft TCP Extensions for High Performance August 2003 2**31 / B > MSL (secs) [1] The following table shows the value for Twrap = 2**31/B in seconds, for some important values of the bandwidth B: Network B*8 B Twrap bits/sec bytes/sec secs _______ _______ ______ ______ ARPANET 56kbps 7KBps 3*10**5 (~3.6 days) DS1 1.5Mbps 190KBps 10**4 (~3 hours) Ethernet 10Mbps 1.25MBps 1700 (~30 mins) DS3 45Mbps 5.6MBps 380 FDDI 100Mbps 12.5MBps 170 Gigabit 1Gbps 125MBps 17 It is clear that wrap-around of the sequence space is not a problem for 56kbps packet switching or even 10Mbps Ethernets. On the other hand, at DS3 and FDDI speeds, Twrap is comparable to the 2 minute MSL assumed by the TCP specification [Postel81]. Moving towards gigabit speeds, Twrap becomes too small for reliable enforcement by the Internet TTL mechanism. The 16-bit window field of TCP limits the effective bandwidth B to 2**16/RTT, where RTT is the round-trip time in seconds [McKenzie89]. If the RTT is large enough, this limits B to a value that meets the constraint [1] for a large MSL value. For example, consider a transcontinental backbone with an RTT of 60ms (set by the laws of physics). With the bandwidth*delay product limited to 64KB by the TCP window size, B is then limited to 1.1MBps, no matter how high the theoretical transfer rate of the path. This corresponds to cycling the sequence number space in Twrap= 2000 secs, which is safe in today's Internet. It is important to understand that the culprit is not the larger window but rather the high bandwidth. For example, consider a (very large) FDDI LAN with a diameter of 10km. Using the speed of light, we can compute the RTT across the ring as (2*10**4)/(3*10**8) = 67 microseconds, and the delay*bandwidth product is then 833 bytes. A TCP connection across this LAN using a window of only 833 bytes will run at the full 100mbps and can wrap the sequence space in about 3 minutes, very close to the MSL of TCP. Thus, high speed alone can cause a reliability problem with sequence number wrap-around, even without extended windows. Network Working Group Expires February 2004 [Page 6] Internet-Draft TCP Extensions for High Performance August 2003 Watson's Delta-T protocol [Watson81] includes network-layer mechanisms for precise enforcement of an MSL. In contrast, the IP mechanism for MSL enforcement is loosely defined and even more loosely implemented in the Internet. Therefore, it is unwise to depend upon active enforcement of MSL for TCP connections, and it is unrealistic to imagine setting MSL's smaller than the current values (e.g., 120 seconds specified for TCP). A possible fix for the problem of cycling the sequence space would be to increase the size of the TCP sequence number field. For example, the sequence number field (and also the acknowledgment field) could be expanded to 64 bits. This could be done either by changing the TCP header or by means of an additional option. Section 5 presents a different mechanism, which we call PAWS (Protect Against Wrapped Sequence numbers), to extend TCP reliability to transfer rates well beyond the foreseeable upper limit of network bandwidths. PAWS uses the TCP Timestamps option defined in Section 4 to protect against old duplicates from the same connection. 1.3 Using TCP options The extensions defined in this memo all use new TCP options. We must address two possible issues concerning the use of TCP options: (1) compatibility and (2) overhead. We must pay careful attention to compatibility, i.e., to interoperation with existing implementations. The only TCP option defined previously, MSS, may appear only on a SYN segment. Every implementation should (and we expect that most will) ignore unknown options on SYN segments. However, some buggy TCP implementation might be crashed by the first appearance of an option on a non-SYN segment. Therefore, for each of the extensions defined below, TCP options will be sent on non-SYN segments only after an exchange of options on the the SYN segments has indicated that both sides understand the extension. Furthermore, an extension option will be sent in a segment only if the corresponding option was received in the initial segment. A question may be raised about the bandwidth and processing overhead for TCP options. Those options that occur on SYN segments are not likely to cause a performance concern. Opening a TCP connection requires execution of significant special-case code, and the processing of options is unlikely to increase that cost significantly. On the other hand, a Timestamps option may appear in any data or ACK segment, adding 12 bytes to the 20-byte TCP header. We Network Working Group Expires February 2004 [Page 7] Internet-Draft TCP Extensions for High Performance August 2003 believe that the bandwidth saved by reducing unnecessary retransmissions will more than pay for the extra header bandwidth. There is also an issue about the processing overhead for parsing the variable byte-aligned format of options, particularly with a RISC-architecture CPU. Appendix A contains a recommended layout of the options in TCP headers to achieve reasonable data field alignment. In the spirit of Header Prediction, a TCP can quickly test for this layout and if it is verified then use a fast path. Hosts that use this canonical layout will effectively use the options as a set of fixed-format fields appended to the TCP header. However, to retain the philosophical and protocol framework of TCP options, a TCP must be prepared to parse an arbitrary options field, albeit with less efficiency. Finally, we observe that most of the mechanisms defined in this memo are important for LFN's and/or very high-speed networks. For low-speed networks, it might be a performance optimization to NOT use these mechanisms. A TCP vendor concerned about optimal performance over low-speed paths might consider turning these extensions off for low-speed paths, or allow a user or installation manager to disable them. 2. TCP WINDOW SCALE OPTION 2.1 Introduction The window scale extension expands the definition of the TCP window to 32 bits and then uses a scale factor to carry this 32-bit value in the 16-bit Window field of the TCP header (SEG.WND in RFC-793). The scale factor is carried in a new TCP option, Window Scale. This option is sent only in a SYN segment (a segment with the SYN bit on), hence the window scale is fixed in each direction when a connection is opened. (Another design choice would be to specify the window scale in every TCP segment. It would be incorrect to send a window scale option only when the scale factor changed, since a TCP option in an acknowledgement segment will not be delivered reliably (unless the ACK happens to be piggy-backed on data in the other direction). Fixing the scale when the connection is opened has the advantage of lower overhead but the disadvantage that the scale factor cannot be changed during the connection.) The maximum receive window, and therefore the scale factor, is determined by the maximum receive buffer space. In a typical modern implementation, this maximum buffer space is set by default but can be overridden by a user program before a TCP connection is opened. This determines the scale factor, and therefore no new user interface is needed for window scaling. Network Working Group Expires February 2004 [Page 8] Internet-Draft TCP Extensions for High Performance August 2003 2.2 Window Scale Option The three-byte Window Scale option may be sent in a SYN segment by a TCP. It has two purposes: (1) indicate that the TCP is prepared to do both send and receive window scaling, and (2) communicate a scale factor to be applied to its receive window. Thus, a TCP that is prepared to scale windows should send the option, even if its own scale factor is 1. The scale factor is limited to a power of two and encoded logarithmically, so it may be implemented by binary shift operations. TCP Window Scale Option (WSopt): Kind: 3 Length: 3 bytes +---------+---------+---------+ | Kind=3 |Length=3 |shift.cnt| +---------+---------+---------+ This option is an offer, not a promise; both sides must send Window Scale options in their SYN segments to enable window scaling in either direction. If window scaling is enabled, then the TCP that sent this option will right-shift its true receive-window values by 'shift.cnt' bits for transmission in SEG.WND. The value 'shift.cnt' may be zero (offering to scale, while applying a scale factor of 1 to the receive window). This option may be sent in an initial segment (i.e., a segment with the SYN bit on and the ACK bit off). It may also be sent in a segment, but only if a Window Scale option was received in the initial segment. A Window Scale option in a segment without a SYN bit should be ignored. The Window field in a SYN (i.e., a or ) segment itself is never scaled. 2.3 Using the Window Scale Option A model implementation of window scaling is as follows, using the notation of RFC-793 [Postel81]: * All windows are treated as 32-bit quantities for storage in the connection control block and for local calculations. This includes the send-window (SND.WND) and the receive- window (RCV.WND) values, as well as the congestion window. Network Working Group Expires February 2004 [Page 9] Internet-Draft TCP Extensions for High Performance August 2003 * The connection state is augmented by two window shift counts, Snd.Wind.Scale and Rcv.Wind.Scale, to be applied to the incoming and outgoing window fields, respectively. * If a TCP receives a segment containing a Window Scale option, it sends its own Window Scale option in the segment. * The Window Scale option is sent with shift.cnt = R, where R is the value that the TCP would like to use for its receive window. * Upon receiving a SYN segment with a Window Scale option containing shift.cnt = S, a TCP sets Snd.Wind.Scale to S and sets Rcv.Wind.Scale to R; otherwise, it sets both Snd.Wind.Scale and Rcv.Wind.Scale to zero. * The window field (SEG.WND) in the header of every incoming segment, with the exception of SYN segments, is left-shifted by Snd.Wind.Scale bits before updating SND.WND: SND.WND = SEG.WND << Snd.Wind.Scale (assuming the other conditions of RFC793 are met, and using the "C" notation "<<" for left-shift). * The window field (SEG.WND) of every outgoing segment, with the exception of SYN segments, is right-shifted by Rcv.Wind.Scale bits: SEG.WND = RCV.WND >> Rcv.Wind.Scale. TCP determines if a data segment is "old" or "new" by testing whether its sequence number is within 2**31 bytes of the left edge of the window, and if it is not, discarding the data as "old". To insure that new data is never mistakenly considered old and vice- versa, the left edge of the sender's window has to be at most 2**31 away from the right edge of the receiver's window. Similarly with the sender's right edge and receiver's left edge. Since the right and left edges of either the sender's or receiver's window differ by the window size, and since the sender and receiver windows can be out of phase by at most the window size, the above constraints imply that 2 * the max window size must be less than 2**31, or max window < 2**30 Since the max window is 2**S (where S is the scaling shift count) times at most 2**16 - 1 (the maximum unscaled window), the maximum Network Working Group Expires February 2004 [Page 10] Internet-Draft TCP Extensions for High Performance August 2003 window is guaranteed to be < 2*30 if S <= 14. Thus, the shift count must be limited to 14 (which allows windows of 2**30 = 1 Gbyte). If a Window Scale option is received with a shift.cnt value exceeding 14, the TCP should log the error but use 14 instead of the specified value. The scale factor applies only to the Window field as transmitted in the TCP header; each TCP using extended windows will maintain the window values locally as 32-bit numbers. For example, the "congestion window" computed by Slow Start and Congestion Avoidance is not affected by the scale factor, so window scaling will not introduce quantization into the congestion window. 3. RTTM: ROUND-TRIP TIME MEASUREMENT 3.1 Introduction Accurate and current RTT estimates are necessary to adapt to changing traffic conditions and to avoid an instability known as "congestion collapse" [Nagle84] in a busy network. However, accurate measurement of RTT may be difficult both in theory and in implementation. Many TCP implementations base their RTT measurements upon a sample of one packet per window or less. While this yields an adequate approximation to the RTT for small windows, it results in an unacceptably poor RTT estimate for an LFN. If we look at RTT estimation as a signal processing problem (which it is), a data signal at some frequency, the packet rate, is being sampled at a lower frequency, the window rate. This lower sampling frequency violates Nyquist's criteria and may therefore introduce "aliasing" artifacts into the estimated RTT [Hamming77]. A good RTT estimator with a conservative retransmission timeout calculation can tolerate aliasing when the sampling frequency is "close" to the data frequency. For example, with a window of 8 packets, the sample rate is 1/8 the data frequency -- less than an order of magnitude different. However, when the window is tens or hundreds of packets, the RTT estimator may be seriously in error, resulting in spurious retransmissions. If there are dropped packets, the problem becomes worse. Zhang [Zhang86], Jain [Jain86] and Karn [Karn87] have shown that it is not possible to accumulate reliable RTT estimates if retransmitted segments are included in the estimate. Since a full window of data will have been transmitted prior to a retransmission, all of the segments in that window will have to be ACKed before the next RTT sample can be taken. This means at least an additional window's worth of time between RTT measurements and, as the error rate approaches one per window of data (e.g., 10**-6 errors per Network Working Group Expires February 2004 [Page 11] Internet-Draft TCP Extensions for High Performance August 2003 bit for the Wideband satellite network), it becomes effectively impossible to obtain a valid RTT measurement. A solution to these problems, which actually simplifies the sender substantially, is as follows: using TCP options, the sender places a timestamp in each data segment, and the receiver reflects these timestamps back in ACK segments. Then a single subtract gives the sender an accurate RTT measurement for every ACK segment (which will correspond to every other data segment, with a sensible receiver). We call this the RTTM (Round-Trip Time Measurement) mechanism. It is vitally important to use the RTTM mechanism with big windows; otherwise, the door is opened to some dangerous instabilities due to aliasing. Furthermore, the option is probably useful for all TCP's, since it simplifies the sender. 3.2 TCP Timestamps Option TCP is a symmetric protocol, allowing data to be sent at any time in either direction, and therefore timestamp echoing may occur in either direction. For simplicity and symmetry, we specify that timestamps always be sent and echoed in both directions. For efficiency, we combine the timestamp and timestamp reply fields into a single TCP Timestamps Option. TCP Timestamps Option (TSopt): Kind: 8 Length: 10 bytes +-------+-------+---------------------+---------------------+ |Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)| +-------+-------+---------------------+---------------------+ 1 1 4 4 The Timestamps option carries two four-byte timestamp fields. The Timestamp Value field (TSval) contains the current value of the timestamp clock of the TCP sending the option. The Timestamp Echo Reply field (TSecr) is only valid if the ACK bit is set in the TCP header; if it is valid, it echos a timestamp value that was sent by the remote TCP in the TSval field of a Timestamps option. When TSecr is not valid, its value must be zero. The TSecr value will generally be from the most recent Timestamp option that was received; however, there are exceptions that are explained below. A TCP may send the Timestamps option (TSopt) in an initial Network Working Group Expires February 2004 [Page 12] Internet-Draft TCP Extensions for High Performance August 2003 segment (i.e., a segment containing a SYN bit and no ACK bit), and may send a TSopt in other segments only if it received a TSopt in the initial segment for the connection. 3.3 The RTTM Mechanism RTTM places a Timestamps option in every segment, with a TSval that is obtained from a (virtual) "timestamp clock". Values of this clock values must be at least approximately proportional to real time, in order to measure actual RTT. These TSval values are echoed in TSecr values in the reverse direction. The difference between a received TSecr value and the current timestamp clock value provides an RTT measurement. When timestamps are used, every segment that is received will contain a TSecr value; however, these values cannot all be used to update the measured RTT. The following example illustrates why. It shows a one-way data flow with segments arriving in sequence without loss. Here A, B, C... represent data blocks occupying successive blocks of sequence numbers, and ACK(A),... represent the corresponding cumulative acknowledgments. The two timestamp fields of the Timestamps option are shown symbolically as . Each TSecr field contains the value most recently received in a TSval field; these echoed values. labelled "TS.Recent", are shown in parentheses. TCP A TCP B (TS.Recent) (TS.Recent) 1. (120) ---> (1) 2. (125) <--- (1) 3. (125) ---> (6) 4. (130) <--- (6) . . . ( Pause for 60 timestamp clock ticks ) . . . . 5. (130) ---> (1) 6. (125) <--- (1) 4. (127) ---> ... 5. ... <--- (5) Network Working Group Expires February 2004 [Page 13] Internet-Draft TCP Extensions for High Performance August 2003 TCP A TCP B ------> <---- ------> <---- . . . . . . . . . . . . . . . . . . . . . . ------> <---- (etc) The dotted line marks a pause (60 time units long) in which A had nothing to send. Note that this pause inflates the RTT which B could infer from receiving TSecr=131 in data segment C. Thus, in one-way data flows, RTTM in the reverse direction measures a value that is inflated by gaps in sending data. However, the following rule prevents a resulting inflation of the measured RTT: RTTM Rule: A TSecr value received in a segment is used to update the averaged RTT measurement only if the segment acknowledges some new data, i.e., only if it advances the left edge of the send window. Since TCP B is not sending data, the data segment C does not acknowledge any new data when it arrives at B. Thus, the inflated RTTM measurement is not used to update B's RTTM measurement. 3.4 Which Timestamp to Echo If more than one Timestamps option is received before a reply segment is sent, the TCP must choose only one of the TSvals to echo, ignoring the others. To minimize the state kept in the receiver (i.e., the number of unprocessed TSvals), the receiver should be required to retain at most one timestamp in the connection control block. There are three situations to consider: (A) Delayed ACKs. Network Working Group Expires February 2004 [Page 14] Internet-Draft TCP Extensions for High Performance August 2003 Many TCP's acknowledge only every Kth segment out of a group of segments arriving within a short time interval; this policy is known generally as "delayed ACKs". The data-sender TCP must measure the effective RTT, including the additional time due to delayed ACKs, or else it will retransmit unnecessarily. Thus, when delayed ACKs are in use, the receiver should reply with the TSval field from the earliest unacknowledged segment. (B) A hole in the sequence space (segment(s) have been lost). The sender will continue sending until the window is filled, and the receiver may be generating ACKs as these out-of-order segments arrive (e.g., to aid "fast retransmit"). The lost segment is probably a sign of congestion, and in that situation the sender should be conservative about retransmission. Furthermore, it is better to overestimate than underestimate the RTT. An ACK for an out-of-order segment should therefore contain the timestamp from the most recent segment that advanced the window. The same situation occurs if segments are re-ordered by the network. (C) A filled hole in the sequence space. The segment that fills the hole represents the most recent measurement of the network characteristics. On the other hand, an RTT computed from an earlier segment would probably include the sender's retransmit time-out, badly biasing the sender's average RTT estimate. Thus, the timestamp from the latest segment (which filled the hole) must be echoed. An algorithm that covers all three cases is described in the following rules for Timestamps option processing on a synchronized connection: (1) The connection state is augmented with two 32-bit slots: TS.Recent holds a timestamp to be echoed in TSecr whenever a segment is sent, and Last.ACK.sent holds the ACK field from the last segment sent. Last.ACK.sent will equal RCV.NXT except when ACKs have been delayed. (2) If: SEG.TSval >= TSrecent and SEG.SEQ <= Last.ACK.sent then SEG.TSval is copied to TS.Recent; otherwise, it is ignored. Network Working Group Expires February 2004 [Page 15] Internet-Draft TCP Extensions for High Performance August 2003 (3) When a TSopt is sent, its TSecr field is set to the current TS.Recent value. The following examples illustrate these rules. Here A, B, C... represent data segments occupying successive blocks of sequence numbers, and ACK(A),... represent the corresponding acknowledgment segments. Note that ACK(A) has the same sequence number as B. We show only one direction of timestamp echoing, for clarity. o Packets arrive in sequence, and some of the ACKs are delayed. By Case (A), the timestamp from the oldest unacknowledged segment is echoed. TS.Recent -------------------> 1 -------------------> 1 -------------------> 1 <---- (etc) o Packets arrive out of order, and every packet is acknowledged. By Case (B), the timestamp from the last segment that advanced the left window edge is echoed, until the missing segment arrives; it is echoed according to Case (C). The same sequence would occur if segments B and D were lost and retransmitted.. Network Working Group Expires February 2004 [Page 16] Internet-Draft TCP Extensions for High Performance August 2003 TS.Recent -------------------> 1 <---- 1 -------------------> 1 <---- 1 -------------------> 2 <---- 2 -------------------> 2 <---- 2 -------------------> 4 <---- (etc) 4. PAWS: PROTECT AGAINST WRAPPED SEQUENCE NUMBERS 4.1 Introduction Section 4.2 describes a simple mechanism to reject old duplicate segments that might corrupt an open TCP connection; we call this mechanism PAWS (Protect Against Wrapped Sequence numbers). PAWS operates within a single TCP connection, using state that is saved in the connection control block. Section 4.3 and Appendix C discuss the implications of the PAWS mechanism for avoiding old duplicates from previous incarnations of the same connection. 4.2 The PAWS Mechanism PAWS uses the same TCP Timestamps option as the RTTM mechanism described earlier, and assumes that every received TCP segment (including data and ACK segments) contains a timestamp SEG.TSval whose values are monotone non-decreasing in time. The basic idea is that a segment can be discarded as an old duplicate if it is received with a timestamp SEG.TSval less than some timestamp recently received on this connection. In both the PAWS and the RTTM mechanism, the "timestamps" are 32-bit unsigned integers in a modular 32-bit space. Thus, "less Network Working Group Expires February 2004 [Page 17] Internet-Draft TCP Extensions for High Performance August 2003 than" is defined the same way it is for TCP sequence numbers, and the same implementation techniques apply. If s and t are timestamp values, s < t if 0 < (t - s) < 2**31, computed in unsigned 32-bit arithmetic. The choice of incoming timestamps to be saved for this comparison must guarantee a value that is monotone increasing. For example, we might save the timestamp from the segment that last advanced the left edge of the receive window, i.e., the most recent in- sequence segment. Instead, we choose the value TS.Recent introduced in Section 3.4 for the RTTM mechanism, since using a common value for both PAWS and RTTM simplifies the implementation of both. As Section 3.4 explained, TS.Recent differs from the timestamp from the last in-sequence segment only in the case of delayed ACKs, and therefore by less than one window. Either choice will therefore protect against sequence number wrap-around. RTTM was specified in a symmetrical manner, so that TSval timestamps are carried in both data and ACK segments and are echoed in TSecr fields carried in returning ACK or data segments. PAWS submits all incoming segments to the same test, and therefore protects against duplicate ACK segments as well as data segments. (An alternative un-symmetric algorithm would protect against old duplicate ACKs: the sender of data would reject incoming ACK segments whose TSecr values were less than the TSecr saved from the last segment whose ACK field advanced the left edge of the send window. This algorithm was deemed to lack economy of mechanism and symmetry.) TSval timestamps sent on {SYN} and {SYN,ACK} segments are used to initialize PAWS. PAWS protects against old duplicate non-SYN segments, and duplicate SYN segments received while there is a synchronized connection. Duplicate {SYN} and {SYN,ACK} segments received when there is no connection will be discarded by the normal 3-way handshake and sequence number checks of TCP. It is recommended that RST segments NOT carry timestamps, and that RST segments be acceptable regardless of their timestamp. Old duplicate RST segments should be exceedingly unlikely, and their cleanup function should take precedence over timestamps. 4.2.1 Basic PAWS Algorithm The PAWS algorithm requires the following processing to be performed on all incoming segments for a synchronized connection: R1) If there is a Timestamps option in the arriving segment and SEG.TSval < TS.Recent and if TS.Recent is valid (see later discussion), then treat the arriving segment as not Network Working Group Expires February 2004 [Page 18] Internet-Draft TCP Extensions for High Performance August 2003 acceptable: Send an acknowledgement in reply as specified in RFC-793 page 69 and drop the segment. Note: it is necessary to send an ACK segment in order to retain TCP's mechanisms for detecting and recovering from half-open connections. For example, see Figure 10 of RFC-793. R2) If the segment is outside the window, reject it (normal TCP processing) R3) If an arriving segment satisfies: SEG.SEQ <= Last.ACK.sent (see Section 3.4), then record its timestamp in TS.Recent. R4) If an arriving segment is in-sequence (i.e., at the left window edge), then accept it normally. R5) Otherwise, treat the segment as a normal in-window, out- of-sequence TCP segment (e.g., queue it for later delivery to the user). Steps R2, R4, and R5 are the normal TCP processing steps specified by RFC-793. It is important to note that the timestamp is checked only when a segment first arrives at the receiver, regardless of whether it is in-sequence or it must be queued for later delivery. Consider the following example. Suppose the segment sequence: A.1, B.1, C.1, ..., Z.1 has been sent, where the letter indicates the sequence number and the digit represents the timestamp. Suppose also that segment B.1 has been lost. The timestamp in TS.TStamp is 1 (from A.1), so C.1, ..., Z.1 are considered acceptable and are queued. When B is retransmitted as segment B.2 (using the latest timestamp), it fills the hole and causes all the segments through Z to be acknowledged and passed to the user. The timestamps of the queued segments are *not* inspected again at this time, since they have already been accepted. When B.2 is accepted, TS.Stamp is set to 2. This rule allows reasonable performance under loss. A full window of data is in transit at all times, and after a loss a full window less one packet will show up out-of-sequence to be queued at the receiver (e.g., up to ~2**30 bytes of data); the timestamp option must not result in discarding this data. Network Working Group Expires February 2004 [Page 19] Internet-Draft TCP Extensions for High Performance August 2003 In certain unlikely circumstances, the algorithm of rules R1-R4 could lead to discarding some segments unnecessarily, as shown in the following example: Suppose again that segments: A.1, B.1, C.1, ..., Z.1 have been sent in sequence and that segment B.1 has been lost. Furthermore, suppose delivery of some of C.1, ... Z.1 is delayed until AFTER the retransmission B.2 arrives at the receiver. These delayed segments will be discarded unnecessarily when they do arrive, since their timestamps are now out of date. This case is very unlikely to occur. If the retransmission was triggered by a timeout, some of the segments C.1, ... Z.1 must have been delayed longer than the RTO time. This is presumably an unlikely event, or there would be many spurious timeouts and retransmissions. If B's retransmission was triggered by the "fast retransmit" algorithm, i.e., by duplicate ACKs, then the queued segments that caused these ACKs must have been received already. Even if a segment were delayed past the RTO, the Fast Retransmit mechanism [Jacobson90c] will cause the delayed packets to be retransmitted at the same time as B.2, avoiding an extra RTT and therefore causing a very small performance penalty. We know of no case with a significant probability of occurrence in which timestamps will cause performance degradation by unnecessarily discarding segments. 4.2.2 Timestamp Clock It is important to understand that the PAWS algorithm does not require clock synchronization between sender and receiver. The sender's timestamp clock is used to stamp the segments, and the sender uses the echoed timestamp to measure RTT's. However, the receiver treats the timestamp as simply a monotone- increasing serial number, without any necessary connection to its clock. From the receiver's viewpoint, the timestamp is acting as a logical extension of the high-order bits of the sequence number. The receiver algorithm does place some requirements on the frequency of the timestamp clock. (a) The timestamp clock must not be "too slow". It must tick at least once for each 2**31 bytes sent. In fact, in order to be useful to the sender for round trip Network Working Group Expires February 2004 [Page 20] Internet-Draft TCP Extensions for High Performance August 2003 timing, the clock should tick at least once per window's worth of data, and even with the RFC-1072 window extension, 2**31 bytes must be at least two windows. To make this more quantitative, any clock faster than 1 tick/sec will reject old duplicate segments for link speeds of ~8 Gbps. A 1ms timestamp clock will work at link speeds up to 8 Tbps (8*10**12) bps! (b) The timestamp clock must not be "too fast". Its recycling time must be greater than MSL seconds. Since the clock (timestamp) is 32 bits and the worst-case MSL is 255 seconds, the maximum acceptable clock frequency is one tick every 59 ns. However, it is desirable to establish a much longer recycle period, in order to handle outdated timestamps on idle connections (see Section 4.2.3), and to relax the MSL requirement for preventing sequence number wrap-around. With a 1 ms timestamp clock, the 32-bit timestamp will wrap its sign bit in 24.8 days. Thus, it will reject old duplicates on the same connection if MSL is 24.8 days or less. This appears to be a very safe figure; an MSL of 24.8 days or longer can probably be assumed by the gateway system without requiring precise MSL enforcement by the TTL value in the IP layer. Based upon these considerations, we choose a timestamp clock frequency in the range 1 ms to 1 sec per tick. This range also matches the requirements of the RTTM mechanism, which does not need much more resolution than the granularity of the retransmit timer, e.g., tens or hundreds of milliseconds. The PAWS mechanism also puts a strong monotonicity requirement on the sender's timestamp clock. The method of implementation of the timestamp clock to meet this requirement depends upon the system hardware and software. * Some hosts have a hardware clock that is guaranteed to be monotonic between hardware resets. * A clock interrupt may be used to simply increment a binary integer by 1 periodically. * The timestamp clock may be derived from a system clock that is subject to being abruptly changed, by adding a variable offset value. This offset is initialized to zero. When a new timestamp clock value is needed, the offset can be adjusted as necessary to make the new value Network Working Group Expires February 2004 [Page 21] Internet-Draft TCP Extensions for High Performance August 2003 equal to or larger than the previous value (which was saved for this purpose). 4.2.3 Outdated Timestamps If a connection remains idle long enough for the timestamp clock of the other TCP to wrap its sign bit, then the value saved in TS.Recent will become too old; as a result, the PAWS mechanism will cause all subsequent segments to be rejected, freezing the connection (until the timestamp clock wraps its sign bit again). With the chosen range of timestamp clock frequencies (1 sec to 1 ms), the time to wrap the sign bit will be between 24.8 days and 24800 days. A TCP connection that is idle for more than 24 days and then comes to life is exceedingly unusual. However, it is undesirable in principle to place any limitation on TCP connection lifetimes. We therefore require that an implementation of PAWS include a mechanism to "invalidate" the TS.Recent value when a connection is idle for more than 24 days. (An alternative solution to the problem of outdated timestamps would be to send keepalive segments at a very low rate, but still more often than the wrap-around time for timestamps, e.g., once a day. This would impose negligible overhead. However, the TCP specification has never included keepalives, so the solution based upon invalidation was chosen.) Note that a TCP does not know the frequency, and therefore, the wraparound time, of the other TCP, so it must assume the worst. The validity of TS.Recent needs to be checked only if the basic PAWS timestamp check fails, i.e., only if SEG.TSval < TS.Recent. If TS.Recent is found to be invalid, then the segment is accepted, regardless of the failure of the timestamp check, and rule R3 updates TS.Recent with the TSval from the new segment. To detect how long the connection has been idle, the TCP may update a clock or timestamp value associated with the connection whenever TS.Recent is updated, for example. The details will be implementation-dependent. 4.2.4 Header Prediction "Header prediction" [Jacobson90a] is a high-performance transport protocol implementation technique that is most important for high-speed links. This technique optimizes the code for the most common case, receiving a segment correctly Network Working Group Expires February 2004 [Page 22] Internet-Draft TCP Extensions for High Performance August 2003 and in order. Using header prediction, the receiver asks the question, "Is this segment the next in sequence?" This question can be answered in fewer machine instructions than the question, "Is this segment within the window?" Adding header prediction to our timestamp procedure leads to the following recommended sequence for processing an arriving TCP segment: H1) Check timestamp (same as step R1 above) H2) Do header prediction: if segment is next in sequence and if there are no special conditions requiring additional processing, accept the segment, record its timestamp, and skip H3. H3) Process the segment normally, as specified in RFC-793. This includes dropping segments that are outside the window and possibly sending acknowledgments, and queueing in-window, out-of-sequence segments. Another possibility would be to interchange steps H1 and H2, i.e., to perform the header prediction step H2 FIRST, and perform H1 and H3 only when header prediction fails. This could be a performance improvement, since the timestamp check in step H1 is very unlikely to fail, and it requires interval arithmetic on a finite field, a relatively expensive operation. To perform this check on every single segment is contrary to the philosophy of header prediction. We believe that this change might reduce CPU time for TCP protocol processing by up to 5-10% on high-speed networks. However, putting H2 first would create a hazard: a segment from 2**32 bytes in the past might arrive at exactly the wrong time and be accepted mistakenly by the header-prediction step. The following reasoning has been introduced [Jacobson90b] to show that the probability of this failure is negligible. If all segments are equally likely to show up as old duplicates, then the probability of an old duplicate exactly matching the left window edge is the maximum segment size (MSS) divided by the size of the sequence space. This ratio must be less than 2**-16, since MSS must be < 2**16; for example, it will be (2**12)/(2**32) = 2**-20 for an FDDI link. However, the older a segment is, the less likely it is to be retained in the Internet, and under any reasonable model of segment lifetime the probability of an old duplicate exactly at the left window edge must be much smaller than 2**-16. Network Working Group Expires February 2004 [Page 23] Internet-Draft TCP Extensions for High Performance August 2003 The 16 bit TCP checksum also allows a basic unreliability of one part in 2**16. A protocol mechanism whose reliability exceeds the reliability of the TCP checksum should be considered "good enough", i.e., it won't contribute significantly to the overall error rate. We therefore believe we can ignore the problem of an old duplicate being accepted by doing header prediction before checking the timestamp. However, this probabilistic argument is not universally accepted, and the consensus at present is that the performance gain does not justify the hazard in the general case. It is therefore recommended that H2 follow H1. 4.3. Duplicates from Earlier Incarnations of Connection The PAWS mechanism protects against errors due to sequence number wrap-around on high-speed connection. Segments from an earlier incarnation of the same connection are also a potential cause of old duplicate errors. In both cases, the TCP mechanisms to prevent such errors depend upon the enforcement of a maximum segment lifetime (MSL) by the Internet (IP) layer (see Appendix of RFC-1185 for a detailed discussion). Unlike the case of sequence space wrap-around, the MSL required to prevent old duplicate errors from earlier incarnations does not depend upon the transfer rate. If the IP layer enforces the recommended 2 minute MSL of TCP, and if the TCP rules are followed, TCP connections will be safe from earlier incarnations, no matter how high the network speed. Thus, the PAWS mechanism is not required for this case. We may still ask whether the PAWS mechanism can provide additional security against old duplicates from earlier connections, allowing us to relax the enforcement of MSL by the IP layer. Appendix B explores this question, showing that further assumptions and/or mechanisms are required, beyond those of PAWS. This is not part of the current extension. 5. CONCLUSIONS AND ACKNOWLEDGMENTS This memo presented a set of extensions to TCP to provide efficient operation over large-bandwidth*delay-product paths and reliable operation over very high-speed paths. These extensions are designed to provide compatible interworking with TCP's that do not implement the extensions. These mechanisms are implemented using new TCP options for scaled windows and timestamps. The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Network Working Group Expires February 2004 [Page 24] Internet-Draft TCP Extensions for High Performance August 2003 Against Wrapped Sequences). The Window Scale option was originally suggested by Mike St. Johns of USAF/DCA. The present form of the option was suggested by Mike Karels of UC Berkeley in response to a more cumbersome scheme defined by Van Jacobson. Lixia Zhang helped formulate the PAWS mechanism description in RFC-1185. Finally, much of this work originated as the result of discussions within the End-to-End Task Force on the theoretical limitations of transport protocols in general and TCP in particular. Task force members and other on the end2end-interest list have made valuable contributions by pointing out flaws in the algorithms and the documentation. Continued discussion and development since the publication of RFC 1323 has occurred in the IETF TCP Large Windows Working Group. The authors are grateful for all these contributions. 6. REFERENCES [Braden89] Braden, R., editor, "Requirements for Internet Hosts -- Communication Layers", RFC 1122, October, 1989 [Clark87] Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk Data Transfer Protocol", RFC 998, MIT, March 1987. [Garlick77] Garlick, L., R. Rom, and J. Postel, "Issues in Reliable Host-to-Host Protocols", Proc. Second Berkeley Workshop on Distributed Data Management and Computer Networks, May 1977. [Hamming77] Hamming, R., "Digital Filters", ISBN 0-13-212571-4, Prentice Hall, Englewood Cliffs, N.J., 1977. [Cheriton88] Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC 1045, Stanford University, February 1988. [Jacobson88a] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM '88, Stanford, CA., August 1988. [Jacobson88b] Jacobson, V., and R. Braden, "TCP Extensions for Long-Delay Paths", RFC-1072, LBL and USC/Information Sciences Institute, October 1988. [Jacobson90a] Jacobson, V., "4BSD Header Prediction", ACM Computer Communication Review, April 1990. [Jacobson90b] Jacobson, V., Braden, R., and Zhang, L., "TCP Extension for High-Speed Paths", RFC-1185, LBL and USC/Information Sciences Institute, October 1990. [Jacobson90c] Jacobson, V., "Modified TCP congestion avoidance algorithm", Message to end2end-interest mailing list, April 1990. Network Working Group Expires February 2004 [Page 25] Internet-Draft TCP Extensions for High Performance August 2003 [Jain86] Jain, R., "Divergence of Timeout Algorithms for Packet Retransmissions", Proc. Fifth Phoenix Conf. on Comp. and Comm., Scottsdale, Arizona, March 1986. [Karn87] Karn, P. and C. Partridge, "Estimating Round-Trip Times in Reliable Transport Protocols", Proc. SIGCOMM '87, Stowe, VT, August 1987. [Mathis96] Mathis, M., Mahdavi, J., Floyd, S., and Romanow, A., "TCP Selective Acknowledgment Options", RFC 2018, October, 1996. [McKenzie89] McKenzie, A., "A Problem with the TCP Big Window Option", RFC 1110, BBN STC, August 1989. [Nagle84] Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, FACC, January 1984. [NBS85] Colella, R., Aronoff, R., and K. Mills, "Performance Improvements for ISO Transport", Ninth Data Comm Symposium, published in ACM SIGCOMM Comp Comm Review, vol. 15, no. 5, September 1985. [Postel81] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981. [Postel83] Postel, J., "The TCP Maximum Segment Size and Related Topics", RFC 879, ISI, November 1983. [Stevens97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, NOAO, January 1997. [Velten84] Velten, D., Hinden, R., and J. Sax, "Reliable Data Protocol", RFC 908, BBN, July 1984. [Watson81] Watson, R., "Timer-based Mechanisms in Reliable Transport Protocol Connection Management", Computer Networks, Vol. 5, 1981. [Zhang86] Zhang, L., "Why TCP Timers Don't Work Well", Proc. SIGCOMM '86, Stowe, Vt., August 1986. Network Working Group Expires February 2004 [Page 26] Internet-Draft TCP Extensions for High Performance August 2003 APPENDIX A: IMPLEMENTATION SUGGESTIONS TCP Option Layout The following layouts are recommended for sending options on non-SYN segments, to achieve maximum feasible alignment of 32-bit and 64-bit machines. +--------+--------+--------+--------+ | NOP | NOP | TSopt | 10 | +--------+--------+--------+--------+ | TSval timestamp | +--------+--------+--------+--------+ | TSecr timestamp | +--------+--------+--------+--------+ Interaction with the TCP Urgent Pointer The TCP Urgent pointer, like the TCP window, is a 16 bit value. Some of the original discussion for the TCP Window Scale option included proposals to increase the Urgent pointer to 32 bits. As it turns out, this is unnecessary. There are two observations that should be made: (1) With IP Version 4, the largest amount of TCP data that can be sent in a single packet is 65495 bytes (64K - 1 - size of fixed IP and TCP headers). (2) Updates to the urgent pointer while the user is in "urgent mode" are invisible to the user. This means that if the Urgent Pointer points beyond the end of the TCP data in the current packet, then the user will remain in urgent mode until the next TCP packet arrives. That packet will update the urgent pointer to a new offset, and the user will never have left urgent mode. Thus, to properly implement the Urgent Pointer, the sending TCP only has to check for overflow of the 16 bit Urgent Pointer field before filling it in. If it does overflow, than a value of 65535 should be inserted into the Urgent Pointer. TCP Options and MSS There has been some confusion as to what value should be filled in the TCP MSS option when using TCP options. RFC-879 Network Working Group Expires February 2004 [Page 27] Internet-Draft TCP Extensions for High Performance August 2003 [Postel83] stated: The MSS counts only data octets in the segment, it does not count the TCP header or the IP header. which is unclear about what to do about TCP options. RFC-1122 [Braden89] attempted to clarify this in section 4.2.2.6, but there still seems to be confusion. So, the MSS value to be sent in an MSS option should be equal to the effective MTU minus the fixed IP and TCP headers. Since both IP and TCP options are ignored when calculating the value for the MSS option, if there are any IP or TCP options to be sent in a packet, then the sender must decrease the size of the TCP data accordingly. The reason for this can be seen in the following table: +--------------------+--------------------+ | MSS is adjusted | MSS isn't adjusted | | to include options | to include options | +----------------+--------------------+--------------------+ | Sender adjusts | Packets are too | Packets are the | | length for | short | correct length | | options | | | +----------------+--------------------+--------------------+ | Sender doesn't | Packets are the | Packets are too | | adjust length | correct length | long. | | for options | | | +----------------+--------------------+--------------------+ Since the goal is to not send IP datagrams that have to be fragmented, and packets sent with the constraints in the lower right of this grid will cause IP fragmentation, the only way to guarantee that this doesn't happen is for the data sender to decrease the TCP data length by the size of the IP and TCP options. And since the sender will be adjusting the TCP data length when sending IP and TCP options, there is no need to include the IP and TCP option lengths in the MSS value. APPENDIX B: DUPLICATES FROM EARLIER CONNECTION INCARNATIONS There are two cases to be considered: (1) a system crashing (and losing connection state) and restarting, and (2) the same connection being closed and reopened without a loss of host state. These will be described in the following two sections. B.1 System Crash with Loss of State Network Working Group Expires February 2004 [Page 28] Internet-Draft TCP Extensions for High Performance August 2003 TCP's quiet time of one MSL upon system startup handles the loss of connection state in a system crash/restart. For an explanation, see for example "When to Keep Quiet" in the TCP protocol specification [Postel81]. The MSL that is required here does not depend upon the transfer speed. The current TCP MSL of 2 minutes seems acceptable as an operational compromise, as many host systems take this long to boot after a crash. However, the timestamp option may be used to ease the MSL requirements (or to provide additional security against data corruption). If timestamps are being used and if the timestamp clock can be guaranteed to be monotonic over a system crash/restart, i.e., if the first value of the sender's timestamp clock after a crash/restart can be guaranteed to be greater than the last value before the restart, then a quiet time will be unnecessary. To dispense totally with the quiet time would require that the host clock be synchronized to a time source that is stable over the crash/restart period, with an accuracy of one timestamp clock tick or better. We can back off from this strict requirement to take advantage of approximate clock synchronization. Suppose that the clock is always re-synchronized to within N timestamp clock ticks and that booting (extended with a quiet time, if necessary) takes more than N ticks. This will guarantee monotonicity of the timestamps, which can then be used to reject old duplicates even without an enforced MSL. B.2 Closing and Reopening a Connection When a TCP connection is closed, a delay of 2*MSL in TIME-WAIT state ties up the socket pair for 4 minutes (see Section 3.5 of [Postel81]. Applications built upon TCP that close one connection and open a new one (e.g., an FTP data transfer connection using Stream mode) must choose a new socket pair each time. The TIME- WAIT delay serves two different purposes: (a) Implement the full-duplex reliable close handshake of TCP. The proper time to delay the final close step is not really related to the MSL; it depends instead upon the RTO for the FIN segments and therefore upon the RTT of the path. (It could be argued that the side that is sending a FIN knows what degree of reliability it needs, and therefore it should be able to determine the length of the TIME-WAIT delay for the FIN's recipient. This could be accomplished with an appropriate TCP option in FIN segments.) Although there is no formal upper-bound on RTT, common network engineering practice makes an RTT greater than 1 Network Working Group Expires February 2004 [Page 29] Internet-Draft TCP Extensions for High Performance August 2003 minute very unlikely. Thus, the 4 minute delay in TIME-WAIT state works satisfactorily to provide a reliable full-duplex TCP close. Note again that this is independent of MSL enforcement and network speed. The TIME-WAIT state could cause an indirect performance problem if an application needed to repeatedly close one connection and open another at a very high frequency, since the number of available TCP ports on a host is less than 2**16. However, high network speeds are not the major contributor to this problem; the RTT is the limiting factor in how quickly connections can be opened and closed. Therefore, this problem will be no worse at high transfer speeds. (b) Allow old duplicate segments to expire. To replace this function of TIME-WAIT state, a mechanism would have to operate across connections. PAWS is defined strictly within a single connection; the last timestamp is TS.Recent is kept in the connection control block, and discarded when a connection is closed. An additional mechanism could be added to the TCP, a per-host cache of the last timestamp received from any connection. This value could then be used in the PAWS mechanism to reject old duplicate segments from earlier incarnations of the connection, if the timestamp clock can be guaranteed to have ticked at least once since the old connection was open. This would require that the TIME-WAIT delay plus the RTT together must be at least one tick of the sender's timestamp clock. Such an extension is not part of the proposal of this RFC. Note that this is a variant on the mechanism proposed by Garlick, Rom, and Postel [Garlick77], which required each host to maintain connection records containing the highest sequence numbers on every connection. Using timestamps instead, it is only necessary to keep one quantity per remote host, regardless of the number of simultaneous connections to that host. Network Working Group Expires February 2004 [Page 30] Internet-Draft TCP Extensions for High Performance August 2003 APPENDIX C: CHANGES FROM RFC-1072, RFC-1185, RFC-1323 The protocol extensions defined in RFC-1323 document differ in several important ways from those defined in RFC-1072 and RFC-1185. (a) SACK has been split off into a separate document, RFC 2018 [Mathis96]. (b) The detailed rules for sending timestamp replies (see Section 3.4) differ in important ways. The earlier rules could result in an under-estimate of the RTT in certain cases (packets dropped or out of order). (c) The same value TS.Recent is now shared by the two distinct mechanisms RTTM and PAWS. This simplification became possible because of change (b). (d) An ambiguity in RFC-1185 was resolved in favor of putting timestamps on ACK as well as data segments. This supports the symmetry of the underlying TCP protocol. (e) The echo and echo reply options of RFC-1072 were combined into a single Timestamps option, to reflect the symmetry and to simplify processing. (f) The problem of outdated timestamps on long-idle connections, discussed in Section 4.2.2, was realized and resolved. (g) RFC-1185 recommended that header prediction take precedence over the timestamp check. Based upon some scepticism about the probabilistic arguments given in Section 4.2.4, it was decided to recommend that the timestamp check be performed first. (h) The spec was modified so that the extended options will be sent on segments only when they are received in the corresponding segments. This provides the most conservative possible conditions for interoperation with implementations without the extensions. In addition to these substantive changes, the present RFC attempts to specify the algorithms unambiguously by presenting modifications to the Event Processing rules of RFC-793; see Appendix F. There are additional changes in this document from RFC-1323. These changes are: (a) The description of which TSecr values can be used to update the measured RTT has been clarified. Specifically, with Timestamps, the Karn algorithm [Karn87] is disabled. The Karn algorithm Network Working Group Expires February 2004 [Page 31] Internet-Draft TCP Extensions for High Performance August 2003 disables all RTT measurements during retransmission, since it is ambiguous whether the ACK is is for the original packet, or the retransmitted packet. With Timestamps, that ambiguity is removed since the TSecr in the ACK will contain the TSval from which ever data packet made it to the destination. (b) In RFC-1323, section 3.4, step (2) of the algorithm to control which timestamp is echoed was incorrect in two regards: (1) It failed to update TSrecent for a retransmitted segment that resulted from a lost ACK. (2) It failed if SEG.LEN = 0. In the new algorithm, the case of SEG.TSval = TSrecent is included for consistency with the PAWS test. (c) One correction was made to the Event Processing Summary in Appendix F. In SEND CALL/ESTABLISHED STATE, RCV.WND is used to fill in the SEG.WND value, not SND.WND. (d) New pseudo-code summary has been added in Appendix E. (e) Appendix A has been expanded with information about the TCP MSS option and the TCP Urgent Pointer. Network Working Group Expires February 2004 [Page 32] Internet-Draft TCP Extensions for High Performance August 2003 APPENDIX D: SUMMARY OF NOTATION The following notation has been used in this document. Options WSopt: TCP Window Scale Option TSopt: TCP Timestamps Option Option Fields shift.cnt: Window scale byte in WSopt. TSval: 32-bit Timestamp Value field in TSopt. TSecr: 32-bit Timestamp Reply field in TSopt. Option Fields in Current Segment SEG.TSval: TSval field from TSopt in current segment. SEG.TSecr: TSecr field from TSopt in current segment. SEG.WSopt: 8-bit value in WSopt Clock Values my.TSclock: Local source of 32-bit timestamp values my.TSclock.rate: Period of my.TSclock (1 ms to 1 sec). Per-Connection State Variables TS.Recent: Latest received Timestamp Last.ACK.sent: Last ACK field sent Snd.TS.OK: 1-bit flag Snd.WS.OK: 1-bit flag Rcv.Wind.Scale: Receive window scale power Snd.Wind.Scale: Send window scale power Start.Time: my.TSclock value when segment being timed was sent (used by pre-1323 code). Procedure Update_SRTT( m ) Procedure to update the smoothed RTT and RTT variance estimates, using the rules of [Jacobson88a], given m, a new RTT measurement. Network Working Group Expires February 2004 [Page 33] Internet-Draft TCP Extensions for High Performance August 2003 APPENDIX E: PSEUDO-CODE SUMMARY Create new TCB => { Rcv.wind.scale = MIN( 14, MAX( 0, floor(log2(receive buffer space)) - 15 ) ); Snd.wind.scale = 0; Last.ACK.sent = 0; Snd.TS.OK = Snd.WS.OK = FALSE; } Send initial {SYN} segment => { SEG.WND = MIN( RCV.WND, 65535 ); Include in segment: TSopt(TSval=my.TSclock, TCecr=0); Include in segment: WSopt = Rcv.wind.scale; } Send {SYN, ACK} segment => { SEG.ACK = Last.ACK.sent = RCV.NXT; SEG.WND = MIN( RCV.WND, 65535 ); if (Snd.TS.OK) then Include in segment: TSopt(TSval=my.TSclock, TSecr=TS.Recent); if (Snd.WS.OK) then Include in segment: WSopt = Rcv.wind.scale; } Receive {SYN} or {SYN,ACK} segment => { if (Segment contains TSopt) then { TS.Recent = SEG.TSval; Snd.TS.OK = TRUE; if (is {SYN,ACK} segment) then Update_SRTT( (my.TSclock - SEG.TSecr)/my.TSclock.rate ) ; } if Segment contains WSopt) then { Snd.wind.scale = SEG.WSopt; Snd.WS.OK = TRUE; } else Rcv.wind.scale = Snd.wind.scale = 0; } Network Working Group Expires February 2004 [Page 34] Internet-Draft TCP Extensions for High Performance August 2003 Send non-SYN segment => { SEG.ACK = Last.ACK.sent = RCV.NXT; SEG.WND = MIN( RCV.WND >> Rcv.wind.scale, 65535 ); if (Snd.TS.OK) then Include in segment: TSopt(TSval=my.TSclock, TSecr=TS.Recent); } Receive non-SYN segment in (state >= ESTABLISHED) => { Window = (SEG.WND << Snd.wind.scale); /* Use 32-bit 'Window' instead of 16-bit 'SEG.WND' * in rest of processing. */ if (Segment contains TSopt) then { if (SEG.TSval < TS.Recent && Idle less than 24 days) then { if (Send.TS.OK AND (NOT RST) ) then { /* Timestamp too old => * segment is unacceptable. */ Send ACK segment; Discard segment and return; } } else { if (SEG.SEQ =< Last.ACK.sent) then TS.Recent = SEG.TSval; } } if (SEG.ACK > SND.UNA) then { /* (At least part of) first segment in * retransmission queue has been ACKd */ if (Segment contains TSopt) then Update_SRTT( (my.TSclock - SEG.TSecr)/my.TSclock.rate); else Update_SRTT( /* for compatibility */ (my.TSclock - Start.Time)/my.TSclock.rate); } } Network Working Group Expires February 2004 [Page 35] Internet-Draft TCP Extensions for High Performance August 2003 APPENDIX F: EVENT PROCESSING SUMMARY Event Processing OPEN Call ... An initial send sequence number (ISS) is selected. Send a SYN segment of the form: ... SEND Call CLOSED STATE (i.e., TCB does not exist) ... LISTEN STATE If the foreign socket is specified, then change the connection from passive to active, select an ISS. Send a SYN segment containing the options: and . Set SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT state. ... SYN-SENT STATE SYN-RECEIVED STATE ... ESTABLISHED STATE CLOSE-WAIT STATE Segmentize the buffer and send it with a piggybacked acknowledgment (acknowledgment value = RCV.NXT). ... If the urgent flag is set ... If the Snd.TS.OK flag is set, then include the TCP Timestamps option in each data segment. Scale the receive window for transmission in the segment header: SEG.WND = (RCV.WND >> Rcv.Wind.Scale). Network Working Group Expires February 2004 [Page 36] Internet-Draft TCP Extensions for High Performance August 2003 SEGMENT ARRIVES ... If the state is LISTEN then first check for an RST ... second check for an ACK ... third check for a SYN if the SYN bit is set, check the security. If the ... ... If the SEG.PRC is less than the TCB.PRC then continue. Check for a Window Scale option (WSopt); if one is found, save SEG.WSopt in Snd.Wind.Scale and set Snd.WS.OK flag on. Otherwise, set both Snd.Wind.Scale and Rcv.Wind.Scale to zero and clear Snd.WS.OK flag. Check for a TSopt option; if one is found, save SEG.TSval in the variable TS.Recent and turn on the Snd.TS.OK bit. Set RCV.NXT to SEG.SEQ+1, IRS is set to SEG.SEQ and any other control or text should be queued for processing later. ISS should be selected and a SYN segment sent of the form: If the Snd.WS.OK bit is on, include a WSopt option in this segment. If the Snd.TS.OK bit is on, include a TSopt in this segment. Last.ACK.sent is set to RCV.NXT. SND.NXT is set to ISS+1 and SND.UNA to ISS. The connection state should be changed to SYN-RECEIVED. Note that any other incoming control or data (combined with SYN) will be processed in the SYN-RECEIVED state, but processing of SYN and ACK should not be repeated. If the listen was not fully specified (i.e., the foreign socket was not fully specified), then the unspecified fields should be filled in now. fourth other text or control Network Working Group Expires February 2004 [Page 37] Internet-Draft TCP Extensions for High Performance August 2003 ... If the state is SYN-SENT then first check the ACK bit ... fourth check the SYN bit ... If the SYN bit is on and the security/compartment and precedence are acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to SEG.SEQ, and any acknowledgements on the retransmission queue which are thereby acknowledged should be removed. Check for a Window Scale option (WSopt); if is found, save SEG.WSopt in Snd.Wind.Scale; otherwise, set both Snd.Wind.Scale and Rcv.Wind.Scale to zero. Check for a TSopt option; if one is found, save SEG.TSval in variable TS.Recent and turn on the Snd.TS.OK bit in the connection control block. If the ACK bit is set, use my.TSclock - SEG.TSecr as the initial RTT estimate. If SND.UNA > ISS (our SYN has been ACKed), change the connection state to ESTABLISHED, form an ACK segment: and send it. If the Snd.Echo.OK bit is on, include a TSopt option in this ACK segment. Last.ACK.sent is set to RCV.NXT. Data or controls which were queued for transmission may be included. If there are other controls or text in the segment then continue processing at the sixth step below where the URG bit is checked, otherwise return. Otherwise enter SYN-RECEIVED, form a SYN,ACK segment: and send it. If the Snd.Echo.OK bit is on, include a TSopt option in this segment. If the Snd.WS.OK bit is on, include a WSopt option in this segment. Last.ACK.sent is set to RCV.NXT. Network Working Group Expires February 2004 [Page 38] Internet-Draft TCP Extensions for High Performance August 2003 If there are other controls or text in the segment, queue them for processing after the ESTABLISHED state has been reached, return. fifth, if neither of the SYN or RST bits is set then drop the segment and return. Otherwise, First, check sequence number SYN-RECEIVED STATE ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE CLOSE-WAIT STATE CLOSING STATE LAST-ACK STATE TIME-WAIT STATE Segments are processed in sequence. Initial tests on arrival are used to discard old duplicates, but further processing is done in SEG.SEQ order. If a segment's contents straddle the boundary between old and new, only the new parts should be processed. Rescale the received window field: TrueWindow = SEG.WND << Snd.Wind.Scale, and use "TrueWindow" in place of SEG.WND in the following steps. Check whether the segment contains a Timestamps option and bit Snd.TS.OK is on. If so: If SEG.TSval < TS.Recent, then test whether connection has been idle less than 24 days; if both are true, then the segment is not acceptable; follow steps below for an unacceptable segment. If SEG.SEQ is equal to Last.ACK.sent, then save SEG.ECopt in variable TS.Recent. There are four cases for the acceptability test for an incoming segment: ... Network Working Group Expires February 2004 [Page 39] Internet-Draft TCP Extensions for High Performance August 2003 If an incoming segment is not acceptable, an acknowledgment should be sent in reply (unless the RST bit is set, if so drop the segment and return): Last.ACK.sent is set to SEG.ACK of the acknowledgment. If the Snd.Echo.OK bit is on, include the Timestamps option in this ACK segment. Set Last.ACK.sent to SEG.ACK and send the ACK segment. After sending the acknowledgment, drop the unacceptable segment and return. ... fifth check the ACK field. if the ACK bit is off drop the segment and return. if the ACK bit is on ... ESTABLISHED STATE If SND.UNA < SEG.ACK =< SND.NXT then, set SND.UNA <- SEG.ACK. Also compute a new estimate of round-trip time. If Snd.TS.OK bit is on, use my.TSclock - SEG.TSecr; otherwise use the elapsed time since the first segment in the retransmission queue was sent. Any segments on the retransmission queue which are thereby entirely acknowledged... ... Seventh, process the segment text. ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE ... Send an acknowledgment of the form: If the Snd.TS.OK bit is on, include Timestamps option Network Working Group Expires February 2004 [Page 40] Internet-Draft TCP Extensions for High Performance August 2003 in this ACK segment. Set Last.ACK.sent to SEG.ACK of the acknowledgment, and send it. This acknowledgment should be piggy-backed on a segment being transmitted if possible without incurring undue delay. ... Security Considerations Security issues are not discussed in this memo. Authors' Addresses Van Jacobson Packet Design 2465 Latham Street Mountain View, CA 94040 EMail: van@packetdesign.com Bob Braden University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: (310) 448-9173 EMail: Braden@ISI.EDU David Borman Wind River Systems, Inc. 1250 Northland Drive, #175 Mendota Heights, MN 55120-1154 Phone: (612) 405-8194 Email: dab@BSDI.COM Network Working Group Expires February 2004 [Page 41] _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Aug 13 04:28: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 EAA12319 for ; Wed, 13 Aug 2003 04:28: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 19mqzK-0005C9-2k for tsvwg-archive@odin.ietf.org; Wed, 13 Aug 2003 04:28:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7D8S956019892 for tsvwg-archive@odin.ietf.org; Wed, 13 Aug 2003 04:28:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mqzB-0005Aj-L9; Wed, 13 Aug 2003 04:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mqz0-0005AX-Eb for tsvwg@optimus.ietf.org; Wed, 13 Aug 2003 04:27: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 EAA12314 for ; Wed, 13 Aug 2003 04:27:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mqyv-0007bJ-00 for tsvwg@ietf.org; Wed, 13 Aug 2003 04:27:45 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19mqyu-0007bG-00 for tsvwg@ietf.org; Wed, 13 Aug 2003 04:27:44 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7D8Re7W006599; Wed, 13 Aug 2003 10:27:40 +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 QXY8QRB8; Wed, 13 Aug 2003 10:27:44 +0200 Received: from res0010384da36.ericsson.com (rac182pc.edd.ericsson.se [164.48.123.182]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id KAA15821; Wed, 13 Aug 2003 10:27:38 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030813093329.027bb2b0@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 13 Aug 2003 10:26:33 +0200 To: David Borman From: Reiner Ludwig Subject: Re: [Tsvwg] Updating timestamps (ts_recent) in Linux Cc: martin.duke@boeing.com, tsvwg@ietf.org In-Reply-To: <200308121553.h7CFrnIh022482@frantic.weston.bsdi.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 17:53 12.08.2003, David Borman wrote: >As a final thought, updating TSrecent more often does not mean that you >can get RTT measurements more often. It continues to be the case that the >only time you can get a reliable RTT measurement from timestamps is when >when new data is acknowledged. That is because dup ACK packets can be >spontainiously generated by the remote side to do a window update. In >that case, taking an RTT measurement can be vastly over inflated. And >since there is no way to reliably identify whether a received dup ACK >is due to out-of-order data arriving or due to the remote side deciding >to update the window, the best course of action is to only take RTT >measurements when new data is acknowledged. This brings up another issue that is currently not defined in any RFC: what is a DUPACK? The BSD code (tcp_input.c) is quite clear about it: an ACK is a DUPACK if 1. the TCP sender has outstanding data, AND 2. the ACK number is the largest seen so far, i.e., it acks snd_una, AND 3. the ACK is a pure ACK, i.e., SEG.LEN == 0, AND 4. the advertized window info didn't change, i.e., this is *not a window update*. So, we with this definition of a DUPACK it should be save for the TCP receiver to echo the most recently received ts_val in DUPACKs, and for the TCP sender to use such DUPACKs to get a reliable RTT measurement. Did I miss something? ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Aug 13 10: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 KAA22528 for ; Wed, 13 Aug 2003 10: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 19mx0n-0001ry-7e for tsvwg-archive@odin.ietf.org; Wed, 13 Aug 2003 10:54:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DEs5hI007183 for tsvwg-archive@odin.ietf.org; Wed, 13 Aug 2003 10: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 19mx0j-0001rk-Cx; Wed, 13 Aug 2003 10: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 19mwzo-0001qz-8j for tsvwg@optimus.ietf.org; Wed, 13 Aug 2003 10:53: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 KAA22505 for ; Wed, 13 Aug 2003 10:52:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mwzl-00029X-00 for tsvwg@ietf.org; Wed, 13 Aug 2003 10:53:01 -0400 Received: from frantic-dmz.weston.bsdi.com ([206.196.54.22] helo=frantic.weston.bsdi.com) by ietf-mx with esmtp (Exim 4.12) id 19mwzk-00029M-00 for tsvwg@ietf.org; Wed, 13 Aug 2003 10:53:01 -0400 Received: from frantic.weston.bsdi.com (localhost.BSDI.COM [127.0.0.1]) by frantic.weston.bsdi.com (8.12.5/8.12.5) with ESMTP id h7DEqHOn024215; Wed, 13 Aug 2003 09:52:17 -0500 (CDT) Received: (from dab@localhost) by frantic.weston.bsdi.com (8.12.5/8.12.5/Submit) id h7DEqGbF024214; Wed, 13 Aug 2003 09:52:16 -0500 (CDT) Date: Wed, 13 Aug 2003 09:52:16 -0500 (CDT) From: David Borman Message-Id: <200308131452.h7DEqGbF024214@frantic.weston.bsdi.com> To: Reiner.Ludwig@ericsson.com Subject: Re: [Tsvwg] Updating timestamps (ts_recent) in Linux Cc: martin.duke@boeing.com, tsvwg@ietf.org Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > Date: Wed, 13 Aug 2003 10:26:33 +0200 > From: Reiner Ludwig > Subject: Re: [Tsvwg] Updating timestamps (ts_recent) in Linux > > At 17:53 12.08.2003, David Borman wrote: > >As a final thought, updating TSrecent more often does not mean that you > >can get RTT measurements more often. It continues to be the case that the > >only time you can get a reliable RTT measurement from timestamps is when > >when new data is acknowledged. That is because dup ACK packets can be > >spontainiously generated by the remote side to do a window update. In > >that case, taking an RTT measurement can be vastly over inflated. And > >since there is no way to reliably identify whether a received dup ACK > >is due to out-of-order data arriving or due to the remote side deciding > >to update the window, the best course of action is to only take RTT > >measurements when new data is acknowledged. > > This brings up another issue that is currently not defined in any RFC: what > is a DUPACK? > > The BSD code (tcp_input.c) is quite clear about it: an ACK is a DUPACK if > 1. the TCP sender has outstanding data, AND > 2. the ACK number is the largest seen so far, i.e., it acks snd_una, AND > 3. the ACK is a pure ACK, i.e., SEG.LEN == 0, AND > 4. the advertized window info didn't change, > i.e., this is *not a window update*. > > So, we with this definition of a DUPACK it should be save for the TCP > receiver to echo the most recently received ts_val in DUPACKs, and for the Yes, the changed rule (2) in section 3.4 does a much better job of updating TSrecent. The only time it doesn't update TSrecent when a newer timestamp is received, is when a packet arrives out-of-order. If you always update TSrecent when you get a newer timestamp, then you'd get this scenario with re-ordering packets (modified from 1323): TS.Recent -------------------> 1 #1) <---- 1 -------------------> 3 #2) <---- 3 -------------------> 3 #3) <---- 3 -------------------> 5 #4) <---- 5 -------------------> 5 #5) <---- As you can see, the ACK#3 and ACK#5 both are echoing a timestamp that is newer than the timestamp that was received in the packet that filled the hole. This leads to an underestimation for the RTT for both packets, which are the ones that would be used for RTT measurement. In addition, if #3 got lost, then #4 would be seen as the new ACK and it's shorter RTT value would be used. With the 1323 rules, #4 would be echoing TSecr=2, not TSecr=5, leading to an overestimation of the RTT rather than an underestimation. The argument in 1323 is that it's always better to overestimate than underestimate the RTT. > TCP sender to use such DUPACKs to get a reliable RTT measurement. > > Did I miss something? > > ///Reiner In the above example, if you allow the RTT values from the DUPACKs to be used (#2 & #4), you'll be using even shorter RTT values, skewing the RTT even more. And if the other side is not using this new echo scheme, then using the DUPACKs for timing information could lead wildly overestimating the RTT (too much of an overestimation is also a bad thing...) -David Borman _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Aug 13 13:50: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 NAA27652 for ; Wed, 13 Aug 2003 13:50: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 19mzl7-0003Lw-Dt for tsvwg-archive@odin.ietf.org; Wed, 13 Aug 2003 13:50:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DHo5vR012885 for tsvwg-archive@odin.ietf.org; Wed, 13 Aug 2003 13:50:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzl3-0003Li-CH; Wed, 13 Aug 2003 13: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 19mzko-0003LH-4W for tsvwg@optimus.ietf.org; Wed, 13 Aug 2003 13:49: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 NAA27619 for ; Wed, 13 Aug 2003 13:49:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mzkl-0003Wd-00 for tsvwg@ietf.org; Wed, 13 Aug 2003 13:49:43 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19mzkl-0003Wa-00 for tsvwg@ietf.org; Wed, 13 Aug 2003 13:49:43 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7DHnegM001816; Wed, 13 Aug 2003 19:49:40 +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 QY12CHWX; Wed, 13 Aug 2003 19:49:45 +0200 Received: from res0010384da36.ericsson.com (rac182pc.edd.ericsson.se [164.48.123.182]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id TAA00652; Wed, 13 Aug 2003 19:49:35 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030813185342.028d2480@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 13 Aug 2003 19:50:21 +0200 To: David Borman From: Reiner Ludwig Subject: Re: [Tsvwg] Updating timestamps (ts_recent) in Linux Cc: tsvwg@ietf.org In-Reply-To: <200308131452.h7DEqGbF024214@frantic.weston.bsdi.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 16:52 13.08.2003, David Borman wrote: > > This brings up another issue that is currently not defined in any RFC: > what > > is a DUPACK? > > > > The BSD code (tcp_input.c) is quite clear about it: an ACK is a DUPACK if > > 1. the TCP sender has outstanding data, AND > > 2. the ACK number is the largest seen so far, i.e., it acks snd_una, AND > > 3. the ACK is a pure ACK, i.e., SEG.LEN == 0, AND > > 4. the advertized window info didn't change, > > i.e., this is *not a window update*. > > > > So, we with this definition of a DUPACK it should be save for the TCP > > receiver to echo the most recently received ts_val in DUPACKs, and for the > >Yes, the changed rule (2) in section 3.4 does a much better job of updating >TSrecent. The only time it doesn't update TSrecent when a newer timestamp >is received, is when a packet arrives out-of-order. And, I still think we can do better ... >If you always update TSrecent when you get a newer timestamp, then you'd >get this scenario with re-ordering packets (modified from 1323): > TS.Recent > -------------------> > 1 > #1) <---- > 1 > -------------------> > 3 > #2) <---- > 3 > -------------------> > 3 > #3) <---- > 3 > -------------------> > 5 > #4) <---- > 5 > -------------------> > 5 > #5) <---- > >As you can see, the ACK#3 and ACK#5 both are echoing a timestamp >that is newer than the timestamp that was received in the packet >that filled the hole. This leads to an underestimation for the RTT >for both packets, which are the ones that would be used for RTT >measurement. I played with your example for a while, and looked at the following scenario: Assume we have a constant (real) RTT of 100 ms, and the TCP sender's cwnd allows to send the five packets A - E. The TCP sender sends A, 10 ms after it sent A, it sends B, 10 ms after it sent B, it sends C, 20 ms after it sent C, it sends D, 10 ms after it sent D, it sends E. To cause the rordering in your example: B is held up in the network for 20 ms so that C "overtakes", and D is held up in the network for 20 ms so that E "overtakes". As usual the TCP sender (blindly) does 'tcp_now - TSecr' to derive an RTT from every ACK (Karn can be safely disabled with timestamps). The real RTT samples as seen by "somebody traveling in the packet", and as they arrive at the TCP sender are: RTT(A)=100 RTT(C)=100 RTT(B)=120 RTT(E)=100 RTT(D)=120 The RTT samples taken by a TCP sender using the rule I suggested are: RTT(A)=100 RTT(C)=100 RTT(B)=110(-10) RTT(E)=100 RTT(D)=110(-10) The RTT samples taken by a TCP sender using RFC1323 are: RTT(A)=100 RTT(C)=120(+20) RTT(B)=120 RTT(E)=140(+40) RTT(D)=120 So, you are right. The rule I suggested leads to a slight underestimation, while RFC1323 - as expected - leads to overestimation. But, what if we simply forget about TS.Recent and simply let the TCP receiver echo TSval received in the segment for which it sends an ACK? Then, in your example the TCP sender would see TSecr=1, 3, 2, 5, 4, and in the scenario I gave above the RTT samples taken by the TCP sender would be: RTT(A)=100 RTT(C)=100 RTT(B)=120 RTT(E)=100 RTT(D)=120 => the true RTTs. No over-/under-estimation. We would still need to take care of delayed ACKs, though. For that we could use TS.Recent. We would store in TS.Recent the TSval from an in-sequence data segement for which an ACK is not generated immediately due to delayed ACK, and would echo TS.Recent in the delayed ACK. >In the above example, if you allow the RTT values from the >DUPACKs to be used (#2 & #4), you'll be using even shorter RTT >values, skewing the RTT even more. I don't think so. Those RTT values would even be the correct values. >And if the other side is not >using this new echo scheme, then using the DUPACKs for timing >information could lead wildly overestimating the RTT (too much of >an overestimation is also a bad thing...) A TCP sender could easily detect whether a TCP receiver is using RFC1323 or a newer echo scheme: with RFC1323 the TSecr values in subsequent DUPACKs don't change. Apart from these corner cases, I wonder if we are losing the bigger picture. The very common case is that the TCP sender receives a series of DUPACKs during loss recovery. The recovery phase at least lasts for one RTT during which today with RFC1323 the RTT can't be sampled. Reordering, on the other hand, has so far only been reported to be a rare event in the Internet. Studies that did find large reordering, later found that this was due to some hardware glitch that then got fixed. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Aug 13 16:37: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 QAA05040 for ; Wed, 13 Aug 2003 16: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 19n2Mh-0006a8-Vh for tsvwg-archive@odin.ietf.org; Wed, 13 Aug 2003 16:37:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DKb3mH025282 for tsvwg-archive@odin.ietf.org; Wed, 13 Aug 2003 16: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 19n2Mf-0006YL-A1; Wed, 13 Aug 2003 16: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 19n2MV-0006Xk-JJ for tsvwg@optimus.ietf.org; Wed, 13 Aug 2003 16:36: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 QAA05033 for ; Wed, 13 Aug 2003 16:36:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2MT-0004r7-00 for tsvwg@ietf.org; Wed, 13 Aug 2003 16:36:49 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19n2MS-0004r4-00 for tsvwg@ietf.org; Wed, 13 Aug 2003 16:36:48 -0400 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA23717; Wed, 13 Aug 2003 13:35:59 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id NAA07202; Wed, 13 Aug 2003 13:36:43 -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 h7DKYvR02803; Wed, 13 Aug 2003 13:34:57 -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, 13 Aug 2003 13:33:41 -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] Updating timestamps (ts_recent) in Linux Date: Wed, 13 Aug 2003 13:33:41 -0700 Message-ID: Thread-Topic: [Tsvwg] Updating timestamps (ts_recent) in Linux Thread-Index: AcNhw4cpuvRIG6zdQKi0xYGasURdFwAFcCSw From: "Duke, Martin" To: "Reiner Ludwig" , "David Borman" Cc: X-OriginalArrivalTime: 13 Aug 2003 20:33:41.0975 (UTC) FILETIME=[2F3C4670:01C361DA] 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 >=20 > The real RTT samples as seen by "somebody traveling in the=20 > packet", and as=20 > they arrive at the TCP sender are: > RTT(A)=3D100 > RTT(C)=3D100 > RTT(B)=3D120 > RTT(E)=3D100 > RTT(D)=3D120 >=20 > The RTT samples taken by a TCP sender using the rule I suggested are: > RTT(A)=3D100 > RTT(C)=3D100 > RTT(B)=3D110(-10) > RTT(E)=3D100 > RTT(D)=3D110(-10) >=20 > The RTT samples taken by a TCP sender using RFC1323 are: > RTT(A)=3D100 > RTT(C)=3D120(+20) > RTT(B)=3D120 > RTT(E)=3D140(+40) > RTT(D)=3D120 Remember that using RFC 1323, only 3 measurements are taken because 2 of = the ACKs do not ack new data. Using RFC 1323, the measurements are taken from the 1st, 3rd, and 5th = ACKs, and are RTT(A) =3D 100 RTT(B) =3D 120 RTT(D) =3D 120 (Packets C and E do not update ts_recent) So I don't see what the problem is in your example. Martin =20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Aug 14 02:43: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 CAA01491 for ; Thu, 14 Aug 2003 02:43: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 19nBpF-0002f9-Vn for tsvwg-archive@odin.ietf.org; Thu, 14 Aug 2003 02:43:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7E6h9Yt010230 for tsvwg-archive@odin.ietf.org; Thu, 14 Aug 2003 02:43:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nBp8-0002eC-62; Thu, 14 Aug 2003 02:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nBoB-0002bV-DZ for tsvwg@optimus.ietf.org; Thu, 14 Aug 2003 02:42: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 CAA01447 for ; Thu, 14 Aug 2003 02:41:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nBo7-0000C1-00 for tsvwg@ietf.org; Thu, 14 Aug 2003 02:41:59 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19nBo6-0000By-00 for tsvwg@ietf.org; Thu, 14 Aug 2003 02:41:58 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7E6fu7W011372; Thu, 14 Aug 2003 08:41:56 +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 QX51LFV6; Thu, 14 Aug 2003 08:41:56 +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 IAA22749; Thu, 14 Aug 2003 08:41:55 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030814081348.00aa7568@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 14 Aug 2003 08:42:42 +0200 To: "Duke, Martin" From: Reiner Ludwig Cc: tsvwg@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Tsvwg] RFC1323.bis [was: Updating timestamps (ts_recent)] Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@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 22:33 13.08.2003, Duke, Martin wrote: > > > > The real RTT samples as seen by "somebody traveling in the > > packet", and as > > they arrive at the TCP sender are: > > RTT(A)=100 > > RTT(C)=100 > > RTT(B)=120 > > RTT(E)=100 > > RTT(D)=120 > > > > The RTT samples taken by a TCP sender using the rule I suggested are: > > RTT(A)=100 > > RTT(C)=100 > > RTT(B)=110(-10) > > RTT(E)=100 > > RTT(D)=110(-10) > > > > The RTT samples taken by a TCP sender using RFC1323 are: > > RTT(A)=100 > > RTT(C)=120(+20) > > RTT(B)=120 > > RTT(E)=140(+40) > > RTT(D)=120 > >Remember that using RFC 1323, only 3 measurements are taken because 2 of >the ACKs do not ack new data. > >Using RFC 1323, the measurements are taken from the 1st, 3rd, and 5th >ACKs, and are > >RTT(A) = 100 >RTT(B) = 120 >RTT(D) = 120 >(Packets C and E do not update ts_recent) True. And if we would continue to use RFC1323's rule of only taking RTT samples from ACKs for new data then with any of the echo schemes only the ACKs for A, B, and D got sampled. >So I don't see what the problem is in your example. RFC1323's sender rule of only taking RTT samples from ACKs for new data is one half of the problem I see. The other half of that problem is RFC1323's receiver echo rule (B)). The combination of both halves of that problem lead to the fact that during a typical loss recovery, when an RTT worth of DUPACKs return, the sender can't sample the RTT. So far, I haven't seen a good reason for why this has to be like that. I would therefore like to see RFC1323 changed in such a way that (1) the TCP sender is allowed to sample the RTT from DUPACKs, and (2) that the TCP receiver echos the most recently received TSval in DUPACKs. Clearly, having (1) without (2) makes little sense, and vice versa. The problem you raised is different, but related, and relevant, I believe. BTW, whatever RFC1323.bis gets created, it might be a good idea to include RFC1323.bis-capability-indication in the initial SYN/SYN-ACK handshake. Another open issue with RFC1323, I think, is the question of whether *every* segment MUST carry a TS option once that was negotiated in the SYN/SYN-ACK handshake. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Aug 14 09: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 JAA09242 for ; Thu, 14 Aug 2003 09: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 19nI98-0002Qm-8q for tsvwg-archive@odin.ietf.org; Thu, 14 Aug 2003 09:28:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EDS6nk009308 for tsvwg-archive@odin.ietf.org; Thu, 14 Aug 2003 09:28:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nI93-0002Q0-99; Thu, 14 Aug 2003 09:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nI8v-0002Pf-2E for tsvwg@optimus.ietf.org; Thu, 14 Aug 2003 09:27: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 JAA09227 for ; Thu, 14 Aug 2003 09:27:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nI8t-0002CE-00 for tsvwg@ietf.org; Thu, 14 Aug 2003 09:27:51 -0400 Received: from frantic-dmz.weston.bsdi.com ([206.196.54.22] helo=frantic.weston.bsdi.com) by ietf-mx with esmtp (Exim 4.12) id 19nI8s-0002Bz-00 for tsvwg@ietf.org; Thu, 14 Aug 2003 09:27:50 -0400 Received: from frantic.weston.bsdi.com (localhost.BSDI.COM [127.0.0.1]) by frantic.weston.bsdi.com (8.12.5/8.12.5) with ESMTP id h7EDRDOn025914; Thu, 14 Aug 2003 08:27:14 -0500 (CDT) Received: (from dab@localhost) by frantic.weston.bsdi.com (8.12.5/8.12.5/Submit) id h7EDRDgE025913; Thu, 14 Aug 2003 08:27:13 -0500 (CDT) Date: Thu, 14 Aug 2003 08:27:13 -0500 (CDT) From: David Borman Message-Id: <200308141327.h7EDRDgE025913@frantic.weston.bsdi.com> To: end2end-interest@postel.org, tsvwg@ietf.org Subject: [Tsvwg] RFC 1323 revision Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@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, A revision to RFC 1323, TCP Extensions for High Performance, is currently being discussed on the tsvwg@ietf.org mailing list. Is this the right place for this discussion, or should it move over to end2end-interest@postel.org, the End to End mailing list? (The TCP Large Windows mailing list is no longer active.) -David Borman _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Aug 14 15:01: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 PAA22226 for ; Thu, 14 Aug 2003 15:01: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 19nNLT-0002pN-2H for tsvwg-archive@odin.ietf.org; Thu, 14 Aug 2003 15:01:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EJ1BDk010840 for tsvwg-archive@odin.ietf.org; Thu, 14 Aug 2003 15:01:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nNLK-0002o5-Ta; Thu, 14 Aug 2003 15:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nNKg-0002nH-CG for tsvwg@optimus.ietf.org; Thu, 14 Aug 2003 15:00: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 PAA22179 for ; Thu, 14 Aug 2003 15:00:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nNKd-0005Ak-00 for tsvwg@ietf.org; Thu, 14 Aug 2003 15:00:19 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 19nNKc-0005AM-00 for tsvwg@ietf.org; Thu, 14 Aug 2003 15:00:18 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 809B168A1A for ; Thu, 14 Aug 2003 14:59:47 -0400 (EDT) Received: from guns.grc.nasa.gov (guns.grc.nasa.gov [139.88.122.88]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h7EIxkrE023358; Thu, 14 Aug 2003 14:59:46 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.grc.nasa.gov (Postfix) with ESMTP id 24C723BB3CD; Thu, 14 Aug 2003 14:59:46 -0400 (EDT) To: tsvwg@ietf.org Cc: "Ethan Blanton" Cc: Reiner Ludwig 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: Get Over It Date: Thu, 14 Aug 2003 14:59:46 -0400 Message-Id: <20030814185946.24C723BB3CD@guns.grc.nasa.gov> Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Folks- Ethan and I just revised the i-d per the thread on tsvwg over the last month. The two major changes to the document are: * if the SACK scoreboard is empty when a DSACK rolls in then we say the TCP cannot revert its congestion control state because the presumption is that all the ACKs have been lost * if the TCP ertransmits something more than once then the TCP cannot revert the congestion control state because DSACKs can no longer resolve the retransmission ambiguity We have sent the new version of the i-d to the archives and so it will appear in the standard places in the next few days. It is available at: http://roland.grc.nasa.gov/~mallman/papers/draft-ietf-tsvwg-dup-notify-01.txt now. We would appreciate comments on the new version. 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 Fri Aug 15 07:47:11 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 HAA24975 for ; Fri, 15 Aug 2003 07:47: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 19nd2Z-0007Cy-Nc for tsvwg-archive@odin.ietf.org; Fri, 15 Aug 2003 07:46:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FBkhEQ027702 for tsvwg-archive@odin.ietf.org; Fri, 15 Aug 2003 07:46:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nd1s-00079Y-RK; Fri, 15 Aug 2003 07:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nd1J-00077r-34 for tsvwg@optimus.ietf.org; Fri, 15 Aug 2003 07:45: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 HAA24889 for ; Fri, 15 Aug 2003 07:45:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nd1I-00020G-00 for tsvwg@ietf.org; Fri, 15 Aug 2003 07:45:24 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19nd1H-00020D-00 for tsvwg@ietf.org; Fri, 15 Aug 2003 07:45:23 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id EA6A0328B8; Fri, 15 Aug 2003 07:45:22 -0400 (EDT) Received: from louie.udel.edu (louie.udel.edu [128.4.40.12]) by mail.eecis.udel.edu (Postfix) with ESMTP id CEF40328B8; Fri, 15 Aug 2003 07:45:14 -0400 (EDT) Date: Fri, 15 Aug 2003 07:45:13 -0400 (EDT) From: Sourabh Ladha X-X-Sender: To: Mark Allman Cc: , Ethan Blanton , Reiner Ludwig Subject: Re: [Tsvwg] Issues with draft-blanton-dsack-use-02 In-Reply-To: <20030814185946.24C723BB3CD@guns.grc.nasa.gov> 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: , Hi Mark/All, * In the draft the following is about the SACK scoreboard: "We assume the TCP sender has a data structure to hold selective acknowledgment information (e.g., as outlined in [RFC3517])." Traditionally entries lying below the cumulative ACK point are deleted from the scoreboard. But the DSACK information normally comes after loss recovery has exited. So how long should the scoreboard entries be maintained beyond what is required in 3517? (1 ACK after loss recovery exits in Fast retransmit; and N Acks after loss recovery exits in a timeout (GoBackN)?) * In the Security Considerations, ECN Nonce 3540 is offered as a protection. But 3540 calls for disabling Nonce Sum checks for DupAcks. Is the draft suggesting some extension to 3540 that NS be checked for DupAcks carrying DSACK? It may be helpful to be more explicit on the above in the ID. Thanks On Thu, 14 Aug 2003, Mark Allman wrote: > > Folks- > > Ethan and I just revised the i-d per the thread on tsvwg over the > last month. The two major changes to the document are: > > * if the SACK scoreboard is empty when a DSACK rolls in then we > say the TCP cannot revert its congestion control state because > the presumption is that all the ACKs have been lost > > * if the TCP ertransmits something more than once then the TCP > cannot revert the congestion control state because DSACKs can no > longer resolve the retransmission ambiguity > > We have sent the new version of the i-d to the archives and so it > will appear in the standard places in the next few days. It is > available at: > > http://roland.grc.nasa.gov/~mallman/papers/draft-ietf-tsvwg-dup-notify-01.txt > > now. > > We would appreciate comments on the new version. > > Thanks, > allman > > > -- > Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Aug 15 19: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 TAA17386 for ; Fri, 15 Aug 2003 19: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 19nna7-0001Nl-8i for tsvwg-archive@odin.ietf.org; Fri, 15 Aug 2003 19:02:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FN23QN005302 for tsvwg-archive@odin.ietf.org; Fri, 15 Aug 2003 19:02:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nna5-0001N0-3F; Fri, 15 Aug 2003 19: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 19nnZT-0001MC-VL for tsvwg@optimus.ietf.org; Fri, 15 Aug 2003 19:01: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 TAA17358 for ; Fri, 15 Aug 2003 19:01:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nnZQ-0006kf-00 for tsvwg@ietf.org; Fri, 15 Aug 2003 19:01:20 -0400 Received: from swordfish.cs.caltech.edu ([131.215.44.124]) by ietf-mx with esmtp (Exim 4.12) id 19nnZQ-0006kc-00 for tsvwg@ietf.org; Fri, 15 Aug 2003 19:01:20 -0400 Received: from fast2.cs.caltech.edu (fast2.cs.caltech.edu [131.215.45.55]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id 0B83CDF265 for ; Fri, 15 Aug 2003 16:01:20 -0700 (PDT) Received: from localhost (chengjin@localhost) by fast2.cs.caltech.edu (8.11.6/8.9.3) with ESMTP id h7FN1KV05379 for ; Fri, 15 Aug 2003 16:01:20 -0700 X-Authentication-Warning: fast2.cs.caltech.edu: chengjin owned process doing -bs Date: Fri, 15 Aug 2003 16:01:19 -0700 (PDT) From: Cheng Jin To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Tsvwg] delay based congestion control Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hello, everyone. We have recently submitted a paper to HOTNET on delay-based congestion control algorithms. We present a case for delay based congestion control algorithms in the absence of explicit congestion feedback. Even though the advantages of delay based algorithms are small in low-speed networks, they are decisive in high-speed networks. The paper is at: http://netlab.caltech.edu/pub/papers/hotnet2003.pdf Comments and suggestions are greatly appreciated, Cheng _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Aug 18 13:49: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 NAA27320 for ; Mon, 18 Aug 2003 13:49: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 19oo7u-0006hG-Mf for tsvwg-archive@odin.ietf.org; Mon, 18 Aug 2003 13:49:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IHn6oD025727 for tsvwg-archive@odin.ietf.org; Mon, 18 Aug 2003 13:49:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oo7p-0006gq-1z; Mon, 18 Aug 2003 13: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 19oo7D-0006gS-7N for tsvwg@optimus.ietf.org; Mon, 18 Aug 2003 13:48: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 NAA27305 for ; Mon, 18 Aug 2003 13:48:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oo7B-0001EW-00 for tsvwg@ietf.org; Mon, 18 Aug 2003 13:48:21 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 19oo7A-0001EC-00 for tsvwg@ietf.org; Mon, 18 Aug 2003 13:48:20 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 5C7336897C for ; Mon, 18 Aug 2003 13:47:50 -0400 (EDT) Received: from guns.grc.nasa.gov (guns.grc.nasa.gov [139.88.122.88]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h7IHlnvj029809; Mon, 18 Aug 2003 13:47:49 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.grc.nasa.gov (Postfix) with ESMTP id 99FFC3BB3F8; Mon, 18 Aug 2003 13:47:48 -0400 (EDT) To: tsvwg@ietf.org, "Ethan Blanton" , Reiner Ludwig From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Re: [Tsvwg] Issues with draft-blanton-dsack-use-02 Organization: BBN Technologies/NASA GRC Song-of-the-Day: Imagine Date: Mon, 18 Aug 2003 13:47:48 -0400 Message-Id: <20030818174748.99FFC3BB3F8@guns.grc.nasa.gov> Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > Ethan and I just revised the i-d per the thread on tsvwg over the > last month. The two major changes to the document are: > > * if the SACK scoreboard is empty when a DSACK rolls in then we > say the TCP cannot revert its congestion control state because > the presumption is that all the ACKs have been lost > > * if the TCP ertransmits something more than once then the TCP > cannot revert the congestion control state because DSACKs can no > longer resolve the retransmission ambiguity > > We have sent the new version of the i-d to the archives and so it > will appear in the standard places in the next few days. It is > available at: > > [BUSTED URL] > > now. Folks- I misnamed the i-d for some reason. In any case, the name of the I-D in question is "draft-ietf-tsvwg-dsack-use-01.txt". It should pop up in the archives soon. You can also slurp a copy from: http://roland.grc.nasa.gov/~mallman/papers/draft-ietf-tsvwg-dsack-use-01.txt Sorry for the confusion, 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 Aug 19 08: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 IAA07558 for ; Tue, 19 Aug 2003 08: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 19p5nN-00036J-8X for tsvwg-archive@odin.ietf.org; Tue, 19 Aug 2003 08:41:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JCf5gw011915 for tsvwg-archive@odin.ietf.org; Tue, 19 Aug 2003 08: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 19p5nK-000360-7e; Tue, 19 Aug 2003 08: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 19p5mQ-00035R-AJ for tsvwg@optimus.ietf.org; Tue, 19 Aug 2003 08:40:06 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07499; Tue, 19 Aug 2003 08:40:01 -0400 (EDT) Message-Id: <200308191240.IAA07499@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: tsvwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 19 Aug 2003 08:40:01 -0400 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-dsack-use-01.txt Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions Author(s) : E. Blanton, M. Allman Filename : draft-ietf-tsvwg-dsack-use-01.txt Pages : 7 Date : 2003-8-18 TCP and SCTP provide notification of duplicate segment receipt through DSACK and Duplicate TSN notification, respectively. This document presents a conservative method of using this information to identify unnecessary retransmissions for various applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-dsack-use-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-dsack-use-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-dsack-use-01.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-8-18144441.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-dsack-use-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-dsack-use-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-18144441.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 Aug 19 09: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 JAA08767 for ; Tue, 19 Aug 2003 09:05: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 19p6Aa-0003on-4A for tsvwg-archive@odin.ietf.org; Tue, 19 Aug 2003 09:05:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JD54aK014678 for tsvwg-archive@odin.ietf.org; Tue, 19 Aug 2003 09: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 19p6AX-0003nq-JB; Tue, 19 Aug 2003 09: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 19p69h-0003nJ-So for tsvwg@optimus.ietf.org; Tue, 19 Aug 2003 09:04: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 JAA08703 for ; Tue, 19 Aug 2003 09:04:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p69g-0007gG-00 for tsvwg@ietf.org; Tue, 19 Aug 2003 09:04:08 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19p69f-0007fz-00 for tsvwg@ietf.org; Tue, 19 Aug 2003 09:04:07 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 4F401206607 for ; Tue, 19 Aug 2003 09:02:23 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19p5oL-0006yo-2I for ietf-announce-list@asgard.ietf.org; Tue, 19 Aug 2003 08:42:05 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19p5mP-0006wr-Hz for all-ietf@asgard.ietf.org; Tue, 19 Aug 2003 08:40:05 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07499; Tue, 19 Aug 2003 08:40:01 -0400 (EDT) Message-Id: <200308191240.IAA07499@ietf.org> To: IETF-Announce: ; Cc: tsvwg@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Tue, 19 Aug 2003 08:40:01 -0400 Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+76656_1959319276609_649392927477" Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-dsack-use-01.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: , --MIMEStream=_0+76656_1959319276609_649392927477 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions Author(s) : E. Blanton, M. Allman Filename : draft-ietf-tsvwg-dsack-use-01.txt Pages : 7 Date : 2003-8-18 TCP and SCTP provide notification of duplicate segment receipt through DSACK and Duplicate TSN notification, respectively. This document presents a conservative method of using this information to identify unnecessary retransmissions for various applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-dsack-use-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-dsack-use-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-dsack-use-01.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. --MIMEStream=_0+76656_1959319276609_649392927477 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+203187_9014761693095_33599006398" --MIMEStream=_1+203187_9014761693095_33599006398 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-18144441.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-dsack-use-01.txt --MIMEStream=_1+203187_9014761693095_33599006398 Content-Type: Message/External-body; name="draft-ietf-tsvwg-dsack-use-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-18144441.I-D@ietf.org> --MIMEStream=_1+203187_9014761693095_33599006398-- --MIMEStream=_0+76656_1959319276609_649392927477-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Aug 19 14:18: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 OAA27635 for ; Tue, 19 Aug 2003 14:18: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 19pB3V-0002Ab-OO for tsvwg-archive@odin.ietf.org; Tue, 19 Aug 2003 14:18:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JII5GC008314 for tsvwg-archive@odin.ietf.org; Tue, 19 Aug 2003 14:18:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pB3R-000299-D8; Tue, 19 Aug 2003 14: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 19pB2X-00022T-Am for tsvwg@optimus.ietf.org; Tue, 19 Aug 2003 14:17: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 OAA27586 for ; Tue, 19 Aug 2003 14:17:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pB2U-0004wy-00 for tsvwg@ietf.org; Tue, 19 Aug 2003 14:17:02 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by ietf-mx with esmtp (Exim 4.12) id 19pB2T-0004wU-00 for tsvwg@ietf.org; Tue, 19 Aug 2003 14:17:01 -0400 Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by cypress.neustar.com (8.11.6/8.11.6) with ESMTP id h7JIGDG11664; Tue, 19 Aug 2003 18:16:14 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Aug 2003 14:16:14 -0400 Message-ID: From: "Peterson, Jon" To: "'David Borman'" , end2end-interest@postel.org, tsvwg@ietf.org Subject: RE: [Tsvwg] RFC 1323 revision Date: Tue, 19 Aug 2003 14:16:26 -0400 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: , I believe that the TSVWG is a reasonable place to discuss this work (at least until the long-expected TCP WG is formed), and that an IETF WG mailing list is the right place to manage documents that aspire to become standards-track RFCs. Of course, pursuing this document in the TSVWG would not preclude analysis on the venerable e2e list, which of course harbors numerous non-overlapping experts who could provide valuable input on this work. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: David Borman [mailto:dab@BSDI.COM] > Sent: Thursday, August 14, 2003 6:27 AM > To: end2end-interest@postel.org; tsvwg@ietf.org > Subject: [Tsvwg] RFC 1323 revision > > > Hi, > > A revision to RFC 1323, TCP Extensions for High Performance, is > currently being discussed on the tsvwg@ietf.org mailing list. > Is this the right place for this discussion, or should it move > over to end2end-interest@postel.org, the End to End mailing list? > (The TCP Large Windows mailing list is no longer active.) > > -David Borman > > _______________________________________________ > 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 Aug 22 10:02: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 KAA25064 for ; Fri, 22 Aug 2003 10:02: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 19qCUQ-0003dM-6A for tsvwg-archive@odin.ietf.org; Fri, 22 Aug 2003 10:02:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7ME26gN013964 for tsvwg-archive@odin.ietf.org; Fri, 22 Aug 2003 10:02:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qCUM-0003cK-R3; Fri, 22 Aug 2003 10:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qCU5-0003bD-7H for tsvwg@optimus.ietf.org; Fri, 22 Aug 2003 10:01:45 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24898; Fri, 22 Aug 2003 10:01:38 -0400 (EDT) Message-Id: <200308221401.KAA24898@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, 22 Aug 2003 10:01:38 -0400 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-prsctp-01.txt Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : SCTP Partial Reliability Extension Author(s) : R. Stewart et al. Filename : draft-ietf-tsvwg-prsctp-01.txt Pages : 27 Date : 2003-8-22 This memo describes an extension to the Stream Control Transmission Protocol (SCTP) RFC2960 [5] that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes (1) the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type (2) one example partially reliable service that can be provided to the upper layer via this mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-prsctp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-prsctp-01.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-8-22090115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-prsctp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-prsctp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-22090115.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 Aug 22 12: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 MAA05693 for ; Fri, 22 Aug 2003 12: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 19qElg-00031N-5D for tsvwg-archive@odin.ietf.org; Fri, 22 Aug 2003 12:28:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MGS46T011607 for tsvwg-archive@odin.ietf.org; Fri, 22 Aug 2003 12: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 19qEld-00030R-5L; Fri, 22 Aug 2003 12:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qElU-000306-Rg for tsvwg@optimus.ietf.org; Fri, 22 Aug 2003 12:27: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 MAA05681 for ; Fri, 22 Aug 2003 12:27:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qElT-0006fa-00 for tsvwg@ietf.org; Fri, 22 Aug 2003 12:27:51 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 19qElS-0006fS-00 for tsvwg@ietf.org; Fri, 22 Aug 2003 12:27:50 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 7BD6B68A13 for ; Fri, 22 Aug 2003 12:27:20 -0400 (EDT) Received: from guns.grc.nasa.gov (guns.grc.nasa.gov [139.88.122.88]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h7MGRKld016289 for ; Fri, 22 Aug 2003 12:27:20 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.grc.nasa.gov (Postfix) with ESMTP id E2F0B3BB3F8 for ; Fri, 22 Aug 2003 12:27:19 -0400 (EDT) To: tsvwg@ietf.org From: Mark Allman Reply-To: mallman@grc.nasa.gov Organization: BBN Technologies/NASA GRC Song-of-the-Day: Ticket to Ride Date: Fri, 22 Aug 2003 12:27:19 -0400 Message-Id: <20030822162719.E2F0B3BB3F8@guns.grc.nasa.gov> Subject: [Tsvwg] new revision of early retransmit available Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Folks- We have just sent a new version of the Early Retransmit internet draft to the secratariet. It should appear in the archives in a couple of days. It is available from: http://roland.grc.nasa.gov/~mallman/papers/draft-allman-tcp-early-rexmt-02.txt now. The largest change in the document is that it now includes a variant that uses SACK information to make ER more robust. The problem that we have found is that the instances where ER will help are windowed quite a bit when it just counts duplicate ACKs. First consider two states the reciever could be in.... * S1: the receiver has ACKed all data received * S2: the receiver has received a packet but is delaying its ACK for another arrival (or the timer) When the receiver is in S1 and an out-of-order segment arrives a dup ACK will be triggered and ER will work nicely (or, as nicely as possible). When the receiver is in S2 and an out-of-order segment arrives the receiver will send an immediate ACK, but it will not be a duplicate -- but, rather it will cover previously unACKed data. In this case, ER is not in a happy place because it expects a duplicate ACK from all but one of the segments outstanding. So, we (meaning Josh, really) figured out that if we leveraged SACK information we could just tell when all but one packet has arrived at the receiver and key on that for ER, rather than try to count duplicate ACKs. (Because even if the ACK for out-of-order data is cumulatively ACKs previously unACKed data (i.e., is not a dup ACK) it will still have SACK information indicating what packet triggered the ACK.) This scheme seems more robust. At the moment both schemes are in the draft. But, we are seriously considering ripping out the version that does not use SACK on the grounds that if you're not using SACK and you are interested in good loss recovery in 2003 then you really can't be all that interested. (Recent measurements: I am seeing > 90% of web clients support SACK at a web server I am watching. I ran tbit against 61,000+ web servers and 65% support SACK.) We'd be interested in getting feedback on any of the above issues (and the text of the draft itself, of course). Thanks! allman _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sun Aug 24 05:46: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 FAA29611 for ; Sun, 24 Aug 2003 05:46: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 19qrRo-0003U9-U8 for tsvwg-archive@odin.ietf.org; Sun, 24 Aug 2003 05:46:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7O9k820013398 for tsvwg-archive@odin.ietf.org; Sun, 24 Aug 2003 05:46:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qrRh-0003To-SJ; Sun, 24 Aug 2003 05: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 19qrRb-0003TW-QN for tsvwg@optimus.ietf.org; Sun, 24 Aug 2003 05:45: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 FAA29585 for ; Sun, 24 Aug 2003 05:45:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qrRY-0004P9-00 for tsvwg@ietf.org; Sun, 24 Aug 2003 05:45:52 -0400 Received: from cs180094.pp.htv.fi ([213.243.180.94] helo=hades.pp.htv.fi) by ietf-mx with esmtp (Exim 4.12) id 19qrRX-0004P5-00 for tsvwg@ietf.org; Sun, 24 Aug 2003 05:45:51 -0400 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h7O9a5lA012134; Sun, 24 Aug 2003 12:36:05 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h7O9a3f9012133; Sun, 24 Aug 2003 12:36:03 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [Tsvwg] new revision of early retransmit available From: Mika Liljeberg To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org In-Reply-To: <20030822162719.E2F0B3BB3F8@guns.grc.nasa.gov> References: <20030822162719.E2F0B3BB3F8@guns.grc.nasa.gov> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1061717763.723.32.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 24 Aug 2003 12:36:03 +0300 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, The SACK variant looks a lot more robust compared to the ack counting variant. I would feel fairly confident in putting this into an implementation. I tend to agree that today there's really no excuse to not do SACK if one is at all interested in performance, so I think a SACK only variant would be fine. One suggestion for improvement, though. Standard Nagle will prevent any smaller than MSS sized segment of new data from being sent unless all the preceding segments have been acked first. This means that limited transmit typically cannot be applied with the last segment of a data burst and, in particular, at the end of the connection. The draft discusses the problems observed with limited transmit and a small congestion window but doesn't mention the interaction with Nagle anywhere. I would be good to give some attention to this as well. Early retransmit can help in both cases. MikaL On Fri, 2003-08-22 at 19:27, Mark Allman wrote: > Folks- > > We have just sent a new version of the Early Retransmit internet > draft to the secratariet. It should appear in the archives in a > couple of days. It is available from: > > http://roland.grc.nasa.gov/~mallman/papers/draft-allman-tcp-early-rexmt-02.txt > > now. > > The largest change in the document is that it now includes a variant > that uses SACK information to make ER more robust. The problem that > we have found is that the instances where ER will help are windowed > quite a bit when it just counts duplicate ACKs. > > First consider two states the reciever could be in.... > > * S1: the receiver has ACKed all data received > * S2: the receiver has received a packet but is delaying its ACK > for another arrival (or the timer) > > When the receiver is in S1 and an out-of-order segment arrives a dup > ACK will be triggered and ER will work nicely (or, as nicely as > possible). > > When the receiver is in S2 and an out-of-order segment arrives the > receiver will send an immediate ACK, but it will not be a duplicate > -- but, rather it will cover previously unACKed data. In this case, > ER is not in a happy place because it expects a duplicate ACK from > all but one of the segments outstanding. > > So, we (meaning Josh, really) figured out that if we leveraged SACK > information we could just tell when all but one packet has arrived > at the receiver and key on that for ER, rather than try to count > duplicate ACKs. (Because even if the ACK for out-of-order data is > cumulatively ACKs previously unACKed data (i.e., is not a dup ACK) > it will still have SACK information indicating what packet triggered > the ACK.) This scheme seems more robust. > > At the moment both schemes are in the draft. But, we are seriously > considering ripping out the version that does not use SACK on the > grounds that if you're not using SACK and you are interested in good > loss recovery in 2003 then you really can't be all that interested. > (Recent measurements: I am seeing > 90% of web clients support SACK > at a web server I am watching. I ran tbit against 61,000+ web > servers and 65% support SACK.) > > We'd be interested in getting feedback on any of the above issues > (and the text of the draft itself, of course). > > Thanks! > > allman > > _______________________________________________ > 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 Aug 25 08:13: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 IAA12556 for ; Mon, 25 Aug 2003 08:13: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 19rGDd-0004aC-Vf for tsvwg-archive@odin.ietf.org; Mon, 25 Aug 2003 08:13:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PCD9Uk017613 for tsvwg-archive@odin.ietf.org; Mon, 25 Aug 2003 08:13:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rGDV-0004ZJ-4e; Mon, 25 Aug 2003 08:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rGD1-0004Yh-GJ for tsvwg@optimus.ietf.org; Mon, 25 Aug 2003 08:12: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 IAA12522 for ; Mon, 25 Aug 2003 08:12:26 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rGD0-00003X-00 for tsvwg@ietf.org; Mon, 25 Aug 2003 08:12:30 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19rGCy-00003Q-00 for tsvwg@ietf.org; Mon, 25 Aug 2003 08:12:29 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7PCBnB08526 for ; Mon, 25 Aug 2003 15:12:15 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Aug 2003 15:11:48 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 25 Aug 2003 15:11:48 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 25 Aug 2003 15:10:49 +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 Date: Mon, 25 Aug 2003 15:10:44 +0300 Message-ID: Thread-Topic: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) Thread-Index: AcNohTUkGOb9yuZ2RfO6L0+ECsgW+wCfAQLA To: , Cc: , , X-OriginalArrivalTime: 25 Aug 2003 12:10:49.0584 (UTC) FILETIME=[EC0BC700:01C36B01] Content-Transfer-Encoding: quoted-printable Subject: [Tsvwg] RE: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@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 Gentlemen, This is a good document, I am glad to see this kind of document being worked on. I understand that this must have been a huge undertaking, but I have some very quick requests. Could you improve the ToC, for example, listing the RFCs as subsections? Also, the formatting of the document is confusing - I believe that all paragraph text should be indented - which it is not; however text copied from existing RFCs should probably be doubly indented (it is currently indented a single time, for example in 3.3.1) I hope this is not overly nit-picky, but my first attempt at=20 reading this document was not successful as the current formatting got in the way of understanding what is being discussed. thanks, John > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > Sent: 22 August, 2003 11:09 > To: tsvwg@ietf.org > Cc: bob@thefinks.com; Soininen Jonne (NET/Helsinki); > andreas.bergstrom@hiof.no > Subject: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents > (fwd) >=20 >=20 > FYI; >=20 > Your oxen are being gutted and you're invited to the bloodfest. >=20 > In other words.. >=20 > Feedback & Review is sought. Please take a look at the=20 > transport IPv4=20 > survey document: > =20 > =20 > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4surve > y-trans-01.txt >=20 > It's not too long; please send feedback. In particular, it=20 > would be good > to identify specifications which have incorrect information, or > specifications which are not longer relevant and could be moved to > historic (if someone bothered to do that, but that's a=20 > different topic), > or the like. >=20 > Thanks, > Pekka, Jonne & Bob > v6ops co-chairs >=20 > ---------- Forwarded message ---------- > Date: Fri, 22 Aug 2003 10:38:49 +0300 (EEST) > From: Pekka Savola > To: v6ops@ops.ietf.org > Cc: bob@thefinks.com, jonne.soininen@nokia.com,=20 > cesar.olvera@consulintel.es, > andreas.bergstrom@hiof.no > Subject: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents >=20 > Hi all, >=20 > This is a WG Last Call for comments on sending the following the next > three "Survey of IPv4 Addresses in Currently Deployed IETF Standards" > documents to the IESG for consideration as Informational RFCs: >=20 > Survey of IPv4 Addresses in Currently Deployed IETF Routing=20 > Area Standards > =20 http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-0= 1.txt Survey of IPv4 Addresses in Currently Deployed IETF Security Area = Standards = http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-01.tx= t Survey of IPv4 Addresses in Currently Deployed IETF Transport Area=20 Standards =20 http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-01.= txt Please review these documents carefully, and send your feedback to the list (editorial modifications may also be sent to the editors, Cesar for the first, Andreas for the other two). Please also indicate whether or not you believe that this document is ready to go to the IESG. Silence does NOT indicate consent. Unless sufficient support is demonstrated on the list, the documents will not be send to the IESG. The last call will end in 3 weeks, on 12th September. Pekka, Jonne & Bob _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Aug 25 08:42: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 IAA13609 for ; Mon, 25 Aug 2003 08:42: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 19rGfa-0005gh-Iz for tsvwg-archive@odin.ietf.org; Mon, 25 Aug 2003 08:42:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PCg2UR021838 for tsvwg-archive@odin.ietf.org; Mon, 25 Aug 2003 08:42:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rGfY-0005fI-TO; Mon, 25 Aug 2003 08: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 19rGfA-0005en-CI for tsvwg@optimus.ietf.org; Mon, 25 Aug 2003 08:41: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 IAA13571 for ; Mon, 25 Aug 2003 08:41:30 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rGf9-0000K2-00 for tsvwg@ietf.org; Mon, 25 Aug 2003 08:41:35 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19rGf7-0000Jz-00 for tsvwg@ietf.org; Mon, 25 Aug 2003 08:41:34 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7PCfSB08596 for ; Mon, 25 Aug 2003 15:41:32 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Aug 2003 15:41:28 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 25 Aug 2003 15:41:27 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 25 Aug 2003 15:41:27 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 25 Aug 2003 15:41:26 +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 Date: Mon, 25 Aug 2003 15:41:26 +0300 Message-ID: Thread-Topic: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) Thread-Index: AcNohTUkGOb9yuZ2RfO6L0+ECsgW+wCfUlqg To: , Cc: , , X-OriginalArrivalTime: 25 Aug 2003 12:41:26.0917 (UTC) FILETIME=[332E8B50:01C36B06] Content-Transfer-Encoding: quoted-printable Subject: [Tsvwg] RE: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@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, Further comments: Section 4 doesn't contain any Draft Standards ... I assume this is an = oversite. In section 5, it might be better not to list the specs that have no IPv4 = dependencies, or better yet, move them all to an appendix and list them in tabular = format. References are a little sparse, too - you may want to consider putting = all RFCs listed into the References as well. thanks, John _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Aug 25 10:18: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 KAA20230 for ; Mon, 25 Aug 2003 10:18: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 19rIAp-0000xL-8C for tsvwg-archive@odin.ietf.org; Mon, 25 Aug 2003 10:18:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PEIMVu003652 for tsvwg-archive@odin.ietf.org; Mon, 25 Aug 2003 10:18:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rIAj-0000w2-RW; Mon, 25 Aug 2003 10:18:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rIA1-0000uY-CA for tsvwg@optimus.ietf.org; Mon, 25 Aug 2003 10:17: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 KAA20141 for ; Mon, 25 Aug 2003 10:17:26 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rI9z-0001cu-00 for tsvwg@ietf.org; Mon, 25 Aug 2003 10:17:31 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19rI9y-0001cr-00 for tsvwg@ietf.org; Mon, 25 Aug 2003 10:17:30 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7PEHSB11775 for ; Mon, 25 Aug 2003 17:17:29 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Aug 2003 17:17:28 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 25 Aug 2003 17:17:28 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 25 Aug 2003 17:17:27 +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 Date: Mon, 25 Aug 2003 17:17:27 +0300 Message-ID: Thread-Topic: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) Thread-Index: AcNrDw3W9uJtP1h4SY+z+0KPfK0MZwABBu6A To: Cc: , , , X-OriginalArrivalTime: 25 Aug 2003 14:17:27.0876 (UTC) FILETIME=[9CFB2040:01C36B13] Content-Transfer-Encoding: quoted-printable Subject: [Tsvwg] transport doc RE: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@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 Pekka, > > Could you improve > > the ToC, for example, listing the RFCs as subsections? =20 >=20 > ToC could get quite long, compare to ...-ipv4survey-apps-01. It may = not=20 > necessarily make it clearer (IMHO). It also may be more difficult to=20 > generate a "full ToC", depends on the tools used. OK - I was just looking for an easier way to find particular RFCs / protocols, as most readers won't be experts on all of the RFCs included. =20 > Personally I don't have a strong opinion either way. >=20 > > Also, > > the formatting of the document is confusing - I believe that > > all paragraph text should be indented - which it is not;=20 >=20 > Agreed, I don't know how difficult this would be given the methods = used to=20 > edit the documents. See my above comment. =20 > > however > > text copied from existing RFCs should probably be doubly indented > > (it is currently indented a single time, for example in 3.3.1) >=20 > I agree but this could cause problems, if the double-intending would = push=20 > the length beyond 72 characters, there could be problems.. Reformatting might be OK, depending upon the tools used - again, just looking for a way to improve readability. > > I hope this is not overly nit-picky, but my first attempt at=20 > > reading this document was not successful as the current formatting > > got in the way of understanding what is being discussed. >=20 > Yep. >=20 > > Section 4 doesn't contain any Draft Standards ... I assume=20 > this is an > > oversite. >=20 > Maybe Andreas forgot to add the sentence saying that there are no = Draft=20 > Standards here (or if there actually are, those are missing = somewhere). OK > > In section 5, it might be better not to list the specs that have no = IPv4 > > dependencies, or better yet, move them all to an appendix and list = them > > in tabular format. >=20 > We're trying to list these documents under section 7. Hopefully this = is=20 > clear enough, as we'd hope to avoid restructuring Phil's legacy too=20 > much..? OK, just a suggestion to improve readability. =20 > > References are a little sparse, too - you may want to=20 > consider putting > > all RFCs listed into the References as well. >=20 > I disagree, but not strongly; IMHO, it should be apparent that the=20 > specific RFC's are all "unofficial" RFC's .. the list in the end would = > just get very, very long for not significant benefit (one that I could = see=20 > anyway). That is fine will me. I'll try to read the document tomorrow for technical comments. John _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Aug 26 15:40:41 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 PAA00297 for ; Tue, 26 Aug 2003 15:40:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjfq-0002IC-CK for tsvwg-archive@odin.ietf.org; Tue, 26 Aug 2003 15:40:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QJeCKL008764 for tsvwg-archive@odin.ietf.org; Tue, 26 Aug 2003 15:40:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjfS-0002DQ-Jg; Tue, 26 Aug 2003 15:39:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rT5I-0008HY-HM for tsvwg@optimus.ietf.org; Mon, 25 Aug 2003 21:57: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 VAA27301 for ; Mon, 25 Aug 2003 21:57:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rT5F-0002HS-00 for tsvwg@ietf.org; Mon, 25 Aug 2003 21:57:21 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19rT5E-0002HE-00 for tsvwg@ietf.org; Mon, 25 Aug 2003 21:57:21 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 25 Aug 2003 19:06:29 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7Q1un7b011433; Mon, 25 Aug 2003 18:56:49 -0700 (PDT) Received: from cisco.com (mbashyam-u10.cisco.com [10.34.36.39]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKT91916; Mon, 25 Aug 2003 18:48:00 -0700 (PDT) Message-ID: <3F4ABE60.B4D3572E@cisco.com> Date: Mon, 25 Aug 2003 18:56:48 -0700 From: Murali Bashyam Organization: Cisco Systems Inc X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] overlapping TCP segments during reassembly Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Is there any guidelines outlined by any TCP RFC's for determining what data in the sequence space to keep and what to drop during TCP out of order packet reassembly when there are overlaps? The BSD code tries to trim the incoming segment when there is an overlap with a previous segment in sequence space, and trims the already queued segments when there is an overlap with succeeding segments in sequence space. I was curious abt the motivation behind this strategy. Murali _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Aug 26 18:37: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 SAA17302 for ; Tue, 26 Aug 2003 18:37:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmIA-0003KU-QP for tsvwg-archive@odin.ietf.org; Tue, 26 Aug 2003 18:28:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QMRwr8012757 for tsvwg-archive@odin.ietf.org; Tue, 26 Aug 2003 18:27:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rlwh-0002UV-0B; Tue, 26 Aug 2003 18:05:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rHeq-0007up-Qi for tsvwg@optimus.ietf.org; Mon, 25 Aug 2003 09:45: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 JAA17367 for ; Mon, 25 Aug 2003 09:45:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rHeo-0001EP-00 for tsvwg@ietf.org; Mon, 25 Aug 2003 09:45:18 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19rHen-0001Dz-00 for tsvwg@ietf.org; Mon, 25 Aug 2003 09:45:18 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7PDihq14809; Mon, 25 Aug 2003 16:44:43 +0300 Date: Mon, 25 Aug 2003 16:44:43 +0300 (EEST) From: Pekka Savola To: john.loughney@nokia.com cc: tsvwg@ietf.org, , , In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Tsvwg] RE: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Thanks for review.. (the document in question is the Transport Area document). I'm responding to the both emails here. On Mon, 25 Aug 2003 john.loughney@nokia.com wrote: > This is a good document, I am glad to see this kind of document > being worked on. I understand that this must have been a huge > undertaking, but I have some very quick requests. Ok.. > Could you improve > the ToC, for example, listing the RFCs as subsections? ToC could get quite long, compare to ...-ipv4survey-apps-01. It may not necessarily make it clearer (IMHO). It also may be more difficult to generate a "full ToC", depends on the tools used. Personally I don't have a strong opinion either way. > Also, > the formatting of the document is confusing - I believe that > all paragraph text should be indented - which it is not; Agreed, I don't know how difficult this would be given the methods used to edit the documents. > however > text copied from existing RFCs should probably be doubly indented > (it is currently indented a single time, for example in 3.3.1) I agree but this could cause problems, if the double-intending would push the length beyond 72 characters, there could be problems.. > I hope this is not overly nit-picky, but my first attempt at > reading this document was not successful as the current formatting > got in the way of understanding what is being discussed. Yep. > Section 4 doesn't contain any Draft Standards ... I assume this is an > oversite. Maybe Andreas forgot to add the sentence saying that there are no Draft Standards here (or if there actually are, those are missing somewhere). > In section 5, it might be better not to list the specs that have no IPv4 > dependencies, or better yet, move them all to an appendix and list them > in tabular format. We're trying to list these documents under section 7. Hopefully this is clear enough, as we'd hope to avoid restructuring Phil's legacy too much..? > References are a little sparse, too - you may want to consider putting > all RFCs listed into the References as well. I disagree, but not strongly; IMHO, it should be apparent that the specific RFC's are all "unofficial" RFC's .. the list in the end would just get very, very long for not significant benefit (one that I could see anyway). Thoughts? > > -----Original Message----- > > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: 22 August, 2003 11:09 > > To: tsvwg@ietf.org > > Cc: bob@thefinks.com; Soininen Jonne (NET/Helsinki); > > andreas.bergstrom@hiof.no > > Subject: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents > > (fwd) > > > > > > FYI; > > > > Your oxen are being gutted and you're invited to the bloodfest. > > > > In other words.. > > > > Feedback & Review is sought. Please take a look at the > > transport IPv4 > > survey document: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4surve > > y-trans-01.txt > > > > It's not too long; please send feedback. In particular, it > > would be good > > to identify specifications which have incorrect information, or > > specifications which are not longer relevant and could be moved to > > historic (if someone bothered to do that, but that's a > > different topic), > > or the like. > > > > Thanks, > > Pekka, Jonne & Bob > > v6ops co-chairs > > > > ---------- Forwarded message ---------- > > Date: Fri, 22 Aug 2003 10:38:49 +0300 (EEST) > > From: Pekka Savola > > To: v6ops@ops.ietf.org > > Cc: bob@thefinks.com, jonne.soininen@nokia.com, > > cesar.olvera@consulintel.es, > > andreas.bergstrom@hiof.no > > Subject: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents > > > > Hi all, > > > > This is a WG Last Call for comments on sending the following the next > > three "Survey of IPv4 Addresses in Currently Deployed IETF Standards" > > documents to the IESG for consideration as Informational RFCs: > > > > Survey of IPv4 Addresses in Currently Deployed IETF Routing > > Area Standards > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-01.txt > > Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-01.txt > > Survey of IPv4 Addresses in Currently Deployed IETF Transport Area > Standards > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-01.txt > > Please review these documents carefully, and send your feedback to the > list (editorial modifications may also be sent to the editors, Cesar for > the first, Andreas for the other two). Please also indicate whether or > not you believe that this document is ready to go to the IESG. Silence > does NOT indicate consent. Unless sufficient support is demonstrated on > the list, the documents will not be send to the IESG. > > The last call will end in 3 weeks, on 12th September. > > Pekka, Jonne & Bob > > > > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Aug 27 00:42: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 AAA19777 for ; Wed, 27 Aug 2003 00:42: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 19rnoA-0008Ho-FP for tsvwg-archive@odin.ietf.org; Tue, 26 Aug 2003 20:05:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R056Y7031811 for tsvwg-archive@odin.ietf.org; Tue, 26 Aug 2003 20:05:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmPh-0003cU-FY; Tue, 26 Aug 2003 18:35:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rlSu-00016w-VH for tsvwg@optimus.ietf.org; Tue, 26 Aug 2003 17:35:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11821 for ; Tue, 26 Aug 2003 17:34:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rlSs-0002ZF-00 for tsvwg@ietf.org; Tue, 26 Aug 2003 17:34:58 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19rlSr-0002Z8-00 for tsvwg@ietf.org; Tue, 26 Aug 2003 17:34:57 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h7QLYte3074649; Tue, 26 Aug 2003 14:34:55 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200308262134.h7QLYte3074649@cougar.icir.org> To: john.loughney@nokia.com cc: tsvwg@ietf.org From: Sally Floyd Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-highspeed-00 Date: Tue, 26 Aug 2003 14:34:55 -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: , Since the two-week working group last call for this ended yesterday, and I haven't seen any comments on the mailing list, I will submit the revised draft of draft-ietf-tsvwg-highspeed-00 with the changes that were already agreed-upon (appended below), and draft-ietf-tsvwg-highspeed and draft-ietf-tsvwg-slowstart should then be ready to be forwarded to the IESG for IESG Last Call. Thanks, - Sally http://www.icir.org/floyd/ ------------------------------------------------------------------- The web page at "http://www.icir.org/floyd/hstcp/draft-ietf-tsvwg-highspeed-00.errata" contains the changes that have already been agreed upon, that I am going to submit now: 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 Wed Aug 27 00:51: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 AAA20817 for ; Wed, 27 Aug 2003 00:51: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 19rmgo-0004pD-A7 for tsvwg-archive@odin.ietf.org; Tue, 26 Aug 2003 18:53:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QMrQCj018521 for tsvwg-archive@odin.ietf.org; Tue, 26 Aug 2003 18:53:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmPI-0003a2-E7; Tue, 26 Aug 2003 18:35:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rlcu-0001ZP-Pc for tsvwg@optimus.ietf.org; Tue, 26 Aug 2003 17:45: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 RAA12398 for ; Tue, 26 Aug 2003 17:45:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rlcs-0002iT-00 for tsvwg@ietf.org; Tue, 26 Aug 2003 17:45:18 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19rlcr-0002hC-00 for tsvwg@ietf.org; Tue, 26 Aug 2003 17:45:17 -0400 Received: from asomi.com (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id A8FED246324; Tue, 26 Aug 2003 17:45:00 -0400 (EDT) Date: Tue, 26 Aug 2003 16:44:17 -0500 Subject: Re: [Tsvwg] overlapping TCP segments during reassembly Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: tsvwg@ietf.org To: Murali Bashyam From: Caitlin Bestler In-Reply-To: <3F4ABE60.B4D3572E@cisco.com> Message-Id: <71756FCA-D80E-11D7-B171-003065D48EE0@asomi.com> 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 On Monday, August 25, 2003, at 08:56 PM, Murali Bashyam wrote: > Hi > > Is there any guidelines outlined by any TCP RFC's for determining what > data in the sequence space to keep and what to drop during TCP out of > order packet reassembly when there are overlaps? The BSD code tries to > trim the incoming segment when there is an overlap with a previous > segment in sequence space, and trims the already queued segments when > there is an overlap with succeeding segments in sequence space. I was > curious abt the motivation behind this strategy. > > Murali > Certain things are implied: 1) overlaps indicate retransmissions. 2) multiple valid segments must all have the same value for any given byte in the TCP stream, i.e. the retransmit can only correct transmission errors it cannot "fix" the data. 3) you can only deliver a given byte to the TCP consumer once. So, if you have a buffered but undelivered sequence, should you replace it with new content? Well, since you know the values are the same, why not optimize the copy by simply not performing it? 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 Wed Aug 27 00:55: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 AAA21215 for ; Wed, 27 Aug 2003 00:55: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 19rmkM-00050G-58 for tsvwg-archive@odin.ietf.org; Tue, 26 Aug 2003 18:57:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QMv6ap019197 for tsvwg-archive@odin.ietf.org; Tue, 26 Aug 2003 18:57:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rlzk-00030B-Lv; Tue, 26 Aug 2003 18:08:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rkcD-0007NJ-0T for tsvwg@optimus.ietf.org; Tue, 26 Aug 2003 16:40: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 QAA07616 for ; Tue, 26 Aug 2003 16:40:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rkcB-0001FI-00 for tsvwg@ietf.org; Tue, 26 Aug 2003 16:40:31 -0400 Received: from frantic-dmz.weston.bsdi.com ([206.196.54.22] helo=frantic.weston.bsdi.com) by ietf-mx with esmtp (Exim 4.12) id 19rkcA-0001Ea-00 for tsvwg@ietf.org; Tue, 26 Aug 2003 16:40:30 -0400 Received: from frantic.weston.bsdi.com (localhost.BSDI.COM [127.0.0.1]) by frantic.weston.bsdi.com (8.12.5/8.12.5) with ESMTP id h7QKdfAl019626; Tue, 26 Aug 2003 15:39:41 -0500 (CDT) Received: (from dab@localhost) by frantic.weston.bsdi.com (8.12.5/8.12.5/Submit) id h7QKdePe019625; Tue, 26 Aug 2003 15:39:40 -0500 (CDT) Date: Tue, 26 Aug 2003 15:39:40 -0500 (CDT) From: David Borman Message-Id: <200308262039.h7QKdePe019625@frantic.weston.bsdi.com> To: mbashyam@cisco.com, tsvwg@ietf.org Subject: Re: [Tsvwg] overlapping TCP segments during reassembly Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > Date: Mon, 25 Aug 2003 18:56:48 -0700 > From: Murali Bashyam > Subject: [Tsvwg] overlapping TCP segments during reassembly ... > Is there any guidelines outlined by any TCP RFC's for determining what > data in the sequence space to keep and what to drop during TCP out of > order packet reassembly when there are overlaps? The BSD code tries to > trim the incoming segment when there is an overlap with a previous > segment in sequence space, and trims the already queued segments when > there is an overlap with succeeding segments in sequence space. I was > curious abt the motivation behind this strategy. In the BSD code, it is less work to trim from the front of an mbuf chain than from the tail of an mbuf chain, so when the front overlaps it's easier to trim the new segment, and when the tail overlaps it's easier to trim the succeeding segments. See m_adj() in uipc_mbuf.c. -David Borman _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Aug 27 13:49:11 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 NAA21885 for ; Wed, 27 Aug 2003 13:49: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 19s2nV-0008Pg-FX for tsvwg-archive@odin.ietf.org; Wed, 27 Aug 2003 12:05:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RG5PuU032337 for tsvwg-archive@odin.ietf.org; Wed, 27 Aug 2003 12:05:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2Vr-00087a-Ew; Wed, 27 Aug 2003 11:47:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s1Gy-0005X6-Nl for tsvwg@optimus.ietf.org; Wed, 27 Aug 2003 10:27:44 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01786; Wed, 27 Aug 2003 10:27:38 -0400 (EDT) Message-Id: <200308271427.KAA01786@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, 27 Aug 2003 10:27:37 -0400 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-highspeed-01.txt,.ps Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : HighSpeed TCP for Large Congestion Windows Author(s) : S. Floyd Filename : draft-ietf-tsvwg-highspeed-01.txt,.ps Pages : 36 Date : 2003-8-27 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-01.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-01.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-01.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-8-27103729.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-highspeed-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-highspeed-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-27103729.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Aug 27 21:07: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 VAA26121 for ; Wed, 27 Aug 2003 21:07: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 19s5wu-0004Ek-Vc for tsvwg-archive@odin.ietf.org; Wed, 27 Aug 2003 15:27:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RJRKja016245 for tsvwg-archive@odin.ietf.org; Wed, 27 Aug 2003 15:27:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s3pp-0004IB-9l; Wed, 27 Aug 2003 13:11:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2Xw-00089H-P7 for tsvwg@optimus.ietf.org; Wed, 27 Aug 2003 11:49: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 LAA10971 for ; Wed, 27 Aug 2003 11:49:15 -0400 (EDT) From: dbelen@netmode.ece.ntua.gr Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s2Xv-0001SQ-00 for tsvwg@ietf.org; Wed, 27 Aug 2003 11:49:19 -0400 Received: from p130.n-lapop01.stsn.com ([12.129.240.130] helo=SHOWCASE-9153) by ietf-mx with esmtp (Exim 4.12) id 19s2Xs-0001RF-00 for tsvwg@ietf.org; Wed, 27 Aug 2003 11:49:18 -0400 To: Date: Wed, 27 Aug 2003 8:50:00 --0700 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_006C94C0" Message-Id: Subject: [Tsvwg] Re: Re: My details Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_006C94C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_006C94C0 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_006C94C0-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Aug 27 21:30: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 VAA28045 for ; Wed, 27 Aug 2003 21:30: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 19sAyr-0002qS-CZ for tsvwg-archive@odin.ietf.org; Wed, 27 Aug 2003 20:49:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S0nf6X010927 for tsvwg-archive@odin.ietf.org; Wed, 27 Aug 2003 20:49:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5Qg-0002Ya-Tf; Wed, 27 Aug 2003 14:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s25G-0007Dg-JE for tsvwg@optimus.ietf.org; Wed, 27 Aug 2003 11:19: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 LAA07927 for ; Wed, 27 Aug 2003 11:19:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s25F-0000js-00 for tsvwg@ietf.org; Wed, 27 Aug 2003 11:19:41 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19s25E-0000jp-00 for tsvwg@ietf.org; Wed, 27 Aug 2003 11:19:41 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 4B24620660C for ; Wed, 27 Aug 2003 11:18:03 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19s1Q7-0005wL-Vk for ietf-announce-list@asgard.ietf.org; Wed, 27 Aug 2003 10:37:11 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19s1Gx-0005VZ-1I for all-ietf@asgard.ietf.org; Wed, 27 Aug 2003 10:27:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01786; Wed, 27 Aug 2003 10:27:38 -0400 (EDT) Message-Id: <200308271427.KAA01786@ietf.org> To: IETF-Announce: ; Cc: tsvwg@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Wed, 27 Aug 2003 10:27:37 -0400 Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+282295_9198827632547_06871476828" Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-highspeed-01.txt,.ps 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: , --MIMEStream=_0+282295_9198827632547_06871476828 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-01.txt,.ps Pages : 36 Date : 2003-8-27 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-01.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-01.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-01.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. --MIMEStream=_0+282295_9198827632547_06871476828 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+164380_81821302812009_8908657616" --MIMEStream=_1+164380_81821302812009_8908657616 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-27103729.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-highspeed-01.txt --MIMEStream=_1+164380_81821302812009_8908657616 Content-Type: Message/External-body; name="draft-ietf-tsvwg-highspeed-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-27103729.I-D@ietf.org> --MIMEStream=_1+164380_81821302812009_8908657616-- --MIMEStream=_0+282295_9198827632547_06871476828-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Aug 27 22:22:57 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 VAA28044 for ; Wed, 27 Aug 2003 21:30: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 19sADq-0000EL-Dc for tsvwg-archive@odin.ietf.org; Wed, 27 Aug 2003 20:01:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S016K5000866 for tsvwg-archive@odin.ietf.org; Wed, 27 Aug 2003 20:01:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4vW-00012t-UP; Wed, 27 Aug 2003 14:21:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rpXT-0004iR-D8 for tsvwg@optimus.ietf.org; Tue, 26 Aug 2003 21:55: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 VAA04030 for ; Tue, 26 Aug 2003 21:55:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rpXQ-0000Ik-00 for tsvwg@ietf.org; Tue, 26 Aug 2003 21:55:56 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19rpXP-0000Gw-00 for tsvwg@ietf.org; Tue, 26 Aug 2003 21:55:55 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7R1tPix004310; Tue, 26 Aug 2003 18:55:25 -0700 (PDT) Received: from cisco.com (mbashyam-u10.cisco.com [10.34.36.39]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKV21348; Tue, 26 Aug 2003 18:46:28 -0700 (PDT) Message-ID: <3F4C0F8D.115D3563@cisco.com> Date: Tue, 26 Aug 2003 18:55:25 -0700 From: Murali Bashyam Organization: Cisco Systems Inc X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Caitlin Bestler CC: tsvwg@ietf.org Subject: Re: [Tsvwg] overlapping TCP segments during reassembly References: <71756FCA-D80E-11D7-B171-003065D48EE0@asomi.com> 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 Caitlin Bestler wrote: > On Monday, August 25, 2003, at 08:56 PM, Murali Bashyam wrote: > > > Hi > > > > Is there any guidelines outlined by any TCP RFC's for determining what > > data in the sequence space to keep and what to drop during TCP out of > > order packet reassembly when there are overlaps? The BSD code tries to > > trim the incoming segment when there is an overlap with a previous > > segment in sequence space, and trims the already queued segments when > > there is an overlap with succeeding segments in sequence space. I was > > curious abt the motivation behind this strategy. > > > > Murali > > > > Certain things are implied: > > 1) overlaps indicate retransmissions. > > 2) multiple valid segments must all have the same value > for any given byte in the TCP stream, i.e. the > retransmit can only correct transmission errors > it cannot "fix" the data. > > 3) you can only deliver a given byte to the TCP consumer once. > > So, if you have a buffered but undelivered sequence, should > you replace it with new content? Well, since you know the > values are the same, why not optimize the copy by simply > not performing it? Right, based on these assumptions, that was the policy i was leaning towards, can i simply apply all the trimming i need to do on the incoming segment and always honour the already buffered data? Would this end up violating any delivery semantics? Murali > > > Caitlin Bestler - cait@asomi.com - http://asomi.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