From owner-tcp-impl@grc.nasa.gov Fri Dec 7 03:15:43 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15992 for ; Fri, 7 Dec 2001 03:15:42 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 63801C6937; Fri, 7 Dec 2001 03:15:43 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAaYa43m; Fri, 7 Dec 01 03:15:43 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA17717 for tcp-impl-outgoing; Fri, 7 Dec 2001 02:59:12 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA17706 for ; Fri, 7 Dec 2001 02:59:11 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id CAA18080 for ; Fri, 7 Dec 2001 02:59:09 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 28B76640C2; Fri, 7 Dec 2001 02:56:19 -0500 (EST) Received: from h235.p106.iij4u.or.jp(210.130.106.235) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAADtaay5; Fri, 7 Dec 01 02:56:18 -0500 Received: from localhost (localhost [127.0.0.1]) by viola.demizu.org (8.11.0/8.11.0) with ESMTP id fB781ev00313; Fri, 7 Dec 2001 17:01:41 +0900 (JST) From: Noritoshi Demizu To: tcp-impl@grc.nasa.gov Subject: Documents on Timestamps option X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011207170139K.demizu@dd.iij4u.or.jp> Date: Fri, 07 Dec 2001 17:01:39 +0900 X-Dispatcher: impost version 0.99i (Apr. 6, 1997) Lines: 28 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, (I am sorry if here is not an appropriate forum to ask this question.) Q: Which document is the best to refer to implement TCP Timestamps option? TCP Timestamps option is defiend in RFC1323, which is a proposed standard. However, through my experience, I think step (2) of section 3.4 in RFC1323 should be fixed as described in section 2.3 of [1] bellow. Otherwise, measured RTT could become much larger than the actual value when ACKs were lost. I found an internet-draft [2], which is to update RFC1323 and fixes the problem above. But, it has not been published as an RFC. Is there a technical problem in this I-D? So, I am wondering which document I should refer to. Thank you very much. Noritoshi Demizu. [1] R. Braden, "TCP Extensions for High Performance: An Update", Jun 1993 http://www.kohala.com/start/tcplw-extensions.txt [2] V. Jacobson, R. Braden and D. Borman, "TCP Extensions for High Performance", Feb 1997 http://www.watersprings.org/pub/id/draft-ietf-tcplw-high-performance-00.txt From owner-tcp-impl@grc.nasa.gov Fri Dec 7 04:26:02 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16860 for ; Fri, 7 Dec 2001 04:26:02 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 7B62AC6932; Fri, 7 Dec 2001 04:26:04 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAzuaaTw; Fri, 7 Dec 01 04:26:04 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA26789 for tcp-impl-outgoing; Fri, 7 Dec 2001 04:15:52 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA26785 for ; Fri, 7 Dec 2001 04:15:51 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id EAA00387 for ; Fri, 7 Dec 2001 04:15:50 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 9E7B4C68E4; Fri, 7 Dec 2001 04:15:50 -0500 (EST) Received: from unknown(202.125.87.14) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAdbaqgv; Fri, 7 Dec 01 04:15:48 -0500 Received: from sarayu (machine248 [172.16.1.248]) by brahma.roc.com (8.9.3/8.8.7) with SMTP id OAA29637 for ; Fri, 7 Dec 2001 14:50:55 +0530 Message-ID: <004801c17f00$2974e9e0$f80110ac@roc.com> From: "Srinivas" To: Subject: Query - TCP Window Advertisement. Date: Fri, 7 Dec 2001 14:48:39 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01C17F2E.420DD330" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0045_01C17F2E.420DD330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have a question regarding window zero advertisement during = connection establishment process. When a TCP at the receiver side receives a SYN packet when it has not = got any resource( memory buffer) to support additional connections, how = should it respond to the incoming SYN packet. 1) should it send a reset to the other end. 2) or should it send a SYN,ACK in response with a window advertisement = of zero. expecting ur reply. Regards srinivas ------=_NextPart_000_0045_01C17F2E.420DD330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
        I have a=20 question regarding window zero advertisement during connection = establishment=20 process.
 
When a TCP at the receiver side = receives a SYN=20 packet when it has not got any resource( memory buffer) to support = additional=20 connections, how should it respond to the incoming SYN = packet.
1) should it send a reset to the other=20 end.
2) or should it send a SYN,ACK in = response with a=20 window advertisement of zero.
 
expecting ur reply.
 
Regards
srinivas
 
------=_NextPart_000_0045_01C17F2E.420DD330-- From owner-tcp-impl@grc.nasa.gov Fri Dec 7 04:44:24 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17021 for ; Fri, 7 Dec 2001 04:44:23 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 5029464180; Fri, 7 Dec 2001 04:43:13 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAYFaOur; Fri, 7 Dec 01 04:43:13 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA28636 for tcp-impl-outgoing; Fri, 7 Dec 2001 04:34:37 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA28628 for ; Fri, 7 Dec 2001 04:34:36 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id EAA01237 for ; Fri, 7 Dec 2001 04:34:32 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id E59E16419A; Fri, 7 Dec 2001 04:32:16 -0500 (EST) Received: from lightning.swansea.linux.org.uk(194.168.151.1) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAA_baqvp; Fri, 7 Dec 01 04:32:15 -0500 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 16CHV4-0005D8-00; Fri, 07 Dec 2001 09:40:58 +0000 Subject: Re: Query - TCP Window Advertisement. To: srinia@qpackets.com (Srinivas) Date: Fri, 7 Dec 2001 09:40:58 +0000 (GMT) Cc: tcp-impl@grc.nasa.gov In-Reply-To: <004801c17f00$2974e9e0$f80110ac@roc.com> from "Srinivas" at Dec 07, 2001 02:48:39 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > When a TCP at the receiver side receives a SYN packet when it has not = > got any resource( memory buffer) to support additional connections, how = > should it respond to the incoming SYN packet. > 1) should it send a reset to the other end. > 2) or should it send a SYN,ACK in response with a window advertisement = > of zero. 3) drop it Seriously - if you have a reasonable expectation you might be able to handle it next time around, throw the frame away. The client will politely retry and do back off until resource exists or the user gets bored. If you want to implement some kind of queueing then syn|ack with window zero is also perfectly reasonable, and will let you hold the connection and then process it in order. Sending a reset seems to be wrong in just about all cases. Its not that nobody is listening on the port (which RST would be saying) its "give me a minute I'll get around to you" Alan From owner-tcp-impl@grc.nasa.gov Fri Dec 7 05:25:07 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17872 for ; Fri, 7 Dec 2001 05:25:06 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 68D1AC6999; Fri, 7 Dec 2001 05:23:52 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAi_ai5G; Fri, 7 Dec 01 05:23:52 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA03921 for tcp-impl-outgoing; Fri, 7 Dec 2001 05:14:53 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id FAA03914 for ; Fri, 7 Dec 2001 05:14:52 -0500 (EST) From: Gregory.Maman@space.alcatel.fr Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id FAA03880 for ; Fri, 7 Dec 2001 05:14:51 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id A57BE640A8; Fri, 7 Dec 2001 05:14:51 -0500 (EST) Received: from mel.alcatel.fr(212.208.74.132) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAA03aGOx; Fri, 7 Dec 01 05:14:51 -0500 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET) with ESMTP id fB7AEnjV011416 for ; Fri, 7 Dec 2001 11:14:49 +0100 Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.210.38]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with SMTP id LAA26505 for ; Fri, 7 Dec 2001 11:14:09 +0100 (MET) Received: by vzmta01.netfr.alcatel.fr(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256B1B.0037C07F ; Fri, 7 Dec 2001 11:08:57 +0100 X-Lotus-FromDomain: ALCATEL-SPACE To: tcp-impl@grc.nasa.gov Message-ID: Date: Fri, 7 Dec 2001 11:13:43 +0100 Subject: current OS TCP stack Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id FAA03915 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by lombok-fi.lerc.nasa.gov id FAA03921 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA17872 I would like to know what are the newest TCP features available in the latest OS distributions (Windows 2000/XP, Linux 2.5,....) Thanks ALCATEL SPACE INDUSTRIES DSR/RE/A -- Ingénieur Réseaux Tel : 33 (0) 5 34 35 35 14 / Fax : 33 (0) 5 34 35 61 69 Porte : F-2076 / E-Mail : gregory.maman@space.alcatel.fr From owner-tcp-impl@grc.nasa.gov Mon Dec 10 04:40:41 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29902 for ; Mon, 10 Dec 2001 04:40:41 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 211CDC69A1; Mon, 10 Dec 2001 04:38:48 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAyaaqnl; Mon, 10 Dec 01 04:38:47 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA05620 for tcp-impl-outgoing; Mon, 10 Dec 2001 04:26:06 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA05616 for ; Mon, 10 Dec 2001 04:26:05 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id EAA29573 for ; Mon, 10 Dec 2001 04:26:05 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 44BA7640A5; Mon, 10 Dec 2001 04:26:04 -0500 (EST) Received: from unknown(202.125.87.14) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAGdaGNT; Mon, 10 Dec 01 04:26:02 -0500 Received: from uday (machine252 [172.16.1.252]) by brahma.roc.com (8.9.3/8.8.7) with SMTP id PAA14536 for ; Mon, 10 Dec 2001 15:01:14 +0530 Message-ID: <01df01c1815b$c6f708d0$fc0110ac@roc.com> From: "Udaya kumar" To: Subject: Fw: Query - TCP Window Advertisement. Date: Mon, 10 Dec 2001 14:49:31 +0530 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 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi Alan Does the explanation below mean that persist timer should be used in the SYN SENT state. If the TCP A that sends out a SYN receive a SYN,ACK from the other TCP B with window advt. as zero then should TCP A probe the window of TCP B. Anyway connection establishment timer would gain priority and report event on failure to establish conn. even though persist timer may be working and hence window probing may not go on until window availability is shown from TCP B. Is sending SYN,ACK with zero window advt. valid then??? Can persist timer co-exist with conn. establishment timer???? May be dropping a SYN segment is the only option when resource (memory) is not available. Expecting ur reply. thanks uday > ----- Original Message ----- > From: "Alan Cox" > To: "Srinivas" > Cc: > Sent: Friday, December 07, 2001 3:10 PM > Subject: Re: Query - TCP Window Advertisement. > > > > > When a TCP at the receiver side receives a SYN packet when it has not = > > > got any resource( memory buffer) to support additional connections, how > = > > > should it respond to the incoming SYN packet. > > > 1) should it send a reset to the other end. > > > 2) or should it send a SYN,ACK in response with a window advertisement = > > > of zero. > > > > 3) drop it > > > > Seriously - if you have a reasonable expectation you might be able to > handle > > it next time around, throw the frame away. The client will politely retry > > and do back off until resource exists or the user gets bored. > > > > If you want to implement some kind of queueing then syn|ack with window > zero > > is also perfectly reasonable, and will let you hold the connection and > then > > process it in order. > > > > Sending a reset seems to be wrong in just about all cases. Its not that > > nobody is listening on the port (which RST would be saying) its "give me a > > minute I'll get around to you" > > > > Alan > From owner-tcp-impl@grc.nasa.gov Mon Dec 10 05:01:28 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00068 for ; Mon, 10 Dec 2001 05:01:28 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 8D20FC696A; Mon, 10 Dec 2001 04:58:06 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAi1ai0p; Mon, 10 Dec 01 04:58:06 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA08274 for tcp-impl-outgoing; Mon, 10 Dec 2001 04:50:49 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA08264 for ; Mon, 10 Dec 2001 04:50:48 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id EAA00904 for ; Mon, 10 Dec 2001 04:50:40 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 4FA506412B; Mon, 10 Dec 2001 04:47:15 -0500 (EST) Received: from lightning.swansea.linux.org.uk(194.168.151.1) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAA_QaWPY; Mon, 10 Dec 01 04:47:14 -0500 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 16DNAC-0001QN-00; Mon, 10 Dec 2001 09:55:56 +0000 Subject: Re: Fw: Query - TCP Window Advertisement. To: uday@qpackets.com (Udaya kumar) Date: Mon, 10 Dec 2001 09:55:56 +0000 (GMT) Cc: tcp-impl@grc.nasa.gov In-Reply-To: <01df01c1815b$c6f708d0$fc0110ac@roc.com> from "Udaya kumar" at Dec 10, 2001 02:49:31 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Is sending SYN,ACK with zero window advt. valid then??? > Can persist timer co-exist with conn. establishment timer???? I don't see why the question arises. You can send an ack into a zero window From owner-tcp-impl@grc.nasa.gov Mon Dec 10 11:16:50 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04412 for ; Mon, 10 Dec 2001 11:16:50 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 63103C6A0E; Mon, 10 Dec 2001 11:15:46 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAGaaW1w; Mon, 10 Dec 01 11:15:46 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA09698 for tcp-impl-outgoing; Mon, 10 Dec 2001 11:06:07 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA09676 for ; Mon, 10 Dec 2001 11:06:05 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id LAA23884 for ; Mon, 10 Dec 2001 11:06:02 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id D0DAE64181; Mon, 10 Dec 2001 11:05:24 -0500 (EST) Received: from unknown(212.8.180.2) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAepaqWd; Mon, 10 Dec 01 11:05:24 -0500 Received: from mail pickup service by yucntsys2.yucom.be with Microsoft SMTPSVC; Mon, 10 Dec 2001 17:04:52 +0100 Received: from yuclnx5 ([212.8.180.4]) by yucntsys2.yucom.be with Microsoft SMTPSVC(5.5.1877.687.68); Fri, 7 Dec 2001 10:48:58 +0100 Received: (qmail 20722 invoked from network); 7 Dec 2001 09:53:31 -0000 Received: from unknown (HELO seraph2.grc.nasa.gov) (128.156.10.11) by 0 with SMTP; 7 Dec 2001 09:53:31 -0000 Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 613FEC6944; Fri, 7 Dec 2001 04:48:05 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAQZaqmB; Fri, 7 Dec 01 04:48:05 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA28636 for tcp-impl-outgoing; Fri, 7 Dec 2001 04:34:37 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA28628 for ; Fri, 7 Dec 2001 04:34:36 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id EAA01237 for ; Fri, 7 Dec 2001 04:34:32 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id E59E16419A; Fri, 7 Dec 2001 04:32:16 -0500 (EST) Received: from lightning.swansea.linux.org.uk(194.168.151.1) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAA_baqvp; Fri, 7 Dec 01 04:32:15 -0500 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 16CHV4-0005D8-00; Fri, 07 Dec 2001 09:40:58 +0000 Subject: Re: Query - TCP Window Advertisement. To: srinia@qpackets.com (Srinivas) Date: Fri, 7 Dec 2001 09:40:58 +0000 (GMT) Cc: tcp-impl@grc.nasa.gov In-Reply-To: <004801c17f00$2974e9e0$f80110ac@roc.com> from "Srinivas" at Dec 07, 2001 02:48:39 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > When a TCP at the receiver side receives a SYN packet when it has not = > got any resource( memory buffer) to support additional connections, how = > should it respond to the incoming SYN packet. > 1) should it send a reset to the other end. > 2) or should it send a SYN,ACK in response with a window advertisement = > of zero. 3) drop it Seriously - if you have a reasonable expectation you might be able to handle it next time around, throw the frame away. The client will politely retry and do back off until resource exists or the user gets bored. If you want to implement some kind of queueing then syn|ack with window zero is also perfectly reasonable, and will let you hold the connection and then process it in order. Sending a reset seems to be wrong in just about all cases. Its not that nobody is listening on the port (which RST would be saying) its "give me a minute I'll get around to you" Alan From owner-tcp-impl@grc.nasa.gov Mon Dec 10 12:05:54 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05693 for ; Mon, 10 Dec 2001 12:05:53 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 78671641F2; Mon, 10 Dec 2001 12:04:12 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAgGaW2s; Mon, 10 Dec 01 12:04:12 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA23356 for tcp-impl-outgoing; Mon, 10 Dec 2001 11:56:45 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA23342 for ; Mon, 10 Dec 2001 11:56:44 -0500 (EST) From: kuznet@ms2.inr.ac.ru Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id LAA29366 for ; Mon, 10 Dec 2001 11:56:43 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id D23C4C6906; Mon, 10 Dec 2001 11:53:03 -0500 (EST) Received: from minus.inr.ac.ru(193.233.7.97) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAASIaWfF; Mon, 10 Dec 01 11:52:56 -0500 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA16349; Mon, 10 Dec 2001 19:46:24 +0300 Message-Id: <200112101646.TAA16349@ms2.inr.ac.ru> Subject: Re: Fw: Query - TCP Window Advertisement. To: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Mon, 10 Dec 2001 19:46:24 +0300 (MSK) Cc: uday@qpackets.com, tcp-impl@grc.nasa.gov In-Reply-To: from "Alan Cox" at Dec 10, 1 09:55:56 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Hello! > > Is sending SYN,ACK with zero window advt. valid then??? > > Can persist timer co-exist with conn. establishment timer???? > > I don't see why the question arises. You can send an ack into a zero window Seems, he thinks some other timer ("conn. establishment timer") exists in this state. It does not exist, the state is normal good ESTABLISHED after receiving SYN,ACK. No special timers is running and window may be of any value, of course. Alexey From owner-tcp-impl@grc.nasa.gov Mon Dec 10 16:55:22 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12668 for ; Mon, 10 Dec 2001 16:55:19 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id D2F4A64168; Mon, 10 Dec 2001 16:54:47 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAASlaieA; Mon, 10 Dec 01 16:54:47 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA06088 for tcp-impl-outgoing; Mon, 10 Dec 2001 16:42:21 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA06084 for ; Mon, 10 Dec 2001 16:42:20 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id QAA29012 for ; Mon, 10 Dec 2001 16:42:20 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 01B43C68CA; Mon, 10 Dec 2001 16:42:19 -0500 (EST) Received: from 71-203-131-12.bellhead.com(12.131.203.71) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAhBaOCJ; Mon, 10 Dec 01 16:42:19 -0500 Received: from lawyers (mallman@localhost) by lawyers.grc.nasa.gov (8.9.3/8.9.3) with ESMTP id NAA28846; Mon, 10 Dec 2001 13:12:47 -0500 Message-Id: <200112101812.NAA28846@lawyers.grc.nasa.gov> To: "Andrei Gurtov" From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tcp-impl@grc.nasa.gov Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Organization: BBN Technologies/NASA GRC Song-of-the-Day: November Rain Date: Mon, 10 Dec 2001 13:12:47 -0500 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk (Chunking through old messages...) > In my opinion to avoid spurious RTOs TCP should collect RTT > samples more frequently than once per window, Why? Can you explain a bit more? Vern and I found that collecting more samples does not seem to help the accuracy of the timer. See our 1999 SIGCOMM paper: Mark Allman, Vern Paxson. \textit{On Estimating End-to-End Network Path Properties}. ACM SIGCOMM, September 1999. http://roland.grc.nasa.gov/~mallman/papers/estimation.ps allman From owner-tcp-impl@grc.nasa.gov Mon Dec 10 21:16:43 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16560 for ; Mon, 10 Dec 2001 21:16:43 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 5C075C6926; Mon, 10 Dec 2001 21:13:18 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAC7aqMs; Mon, 10 Dec 01 21:13:18 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA08306 for tcp-impl-outgoing; Mon, 10 Dec 2001 21:02:28 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA08294; Mon, 10 Dec 2001 21:02:26 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id VAA15555; Mon, 10 Dec 2001 21:02:26 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 44515C68CA; Mon, 10 Dec 2001 21:02:26 -0500 (EST) Received: from 251-196-131-12.bellhead.com(12.131.196.251) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAESaiNq; Mon, 10 Dec 01 21:02:25 -0500 Received: from gurtoan1nb (36-201-131-12.bellhead.com [12.131.201.36]) by localhost.localdomain (8.11.6/8.11.6) with SMTP id fBB1xZj12261; Mon, 10 Dec 2001 18:59:35 -0700 Message-ID: <00b001c181e7$dd6cad40$24c9830c@ietfslc.com> From: "Andrei Gurtov" To: Cc: References: <200112101812.NAA28846@lawyers.grc.nasa.gov> Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Date: Tue, 11 Dec 2001 03:59:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > > In my opinion to avoid spurious RTOs TCP should collect RTT > > samples more frequently than once per window, > > Why? Can you explain a bit more? > > Vern and I found that collecting more samples does not seem to help > the accuracy of the timer. See our 1999 SIGCOMM paper: I know this paper well, and I agree that based on backbone traces you have been using there probably isn't much benefit of frequent RTT samples. However, I think that if traces would be collected at some wireless gateway, the result might have been different. The environment I was looking at included slow overbuffered links with occasional delay spikes. On slow links the queueing delay can double between two adjacent RTT samples if they are collected once per window. This type of situation was the motivation for VJ to increase the RTTvar coefficient from 2 to 4. Still, experimenting in NS with TCP without timestamps I was getting spurios timeouts after even a slight delay spike or during fast recovery. A technical report with results and traces to back-up this will be available shortly. Hopefully, we will have an interesting discussion. Thanks, Andrei From owner-tcp-impl@grc.nasa.gov Mon Dec 10 23:11:50 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19884 for ; Mon, 10 Dec 2001 23:11:49 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 53808C698A; Mon, 10 Dec 2001 23:08:48 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAATZaOOI; Mon, 10 Dec 01 23:08:48 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id XAA19643 for tcp-impl-outgoing; Mon, 10 Dec 2001 23:00:48 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id XAA19639 for ; Mon, 10 Dec 2001 23:00:47 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id XAA21647 for ; Mon, 10 Dec 2001 23:00:47 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id E5ABD640BE; Mon, 10 Dec 2001 23:00:46 -0500 (EST) Received: from 145-201-131-12.bellhead.com(12.131.201.145) by seraph3.grc.nasa.gov via csmap (V6.0) id srcBAAORa4eB; Mon, 10 Dec 01 23:00:46 -0500 Received: from lawyers (mallman@localhost) by lawyers.grc.nasa.gov (8.9.3/8.9.3) with ESMTP id WAA31925; Mon, 10 Dec 2001 22:39:15 -0500 Message-Id: <200112110339.WAA31925@lawyers.grc.nasa.gov> To: "Andrei Gurtov" From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tcp-impl@grc.nasa.gov Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Organization: BBN Technologies/NASA GRC Song-of-the-Day: November Rain Date: Mon, 10 Dec 2001 22:39:15 -0500 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk > However, I think that if traces would be collected at some > wireless gateway, the result might have been different. The > environment I was looking at included slow overbuffered links with > occasional delay spikes. We also found delay spikes. > On slow links the queueing delay can double between two adjacent > RTT samples if they are collected once per window. This type of > situation was the motivation for VJ to increase the RTTvar > coefficient from 2 to 4. Still, experimenting in NS with TCP > without timestamps I was getting spurios timeouts after even a > slight delay spike or during fast recovery. A technical report > with results and traces to back-up this will be available > shortly. Hopefully, we will have an interesting discussion. I'd like to see your tech report. We did some very simple experiments of links with varying propagation delay (satellite stuff). One of the scenarios we tested was a scenario where the RTT doubled instantly (it was a handoff -- and we modeled it as perfect (no drops, no reordering)). When using an RTO that is RFC 2988 compliant we noted no spurious retransmits. When using a finer grained timer with no minimum RTO we did notice some bogus retransmits. (Of course, in our scenario no amount of RTT measurements would have predicted this increase in RTT because it happened instantly. The point is that the RTT doubled without a spurious retransmit.) The experiment is outlined in the following short paper: Mark Allman, Jim Griner, Alan Richard. TCP Behavior in Networks with Dynamic Propagation Delay. Proceedings of Globecom 2000, November 2000. http://roland.grc.nasa.gov/~mallman/papers/var-delay.ps allman --- Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ From owner-tcp-impl@grc.nasa.gov Tue Dec 11 00:50:42 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26020 for ; Tue, 11 Dec 2001 00:50:42 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 54B45641A0; Tue, 11 Dec 2001 00:49:35 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAA6iaqXU; Tue, 11 Dec 01 00:49:35 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA02562 for tcp-impl-outgoing; Tue, 11 Dec 2001 00:40:54 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id AAA02557 for ; Tue, 11 Dec 2001 00:40:53 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id AAA28208 for ; Tue, 11 Dec 2001 00:40:52 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 37EC2640BE; Tue, 11 Dec 2001 00:40:52 -0500 (EST) Received: from unknown(202.125.87.14) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAp7aW5S; Tue, 11 Dec 01 00:40:49 -0500 Received: from aji (machine250 [172.16.1.250]) by brahma.roc.com (8.9.3/8.8.7) with SMTP id LAA22208 for ; Tue, 11 Dec 2001 11:16:01 +0530 Message-ID: <003301c18206$4db00340$fa0110ac@aji> From: "Aji" To: Subject: regarding URG and PSH flags in send() call Date: Tue, 11 Dec 2001 11:10:11 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01C18234.6673CD20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0030_01C18234.6673CD20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi In the Linux stack version 2.4.2, how the urgent and push flags are set = in the send() user call ? The application gives the send call as int send (int sockfd, const void *msg, int len, int flags); what is the flags mentioned in the above send() call? awaiting reply regards Aji Varghe ------=_NextPart_000_0030_01C18234.6673CD20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
In the Linux stack version 2.4.2, how = the urgent=20 and push flags are set in the send() user call ?
 
The application gives the send call = as
 
int send (int sockfd, const void *msg, = int len, int=20 flags);
 
what is the flags mentioned in the = above send()=20 call?
 
awaiting reply
regards
Aji Varghe
------=_NextPart_000_0030_01C18234.6673CD20-- From owner-tcp-impl@grc.nasa.gov Tue Dec 11 07:47:06 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16958 for ; Tue, 11 Dec 2001 07:47:06 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 52DD2C699B; Tue, 11 Dec 2001 07:44:04 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAaRaq5S; Tue, 11 Dec 01 07:44:04 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA07389 for tcp-impl-outgoing; Tue, 11 Dec 2001 07:29:47 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id HAA07366; Tue, 11 Dec 2001 07:29:45 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id HAA24939; Tue, 11 Dec 2001 07:29:44 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 910A564117; Tue, 11 Dec 2001 07:28:20 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAA0maq2U; Tue, 11 Dec 01 07:28:20 -0500 Received: from aachen.eed.ericsson.se (aachen.eed.ericsson.se [164.48.130.2]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fBBCSGK24443; Tue, 11 Dec 2001 13:28:17 +0100 (MET) Received: from res0010384da36.ericsson.com (rmt160229.am.ericsson.se [138.85.160.229]) by aachen.eed.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id NAA04013; Tue, 11 Dec 2001 13:28:03 +0100 (MET) Message-Id: <5.1.0.14.0.20011211123031.01d74c18@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Dec 2001 13:26:13 +0100 To: mallman@grc.nasa.gov From: Reiner Ludwig Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Cc: "Andrei Gurtov" , Vern Paxson , tcp-impl@grc.nasa.gov, pilc@grc.nasa.gov In-Reply-To: <200112110339.WAA31925@lawyers.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk I'm cross-posting since this is being discussed on tcp-impl@grc.nasa.gov and pilc@grc.nasa.gov ... By now, we have raised (at least) 3 different issues: 1. timing every packet(e.g., by using Timestamps) or not 2. timer granularity 3. RTO minimum Concerning 1: I have found that timing every packet (usually) makes no big difference on delay-dominated paths *but* it makes a big difference on bandwith-dominated paths. Since, I know the trace collection Mark & Vern used for their SIGCOMM99 paper quite well (I used it for my own analysis), I also know that those traces mostly (>> 95%) stem from delay-dominated paths. I believe that that's the reason why Mark & Vern found no big impact when using the Timestamps option. However, I definitely cannot agree to the conclusion that the Timestamps option has no effect on RTO accuracy in the general case. Timing every packet does make the RTO more accurate on bandwidth-dominated links, and thus helps avoid spurious timeouts across such paths. The problem is that the constant gains 1/4 and 1/8 are not appropriate when timing every packet if many packets are in flight (i.e., cwnd is large). In that case, the TCP sender forgets the RTT history too fast. A solution is to make the gains adaptive. This has been addressed in this paper: Reiner Ludwig, Keith Sklower, The Eifel Retransmission Timer. Appears in ACM Computer Communications Review, Vol. 30, No. 3, July 2000. http://iceberg.cs.berkeley.edu/publications.html Others have shown that timing every packet helps avoid spurious timeouts across bandwidth-dominated paths: http://www.ietf.org/internet-drafts/draft-khafizov-pilc-cdma2000-00.txt BTW, when timing every packet, the motivation that Van Jacobson gave for increasing the RTTVAR weight factor from 2 to 4 does not hold any longer. My current analysis shows that a weight factor of 2 is mostly sufficent when timing every packet. But that work hasn't concluded yet. Concerning 2: In my research, I confirm Mark & Vern's finding that in today's Internet a timer granularity of 100 ms gives the best trade-off between timer accuracy vs. host processing load due to timer handling. However, the RTO does get more precise when going down to 10 ms timer ticks, but it's mostly not worth the effort. This might change in the future when typical Internet RTTs come below 100ms. Then, a 10 ms timer granularity is probably more appropriate. Concerning 3: I find it bogus that RFC2988 hardwires the minimum RTO to 1 second. I haven't found any motivation for that. If the retransmission timer is implemented as a hardbeat timer, an RTO minimum of 2 x the granularity (as in BSD) is sufficient. I have data to confirm this, and hope to write that up some time next year. ///Reiner At 04:39 11.12.2001, Mark Allman wrote: > > However, I think that if traces would be collected at some > > wireless gateway, the result might have been different. The > > environment I was looking at included slow overbuffered links with > > occasional delay spikes. > >We also found delay spikes. > > > On slow links the queueing delay can double between two adjacent > > RTT samples if they are collected once per window. This type of > > situation was the motivation for VJ to increase the RTTvar > > coefficient from 2 to 4. Still, experimenting in NS with TCP > > without timestamps I was getting spurios timeouts after even a > > slight delay spike or during fast recovery. A technical report > > with results and traces to back-up this will be available > > shortly. Hopefully, we will have an interesting discussion. > >I'd like to see your tech report. We did some very simple >experiments of links with varying propagation delay (satellite >stuff). One of the scenarios we tested was a scenario where the RTT >doubled instantly (it was a handoff -- and we modeled it as perfect >(no drops, no reordering)). When using an RTO that is RFC 2988 >compliant we noted no spurious retransmits. When using a finer >grained timer with no minimum RTO we did notice some bogus >retransmits. > >(Of course, in our scenario no amount of RTT measurements would have >predicted this increase in RTT because it happened instantly. The >point is that the RTT doubled without a spurious retransmit.) > >The experiment is outlined in the following short paper: > > Mark Allman, Jim Griner, Alan Richard. TCP Behavior in Networks > with Dynamic Propagation Delay. Proceedings of Globecom 2000, > November 2000. > http://roland.grc.nasa.gov/~mallman/papers/var-delay.ps > >allman > > >--- >Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ From owner-tcp-impl@grc.nasa.gov Tue Dec 11 11:01:59 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19483 for ; Tue, 11 Dec 2001 11:01:58 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id A923564093; Tue, 11 Dec 2001 11:02:01 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAcAaiFP; Tue, 11 Dec 01 11:02:01 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA27546 for tcp-impl-outgoing; Tue, 11 Dec 2001 10:50:02 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA27528; Tue, 11 Dec 2001 10:49:59 -0500 (EST) From: qiong-stan.li@philips.com Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id KAA13206; Tue, 11 Dec 2001 10:49:59 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id EFE9164093; Tue, 11 Dec 2001 10:49:58 -0500 (EST) Received: from gw-nl5.philips.com(212.153.235.99) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAA05aa_L; Tue, 11 Dec 01 10:49:58 -0500 Received: from smtpscan-nl2.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl5.philips.com with ESMTP id QAA04182; Tue, 11 Dec 2001 16:49:53 +0100 (MET) (envelope-from qiong-stan.li@philips.com) Received: from smtpscan-nl2.philips.com(130.139.36.22) by gw-nl5.philips.com via mwrap (4.0a) id xma004180; Tue, 11 Dec 01 16:49:53 +0100 Received: from smtprelay-us1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA09157; Tue, 11 Dec 2001 16:49:51 +0100 (MET) Received: from arj001soh.diamond.philips.com (amsoh01.diamond.philips.com [161.88.79.212]) by smtprelay-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id JAA05349; Tue, 11 Dec 2001 09:49:50 -0600 (CST) To: Reiner Ludwig Cc: "Andrei Gurtov" , mallman@grc.nasa.gov, owner-tcp-impl@grc.nasa.gov, pilc@grc.nasa.gov, tcp-impl@grc.nasa.gov, Vern Paxson Subject: Re: Doubt regarding the MANAGING THE RTO TIMER X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 11 Dec 2001 09:57:03 -0600 X-MIMETrack: Serialize by Router on arj001soh/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at 11/12/2001 09:53:46, Serialize complete at 11/12/2001 09:53:46 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0057210585256B1F_=" Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk This is a multipart message in MIME format. --=_alternative 0057210585256B1F_= Content-Type: text/plain; charset="us-ascii" Dear All, I think one of our papers may cast some new insight on this RTO timer issue. In this paper, the dependent properties of measured delay samples are investigated and a new delay estimation method is proposed. The understanding gained in this study may provide some clue on how to set the constant gains of the TCP-style SRTT estimator under different conditions. The paper is: Qiong Li and Dave L. Mills, "Jitter Based Delay Boundary Prediction of Wide-Area Networks", appears in ACM/IEEE Transactions on Networking, Vol. 9, No. 5, Oct., 2001. Available at: http://www.ee.udel.edu/~qli/paper/acm_delay_pred.ps Abstract The delay boundary prediction algorithms currently implemented by transport protocols are lowpass filters based on autoregressive and moving average (ARMA) models. However, recent studies have revealed a fractal-like structure of delay sequences, which may not be well suited to ARMA models. In this paper we propose a novel delay boundary prediction algorithm based on a deviation-lag function (DLF) to characterize end-to-end delay variations. Compared to conventional algorithms derived from ARMA models, the new algorithm can adapt to delay variations more rapidly and share the delay's robust high-order statistical information (jitter deviation) among competing connections along a common network path. Preliminary experiments show it outperforms Jacobson's algorithm, which is based on an ARMA model, by significantly reducing the prediction error rate. To show the practical feasibility of the DLF algorithm, we also propose a skeleton implementation model. Thanks, -qiong _____________________________________ Qiong Li (Stan) Senior Member Research Staff Wireless Communications and Networking (WiCAN) Philips Research USA 345 Scarborough Road, Briarcliff Manor, NY 10510-2099 Tel:(914)945-6408/Fax:(914)945-6580 email: qiong-stan.li@philips.com ** My opinions do not reflect those of my employer ** --=_alternative 0057210585256B1F_= Content-Type: text/html; charset="us-ascii"
Dear All,

I think one of our papers may cast some new insight on this RTO timer issue. In this paper, the dependent properties of measured delay samples are investigated and a new delay estimation method is proposed. The understanding gained in this study may provide some clue on how to set the constant gains of the TCP-style SRTT estimator under different conditions.

The paper is:

 Qiong Li and Dave L. Mills, "Jitter Based Delay Boundary Prediction of Wide-Area Networks", appears in ACM/IEEE Transactions on Networking, Vol. 9, No. 5, Oct., 2001. Available at: http://www.ee.udel.edu/~qli/paper/acm_delay_pred.ps

Abstract

The delay boundary prediction algorithms currently implemented by transport protocols are lowpass filters based on autoregressive and moving average (ARMA) models. However, recent studies have revealed a fractal-like structure of delay sequences, which may not be well suited to ARMA models. In this paper we propose a novel delay boundary prediction algorithm based on a deviation-lag function (DLF) to characterize end-to-end delay variations. Compared to conventional algorithms derived from ARMA models, the new algorithm can adapt to delay variations more rapidly and share the delay's robust high-order statistical information (jitter deviation) among competing connections along a common network path. Preliminary experiments show it outperforms Jacobson's algorithm, which is based on an ARMA model, by significantly reducing the prediction error rate. To show the practical feasibility of the DLF algorithm, we also propose a skeleton impleme! ! ! ! ntation model.

Thanks,

-qiong

_____________________________________
Qiong Li (Stan)
Senior Member Research Staff
Wireless Communications and Networking (WiCAN)
Philips Research USA
345 Scarborough Road, Briarcliff Manor, NY 10510-2099

Tel:(914)945-6408/Fax:(914)945-6580
email: qiong-stan.li@philips.com
** My opinions do not reflect those of my employer ** --=_alternative 0057210585256B1F_=-- From owner-tcp-impl@grc.nasa.gov Tue Dec 11 11:22:39 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19880 for ; Tue, 11 Dec 2001 11:22:39 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id D37D3C69AB; Tue, 11 Dec 2001 11:22:40 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAP8aGVK; Tue, 11 Dec 01 11:22:40 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA06510 for tcp-impl-outgoing; Tue, 11 Dec 2001 11:12:30 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA06489; Tue, 11 Dec 2001 11:12:28 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id LAA16244; Tue, 11 Dec 2001 11:12:26 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 93127C698A; Tue, 11 Dec 2001 11:10:41 -0500 (EST) Received: from 59-203-131-12.bellhead.com(12.131.203.59) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAasa4UH; Tue, 11 Dec 01 11:10:41 -0500 Received: from lawyers (mallman@localhost) by lawyers.grc.nasa.gov (8.9.3/8.9.3) with ESMTP id LAA01048; Tue, 11 Dec 2001 11:09:09 -0500 Message-Id: <200112111609.LAA01048@lawyers.grc.nasa.gov> To: Reiner Ludwig From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: "Andrei Gurtov" , Vern Paxson , tcp-impl@grc.nasa.gov, pilc@grc.nasa.gov Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Organization: BBN Technologies/NASA GRC Song-of-the-Day: November Rain Date: Tue, 11 Dec 2001 11:09:08 -0500 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk > I find it bogus that RFC2988 hardwires the minimum RTO to 1 > second. I haven't found any motivation for that. If the > retransmission timer is implemented as a hardbeat timer, an RTO > minimum of 2 x the granularity (as in BSD) is sufficient. I have > data to confirm this, and hope to write that up some time next > year. We've discussed this before... But, a clarification... RFC 2988 was written so that there would be **a** standard on how to manage the RTO. We essentially took Van's algorithm and codified it. The minimum of 1 second is a traditional aspect of the RTO timer. And, the work that Vern and I did found that the 1 second minimum does, in fact, serve to keep the timer conservative. My understanding (I won't speak for Vern) of RFC 2988 is that it *was not* intended to be the end-all-be-all of RTO schemes. If someone has something that works better (where "better" is intentionally left vague) then I'd be happy to see RFC 2988 relegated to historical. But, I have not yet seen the evidence that such an algorithm exists (not to say that I think your particular algorithm is in any way bad -- just that I have not yet been convinced that it is the Right solution). allman --- Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ From owner-tcp-impl@grc.nasa.gov Tue Dec 11 12:11:55 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20835 for ; Tue, 11 Dec 2001 12:11:49 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 3E19C6416E; Tue, 11 Dec 2001 12:11:53 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAqVaGWh; Tue, 11 Dec 01 12:11:53 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA21354 for tcp-impl-outgoing; Tue, 11 Dec 2001 12:02:53 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA21332; Tue, 11 Dec 2001 12:02:49 -0500 (EST) From: dab@restless.weston.bsdi.com Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id MAA22546; Tue, 11 Dec 2001 12:02:46 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 6EC13C68D6; Tue, 11 Dec 2001 12:02:44 -0500 (EST) Received: from 65-203-131-12.bellhead.com(12.131.203.65) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAQTaGjV; Tue, 11 Dec 01 12:02:44 -0500 Received: (from dab@localhost) by restless.weston.bsdi.com (8.11.2/8.11.2) id fBBGwd000600; Tue, 11 Dec 2001 10:58:39 -0600 (CST) Date: Tue, 11 Dec 2001 10:58:39 -0600 (CST) Message-Id: <200112111658.fBBGwd000600@restless.weston.bsdi.com> To: mallman@grc.nasa.gov, Reiner.Ludwig@Ericsson.com Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Cc: gurtov@cs.Helsinki.FI, pilc@grc.nasa.gov, tcp-impl@grc.nasa.gov, vern@aciri.org Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk One comment on the RTO discussion w.r.t. Timestamps: Without the Timestamps option, due to the Karn algorithm, you do not get an RTT measurment when there is packet loss. If you are losing 1 packet per RTT, you get into a state where you don't get any packet timing information. When using Timestamps, even in the face of packet loss, you can guarantee to get at least one valid timing per RTT. Or, more correctly, with Timestamps, anytime you get an ack for new data, you can reliably use it's timestamp to get a new RTT measurement. -David Borman, dab@bsdi.com From owner-tcp-impl@grc.nasa.gov Tue Dec 11 12:46:31 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21542 for ; Tue, 11 Dec 2001 12:46:31 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id EF93A64242; Tue, 11 Dec 2001 12:44:49 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAYuaq2s; Tue, 11 Dec 01 12:44:49 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA29954 for tcp-impl-outgoing; Tue, 11 Dec 2001 12:36:47 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA29930; Tue, 11 Dec 2001 12:36:45 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id MAA26354; Tue, 11 Dec 2001 12:36:43 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 4088F6419D; Tue, 11 Dec 2001 12:34:36 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAA3Ca44p; Tue, 11 Dec 01 12:34:35 -0500 Received: from aachen.eed.ericsson.se (aachen.eed.ericsson.se [164.48.130.2]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fBBHYXK07461; Tue, 11 Dec 2001 18:34:33 +0100 (MET) Received: from res0010384da36.ericsson.com (rmt160126.am.ericsson.se [138.85.160.126]) by aachen.eed.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id SAA03206; Tue, 11 Dec 2001 18:34:28 +0100 (MET) Message-Id: <5.1.0.14.0.20011211181427.031f45f8@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Dec 2001 18:32:11 +0100 To: mallman@grc.nasa.gov From: Reiner Ludwig Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Cc: Reiner Ludwig , "Andrei Gurtov" , Vern Paxson , tcp-impl@grc.nasa.gov, pilc@grc.nasa.gov In-Reply-To: <200112111609.LAA01048@lawyers.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk At 17:09 11.12.2001, Mark Allman wrote: >We've discussed this before... Yep :-) >RFC 2988 was written so that there would be **a** standard on how to >manage the RTO. I know, and I think that was a good thing to do. Don't get me wrong, I'm glad that we have RFC2988. It's a good document! I only wanted to point out some known issues with it in this discussion. >The minimum of 1 second is a traditional aspect of the RTO >timer. That's the one thing about RFC2988 that I never bought, and I raised that issue when RFC2988 was last called. What you codified was pretty much what is found in the BSD4.4-Lite implementation of TCP, and that one sets RTO to 2x granularity, and not 1 second. >And, the work that Vern and I did found that the 1 second >minimum does, in fact, serve to keep the timer conservative. It sure does. >(not to say that I think your particular >algorithm is in any way bad -- Just as a warning to those who want to experiment with that timer we proposed in ACM Computer Communications Review, Vol. 30, No. 3, July 2000. It has (at least) two severe flaws: - proposing that the RTTVAR weight factor should be adaptive was a bad idea :-( In later work, we found that it should stay constant at 2 or 4 depending on whether every packet is timed or not. - what we termed the "REXMT-Restart Bug" really is not a bug, but instead an extremely valuable safeguard against spurious timeouts in case of rapidly increasing RTTs; even more so when timing every packet. Maybe that was a built-in but undocumented feature of those who implemented the timer in BSD4.4-Lite? The other features we proposed seem to work fine, though :-) More in a paper some time next year. ///Reiner From owner-tcp-impl@grc.nasa.gov Tue Dec 11 13:27:38 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22271 for ; Tue, 11 Dec 2001 13:27:37 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id DD124C6919; Tue, 11 Dec 2001 13:27:39 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAKVaOkl; Tue, 11 Dec 01 13:27:39 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA12360 for tcp-impl-outgoing; Tue, 11 Dec 2001 13:17:15 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA12337; Tue, 11 Dec 2001 13:17:13 -0500 (EST) From: kuznet@ms2.inr.ac.ru Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id NAA01351; Tue, 11 Dec 2001 13:17:13 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id B1D0EC68F9; Tue, 11 Dec 2001 13:17:12 -0500 (EST) Received: from minus.inr.ac.ru(193.233.7.97) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAgDaaxi; Tue, 11 Dec 01 13:17:11 -0500 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA03080; Tue, 11 Dec 2001 21:16:46 +0300 Message-Id: <200112111816.VAA03080@ms2.inr.ac.ru> Subject: Re: Doubt regarding the MANAGING THE RTO TIMER To: Reiner.Ludwig@Ericsson.com (Reiner Ludwig) Date: Tue, 11 Dec 2001 21:16:46 +0300 (MSK) Cc: mallman@grc.nasa.gov, Reiner.Ludwig@Ericsson.com, gurtov@cs.Helsinki.FI, vern@aciri.org, tcp-impl@grc.nasa.gov, pilc@grc.nasa.gov In-Reply-To: <5.1.0.14.0.20011211181427.031f45f8@chapelle.ericsson.se> from "Reiner Ludwig" at Dec 11, 1 06:32:11 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Hello! > - proposing that the RTTVAR weight factor should be adaptive was a bad idea > :-( In later work, we found that it should stay constant at 2 or 4 > depending on whether every packet is timed or not. But do you still insist on time constants proportional to cwnd? :-) > - what we termed the "REXMT-Restart Bug" really is not a bug, but instead > an extremely valuable safeguard against spurious timeouts in case of > rapidly increasing RTTs; With disbalanced weight and ewma constants: no doubts. With small weight your algorithm would calculate strongly underestimated rto when rtt increases. > even more so when timing every packet. Do you have new paper explaing this? Without explanations this sounds strange: timing each packet cannot be worse than timing each rtt in this situation. No matter, the value of this safeguard is real, but different. What's about slow start it restarts timer too lately (with sampling each rtt) and to wrong timeout, so that its usefullness for this is just plain luck. Its real value was shown to me by Andrey Gurtov about year ago: it allows to avoid RTO waiting for outstanding segments trigger fast retransmit. This is real effect. Alexey From owner-tcp-impl@grc.nasa.gov Tue Dec 11 14:12:00 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23230 for ; Tue, 11 Dec 2001 14:11:59 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 0692964188; Tue, 11 Dec 2001 14:12:01 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAySa48U; Tue, 11 Dec 01 14:12:01 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA26634 for tcp-impl-outgoing; Tue, 11 Dec 2001 14:02:16 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA26614 for ; Tue, 11 Dec 2001 14:02:13 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id OAA07842 for ; Tue, 11 Dec 2001 14:02:12 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 28764C6920; Tue, 11 Dec 2001 13:57:21 -0500 (EST) Received: from sparkle.rodents.montreal.qc.ca(216.46.5.7) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAGGaOTt; Tue, 11 Dec 01 13:57:20 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA04972; Tue, 11 Dec 2001 13:57:13 -0500 (EST) Date: Tue, 11 Dec 2001 13:57:13 -0500 (EST) From: der Mouse Message-Id: <200112111857.NAA04972@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: tcp-impl@grc.nasa.gov Cc: ajiv@qpackets.com Subject: Re: regarding URG and PSH flags in send() call Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > In the Linux stack version 2.4.2, how the urgent and push flags are > set in the send() user call ? I don't know Linux specifically. But unless they've broken compatability with Berkeley (which invented send()), URG is set only when userland does an "out-of-band" send and PSH is set at the end of each send() (or other calls which write data, such as write()). > The application gives the send call as > int send (int sockfd, const void *msg, int len, int flags); > what is the flags mentioned in the above send() call? This is rather an RTFM. See the manpage for send(). Mine (which, again, isn't Linux) says The flags parameter may include one or more of the following: #define MSG_OOB 0x1 /* process out-of-band data */ #define MSG_DONTROUTE 0x4 /* bypass routing, use direct interface */ The OOB notion is a gross (and broken) kludge, at least as applied to TCP, but that's a rant for another message. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@grc.nasa.gov Tue Dec 11 14:32:12 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23614 for ; Tue, 11 Dec 2001 14:32:11 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 012A5C68F9; Tue, 11 Dec 2001 14:32:13 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAULaqsE; Tue, 11 Dec 01 14:32:13 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA02051 for tcp-impl-outgoing; Tue, 11 Dec 2001 14:22:16 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA02003; Tue, 11 Dec 2001 14:22:11 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id OAA09992; Tue, 11 Dec 2001 14:22:09 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id F14DD6417E; Tue, 11 Dec 2001 14:21:52 -0500 (EST) Received: from 109-202-131-12.bellhead.com(12.131.202.109) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAw7aacY; Tue, 11 Dec 01 14:21:52 -0500 Received: (from karn@localhost) by maggie.ka9q.net (8.11.1/8.9.3/Debian 8.9.3-21) id fBBJLeQ00986; Tue, 11 Dec 2001 11:21:40 -0800 Date: Tue, 11 Dec 2001 11:21:40 -0800 Message-Id: <200112111921.fBBJLeQ00986@maggie.ka9q.net> From: Phil Karn To: dab@restless.weston.bsdi.com Cc: mallman@grc.nasa.gov, Reiner.Ludwig@Ericsson.com, gurtov@cs.Helsinki.FI, pilc@grc.nasa.gov, tcp-impl@grc.nasa.gov, vern@aciri.org In-reply-to: <200112111658.fBBGwd000600@restless.weston.bsdi.com> (dab@restless.weston.bsdi.com) Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Reply-To: karn@ka9q.net References: <200112111658.fBBGwd000600@restless.weston.bsdi.com> Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk >Without the Timestamps option, due to the Karn algorithm, you do not >get an RTT measurment when there is packet loss. If you are losing 1 >packet per RTT, you get into a state where you don't get any packet >timing information. Dave, No question -- TCP timestamps are a *much* better solution to the RTT measurement problem than my algorithm. But what you say about my algorithm is not quite true. Its whole point is to ensure that you'll eventually get an accurate RTT measurement after a retransmission no matter what the original RTO setting was. You won't "get into a state" where no further timing info arrives. Unless, of course, *none* of the retransmissions get through, in which case timestamps wouldn't work much better. Phil From owner-tcp-impl@grc.nasa.gov Tue Dec 11 14:32:15 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23627 for ; Tue, 11 Dec 2001 14:32:15 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 52C00641A3; Tue, 11 Dec 2001 14:32:15 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAU5aGX1; Tue, 11 Dec 01 14:32:15 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA02049 for tcp-impl-outgoing; Tue, 11 Dec 2001 14:22:16 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA02010; Tue, 11 Dec 2001 14:22:13 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id OAA10011; Tue, 11 Dec 2001 14:22:09 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 9B5B5C692C; Tue, 11 Dec 2001 14:14:01 -0500 (EST) Received: from 109-202-131-12.bellhead.com(12.131.202.109) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAp3aGny; Tue, 11 Dec 01 14:14:01 -0500 Received: (from karn@localhost) by maggie.ka9q.net (8.11.1/8.9.3/Debian 8.9.3-21) id fBBJDkE00981; Tue, 11 Dec 2001 11:13:46 -0800 Date: Tue, 11 Dec 2001 11:13:46 -0800 Message-Id: <200112111913.fBBJDkE00981@maggie.ka9q.net> From: Phil Karn To: Reiner.Ludwig@Ericsson.com Cc: mallman@grc.nasa.gov, gurtov@cs.Helsinki.FI, vern@aciri.org, tcp-impl@grc.nasa.gov, pilc@grc.nasa.gov In-reply-to: <5.1.0.14.0.20011211123031.01d74c18@chapelle.ericsson.se> (message from Reiner Ludwig on Tue, 11 Dec 2001 13:26:13 +0100) Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Reply-To: karn@qualcomm.com References: <5.1.0.14.0.20011211123031.01d74c18@chapelle.ericsson.se> Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk >In my research, I confirm Mark & Vern's finding that in today's >Internet a timer granularity of 100 ms gives the best trade-off >between timer accuracy vs. host processing load due to timer >handling. However, the RTO does get more precise when going down to >10 ms timer ticks, but it's mostly not worth the effort. This might >change in the future when typical Internet RTTs come below >100ms. Then, a 10 ms timer granularity is probably more appropriate. Are you referring to the granularity of the RTT measurements, or the granularity of the timer used to schedule retransmissions? These are often different on many operating systems. E.g., Linux sets the clock interrupt to 100 Hz, meaning it can schedule actions to a 10 ms granularity (modulo CPU scheduling delays). But the x86 hardware lets you read the CPU clock directly, making it possible to achieve extremely fine granularity (1ns for a 1GHz system) when timestamping events like receiving a packet. Phil From owner-tcp-impl@grc.nasa.gov Tue Dec 11 15:17:10 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24200 for ; Tue, 11 Dec 2001 15:17:10 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id C5531642BF; Tue, 11 Dec 2001 15:16:30 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAYnaiul; Tue, 11 Dec 01 15:16:30 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA16189 for tcp-impl-outgoing; Tue, 11 Dec 2001 15:06:15 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA16174; Tue, 11 Dec 2001 15:06:13 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id PAA16116; Tue, 11 Dec 2001 15:06:12 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 20589641F7; Tue, 11 Dec 2001 14:52:23 -0500 (EST) Received: from lightning.swansea.linux.org.uk(194.168.151.1) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAABKaGuc; Tue, 11 Dec 01 14:52:22 -0500 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 16Dt5r-0006Pl-00; Tue, 11 Dec 2001 20:01:35 +0000 Subject: Re: Doubt regarding the MANAGING THE RTO TIMER To: karn@qualcomm.com Date: Tue, 11 Dec 2001 20:01:35 +0000 (GMT) Cc: Reiner.Ludwig@Ericsson.com, mallman@grc.nasa.gov, gurtov@cs.Helsinki.FI, vern@aciri.org, tcp-impl@grc.nasa.gov, pilc@grc.nasa.gov In-Reply-To: <200112111913.fBBJDkE00981@maggie.ka9q.net> from "Phil Karn" at Dec 11, 2001 11:13:46 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > you read the CPU clock directly, making it possible to achieve > extremely fine granularity (1ns for a 1GHz system) when timestamping > events like receiving a packet. Only if you are comparing per processor. The x86 world makes no guarantee that your processors are clocking at the same rate or started at the same clock. From owner-tcp-impl@grc.nasa.gov Tue Dec 11 19:01:18 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27985 for ; Tue, 11 Dec 2001 19:01:18 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 5625E642FF; Tue, 11 Dec 2001 19:00:19 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAzRaimd; Tue, 11 Dec 01 19:00:19 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA03573 for tcp-impl-outgoing; Tue, 11 Dec 2001 18:52:21 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA03551; Tue, 11 Dec 2001 18:52:18 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id SAA09962; Tue, 11 Dec 2001 18:52:16 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 115D6C6925; Tue, 11 Dec 2001 18:50:07 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAqkaWCB; Tue, 11 Dec 01 18:50:06 -0500 Received: from aachen.eed.ericsson.se (aachen.eed.ericsson.se [164.48.130.2]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fBBNo1K07360; Wed, 12 Dec 2001 00:50:01 +0100 (MET) Received: from res0010384da36.ericsson.com (rmt160173.am.ericsson.se [138.85.160.173]) by aachen.eed.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id AAA09588; Wed, 12 Dec 2001 00:49:56 +0100 (MET) Message-Id: <5.1.0.14.0.20011212003008.01de4f40@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 12 Dec 2001 00:30:59 +0100 To: karn@qualcomm.com From: Reiner Ludwig Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Cc: tcp-impl@grc.nasa.gov, pilc@grc.nasa.gov In-Reply-To: <200112111913.fBBJDkE00981@maggie.ka9q.net> References: <5.1.0.14.0.20011211123031.01d74c18@chapelle.ericsson.se> <5.1.0.14.0.20011211123031.01d74c18@chapelle.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk At 20:13 11.12.2001, Phil Karn wrote: > >In my research, I confirm Mark & Vern's finding that in today's > >Internet a timer granularity of 100 ms gives the best trade-off > >between timer accuracy vs. host processing load due to timer > >handling. However, the RTO does get more precise when going down to > >10 ms timer ticks, but it's mostly not worth the effort. This might > >change in the future when typical Internet RTTs come below > >100ms. Then, a 10 ms timer granularity is probably more appropriate. > >Are you referring to the granularity of the RTT measurements, or the >granularity of the timer used to schedule retransmissions? The latter. ///Reiner From owner-tcp-impl@grc.nasa.gov Tue Dec 11 19:02:37 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28032 for ; Tue, 11 Dec 2001 19:02:36 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 93785C6A57; Tue, 11 Dec 2001 19:00:19 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAGVaGLD; Tue, 11 Dec 01 19:00:19 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA03409 for tcp-impl-outgoing; Tue, 11 Dec 2001 18:50:12 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA03405; Tue, 11 Dec 2001 18:50:10 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id SAA09855; Tue, 11 Dec 2001 18:50:09 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id A522464096; Tue, 11 Dec 2001 18:50:09 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAATYaqFa; Tue, 11 Dec 01 18:50:09 -0500 Received: from aachen.eed.ericsson.se (aachen.eed.ericsson.se [164.48.130.2]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fBBNo6K07384; Wed, 12 Dec 2001 00:50:06 +0100 (MET) Received: from res0010384da36.ericsson.com (rmt160173.am.ericsson.se [138.85.160.173]) by aachen.eed.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id AAA09630; Wed, 12 Dec 2001 00:50:01 +0100 (MET) Message-Id: <5.1.0.14.0.20011212003234.0329f8c0@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 12 Dec 2001 00:44:46 +0100 To: kuznet@ms2.inr.ac.ru From: Reiner Ludwig Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Cc: mallman@grc.nasa.gov, gurtov@cs.Helsinki.FI, vern@aciri.org, tcp-impl@grc.nasa.gov, pilc@grc.nasa.gov In-Reply-To: <200112111816.VAA03080@ms2.inr.ac.ru> References: <5.1.0.14.0.20011211181427.031f45f8@chapelle.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk At 19:16 11.12.2001, you wrote: > > - proposing that the RTTVAR weight factor should be adaptive was a bad > idea > > :-( In later work, we found that it should stay constant at 2 or 4 > > depending on whether every packet is timed or not. > >But do you still insist on time constants proportional to cwnd? :-) The gains (1/4 and 1/8) should be made proportional to the flight size when timing every packet. The RTTVAR weight (4) should remain a constant, e.g., 2, 3, or 4, although 3 might be a bad choice because of computing complexity. > > - what we termed the "REXMT-Restart Bug" really is not a bug, but instead > > an extremely valuable safeguard against spurious timeouts in case of > > rapidly increasing RTTs; > >With disbalanced weight and ewma constants: no doubts. With small weight >your algorithm would calculate strongly underestimated rto when rtt increases. I don't follow. Please, explain in more detail. > > even more so when timing every packet. > >Do you have new paper explaing this? Can you read German? :-) A student of mine finished his diploma thesis on this. >Without explanations this sounds >strange: timing each packet cannot be worse than timing each rtt >in this situation. Consider packet N and N+1. If the RTT for N suddenly increases (compared to SRTT) then chances are that the RTT for N+1 will also be increased. Restarting the retransmission timer when the ACK for N arrives, indirectly factors that RTT increase into the retransmission timer setting for N+1. For this safeguard to be there all the time requires that every packet is timed. >No matter, the value of this safeguard is real, but different. >What's about slow start it restarts timer too lately (with sampling >each rtt) and to wrong timeout, so that its usefullness for this >is just plain luck. Its real value was shown to me by Andrey Gurtov >about year ago: it allows to avoid RTO waiting for outstanding segments >trigger fast retransmit. This is real effect. True. ///Reiner From owner-tcp-impl@grc.nasa.gov Tue Dec 11 21:22:45 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00442 for ; Tue, 11 Dec 2001 21:22:45 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id A9634C690C; Tue, 11 Dec 2001 21:22:48 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAP6aWA0; Tue, 11 Dec 01 21:22:48 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA19413 for tcp-impl-outgoing; Tue, 11 Dec 2001 21:11:23 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA19399; Tue, 11 Dec 2001 21:11:17 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id VAA18775; Tue, 11 Dec 2001 21:11:17 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 7885064170; Tue, 11 Dec 2001 21:10:21 -0500 (EST) Received: from cwcsun41.cwc.nus.edu.sg(137.132.163.102) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAABuay7C; Tue, 11 Dec 01 21:10:20 -0500 Received: from liawys.cwc.nus.edu.sg ([172.16.2.234]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with ESMTP id KAA04428; Wed, 12 Dec 2001 10:08:37 +0800 (SGT) Message-Id: <4.3.2.7.2.20011212100651.00b11590@postman.cwc.nus.edu.sg> X-Sender: liawys@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Dec 2001 10:15:02 +0800 To: karn@ka9q.net, dab@restless.weston.bsdi.com From: Liaw Yong Shyang Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Cc: mallman@grc.nasa.gov, Reiner.Ludwig@Ericsson.com, gurtov@cs.Helsinki.FI, pilc@grc.nasa.gov, tcp-impl@grc.nasa.gov, vern@aciri.org In-Reply-To: <200112111921.fBBJLeQ00986@maggie.ka9q.net> References: <200112111658.fBBGwd000600@restless.weston.bsdi.com> <200112111658.fBBGwd000600@restless.weston.bsdi.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_89452066==_.ALT" Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk --=====================_89452066==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, I'm looking at using SACK option to update RTT during fast recovery. What do you think of it? RTT sample is taken using Karn's algorithm to avoid ambiguous acknowledgement from retransmitted packets, and must be taken at least once per RTT unless Karn's algorithm prevents it [RFC 2988]. During fast-recovery, no RTT sample is taken since duplicate acknowledgements are returned. Duplicate acknowledgement does not indicate the triggering packet. However, it is possible to infer the triggering packet from SACK option in the duplicate acknowledgement with SACK option, since the triggering packet is in the first SACK block of the SACK option. Hence, by checking "rtt_seq" (the sequence number when RTT sample is taken) with the first SACK block in duplicate acknowledgements, RTT sample can be updated. The algorithm: If (right edge of the 1st SACK block > rtt_seq and rtt_active) { rtt_active = 0; update RTT sample; } At 11:21 AM 12/11/01 -0800, Phil Karn wrote: > >Without the Timestamps option, due to the Karn algorithm, you do not > >get an RTT measurment when there is packet loss. If you are losing 1 > >packet per RTT, you get into a state where you don't get any packet > >timing information. > >Dave, > >No question -- TCP timestamps are a *much* better solution to the >RTT measurement problem than my algorithm. > >But what you say about my algorithm is not quite true. Its whole point >is to ensure that you'll eventually get an accurate RTT measurement >after a retransmission no matter what the original RTO setting >was. You won't "get into a state" where no further timing info >arrives. Unless, of course, *none* of the retransmissions get through, >in which case timestamps wouldn't work much better. > >Phil --=====================_89452066==_.ALT Content-Type: text/html; charset="us-ascii" X-MIME-Autoconverted: from 8bit to quoted-printable by cwcsun41.cwc.nus.edu.sg id KAA04428 Content-Transfer-Encoding: quoted-printable Hi,

I'm looking at using SACK option to update RTT during fast recovery.  What do you think of it?

RTT sample is taken using Karn=92s algori= thm to avoid ambiguous acknowledgement from retransmitted packets, and must be taken at least once per RTT unless Karn=92s algorithm prevents it [RFC 2988].  During fast-recovery, no RTT sample is taken since duplicate acknowledgements are returned.  Duplicate acknowledgement does not indicate the triggering packet.  However, it is possible to infer the triggering packet from SACK option in the duplicate acknowledgement with SACK option, since the triggering packet is in the first SACK block of the SACK option.  Hence, by checking =93rtt_seq=94 (the sequence number when RTT sample is taken) with the first SACK block in duplicate acknowledgements, RTT sample can be updated.

The algorithm:

If (right edge of the 1st SACK block > rtt_seq and rtt_active) {
        &nb= sp;       rtt_active =3D 0;
        &nb= sp;       update RTT sample;
}



At 11:21 AM 12/11/01 -0800, Phil Karn wrote:
>Without the Timestamps option, due to th= e Karn algorithm, you do not
>get an RTT measurment when there is packet loss.  If you are losing 1
>packet per RTT, you get into a state where you don't get any packet
>timing information.

Dave,

No question -- TCP timestamps are a *much* better solution to the
RTT measurement problem than my algorithm.

But what you say about my algorithm is not quite true. Its whole point
is to ensure that you'll eventually get an accurate RTT measurement
after a retransmission no matter what the original RTO setting
was. You won't "get into a state" where no further timing info
arrives.  Unless, of course, *none* of the retransmissions get through,
in which case timestamps wouldn't work much better.

Phil
--=====================_89452066==_.ALT-- From owner-tcp-impl@grc.nasa.gov Wed Dec 12 01:12:06 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06104 for ; Wed, 12 Dec 2001 01:12:06 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id E8E18641CD; Wed, 12 Dec 2001 01:11:44 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAbGaGPl; Wed, 12 Dec 01 01:11:44 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA10246 for tcp-impl-outgoing; Wed, 12 Dec 2001 01:02:25 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA10218; Wed, 12 Dec 2001 01:02:23 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id BAA00230; Wed, 12 Dec 2001 01:02:21 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 9D356C6951; Wed, 12 Dec 2001 00:59:09 -0500 (EST) Received: from 109-202-131-12.bellhead.com(12.131.202.109) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAZdaqyz; Wed, 12 Dec 01 00:59:09 -0500 Received: (from karn@localhost) by maggie.ka9q.net (8.11.1/8.9.3/Debian 8.9.3-21) id fBC5wla00442; Tue, 11 Dec 2001 21:58:47 -0800 Date: Tue, 11 Dec 2001 21:58:47 -0800 Message-Id: <200112120558.fBC5wla00442@maggie.ka9q.net> From: Phil Karn To: alan@lxorguk.ukuu.org.uk Cc: Reiner.Ludwig@Ericsson.com, mallman@grc.nasa.gov, gurtov@cs.Helsinki.FI, vern@aciri.org, tcp-impl@grc.nasa.gov, pilc@grc.nasa.gov In-reply-to: (message from Alan Cox on Tue, 11 Dec 2001 20:01:35 +0000 (GMT)) Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Reply-To: karn@ka9q.net References: Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Good point, the multi-CPU case hadn't occurred to me. But don't most multi-CPU motherboards use a common clock for all CPUs, at least when they're all running at the same clock rate? And aren't the CPU reset pins driven from the same source? If so, the CPU clock counters should be pretty close. So, in practice, how matched are the RDTSC timestamps on a multi-CPU machine? Phil From owner-tcp-impl@grc.nasa.gov Wed Dec 12 01:41:42 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10023 for ; Wed, 12 Dec 2001 01:41:41 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id B7B8064276; Wed, 12 Dec 2001 01:39:55 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAysaiQs; Wed, 12 Dec 01 01:39:55 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA14282 for tcp-impl-outgoing; Wed, 12 Dec 2001 01:32:21 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA14270; Wed, 12 Dec 2001 01:32:20 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id BAA02341; Wed, 12 Dec 2001 01:32:18 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 0AD33C6906; Wed, 12 Dec 2001 01:31:40 -0500 (EST) Received: from 109-202-131-12.bellhead.com(12.131.202.109) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA4oaGyF; Wed, 12 Dec 01 01:31:39 -0500 Received: (from karn@localhost) by maggie.ka9q.net (8.11.1/8.9.3/Debian 8.9.3-21) id fBC6VaW00505; Tue, 11 Dec 2001 22:31:36 -0800 Date: Tue, 11 Dec 2001 22:31:36 -0800 Message-Id: <200112120631.fBC6VaW00505@maggie.ka9q.net> From: Phil Karn To: Reiner.Ludwig@Ericsson.com Cc: tcp-impl@grc.nasa.gov, pilc@grc.nasa.gov In-reply-to: <5.1.0.14.0.20011212003008.01de4f40@chapelle.ericsson.se> (message from Reiner Ludwig on Wed, 12 Dec 2001 00:30:59 +0100) Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Reply-To: karn@ka9q.net References: <5.1.0.14.0.20011211123031.01d74c18@chapelle.ericsson.se> <5.1.0.14.0.20011211123031.01d74c18@chapelle.ericsson.se> <5.1.0.14.0.20011212003008.01de4f40@chapelle.ericsson.se> Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk >The latter. Ah. So how accurately can events now be scheduled on the various OSes? I haven't kept up with this stuff. The PC architecture has always provided multiple hardware timer channels that can be programmed to interrupt at some future time, either in a one-shot or a repeating mode. The granularity is set by the clock to the timer chip, which is considerably slower than the CPU clock. One of these timers is usually programmed at boot time to interrupt at a 100 Hz rate, and this drives most of the timer events in UNIX and UNIX-like kernels. The original PC had four timer channels. One was used to provide a clock tick to the OS and another was dedicated to memory refresh (this is probably all different now -- I haven't actively programmed at this level since 1990 or so). That left at least one spare timer channel that could schedule an interrupt with a granularity much better than 10 ms. So you sort your scheduled events into a list and set the hardware timer for the first event. When it ticks, you pop the top item off the list, execute it and reload the timer with the appropriate interval for the next event. I did this in my NOS TCP/IP code for scheduling TCP transmissions and it worked well. I don't know if any modern OSes provide a fine-grained scheduling feature like this, but TCP sure would find it useful, especially for transmit pacing. Phil From owner-tcp-impl@grc.nasa.gov Wed Dec 12 02:26:27 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22446 for ; Wed, 12 Dec 2001 02:26:27 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 6BC2C6427B; Wed, 12 Dec 2001 02:24:32 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAcYaGCC; Wed, 12 Dec 01 02:24:32 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA19627 for tcp-impl-outgoing; Wed, 12 Dec 2001 02:16:19 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA19620 for ; Wed, 12 Dec 2001 02:16:18 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id CAA05095 for ; Wed, 12 Dec 2001 02:16:17 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 3EC426417E; Wed, 12 Dec 2001 02:13:20 -0500 (EST) Received: from sparkle.rodents.montreal.qc.ca(216.46.5.7) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAmDaWxA; Wed, 12 Dec 01 02:13:19 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id CAA08786; Wed, 12 Dec 2001 02:13:15 -0500 (EST) Date: Wed, 12 Dec 2001 02:13:15 -0500 (EST) From: der Mouse Message-Id: <200112120713.CAA08786@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: tcp-impl@grc.nasa.gov Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > Good point, the multi-CPU case hadn't occurred to me. > But don't most multi-CPU motherboards use a common clock for all > CPUs, at least when they're all running at the same clock rate? And > aren't the CPU reset pins driven from the same source? If so, the CPU > clock counters should be pretty close. Perhaps. So? Do you really want to build a TCP stack that breaks (or misbehaves badly) because of totally weirded-out RTT estimates when run on baords that don't match your assumptions? Or is this solely for heavily-instrumented research use? In that case, I withdraw the above objection. Another possible objection: I've heard of CPUs that throttle back their clock rate if they start to overheat. If one CPU heats up and the other doesn't, will they both throttle back in sync, or will only the hot one? If the latter, ISTM this has potential to skew their clock counters. Unless, again, you're doing this for research use, in which case you can just avoid such CPUs, or avoid such CPUs in multi-CPU machines (though you may want to avoid them entirely, since the time interval you'll get will depend on how much clock throttling has happened during the round trip you're timing). /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@grc.nasa.gov Wed Dec 12 02:46:17 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22618 for ; Wed, 12 Dec 2001 02:46:17 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id D32B664275; Wed, 12 Dec 2001 02:43:19 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAA1ba4VH; Wed, 12 Dec 01 02:43:19 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA22303 for tcp-impl-outgoing; Wed, 12 Dec 2001 02:37:22 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA22295 for ; Wed, 12 Dec 2001 02:37:21 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id CAA07032 for ; Wed, 12 Dec 2001 02:37:16 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 966A9C69F4; Wed, 12 Dec 2001 02:29:11 -0500 (EST) Received: from sparkle.rodents.montreal.qc.ca(216.46.5.7) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAh0aOjQ; Wed, 12 Dec 01 02:29:10 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id CAA08877; Wed, 12 Dec 2001 02:29:08 -0500 (EST) Date: Wed, 12 Dec 2001 02:29:08 -0500 (EST) From: der Mouse Message-Id: <200112120729.CAA08877@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: tcp-impl@grc.nasa.gov Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > The PC architecture has always provided multiple hardware timer [...] That's fine...if you are writing a TCP stack that never runs on anything but a "PC architecture" machine. I suspect that a stack that marginalizes machines without sufficiently fancy timer hardware will get a rather cool reception. (I sure know it will from me, not that I see much reason to care what one lone gadfly thinks. :-) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@grc.nasa.gov Wed Dec 12 03:06:35 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22789 for ; Wed, 12 Dec 2001 03:06:34 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 451D76428F; Wed, 12 Dec 2001 03:04:49 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAn1aOSM; Wed, 12 Dec 01 03:04:49 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA25137 for tcp-impl-outgoing; Wed, 12 Dec 2001 02:57:35 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA25129 for ; Wed, 12 Dec 2001 02:57:34 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id CAA08497 for ; Wed, 12 Dec 2001 02:57:33 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 5131C6417E; Wed, 12 Dec 2001 02:53:39 -0500 (EST) Received: from unknown(202.125.87.14) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAZZaWLK; Wed, 12 Dec 01 02:53:37 -0500 Received: from vlsi6 (machine35 [172.16.1.35]) by brahma.roc.com (8.9.3/8.8.7) with SMTP id NAA01153 for ; Wed, 12 Dec 2001 13:28:51 +0530 From: "praveen" To: Subject: Query on Acking Out of sequence data Date: Wed, 12 Dec 2001 13:25:22 +0530 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi, When TCP receives out of sequence data, its required to send an Immediate ACK (this is a Duplicate ACK). If The TCP has pending data to be sent, Can this data go along with this immediate ACK? Thanks Praveen From owner-tcp-impl@grc.nasa.gov Wed Dec 12 06:22:29 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24485 for ; Wed, 12 Dec 2001 06:22:28 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 2F2C06431D; Wed, 12 Dec 2001 06:21:14 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAqaaakn; Wed, 12 Dec 01 06:21:13 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA15070 for tcp-impl-outgoing; Wed, 12 Dec 2001 06:12:49 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id GAA15062; Wed, 12 Dec 2001 06:12:48 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id GAA26720; Wed, 12 Dec 2001 06:12:47 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id E4BDCC6972; Wed, 12 Dec 2001 06:10:45 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se(194.237.142.116) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA1JaWRp; Wed, 12 Dec 01 06:10:45 -0500 Received: from aachen.eed.ericsson.se (aachen.eed.ericsson.se [164.48.130.2]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fBCBAhJ07662; Wed, 12 Dec 2001 12:10:43 +0100 (MET) Received: from res0010384da36.ericsson.com (rmt160226.am.ericsson.se [138.85.160.226]) by aachen.eed.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id MAA08376; Wed, 12 Dec 2001 12:10:39 +0100 (MET) Message-Id: <5.1.0.14.0.20011212115708.0329fc78@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 12 Dec 2001 12:03:14 +0100 To: karn@ka9q.net From: Reiner Ludwig Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Cc: Reiner.Ludwig@Ericsson.com, tcp-impl@grc.nasa.gov, pilc@grc.nasa.gov In-Reply-To: <200112120631.fBC6VaW00505@maggie.ka9q.net> References: <5.1.0.14.0.20011212003008.01de4f40@chapelle.ericsson.se> <5.1.0.14.0.20011211123031.01d74c18@chapelle.ericsson.se> <5.1.0.14.0.20011211123031.01d74c18@chapelle.ericsson.se> <5.1.0.14.0.20011212003008.01de4f40@chapelle.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk At 07:31 12.12.2001, Phil Karn wrote: >So you sort your scheduled events into a list and set the hardware >timer for the first event. When it ticks, you pop the top item off the >list, execute it and reload the timer with the appropriate interval >for the next event. I did this in my NOS TCP/IP code for scheduling >TCP transmissions and it worked well. > >I don't know if any modern OSes provide a fine-grained scheduling >feature like this, but TCP sure would find it useful, especially >for transmit pacing. At one point Keith Sklower at UC Berkeley and myself were thinking of implementing that feature for FreeBSD, but we never got around to do it. That would certainly make a difference given that FreeBSD still uses a timer tick of 500 ms for TCP's retransmission timer :-( BTW, since you asked. I believe that latest - Solaris uses 10 ms ticks, - LINUX uses 10 ms ticks, and - MS uses 100 ms ticks. ///Reiner From owner-tcp-impl@grc.nasa.gov Wed Dec 12 06:23:10 2001 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24499 for ; Wed, 12 Dec 2001 06:23:10 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 0FF81C692C; Wed, 12 Dec 2001 06:21:14 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAB_aiSr; Wed, 12 Dec 01 06:21:13 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA14994 for tcp-impl-outgoing; Wed, 12 Dec 2001 06:11:38 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id GAA14984 for ; Wed, 12 Dec 2001 06:11:37 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id GAA26638 for ; Wed, 12 Dec 2001 06:11:36 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id DBBE264141; Wed, 12 Dec 2001 06:10:52 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAALqayNk; Wed, 12 Dec 01 06:10:52 -0500 Received: from aachen.eed.ericsson.se (aachen.eed.ericsson.se [164.48.130.2]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fBCBAoK18740; Wed, 12 Dec 2001 12:10:50 +0100 (MET) Received: from res0010384da36.ericsson.com (rmt160226.am.ericsson.se [138.85.160.226]) by aachen.eed.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id MAA08385; Wed, 12 Dec 2001 12:10:47 +0100 (MET) Message-Id: <5.1.0.14.0.20011212120907.032bedb0@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 12 Dec 2001 12:09:52 +0100 To: "praveen" From: Reiner Ludwig Subject: Re: Query on Acking Out of sequence data Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk At 08:55 12.12.2001, praveen wrote: >When TCP receives out of sequence data, >its required to send an >Immediate ACK (this is a Duplicate ACK). >If The TCP has pending >data to be sent, Can this data go along >with this immediate ACK? No. A DUPACK must also be a pure ACK. ///Reiner From owner-tcp-impl@grc.nasa.gov Wed Dec 12 09:06:33 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02832 for ; Wed, 12 Dec 2001 09:06:32 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 2C49C641EE; Wed, 12 Dec 2001 09:03:05 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAA41aOwX; Wed, 12 Dec 01 09:03:04 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA12037 for tcp-impl-outgoing; Wed, 12 Dec 2001 08:53:07 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA12017 for ; Wed, 12 Dec 2001 08:53:06 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id IAA08149 for ; Wed, 12 Dec 2001 08:53:05 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 21D73C6981; Wed, 12 Dec 2001 08:51:35 -0500 (EST) Received: from lightning.swansea.linux.org.uk(194.168.151.1) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA3la4rS; Wed, 12 Dec 01 08:51:34 -0500 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 16E9vI-000198-00; Wed, 12 Dec 2001 13:59:48 +0000 Subject: Re: Doubt regarding the MANAGING THE RTO TIMER To: mouse@Rodents.Montreal.QC.CA (der Mouse) Date: Wed, 12 Dec 2001 13:59:48 +0000 (GMT) Cc: tcp-impl@grc.nasa.gov In-Reply-To: <200112120713.CAA08786@Sparkle.Rodents.Montreal.QC.CA> from "der Mouse" at Dec 12, 2001 02:13:15 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Another possible objection: I've heard of CPUs that throttle back their > clock rate if they start to overheat. If one CPU heats up and the > other doesn't, will they both throttle back in sync, or will only the > hot one? If the latter, ISTM this has potential to skew their clock > counters. The x86 world they are generally clocked together, but the bus multipliers are per cpu. The heat control is in current intel, via and amd stuff and totally changes the cpu clock speed > (though you may want to avoid them entirely, since the time interval > you'll get will depend on how much clock throttling has happened during > the round trip you're timing). Right. Increasingly I'm finding the tsc is only interesting for micro benchmarking pieces of code From owner-tcp-impl@grc.nasa.gov Wed Dec 12 09:08:03 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02918 for ; Wed, 12 Dec 2001 09:08:03 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id D7397C6A74; Wed, 12 Dec 2001 09:07:25 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA4FaiLW; Wed, 12 Dec 01 09:07:25 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA13729 for tcp-impl-outgoing; Wed, 12 Dec 2001 09:00:14 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA13717; Wed, 12 Dec 2001 09:00:13 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id JAA08761; Wed, 12 Dec 2001 09:00:11 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 4A526640E5; Wed, 12 Dec 2001 08:59:10 -0500 (EST) Received: from lightning.swansea.linux.org.uk(194.168.151.1) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAMtaiYV; Wed, 12 Dec 01 08:59:09 -0500 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 16EA3g-0001DD-00; Wed, 12 Dec 2001 14:08:28 +0000 Subject: Re: Doubt regarding the MANAGING THE RTO TIMER To: karn@ka9q.net Date: Wed, 12 Dec 2001 14:08:28 +0000 (GMT) Cc: Reiner.Ludwig@Ericsson.com, tcp-impl@grc.nasa.gov, pilc@grc.nasa.gov In-Reply-To: <200112120631.fBC6VaW00505@maggie.ka9q.net> from "Phil Karn" at Dec 11, 2001 10:31:36 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Ah. So how accurately can events now be scheduled on the various OSes? Linux we are still using 100Hz. There are patches for doing microsecond level event triggering around. > either in a one-shot or a repeating mode. The granularity is set by > the clock to the timer chip, which is considerably slower than the CPU > clock. One of these timers is usually programmed at boot time to > interrupt at a 100 Hz rate, and this drives most of the timer events > in UNIX and UNIX-like kernels. Basically the 8259 disappeared into the chipset logic, people sawed off unused bits and it doesnt do much any more. There is also the CMOS RTC timer interrupt available (several KHz) and newer machines have ACPI OS timers which run at constant rate at about 2Mhz. Alan From owner-tcp-impl@grc.nasa.gov Wed Dec 12 13:32:13 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15316 for ; Wed, 12 Dec 2001 13:32:12 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id CD101642AB; Wed, 12 Dec 2001 13:31:49 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAYHaizg; Wed, 12 Dec 01 13:31:49 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA26616 for tcp-impl-outgoing; Wed, 12 Dec 2001 13:23:41 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA26600; Wed, 12 Dec 2001 13:23:38 -0500 (EST) From: kuznet@ms2.inr.ac.ru Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id NAA09017; Wed, 12 Dec 2001 13:23:34 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 74D87C6943; Wed, 12 Dec 2001 13:23:15 -0500 (EST) Received: from minus.inr.ac.ru(193.233.7.97) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAFYa4WZ; Wed, 12 Dec 01 13:23:14 -0500 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA17142; Wed, 12 Dec 2001 21:22:56 +0300 Message-Id: <200112121822.VAA17142@ms2.inr.ac.ru> Subject: Re: Doubt regarding the MANAGING THE RTO TIMER To: Reiner.Ludwig@Ericsson.com (Reiner Ludwig) Date: Wed, 12 Dec 2001 21:22:56 +0300 (MSK) Cc: mallman@grc.nasa.gov, gurtov@cs.Helsinki.FI, vern@aciri.org, tcp-impl@grc.nasa.gov, pilc@grc.nasa.gov In-Reply-To: <5.1.0.14.0.20011212003234.0329f8c0@chapelle.ericsson.se> from "Reiner Ludwig" at Dec 12, 1 00:44:46 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Hello! > I don't follow. Please, explain in more detail. Well, in fact you have canceled the question with: > The RTTVAR weight (4) should remain a constant, e.g., 2, 3, or 4, although > 3 might be a bad choice because of computing complexity. Well, it is just basic invariant which holds VJ's formula minimally sane: alpha + beta*gamma >= 1 In this case calculated rto is never less than the last sample. So, when selecting low beta (as in your earlier approach) you have to select high gamma. As soon as you hold beta at 1/4..1/2 now, gamma=2..4 is valid. But your new approach is dubious anyway. We (linux) experienced sad failure with gain of 1/4 and sampling each packet. rttvar collapses to zero each burst of ACKs while one cwnd leaving rto at bare srtt value. This happens in reality when ACKs are compressed at receiver (I called this "erratic ACKs"), I can supply tcpdumps between solaris and linux, showing this failure. Conclusion: rttvar MUST remember information at least over one cwnd. Otherwise, the scheme is deemed to be insane. Partucularly, BSD with RTTM is sick of this too, but survives only because it simply does not use caluclated RTO for all 100% of internet connections holding it at 500...1000msec instead. > Can you read German? :-) A student of mine finished his diploma thesis on this. Alas. Though I learned it in school my memory holds only a few of words. Anyway, are his thesises with color pictures and formulas? They should be intelligible not depending on language problems. :-) > >Without explanations this sounds > >strange: timing each packet cannot be worse than timing each rtt > >in this situation. > > Consider packet N and N+1. If the RTT for N suddenly increases (compared to > SRTT) then chances are that the RTT for N+1 will also be increased. > Restarting the retransmission timer when the ACK for N arrives, indirectly > factors that RTT increase into the retransmission timer setting for N+1. > For this safeguard to be there all the time requires that every packet is > timed. I did not understand. When sampling only each rtt you even have no chances to sense the increase, not speaking about prediction of further increase. Sampling each packet cannot be worse in result. Probably you were hit by the effect of too high gain in rttvar and by effect of "erratic acks". Restart also results in some relief in this case. Alexey From owner-tcp-impl@grc.nasa.gov Wed Dec 12 13:32:51 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15345 for ; Wed, 12 Dec 2001 13:32:51 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id CB475C6A8D; Wed, 12 Dec 2001 13:31:49 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAqIayO2; Wed, 12 Dec 01 13:31:49 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA25989 for tcp-impl-outgoing; Wed, 12 Dec 2001 13:22:27 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA25965; Wed, 12 Dec 2001 13:22:26 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id NAA08666; Wed, 12 Dec 2001 13:22:23 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id ED578642C8; Wed, 12 Dec 2001 13:19:38 -0500 (EST) Received: from 248-206-131-12.bellhead.com(12.131.206.248) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAzdaGOb; Wed, 12 Dec 01 13:19:38 -0500 Received: from lawyers (mallman@localhost) by lawyers.grc.nasa.gov (8.9.3/8.9.3) with ESMTP id NAA10782; Wed, 12 Dec 2001 13:19:12 -0500 Message-Id: <200112121819.NAA10782@lawyers.grc.nasa.gov> To: Reiner Ludwig From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: "Andrei Gurtov" , Vern Paxson , tcp-impl@grc.nasa.gov, pilc@grc.nasa.gov Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Organization: BBN Technologies/NASA GRC Song-of-the-Day: Under the Bridge Date: Wed, 12 Dec 2001 13:19:12 -0500 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk > >The minimum of 1 second is a traditional aspect of the RTO timer. > > That's the one thing about RFC2988 that I never bought, and I > raised that issue when RFC2988 was last called. What you codified > was pretty much what is found in the BSD4.4-Lite implementation of > TCP, and that one sets RTO to 2x granularity, and not 1 second. The 2x the granularity is not the fundemental point, though. That is simply an implementation detail. The ultimate effect is we end up with a 1 second minimum. The analysis in our SIGCOMM paper showed that 2x the granularity was not the key to the performance, but the minimum (in seconds) was. allman --- Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ From owner-tcp-impl@grc.nasa.gov Wed Dec 12 14:01:35 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15879 for ; Wed, 12 Dec 2001 14:01:35 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id BEB6464428; Wed, 12 Dec 2001 14:00:42 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAuNaOEt; Wed, 12 Dec 01 14:00:42 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA04215 for tcp-impl-outgoing; Wed, 12 Dec 2001 13:53:21 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA04196; Wed, 12 Dec 2001 13:53:19 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id NAA11619; Wed, 12 Dec 2001 13:53:16 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 11B27C6A79; Wed, 12 Dec 2001 13:45:30 -0500 (EST) Received: from igw3.watson.ibm.com(198.81.209.18) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAFVa4yb; Wed, 12 Dec 01 13:45:29 -0500 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id fBCIjFn07148; Wed, 12 Dec 2001 13:45:15 -0500 Received: from orinoco.watson.ibm.com (orinoco.watson.ibm.com [9.2.16.142]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id fBCIjGs30362; Wed, 12 Dec 2001 13:45:16 -0500 Received: (from nahum@localhost) by orinoco.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id NAA51684; Wed, 12 Dec 2001 13:45:15 -0500 From: Erich Nahum Message-Id: <200112121845.NAA51684@orinoco.watson.ibm.com> Subject: Re: Doubt regarding the MANAGING THE RTO TIMER To: Reiner.Ludwig@Ericsson.com (Reiner Ludwig) Date: Wed, 12 Dec 2001 13:45:15 -0500 (EST) Cc: karn@ka9q.net, Reiner.Ludwig@Ericsson.com, tcp-impl@grc.nasa.gov, pilc@grc.nasa.gov In-Reply-To: <5.1.0.14.0.20011212115708.0329fc78@chapelle.ericsson.se> from "Reiner Ludwig" at Dec 12, 2001 12:03:14 PM Reply-To: nahum@watson.ibm.com (Erich M. Nahum) X-Url: http://www.research.ibm.com/people/n/nahum/ X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Reiner Ludwig writes: > > >I don't know if any modern OSes provide a fine-grained scheduling > >feature like this, but TCP sure would find it useful, especially > >for transmit pacing. > > At one point Keith Sklower at UC Berkeley and myself were thinking of > implementing that feature for FreeBSD, but we never got around to do it. > That would certainly make a difference given that FreeBSD still uses a > timer tick of 500 ms for TCP's retransmission timer :-( > > BTW, since you asked. I believe that latest > - Solaris uses 10 ms ticks, > - LINUX uses 10 ms ticks, and > - MS uses 100 ms ticks. Actually, FreeBSD discarded the 500 ms timer 2 years ago. From the changelog: | Revision 1.31 Mon Aug 30 21:17:06 1999 UTC (2 years, 3 months ago) by jlemon | Branch: MAIN | Changes since 1.30: +288 -224 lines | Diff to previous 1.30 (colored) | | Restructure TCP timeout handling: | | - eliminate the fast/slow timeout lists for TCP and instead use a | callout entry for each timer. | - increase the TCP timer granularity to HZ | - implement "bad retransmit" recovery, as presented in "On Estimating | End-to-End Network Path Properties", by Allman and Paxson. | | Submitted by: jlemon, wollmann HZ is usually 100 (10 ms clock), but can be compile-time set to larger values. Many people set HZ to 1000 to get a 1 ms clock. If you look at the timer code you'll see they're using a variant of Varghese's timing wheels algorithm. This not only helps timer granularity but scalability for servers. Since web servers have large numbers of connections, many of which are in the TIME-WAIT state, handling large numbers of timers efficiently makes a big difference in server throughput. -Erich -- Erich M. Nahum IBM T.J. Watson Research Center Networking Research P.O. Box 704 nahum@watson.ibm.com Yorktown Heights NY 10598 From owner-tcp-impl@grc.nasa.gov Wed Dec 12 15:37:40 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17633 for ; Wed, 12 Dec 2001 15:37:39 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 64E2DC6A2B; Wed, 12 Dec 2001 15:37:21 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAxtaGKC; Wed, 12 Dec 01 15:37:21 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA04116 for tcp-impl-outgoing; Wed, 12 Dec 2001 15:28:07 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA04107; Wed, 12 Dec 2001 15:28:06 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id PAA24619; Wed, 12 Dec 2001 15:28:04 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id E45C9C69AB; Wed, 12 Dec 2001 15:21:54 -0500 (EST) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAmga43y; Wed, 12 Dec 01 15:21:54 -0500 Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 16EFsx-0001Mf-00; Wed, 12 Dec 2001 20:21:47 +0000 Date: Wed, 12 Dec 2001 20:21:44 +0000 (GMT) From: Lloyd Wood X-X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Reiner Ludwig Cc: tcp-impl@grc.nasa.gov, PILC mailing list Subject: Re: Doubt regarding the MANAGING THE RTO TIMER In-Reply-To: <5.1.0.14.0.20011212003234.0329f8c0@chapelle.ericsson.se> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *16EFsx-0001Mf-00*qvbvuwVY17k* (SECM, UniS) Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk On Wed, 12 Dec 2001, Reiner Ludwig wrote: > >Do you have new paper explaing this? > > Can you read German? :-) Ja, sicherlich - und wir haben auch Babelfish und woerterbucher. > A student of mine finished his diploma thesis on this. Geben Sie den URL an, bitte. L. Reiner shy about citing his work? There's a first time for everything. PGP From owner-tcp-impl@grc.nasa.gov Thu Dec 13 07:17:53 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20239 for ; Thu, 13 Dec 2001 07:17:53 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 231EAC69B7; Thu, 13 Dec 2001 07:15:00 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAgwaW40; Thu, 13 Dec 01 07:14:59 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA22654 for tcp-impl-outgoing; Thu, 13 Dec 2001 07:01:44 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id HAA22634; Thu, 13 Dec 2001 07:01:43 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id HAA29720; Thu, 13 Dec 2001 07:01:42 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id EFBA9C68DD; Thu, 13 Dec 2001 07:01:25 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAtIaaHY; Thu, 13 Dec 01 07:01:25 -0500 Received: from aachen.eed.ericsson.se (aachen.eed.ericsson.se [164.48.130.2]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fBDC1NK15187; Thu, 13 Dec 2001 13:01:23 +0100 (MET) Received: from res0010384da36.ericsson.com (rmt160183.am.ericsson.se [138.85.160.183]) by aachen.eed.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id NAA05494; Thu, 13 Dec 2001 13:01:16 +0100 (MET) Message-Id: <5.1.0.14.0.20011213014034.032cec10@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 13 Dec 2001 01:47:30 +0100 To: Lloyd Wood From: Reiner Ludwig Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Cc: Reiner Ludwig , tcp-impl@grc.nasa.gov, PILC mailing list In-Reply-To: References: <5.1.0.14.0.20011212003234.0329f8c0@chapelle.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk At 21:21 12.12.2001, Lloyd Wood wrote: > > Can you read German? :-) > >Ja, sicherlich - und wir haben auch Babelfish und woerterbucher. I have to appologize. The diploma thesis I referred to is written in English :-) So forget about the Babelfish. >Geben Sie den URL an, bitte. That's the tricky part, but I'll get that fixed. Please, let me know via direct mail (not bothering people on the lists) if you're interested in getting a copy of that thesis. ///Reiner From owner-tcp-impl@grc.nasa.gov Thu Dec 13 08:41:29 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20743 for ; Thu, 13 Dec 2001 08:41:28 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 29001C6A05; Thu, 13 Dec 2001 08:41:15 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAALXa4Tl; Thu, 13 Dec 01 08:41:14 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA07855 for tcp-impl-outgoing; Thu, 13 Dec 2001 08:31:15 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA07850; Thu, 13 Dec 2001 08:31:14 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id IAA05872; Thu, 13 Dec 2001 08:31:14 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 81B0FC6932; Thu, 13 Dec 2001 08:25:28 -0500 (EST) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAApPaqai; Thu, 13 Dec 01 08:25:28 -0500 Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 16EVrU-0003rx-00; Thu, 13 Dec 2001 13:25:20 +0000 Date: Thu, 13 Dec 2001 13:25:12 +0000 (GMT) From: Lloyd Wood X-X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Reiner Ludwig Cc: tcp-impl@grc.nasa.gov, PILC mailing list Subject: Re: Doubt regarding the MANAGING THE RTO TIMER In-Reply-To: <5.1.0.14.0.20011213014034.032cec10@chapelle.ericsson.se> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *16EVrU-0003rx-00*nTzLQv4m35E* (SECM, UniS) Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk On Thu, 13 Dec 2001, Reiner Ludwig wrote: > At 21:21 12.12.2001, Lloyd Wood wrote: > > > Can you read German? :-) > > > >Ja, sicherlich - und wir haben auch Babelfish und woerterbucher. > > I have to appologize. The diploma thesis I referred to is written in > English :-) so easy the two to confuse it is. L. PGP From owner-tcp-impl@grc.nasa.gov Fri Dec 14 05:56:57 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27891 for ; Fri, 14 Dec 2001 05:56:57 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id C595DC693A; Fri, 14 Dec 2001 05:56:47 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA5FaqFe; Fri, 14 Dec 01 05:56:47 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA25416 for tcp-impl-outgoing; Fri, 14 Dec 2001 05:42:59 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id FAA25412 for ; Fri, 14 Dec 2001 05:42:58 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id FAA20904 for ; Fri, 14 Dec 2001 05:42:57 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id F1107640CD; Fri, 14 Dec 2001 05:42:56 -0500 (EST) Received: from unknown(202.125.87.14) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAlmaaiD; Fri, 14 Dec 01 05:42:54 -0500 Received: from vsskumar.qpackets.com (machine235 [172.16.1.235]) by brahma.roc.com (8.9.3/8.8.7) with ESMTP id QAA27165 for ; Fri, 14 Dec 2001 16:18:10 +0530 Message-Id: <5.0.1.4.1.20011214160016.00a847c0@qpackets.com> X-Sender: vsskumar@qpackets.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 14 Dec 2001 16:10:13 +0530 To: tcp-impl@grc.nasa.gov From: kumar Subject: A doubt regarding retransmitted segment. Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_194335750==_.ALT" Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk --=====================_194335750==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi all, I need a small clarification on segments that are to be retransmitted. DOUBT : Lets say, that applicaion A (sending TCP) has sent application B (Receiving TCP) a segment of 1000 bytes. Of these 1000 only 500 reached B and A has to retransmit the rest (500 bytes). 1 ) Can A now send a segment of these 500 bytes only ? Or, it MUST append 500 bytes lying next to this segment and then send a segment of 1000 bytes ? Which of the above should be followed ? 2 ) if the former is allowed, does it lead to silly wondow syndrome (lets say, instead of 500 bytes we had to retransmit 50 bytes)? expecting ur response. thanks kumar --=====================_194335750==_.ALT Content-Type: text/html; charset="us-ascii" Hi all,
      I need a small clarification on segments that are to be retransmitted.

 DOUBT : Lets say, that applicaion A (sending TCP) has sent application B (Receiving TCP) a segment of 1000 bytes. Of these 1000 only 500 reached B and A has to retransmit the rest (500 bytes).

1 )  Can A now send a segment of these 500 bytes only ? Or, it MUST append 500 bytes lying next to this segment and then send a
segment of 1000 bytes ? Which of the above should be followed ?
2 )  if the former is allowed, does it lead to silly wondow syndrome (lets say, instead of 500 bytes we had to retransmit 50 bytes)?

expecting ur response.
thanks
kumar --=====================_194335750==_.ALT-- From owner-tcp-impl@grc.nasa.gov Fri Dec 14 06:03:14 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27966 for ; Fri, 14 Dec 2001 06:03:14 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 58AE2C69B7; Fri, 14 Dec 2001 06:00:02 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAuaaqOf; Fri, 14 Dec 01 06:00:02 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA26010 for tcp-impl-outgoing; Fri, 14 Dec 2001 05:53:06 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id FAA26006 for ; Fri, 14 Dec 2001 05:53:05 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id FAA21249 for ; Fri, 14 Dec 2001 05:53:05 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 0DE1564234; Fri, 14 Dec 2001 05:53:05 -0500 (EST) Received: from unknown(202.125.87.14) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAxTay6E; Fri, 14 Dec 01 05:53:03 -0500 Received: from vsskumar.qpackets.com (machine235 [172.16.1.235]) by brahma.roc.com (8.9.3/8.8.7) with ESMTP id QAA27294 for ; Fri, 14 Dec 2001 16:28:21 +0530 Message-Id: <5.0.1.4.1.20011214161046.00ae9970@qpackets.com> X-Sender: vsskumar@qpackets.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 14 Dec 2001 16:20:27 +0530 To: tcp-impl@grc.nasa.gov From: kumar Subject: A doubt on PUSH bit. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk hi all, May i get a small clarification on PUSH bit in the TCP header ? DOUBT : When a segment arrives with a "push" bit set, do we need to inform the PUSH bit to the application ? From owner-tcp-impl@grc.nasa.gov Fri Dec 14 06:04:54 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27978 for ; Fri, 14 Dec 2001 06:04:53 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 16C3E64471; Fri, 14 Dec 2001 06:01:40 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAl3aiHI; Fri, 14 Dec 01 06:01:39 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA26257 for tcp-impl-outgoing; Fri, 14 Dec 2001 05:55:47 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id FAA26253 for ; Fri, 14 Dec 2001 05:55:46 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id FAA21399 for ; Fri, 14 Dec 2001 05:55:45 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 1C966C694E; Fri, 14 Dec 2001 05:54:58 -0500 (EST) Received: from unknown(202.125.87.14) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAJpa44d; Fri, 14 Dec 01 05:54:55 -0500 Received: from vsskumar.qpackets.com (machine235 [172.16.1.235]) by brahma.roc.com (8.9.3/8.8.7) with ESMTP id QAA27329 for ; Fri, 14 Dec 2001 16:30:12 +0530 Message-Id: <5.0.1.4.1.20011214162104.00ae94f0@qpackets.com> X-Sender: vsskumar@qpackets.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 14 Dec 2001 16:22:18 +0530 To: tcp-impl@grc.nasa.gov From: kumar Subject: A doubt on PUSH bit. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk hi all, May i get a small clarification on PUSH bit in the TCP header ? DOUBT : When a segment arrives with a "push" bit set, do we need to inform the PUSH bit to the application ? expecting ur reply, kumar. From owner-tcp-impl@grc.nasa.gov Fri Dec 14 06:43:23 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28173 for ; Fri, 14 Dec 2001 06:43:22 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 00200C6A1B; Fri, 14 Dec 2001 06:43:11 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAGmaWQo; Fri, 14 Dec 01 06:43:11 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA02519 for tcp-impl-outgoing; Fri, 14 Dec 2001 06:34:23 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id GAA02515 for ; Fri, 14 Dec 2001 06:34:22 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id GAA24491 for ; Fri, 14 Dec 2001 06:34:22 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id EA11DC68D1; Fri, 14 Dec 2001 06:34:21 -0500 (EST) Received: from sparkle.rodents.montreal.qc.ca(216.46.5.7) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAADMaqHm; Fri, 14 Dec 01 06:30:02 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id GAA22885; Fri, 14 Dec 2001 06:28:46 -0500 (EST) Date: Fri, 14 Dec 2001 06:28:46 -0500 (EST) From: der Mouse Message-Id: <200112141128.GAA22885@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: vsskumar@qpackets.com Cc: tcp-impl@grc.nasa.gov Subject: TCP "doubt"s Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > DOUBT : Lets say, that applicaion A (sending TCP) has sent > application B (Receiving TCP) a segment of 1000 bytes. Of these 1000 > only 500 reached B and A has to retransmit the rest (500 bytes). I don't think this is possible. If a sending TCP sends a segment, I _think_ it's all-or-nothing, that it can't partly but not entirely reach the receiving TCP. (If it's fragmented, it can partially but not entirely reach the receiving TCP's host, but if a fragment is lost reassembly will fail and the partial IP packet will be discarded rather than passed up to the TCP layer.) However, something very similar _is_ possible. If the receiving TCP can't hold all the incoming segment's data for some reason, it seems to me that it's permissible for it to ACK only the part that it can keep. Page 74 of RFC 793 seems to imply that a receiving TCP may accept some but not all of the data in an incoming segment, in which case it should, of course, ACK only the data it actually accepts. (If it can't take it all, it really should have advertised a smaller window, but I'm sure there will be cases where that's not possible.) How reasonable this is is another question. > 1 ) Can A now send a segment of these 500 bytes only ? Or, it MUST > append 500 bytes lying next to this segment and then send a segment > of 1000 bytes ? I can't see any reason it must - or even should - retransmit already-acked data just for the sake of retransmitting unacked data in the same context it was originally sent in. Of course, I've missed things plenty often before, and will again. If someone has such a reason, I daresay we'll hear about it. :-) > Which of the above should be followed ? Absent some reason it must retransmit the whole thing, I'd say it's probably better to send only the unacked stuff. > 2 ) if the former is allowed, does it lead to silly wondow syndrome > (lets say, instead of 500 bytes we had to retransmit 50 bytes)? I don't think so, provided we're careful to send a full segment if we have enough data waiting following the unacked portion. > DOUBT : When a segment arrives with a "push" bit set, do we need to > inform the PUSH bit to the application ? You should push the data to the application, if it's ready to accept it. I see no reason to tell the application where PSH bits actually appeared in the data stream; indeed, RFC793 specifically says "The exact push point might not be visible to the receiving user and the push function does not supply a record boundary marker.". However, the "receive" call from the higher layer does include a "push seen" flag in the return; this seems to be largely for user convenience, and I've never seen it actually reflected to userland in sockets, which are depressingly close to a near-universal TCP API. My impression from 793 is that PSH basically means "don't wait for more following data before getting this data to the receiving process". Implementations I've looked at behave, loosely speaking, as though every incoming segment had its PSH bit set - they never gratuitously withhold data they have from the application. PSH is perhaps more important on the transmitting TCP's send call; sockets generally behave as though every completed send()/write()/etc implies a push, unfortunate as this is in some respects. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@grc.nasa.gov Fri Dec 14 10:52:22 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01431 for ; Fri, 14 Dec 2001 10:52:21 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 27C41643D5; Fri, 14 Dec 2001 10:49:22 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAsoa4HR; Fri, 14 Dec 01 10:49:21 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA17962 for tcp-impl-outgoing; Fri, 14 Dec 2001 10:39:06 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA17929 for ; Fri, 14 Dec 2001 10:39:04 -0500 (EST) From: dab@restless.weston.bsdi.com Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id KAA12406 for ; Fri, 14 Dec 2001 10:39:01 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id D4ACBC6A22; Fri, 14 Dec 2001 10:37:42 -0500 (EST) Received: from 65-203-131-12.bellhead.com(12.131.203.65) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA_Da4Ld; Fri, 14 Dec 01 10:37:42 -0500 Received: (from dab@localhost) by restless.weston.bsdi.com (8.11.2/8.11.2) id fBEFabZ00468; Fri, 14 Dec 2001 09:36:37 -0600 (CST) Date: Fri, 14 Dec 2001 09:36:37 -0600 (CST) Message-Id: <200112141536.fBEFabZ00468@restless.weston.bsdi.com> To: tcp-impl@grc.nasa.gov, vsskumar@qpackets.com Subject: Re: A doubt on PUSH bit. Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk > Date: Fri, 14 Dec 2001 16:22:18 +0530 > From: kumar > Subject: A doubt on PUSH bit. ... > DOUBT : When a segment arrives with a "push" bit set, do we need to inform > the PUSH bit to the application ? Not the bit itself. When a packet arrives with the PUSH bit set, then any data that you have received but not yet made available to the application (including the data in this packet) needs to be made available to the application. The BSD networking stack ignores the PUSH bit on receive, because it always makes all received data available to the application. (And I'm speaking of in-seqeuence data; out-of-sequence data is not made available until the missing pieces are received.) -David Borman, dab@bsdi.com From owner-tcp-impl@grc.nasa.gov Fri Dec 14 11:07:25 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01660 for ; Fri, 14 Dec 2001 11:07:25 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 6783FC6A74; Fri, 14 Dec 2001 11:06:11 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAiOaiRn; Fri, 14 Dec 01 11:06:11 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA24255 for tcp-impl-outgoing; Fri, 14 Dec 2001 10:57:54 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA24217 for ; Fri, 14 Dec 2001 10:57:47 -0500 (EST) From: dab@restless.weston.bsdi.com Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id KAA15182 for ; Fri, 14 Dec 2001 10:57:43 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id B66B16438B; Fri, 14 Dec 2001 10:49:04 -0500 (EST) Received: from 65-203-131-12.bellhead.com(12.131.203.65) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAf9aaxR; Fri, 14 Dec 01 10:49:04 -0500 Received: (from dab@localhost) by restless.weston.bsdi.com (8.11.2/8.11.2) id fBEFlxj00491; Fri, 14 Dec 2001 09:47:59 -0600 (CST) Date: Fri, 14 Dec 2001 09:47:59 -0600 (CST) Message-Id: <200112141547.fBEFlxj00491@restless.weston.bsdi.com> To: tcp-impl@grc.nasa.gov, vsskumar@qpackets.com Subject: Re: A doubt regarding retransmitted segment. Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk > Date: Fri, 14 Dec 2001 16:10:13 +0530 > From: kumar > Subject: A doubt regarding retransmitted segment. ... > Hi all, > I need a small clarification on segments that are to be retransmitted. > > DOUBT : Lets say, that applicaion A (sending TCP) has sent application B > (Receiving TCP) a segment of 1000 bytes. Of these 1000 only 500 reached B > and A has to retransmit the rest (500 bytes). > > 1 ) Can A now send a segment of these 500 bytes only ? Or, it MUST append > 500 bytes lying next to this segment and then send a > segment of 1000 bytes ? Which of the above should be followed ? On retransmit, TCP is free to re-packetize the data. (The BSD code does.) So, there is nothing wrong with it retransmitting the next 1000 bytes instead of just the next 500 bytes. It doesn't have to, but most implmentations will include additional data if it is there. > 2 ) if the former is allowed, does it lead to silly wondow syndrome (lets > say, instead of 500 bytes we had to retransmit 50 bytes)? No. We're talking about a retransmit, not the normal data flow. If the sending TCP had already transmitted the additional 500 bytes as part of it's normal data flow, then when the retransmitted packet arrives, the trailing 500 bytes that were previously received will be trimmed off and ignored. If the additional 500 bytes of data had not been previously sent, then the sending TCP's SND_NXT will be after those 500 bytes. Its next packet will start at that point, and the normal Silly Window Avoidance code will deal with any issues. -David Borman, dab@bsdi.com From owner-tcp-impl@grc.nasa.gov Fri Dec 14 11:23:38 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02041 for ; Fri, 14 Dec 2001 11:23:37 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id DA6A7644FE; Fri, 14 Dec 2001 11:21:12 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAbUa4G2; Fri, 14 Dec 01 11:21:12 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA29100 for tcp-impl-outgoing; Fri, 14 Dec 2001 11:13:46 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA29081 for ; Fri, 14 Dec 2001 11:13:45 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id LAA17265 for ; Fri, 14 Dec 2001 11:13:43 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id AE5CEC6915; Fri, 14 Dec 2001 11:09:37 -0500 (EST) Received: from unknown(202.125.87.14) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAeraqDo; Fri, 14 Dec 01 11:09:34 -0500 Received: from sarayu (machine248 [172.16.1.248]) by brahma.roc.com (8.9.3/8.8.7) with SMTP id VAA31082 for ; Fri, 14 Dec 2001 21:44:48 +0530 Message-ID: <009e01c184ba$18493940$f80110ac@roc.com> From: "Srinivas Amaravadi" To: Subject: Doubt regarding PUSH bit, req. Date: Fri, 14 Dec 2001 21:42:11 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009B_01C184E8.2FC17050" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_009B_01C184E8.2FC17050 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Here comes a small doubt about the PUSH bit. can TCP Stack set the PUSH bit by its own. i.e, Eventhough the = Application sitting over the TCP Stack gives the send call WITHOUT psh = bit, can the stack set the psh bit and send the segment out?? if so then = on what conditions the stack sets the psh bit on the segment ?? Regards srinivas=20 ------=_NextPart_000_009B_01C184E8.2FC17050 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
Here comes a small doubt about the PUSH = bit.
can TCP Stack set the PUSH bit by its=20 own. i.e, Eventhough the Application sitting over the TCP = Stack gives=20 the send call  WITHOUT psh bit, can the stack set = the psh=20 bit and send the segment out?? if so then on what conditions the = stack sets=20 the psh bit on the segment ??
 
Regards
srinivas 
------=_NextPart_000_009B_01C184E8.2FC17050-- From owner-tcp-impl@grc.nasa.gov Fri Dec 14 12:12:50 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03147 for ; Fri, 14 Dec 2001 12:12:50 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 3F2F3C6A6E; Fri, 14 Dec 2001 12:11:59 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAADaqfH; Fri, 14 Dec 01 12:11:59 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA14511 for tcp-impl-outgoing; Fri, 14 Dec 2001 12:02:41 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA14505 for ; Fri, 14 Dec 2001 12:02:40 -0500 (EST) From: dab@restless.weston.bsdi.com Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id MAA23120 for ; Fri, 14 Dec 2001 12:02:36 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id CF8DA64302; Fri, 14 Dec 2001 11:34:59 -0500 (EST) Received: from 7-199-131-12.bellhead.com(12.131.199.7) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAA6KaWnb; Fri, 14 Dec 01 11:34:59 -0500 Received: (from dab@localhost) by restless.weston.bsdi.com (8.11.2/8.11.2) id fBEGXqG01033; Fri, 14 Dec 2001 10:33:52 -0600 (CST) Date: Fri, 14 Dec 2001 10:33:52 -0600 (CST) Message-Id: <200112141633.fBEGXqG01033@restless.weston.bsdi.com> To: srinia@trinc.com, tcp-impl@grc.nasa.gov Subject: Re: Doubt regarding PUSH bit, req. Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk > From: "Srinivas Amaravadi" > To: > Subject: Doubt regarding PUSH bit, req. > Date: Fri, 14 Dec 2001 21:42:11 +0530 ... > Here comes a small doubt about the PUSH bit. > can TCP Stack set the PUSH bit by its own. i.e, Eventhough the > Application sitting over the TCP Stack gives the send call WITHOUT psh > bit, can the stack set the psh bit and send the segment out?? if so then Yes. > on what conditions the stack sets the psh bit on the segment ?? The BSD TCP code sets the PUSH bit in any packet when there is no additional data waiting to be sent. -David Borman, dab@bsdi.com From owner-tcp-impl@grc.nasa.gov Fri Dec 14 14:07:58 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05331 for ; Fri, 14 Dec 2001 14:07:57 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 37971C6985; Fri, 14 Dec 2001 14:04:48 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAFbaWA6; Fri, 14 Dec 01 14:04:47 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA12749 for tcp-impl-outgoing; Fri, 14 Dec 2001 13:56:59 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA12729 for ; Fri, 14 Dec 2001 13:56:57 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id NAA05525 for ; Fri, 14 Dec 2001 13:56:57 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 18CED642D1; Fri, 14 Dec 2001 13:50:20 -0500 (EST) Received: from tiquini.ece.arizona.edu(128.196.29.23) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAJcaWmK; Fri, 14 Dec 01 13:50:19 -0500 Received: from yasmine.ece.arizona.edu (yasmine [128.196.28.123]) by tiquini.ece.arizona.edu (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id fBEIoFn26720 for ; Fri, 14 Dec 2001 11:50:15 -0700 (MST) Received: (from krunz@localhost) by yasmine.ece.arizona.edu (8.10.2+Sun/8.10.2) id fBEIrK426706 for tcp-impl@lerc.nasa.gov; Fri, 14 Dec 2001 11:53:20 -0700 (MST) Date: Fri, 14 Dec 2001 11:53:20 -0700 (MST) Message-Id: <200112141853.fBEIrK426706@yasmine.ece.arizona.edu> From: krunz@ece.arizona.edu To: tcp-impl@lerc.nasa.gov Subject: CFP - Mobicom 2002 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk [Appologies if you receive multiple copies of this Call for Papers ] ********************************************************************* Call for Papers *** ACM MobiCom 2002 *** The Eighth Annual International Conference on Mobile Computing and Networking September 23-26, 2002 Westin Peachtree Plaza Atlanta, Georgia, USA http://www.acm.org/sigmobile/mobicom/2002/ Sponsored by ACM SIGMOBILE Submission Deadline: March 1, 2002 ********************************************************************* MobiCom 2002 is the eighth annual conference dedicated to addressing new challenges in mobile computing and networking. MobiCom 2002 solicits papers describing significant research contributions to the field of mobile computing and networking. PAPERS: Authors are invited to submit full papers related to the theory and practice of mobile computing and networking. Original research papers (that are not currently under review by another conference or journal) are solicited. Areas of interest include, but not limited to: * Applications and computing services supporting mobile users * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity * Database and data management issues in mobile computing * Performance of mobile/wireless networks and systems * Security and privacy of mobile/wireless systems * Interaction between different layers of mobile/wireless systems * Integration and interworking of wired and wireless networks * Adaptive applications and systems for mobile environments * Distributed-system aspects of mobile systems * Operating system support for mobility * Location-dependent applications * Wireless multimedia systems * Power management * Mobile agents * Pervasive computing * Wireless sensor networks * Wireless/mobile service management and delivery All papers will be refereed by the program committee. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Kluwer Wireless Networks (WINET) and Mobile Networks and Applications (MONET) journals. CHALLENGES SESSION: Short papers (maximum of 8 pages) that challenge the mobile computing community with new technologies or visionary applications are solicited. Such papers should provide stimulating ideas or visions that may open up exciting avenues of mobile computing research. Papers will be reviewed and should be submitted using the normal submission procedure. Submitted papers should be clearly identified as intended for the Challenges Session. SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their full paper. Papers must meet the following restrictions: - No longer than 12 pages (double column); in font no smaller than 10 points - Fit properly on US Letter-sized paper (8.5 ' 11 inches) with reasonable margins - PostScript version 2 or later, or Portable Document Format (PDF) - Use only Computer Modern or standard Adobe printer fonts (i.e., Courier,Times, Roman, or Helvetica) - Other fonts may be used, but must be included in the PostScript/PDF file Instructions for submission are available at: http://www.acm.org/sigmobile/mobicom/2002/submissions/ All submitted papers will be judged based on their quality through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Authors' names must not appear in the paper or in the PostScript or PDF file. Submitted papers must not be currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs. TUTORIALS: Proposals for tutorials are solicited, and will be evaluated based on the expertise of the instructors and the relevance of the subject matter. Potential instructors should submit a tutorial proposal of at most five pages, including a biographical sketch, to the Tutorial Co-chairs (cath@ecn.purdue.edu or nhv@crhc.uiuc.edu). PANELS: Proposals are solicited for panels that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should contact the Panel Co-chairs (shroff@ecn.purdue.edu or marie-jose.montpetit@nokia.com). RESEARCH DEMOS: Proposals for research demos are solicited. Proposals should not exceed 3 pages and should include a description of the demo and equipment that will be used. Proposals for demos should be sent to the Research Demo Chair (ron@oit.gatech.edu). BEST STUDENT PAPER AWARD: Papers with a student as the primary author will be considered for the Best Student Paper Award with a cash award of $1,000 USD. Students must indicate with their submissions that they would like to be considered for this award. IMPORTANT DATES: * Paper submissions due: March 1, 2002 * Notification of acceptance: June 30, 2002 * Camera-ready version due: July 31, 2002 FOR MORE INFORMATION: Check the conference website or send email to mobicom2002@comet.columbia.edu ORGANIZING COMMITTEE: * General Chair: Ian F. Akyildiz, Georgia Institute of Technology * General Vice-Chairs: - Jason Y. B. Lin, National Chiao Tung University - Ravi Jain, Telcordia * Program Co-Chairs: - Vaduvur Bharghavan, Bytemobile - Andrew T. Campbell, Columbia University * Panels Co-Chairs: - Ness Shroff, Purdue University - Marie-Jose Montpetit, Nokia * Tutorials Co-Chairs: - Catherine Rosenberg, Purdue University - Nitin Vaidya, University of Illinois at Urbana Champaign * Publicity Co-Chairs: - Chuanyi Ji, Georgia Institute of Technology - Marwan M. Krunz, University of Arizona * Workshop Co-Chairs: - Taieb Znati, NSF and University of Pittsburgh - Mehmet Ulema, Monmouth Internet Corporation * Research Demos Chair: Ron Hutchins, Georgia Institute of Technology * Finance Chair: Edward Knightly, Rice University * Registration Chair: Suresh Singh, Portland State University * Sponsorship/Exhibit Chair: Ramesh Govindan, Univ. of Southern California * Local Arrangements Chair: Raghupathy Sivakumar: Georgia Institute of Technology * Steering Committee Chair: Imrich Chlamtac, University of Texas at Dallas From owner-tcp-impl@grc.nasa.gov Fri Dec 14 16:43:09 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08233 for ; Fri, 14 Dec 2001 16:43:08 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id E0F25C6953; Fri, 14 Dec 2001 16:39:51 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA6CayuK; Fri, 14 Dec 01 16:39:51 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA18909 for tcp-impl-outgoing; Fri, 14 Dec 2001 16:28:37 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA18899 for ; Fri, 14 Dec 2001 16:28:35 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id QAA19445 for ; Fri, 14 Dec 2001 16:28:28 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 66CA86431F; Fri, 14 Dec 2001 16:15:47 -0500 (EST) Received: from boreas.isi.edu(128.9.160.161) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAA2VayHq; Fri, 14 Dec 01 16:15:47 -0500 Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id fBELFku18908; Fri, 14 Dec 2001 13:15:46 -0800 (PST) Date: Fri, 14 Dec 2001 13:15:46 -0800 (PST) From: Bob Braden Message-Id: <200112142115.fBELFku18908@boreas.isi.edu> To: tcp-impl@grc.nasa.gov, vsskumar@qpackets.com Subject: Re: A doubt on PUSH bit. X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk *> From owner-tcp-impl@grc.nasa.gov Fri Dec 14 03:02:16 2001 *> X-Sender: vsskumar@qpackets.com *> Date: Fri, 14 Dec 2001 16:20:27 +0530 *> To: tcp-impl@grc.nasa.gov *> From: kumar *> Subject: A doubt on PUSH bit. *> Mime-Version: 1.0 *> X-AntiVirus: scanned by AMaViS 0.2.1 *> *> hi all, *> May i get a small clarification on PUSH bit in the TCP header ? *> *> DOUBT : When a segment arrives with a "push" bit set, do we need to *> inform the PUSH bit to the application ? *> RFC 1122 is the definitive word on this, I think; it says MAY. If you are unfamiliar with RFC 1122, I suggest that you read and digest it before launching any more questions about TCP. I argued in 1978 when TCP was being designed that according to the logic of Push it should be required (and my TCP did pass it), but Berkeley Unix set the modern standard of not passing Push to the receiving application. Essentially, it was (one of the many cases of) the OS folks against the networking folks. The networking folks defined this nice Push mechanism, and the OS folks ignored it. ;-) Bob Braden From owner-tcp-impl@grc.nasa.gov Tue Dec 25 01:46:39 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03627 for ; Tue, 25 Dec 2001 01:46:38 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id F123B640FB; Tue, 25 Dec 2001 01:46:36 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAibaatN; Tue, 25 Dec 01 01:46:36 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA04257 for tcp-impl-outgoing; Tue, 25 Dec 2001 01:29:12 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA04253 for ; Tue, 25 Dec 2001 01:29:11 -0500 (EST) From: helpingfamilies@lycos.com Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id BAA03151 for ; Tue, 25 Dec 2001 01:29:11 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id EED0CC68E2; Tue, 25 Dec 2001 01:29:10 -0500 (EST) Received: from 216-127-234-141.focaldata.net(216.127.234.141) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAJLa4Vw; Tue, 25 Dec 01 01:29:10 -0500 To: tcp-impl@grc.nasa.gov Subject: 6.25% Fixed\ Refinance before rates Go Up! 20142 Date: Mon, 24 Dec 2001 22:36:02 -0800 X-Sender: helpingfamilies@lycos.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-Type: text/html; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: <20011225062910.EED0CC68E2@seraph2.grc.nasa.gov> Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Loan Application

Refinance While Rates Last!

6.25%  Fixed

  • Payoff Debt or Home Improvement
  • Bad Credit Ok
  • Cash Out For Any Reason
     
    Clearly, refinancing is the smart solution for those who want the financial flexibility to use their equity to pay off debt or make improvements in life.

     

    • Loan Application (Fields Marked with * are required)
    Prefix:               Name:        *
    Middle Name:   Last Name: *
    Address  * City:          *
    State    * Zip Code:    *
    Home Phone:    Day Phone:  *
    Fax:               E-Mail:        *
    Length At Present Address:
    * Years  Months     		 Amount Owed on 1st / % Rate:   *  /  %*
    Amount Owed on 2nd / % Rate:   /   % Loan Type 1St / Loan Type 2nd:  *   / 
    Home Value:     * Yearly Income:    *
    Length of Current Employment:          *Years    *Months Are You Self Employed? 
    Credit Rating: Amount Requested: *
    What is the purpose of the loan?
                                Realtor           
    c 2001, An independently owned and operated member of
    The Prudential Real Estate Affiliates, Inc


    To be removed from this one time mailing, simply forward this message to helpingfamilies@lycos.com

    From owner-tcp-impl@grc.nasa.gov Wed Dec 26 06:56:32 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17129 for ; Wed, 26 Dec 2001 06:56:32 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id B624FC68F9; Wed, 26 Dec 2001 06:56:32 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAWUayTI; Wed, 26 Dec 01 06:56:32 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA01036 for tcp-impl-outgoing; Wed, 26 Dec 2001 06:40:54 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id GAA01032 for ; Wed, 26 Dec 2001 06:40:52 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id GAA21921 for ; Wed, 26 Dec 2001 06:40:51 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 731EE640A5; Wed, 26 Dec 2001 06:40:51 -0500 (EST) Received: from unknown(202.125.87.14) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAYGaWLN; Wed, 26 Dec 01 06:40:49 -0500 Received: from yub (machine236 [172.16.1.236]) by brahma.roc.com (8.9.3/8.8.7) with SMTP id RAA15983 for ; Wed, 26 Dec 2001 17:16:28 +0530 Message-ID: <001901c18e03$86b8f940$ec0110ac@roc.com> From: "bhaskar" To: Subject: suggestion needed.... Date: Wed, 26 Dec 2001 17:20:32 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C18E31.9FE60C40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C18E31.9FE60C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi, may i know if there are any specific RFCs for the implementation of = the INITIAL SEQUENCE NUMBER. bye regards, ubyadati ------=_NextPart_000_0016_01C18E31.9FE60C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    hi,
     
       may i know if there are = any specific=20 RFCs for the implementation of the INITIAL SEQUENCE NUMBER.
     
    bye
    regards,
    ubyadati

     
    ------=_NextPart_000_0016_01C18E31.9FE60C40-- From owner-tcp-impl@grc.nasa.gov Wed Dec 26 15:55:22 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20584 for ; Wed, 26 Dec 2001 15:55:22 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 5BAFC640CF; Wed, 26 Dec 2001 15:55:23 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAZ8a4cs; Wed, 26 Dec 01 15:55:23 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA00833 for tcp-impl-outgoing; Wed, 26 Dec 2001 15:47:50 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA00829 for ; Wed, 26 Dec 2001 15:47:49 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id PAA17866 for ; Wed, 26 Dec 2001 15:47:48 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 803EE640BA; Wed, 26 Dec 2001 15:47:48 -0500 (EST) Received: from minotaur.nge.isi.edu(65.114.169.202) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAX2ayCq; Wed, 26 Dec 01 15:47:48 -0500 Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id fBQKlj913117; Wed, 26 Dec 2001 15:47:45 -0500 Message-Id: <200112262047.fBQKlj913117@minotaur.nge.isi.edu> To: "bhaskar" Cc: tcp-impl@grc.nasa.gov Reply-To: mankin@ISI.EDU Subject: Re: suggestion needed.... In-reply-to: Your message of Wed, 26 Dec 2001 17:20:32 +0530. <001901c18e03$86b8f940$ec0110ac@roc.com> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Wed, 26 Dec 2001 15:47:45 -0500 From: Allison Mankin Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk > may i know if there are any specific RFCs for the implementation of > the INITIAL SEQUENCE NUMBER. RFC 1948. It remains very important to implement ISN right, because sequence number guessing attacks are still a serious risk. http://www.cert.org/advisories/CA-2001-09.html From owner-tcp-impl@grc.nasa.gov Wed Dec 26 16:35:13 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20867 for ; Wed, 26 Dec 2001 16:35:13 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 45696C691F; Wed, 26 Dec 2001 16:35:14 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAhRaObx; Wed, 26 Dec 01 16:35:14 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA05685 for tcp-impl-outgoing; Wed, 26 Dec 2001 16:27:40 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA05664 for ; Wed, 26 Dec 2001 16:27:38 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id QAA20217 for ; Wed, 26 Dec 2001 16:27:38 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id CCBBDC68CE; Wed, 26 Dec 2001 16:27:37 -0500 (EST) Received: from calcite.rhyolite.com(192.188.61.3) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA5iaW5u; Wed, 26 Dec 01 16:27:37 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.2.Beta3/8.12.2.Beta3) id fBQLRZrU020017 for tcp-impl@grc.nasa.gov env-from ; Wed, 26 Dec 2001 14:27:35 -0700 (MST) Date: Wed, 26 Dec 2001 14:27:35 -0700 (MST) From: Vernon Schryver Message-Id: <200112262127.fBQLRZrU020017@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: suggestion needed.... Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk > > may i know if there are any specific RFCs for the implementation of > > the INITIAL SEQUENCE NUMBER. > > RFC 1948. It remains very important to implement ISN right, > because sequence number guessing attacks are still a serious risk. > http://www.cert.org/advisories/CA-2001-09.html Yes, but it's also worthwhile to be skeptical of the ISN testers and certifiers. I've seen hysterical (in both senses) alarms about supposedly terrible ISN schemes that, while they failed tests on high speed LANS, did not have holes that would much less difficult to exploit from outside than RFC 1948 schemes. There are not many bits in the sequence number to randomize as suggested by RFC 1948 or anything else, what with the birthday paradox and the need to stay away from the sequence numbers of recent connections. On the other hand, ISN schemes are rarely among the biggest holes on LANs inside firewalls. Then there is the fact that the worst that can be done with an ISN attack is to create an illicit TCP connection. Unless you are foolish enough to authenticate and authorize services based on IP addresses, that is not much of a worry. Such wet-blanket considerations don't concern some security vendors and professional security chicken littles. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@grc.nasa.gov Thu Dec 27 04:12:05 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14556 for ; Thu, 27 Dec 2001 04:12:04 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id A87DC640DA; Thu, 27 Dec 2001 04:12:06 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAARXairl; Thu, 27 Dec 01 04:12:06 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA23322 for tcp-impl-outgoing; Thu, 27 Dec 2001 04:01:00 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA23317; Thu, 27 Dec 2001 04:00:58 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id EAA21014; Thu, 27 Dec 2001 04:00:58 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id D582EC68F9; Thu, 27 Dec 2001 04:00:57 -0500 (EST) Received: from h056.p106.iij4u.or.jp(210.130.106.56) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAniayNh; Thu, 27 Dec 01 04:00:56 -0500 Received: from localhost (localhost [127.0.0.1]) by viola.demizu.org (8.11.0/8.11.0) with ESMTP id fBR8wxt00363; Thu, 27 Dec 2001 17:58:59 +0900 (JST) From: Noritoshi Demizu To: pilc@grc.nasa.gov, tcp-impl@grc.nasa.gov Subject: Re: Doubt regarding the MANAGING THE RTO TIMER In-Reply-To: Your message of "Tue, 11 Dec 2001 10:58:39 -0600 (CST)" References: <200112111658.fBBGwd000600@restless.weston.bsdi.com> X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011227175859X.demizu@dd.iij4u.or.jp> Date: Thu, 27 Dec 2001 17:58:59 +0900 X-Dispatcher: impost version 0.99i (Apr. 6, 1997) Lines: 34 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > When using Timestamps, even in the face of packet loss, > you can guarantee to get at least one valid timing per RTT. > Or, more correctly, with Timestamps, anytime you get an > ack for new data, you can reliably use it's timestamp > to get a new RTT measurement. I think RFC1323 needs to be updated as described in [1] and [2] bellow. If one implemented timestamps option just as described in RFC1323, and when a data packet was retransmitted because the ACK packet was lost, the measured RTT could be larger than the real value. To fix this problem, at least the condition of the rule (2) of section 3.4 in RFC1323 needs to be updated. The condition of the rule (2) of Section 3.4 in RFC1323 is: SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN The condition of [1] and [2] is: SEG.TSval >= TSrecent && SEG.SEQ <= Last.ACK.sent The condition of FreeBSD 4.4R is: SEG.SEQ <= Last.ACK.sent The condition of NetBSD 1.5.2 is the same as RFC1323. The condition of OpenBSD 3.0 is the same as [1] and [2]. (Sorry, I do not know of the Linux implementation.) [1] R. Braden, "TCP Extensions for High Performance: An Update", Jun 1993 http://www.kohala.com/start/tcplw-extensions.txt [2] V. Jacobson, R. Braden and D. Borman, "TCP Extensions for High Performance", Feb 1997 http://www.watersprings.org/pub/id/draft-ietf-tcplw-high-performance-00.txt I hope RFC1323 will be updated. Noritoshi Demizu From owner-tcp-impl@grc.nasa.gov Fri Dec 28 01:50:16 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27431 for ; Fri, 28 Dec 2001 01:50:15 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 69954C6933; Fri, 28 Dec 2001 01:50:17 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAXeaGOZ; Fri, 28 Dec 01 01:50:17 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA21133 for tcp-impl-outgoing; Fri, 28 Dec 2001 01:36:48 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA21129 for ; Fri, 28 Dec 2001 01:36:47 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id BAA11676 for ; Fri, 28 Dec 2001 01:36:46 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 6C541C6924; Fri, 28 Dec 2001 01:36:46 -0500 (EST) Received: from unknown(202.125.87.14) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAMRa4BX; Fri, 28 Dec 01 01:36:44 -0500 Received: from vlsi6 (machine35 [172.16.1.35]) by brahma.roc.com (8.9.3/8.8.7) with SMTP id MAA32438; Fri, 28 Dec 2001 12:12:10 +0530 From: "praveen" To: "Reiner Ludwig" Cc: Subject: RE: Query on Acking Out of sequence data Date: Fri, 28 Dec 2001 12:08:09 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) Importance: Normal In-Reply-To: <5.1.0.14.0.20011212120907.032bedb0@chapelle.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit HI Reiner, Is the SACK also a pure ACK? (Without data, even though TCP has the pending data to transmit). Thanks praveen -----Original Message----- From: Reiner Ludwig [mailto:Reiner.Ludwig@ericsson.com] Sent: Wednesday, December 12, 2001 4:40 PM To: praveen Cc: tcp-impl@grc.nasa.gov Subject: Re: Query on Acking Out of sequence data At 08:55 12.12.2001, praveen wrote: >When TCP receives out of sequence data, >its required to send an >Immediate ACK (this is a Duplicate ACK). >If The TCP has pending >data to be sent, Can this data go along >with this immediate ACK? No. A DUPACK must also be a pure ACK. ///Reiner From owner-tcp-impl@grc.nasa.gov Sat Dec 29 13:44:08 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29377 for ; Sat, 29 Dec 2001 13:44:07 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 436B4641C6; Sat, 29 Dec 2001 13:42:04 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAARsaqTt; Sat, 29 Dec 01 13:42:04 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA24252 for tcp-impl-outgoing; Sat, 29 Dec 2001 13:20:13 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA24243 for ; Sat, 29 Dec 2001 13:20:11 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id NAA00921 for ; Sat, 29 Dec 2001 13:20:11 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 422C3C6901; Sat, 29 Dec 2001 13:20:10 -0500 (EST) Received: from mail.hellasnet.gr(212.54.192.3) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA5ya4gE; Sat, 29 Dec 01 13:20:09 -0500 Received: from wseas.org (ppp1-160.pop.hellasnet.gr [212.251.123.160]) by mail.hellasnet.gr (8.12.1/8.12.1) with SMTP id fBTIJvrL009085 for ; Sat, 29 Dec 2001 20:19:58 +0200 (EET) Message-Id: <200112291819.fBTIJvrL009085@mail.hellasnet.gr> From: "Kostas Ioannou" To: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Date: Sat, 29 Dec 2001 20:20:04 +0200 Content-Transfer-Encoding: 8bit Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit New Page 1

    WSEAS Upcoming Conferences

    http://www.wseas.org

     

    Cancun, Mexico, May 12-16, 2002 (five conferences)

     

    Rethymno, Crete Island, Greece, July 7-14, 2002 (seven conferences)

    Miedzyzdroje, Wolin Island, Poland, August 25-30, 2002 (three conferences)

     

    Miedzyzdroje, Wolin Island, Poland, September 1-5, 2002 (eight conferences)

     

    Skiathos, Skiathos Island, Greece, September 25-28, 2002 (four conferences)


    Copacabana, Rio de Janeiro, Brazil, October 14-17, 2002 (four conferences)

     

    Copacabana, Rio de Janeiro, Brazil, October 21-24, 2002 (three conferences)


    Puerto De La Cruz, Tenerife, Canary Islands, Spain, Dec. 19-21, 2002 (six conferences)

     

     All the WSEAS Sponsored Events will be being held in exciting places and will offer to the participants

    1. Excellent proceedings (with their papers),

    2. Excellent luxurious Post-Conference books by WSEAS Press International Editions with their papers (different edition than the proceedings with different ISBN, hard cover, velvet paper, etc),

    3. Possibility for journal publication,

    4. Lectures by distinguished and famous scientists (VIPs in the areas covered by meetings), magnificant resort hotels and of course

    5. Social and cultural activities of high academical standards!
       

    http://www.wseas.org



    Wishes for a happy new Year



    KOSTAS IOANNOU From owner-tcp-impl@grc.nasa.gov Sat Dec 29 14:18:47 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29563 for ; Sat, 29 Dec 2001 14:18:46 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id E7E03640E1; Sat, 29 Dec 2001 14:18:47 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAApsaORB; Sat, 29 Dec 01 14:18:47 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA27648 for tcp-impl-outgoing; Sat, 29 Dec 2001 14:02:55 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA27644 for ; Sat, 29 Dec 2001 14:02:54 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id OAA02506 for ; Sat, 29 Dec 2001 14:02:53 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id B5F1EC691F; Sat, 29 Dec 2001 14:02:52 -0500 (EST) Received: from unknown(207.224.115.162) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAT_aygL; Sat, 29 Dec 01 14:02:52 -0500 Received: (from root@localhost) by klos.com (8.11.3nb1/8.11.3) id fBTJ2OE24954; Sat, 29 Dec 2001 14:02:24 -0500 (EST) Date: Sat, 29 Dec 2001 14:02:24 -0500 (EST) From: Patrick Klos Message-Id: <200112291902.fBTJ2OE24954@klos.com> To: koioa@wseas.org, tcp-impl@lerc.nasa.gov Subject: NO MORE HTML! Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Is it just me, or does anyone else think posting HTML to the mailing list is unnecessary?!? >From owner-tcp-impl@grc.nasa.gov Sat Dec 29 13:50:30 2001 >From: "Kostas Ioannou" >To: >Date: Sat, 29 Dec 2001 20:20:04 +0200 >Content-Transfer-Encoding: 8bit >Sender: owner-tcp-impl@grc.nasa.gov > > > > >New Page 1 > > > > > >

    >WSEAS Upcoming >Conferences

    >

    >http://www.wseas.org

    >

     

    >

    Cancun, >Mexico, >May 12-16, 2002 (five conferences)style="color: black"> >

    > > > > > >

     

    >

    Rethymno, >Crete >Island, Greece, July 7-14, 2002 (seven conferences)lang="EN-GB" style="color: black"> >

    > > > > > > > >

    Miedzyzdroje, Wolin Island, >Poland, August 25-30, 2002 (three conferences)lang="EN-GB" style="color: black"> >

    > > > >

     

    >

    Miedzyzdroje, >Wolin Island, Poland, September 1-5, 2002 (eight >conferences) >

    > > > > > > > > >

     

    >

    Skiathos, >Skiathos Island, Greece, September 25-28, 2002 (four >conferences) >

    > > > >
    >

    Copacabana, Rio >de Janeiro, Brazil, October 14-17, 2002 (four conferences)lang="EN-GB" style="color: black"> >

    > > > > >

     

    >

    Copacabana, Rio de Janeiro, >Brazil, >October 21-24, 2002 (three conferences) > >

    > > >
    >

    Puerto De La Cruz, Tenerife, >Canary >Islands, Spain, Dec. 19-21, 2002 (six conferences)lang="EN-GB"> >

    > > > > > > >

     

    >

     All >the WSEAS Sponsored Events will be being held in exciting places >and will >offer to the participants

    >
      >
    1. >

      size="3"> > Excellent proceedings (with their papers),

      2. >
    2. >

      Eface="Times new Roman" color="#000000" size="3">xcellent > luxurious Post-Conference books by WSEAS Press International Editions >with > their papers (different edition than the proceedings with different >ISBN, hard > cover, velvet paper, etc),

      3. >
    3. >

      Pface="Times new Roman" color="#000000" size="3">ossibility > for journal publication,

      4. >
    4. >

      size="3"> > Lectures by distinguished and famous scientists (VIPs in the areas >covered by > meetings), magnificant resort hotels and of course

      5. >
    5. >

      size="3"> > Social and cultural activities of high academical standards! >
      > 

      6. >
    >

    http://www.wseas.org

    >
    >
    > >Wishes for a happy new Year >
    >
    >
    >
    > > >KOSTAS IOANNOU > > > > From owner-tcp-impl@grc.nasa.gov Sat Dec 29 22:08:38 2001 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03360 for ; Sat, 29 Dec 2001 22:08:37 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 824C064099; Sat, 29 Dec 2001 22:08:39 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAA5aayHB; Sat, 29 Dec 01 22:08:39 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA15095 for tcp-impl-outgoing; Sat, 29 Dec 2001 20:03:43 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAA15088 for ; Sat, 29 Dec 2001 20:03:42 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id UAA09980 for ; Sat, 29 Dec 2001 20:03:41 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id EB6B8640B2; Sat, 29 Dec 2001 20:01:30 -0500 (EST) Received: from sparkle.rodents.montreal.qc.ca(216.46.5.7) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAVdaqEk; Sat, 29 Dec 01 20:01:28 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id UAA24657; Sat, 29 Dec 2001 20:01:23 -0500 (EST) Date: Sat, 29 Dec 2001 20:01:23 -0500 (EST) From: der Mouse Message-Id: <200112300101.UAA24657@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: patrick@klos.com, koioa@wseas.org, tcp-impl@lerc.nasa.gov Subject: Re: NO MORE HTML! In-Reply-To: <200112291902.fBTJ2OE24954@klos.com> References: <200112291902.fBTJ2OE24954@klos.com> Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > Is it just me, or does anyone else think posting HTML to the mailing > list is unnecessary?!? It's not just you. Indeed, my mailer will _bounce_ HTML messages, at least if they're properly marked as such. (Unmarked HTML usually gets bounced by wetware.) See my signature.... >> Content-Transfer-Encoding: 8bit Ah, but what Content-Type? :-) (And, did you really have to quote the whole thing? I think the first screenful or so would have made your point admirably.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@grc.nasa.gov Mon Dec 31 15:17:21 2001 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06523 for ; Mon, 31 Dec 2001 15:17:20 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id D2BEEC6902; Mon, 31 Dec 2001 15:17:21 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAvSaGWk; Mon, 31 Dec 01 15:17:21 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA02908 for tcp-impl-outgoing; Mon, 31 Dec 2001 15:00:34 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA02904; Mon, 31 Dec 2001 15:00:32 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id PAA18681; Mon, 31 Dec 2001 15:00:32 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id E0DDA64097; Mon, 31 Dec 2001 15:00:31 -0500 (EST) Received: from aland.bbn.com(204.162.9.10) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAFday0R; Mon, 31 Dec 01 15:00:31 -0500 Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (8.11.3/8.11.6) with ESMTP id fBVK0Rt74319; Mon, 31 Dec 2001 15:00:27 -0500 (EST) (envelope-from craig@aland.bbn.com) Message-Id: <200112312000.fBVK0Rt74319@aland.bbn.com> To: Noritoshi Demizu Cc: pilc@grc.nasa.gov, tcp-impl@grc.nasa.gov Subject: Re: Doubt regarding the MANAGING THE RTO TIMER In-Reply-To: Your message of "Thu, 27 Dec 2001 17:58:59 +0900." <20011227175859X.demizu@dd.iij4u.or.jp> Date: Mon, 31 Dec 2001 15:00:27 -0500 From: Craig Partridge Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk In message <20011227175859X.demizu@dd.iij4u.or.jp>, Noritoshi Demizu writes: >I hope RFC1323 will be updated. The usual effective way to update an RFC is to do it yourself -- that is, write the draft, detailing all the issues and the solution, send it around for discussion, then send it to the IETF. One advantage is that this process sometimes reveals either (a) that the protocol is OK after all or (b) that the problems are worse than you thought. Craig