From owner-tcp-impl@lerc.nasa.gov Mon Jan 3 13:35:13 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05694 for ; Mon, 3 Jan 2000 13:35:13 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA22409 for tcp-impl-outgoing; Mon, 3 Jan 2000 10:51:34 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA18761; Mon, 3 Jan 2000 10:31:45 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA05992; Mon, 3 Jan 2000 10:31:44 -0500 (EST) Received: from smtp2.cluster.oleane.net(195.25.12.17) by seraph3.lerc.nasa.gov via smap (V5.0) id xma005815; Mon, 3 Jan 00 10:31:29 -0500 Received: from oleane (dyn-1-1-234.Vin.dialup.oleane.fr [195.25.4.234]) by smtp2.cluster.oleane.net with SMTP id QAA75711; Mon, 3 Jan 2000 16:29:34 +0100 (CET) Message-ID: <005601bf55ff$04f74a80$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: VoDSL 2000 Conference Date: Mon, 3 Jan 2000 16:27:10 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01BF5607.6292A240" 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@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0053_01BF5607.6292A240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hello, =20 The VoDSL 2000 Conference will stand in Paris next 28-31 March. Key = speakers, case studies: take a look at: = http://www.upperside.fr/bavodsl.htm =20 Regards ------=_NextPart_000_0053_01BF5607.6292A240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 =20
Hello,
 
The VoDSL 2000 Conference will stand = in Paris=20 next 28-31 March. Key speakers, case studies: take a look at:  http://www.upperside.fr/bavo= dsl.htm
 
Regards
 
------=_NextPart_000_0053_01BF5607.6292A240-- From owner-tcp-impl@lerc.nasa.gov Mon Jan 10 01:00:47 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15179 for ; Mon, 10 Jan 2000 01:00:46 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA03540 for tcp-impl-outgoing; Sun, 9 Jan 2000 21:57:06 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA03521 for ; Sun, 9 Jan 2000 21:57:03 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id VAA11579; Sun, 9 Jan 2000 21:57:02 -0500 (EST) Received: from mailhost.iprg.nokia.com(205.226.5.12) by seraph3.lerc.nasa.gov via smap (V5.0) id xma011557; Sun, 9 Jan 00 21:56:29 -0500 Received: from aspen.iprg.nokia.com ([205.226.14.73]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id SAA01037 for ; Sun, 9 Jan 2000 18:56:28 -0800 (PST) From: Fred Bauer Received: (fred@localhost) by aspen.iprg.nokia.com (8.8.8/8.6.12) id SAA00389 for tcp-impl@lerc.nasa.gov; Sun, 9 Jan 2000 18:56:27 -0800 (PST) Date: Sun, 9 Jan 2000 18:56:27 -0800 (PST) Message-Id: <200001100256.SAA00389@aspen.iprg.nokia.com> To: tcp-impl@lerc.nasa.gov Subject: INFOCOM 2000 Call For Participation Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk CALL FOR PARTICIPATION ------------------------ IEEE Infocom 2000 (Israel) http://www.comnet.technion.ac.il/infocom2000 (U.S.A.) http://www.cse.ucsc.edu/~rom/infocom2000 (Japan) http://halo.kuamp.kyoto-u.ac.jp/~infocom Dan Panorama Hotel, Tel Aviv, Israel March 26-30, 2000 Sponsored by the IEEE Communications and Computer Societies Download the complete advanced program http://www.comnet.technion.ac.il/infocom2000/infocom00apv7.pdf IMPORTANT DATES =============== Cut-off dates for special lower rates: Hotel reservation cut-off date* January 24, 2000 (only two more weeks to go) Early registration cut-off date February 28, 2000 Infocom 2000 dates: Tutorials March 26-27, 2000 Conference March 28-30, 2000 * Israel is expected to be crowded with tourists during the year 2000. Furthermore, the Pope is scheduled to visit Israel the week before the conference. Hence, it is advised to make HOTEL and FLIGHT reservations for the conference as soon as possible. HOTEL RATES =========== Double Occupancy $157.50 Single Occupancy $139.00 Rates are per room per night and include full Israeli buffet breakfast. The rates also include all taxes for non-israelis. For more details consult the web pages. http://www.comnet.technion.ac.il/infocom2000/reservation.html REGISTRATION FEES ================= Registration fees for an IEEE member prior to February 28, 2000 will be $500 and it will include all technical sessions, open receptions, proceedings (CD) and three lunches. For other fees consult the web pages. ------------- On-line registration: https://secure.computer.org/conf/infocom/register.htm VENUE ===== For the last 18 years, Infocom has been the major conference on computer communications and networking, bringing together researchers and implementors of every aspect of data communications and networks presenting the most up-to-date results and achievements in the field. The 19th annual conference on Computer Communications, Infocom 2000, will be held at the Dan Panorama Hotel in Tel-Aviv, Israel, during the week of March 26-30, 2000. Overlooking the Mediterranean, the Dan Panorama Tel Aviv is a city hotel in a resort setting. Just a few steps away are fine shops, theaters, restaurants and the corporate world of Tel Aviv, contrasted by the ancient port city of Jaffa with its picturesque corners and flea markets for bargain hunters. The hotel features a large swimming pool, beach access and a fully equipped health & fitness center. SCOPE ===== Original papers and panel discussions describing state-of-the-art research and development in all areas of computer networking and data communications will be presented. Browse the excellent technical program and see the papers at http://www.comnet.technion.ac.il/infocom2000/program.html KEYNOTE SPEAKER =============== Prof. Leonard Kleinrock, Chairman, Nomadix, Inc. Keynote title: Nomadic Computing and Smart Spaces http://www.comnet.technion.ac.il/infocom2000/key.html TUTORIALS ========= Full Day -------- - Wavelength-routing optical networks (Kumar Sivarajan, Indian Institute of Science) - The evolution of QoS in the Internet standards community (Jon Crowcroft, University College London) - Overview of network security (Radia Perlman, Sun Microsystems) - Teletraffic Models and Tools: From Basics to Advanced(Khosrow Sohraby, University of Missouri, Kansas City) - IP Multicast: past, present and future (Radia Perlman, Sun Microsystems & Christophe Diot, Sprint) Half Day -------- - MPLS (Loa Andersson, Nortel Networks) - New technologies for LAN systems (Dono Van-Mierop, IBM Israel) - Satellite IP networking (Catherine Rosenberg, Purdue University) - Mobile IP: adding mobility to the Internet (Charles Perkins, Nokia Research) http://www.comnet.technion.ac.il/infocom2000/tutorial.html QUESTIONS? =========================== Write to infocom@comnet.technion.ac.il] From owner-tcp-impl@lerc.nasa.gov Tue Jan 11 08:48:38 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08777 for ; Tue, 11 Jan 2000 08:48:38 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA05995 for tcp-impl-outgoing; Tue, 11 Jan 2000 05:45:44 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id FAA05988; Tue, 11 Jan 2000 05:45:39 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id FAA14252; Tue, 11 Jan 2000 05:45:39 -0500 (EST) Received: from smtp1.cluster.oleane.net(195.25.12.16) by seraph3.lerc.nasa.gov via smap (V5.0) id xma014227; Tue, 11 Jan 00 05:44:59 -0500 Received: from oleane (dyn-1-1-186.Vin.dialup.oleane.fr [195.25.4.186]) by smtp1.cluster.oleane.net with SMTP id LAA20336; Tue, 11 Jan 2000 11:43:57 +0100 (CET) Message-ID: <008501bf5c20$6b51e020$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: SIP 2000 Call for Paper Date: Tue, 11 Jan 2000 11:41:20 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0082_01BF5C28.C79F0D00" 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@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0082_01BF5C28.C79F0D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIP 2000: beyond H.323?=20 Discussing and debating in Paris May 10-12. A CFP is online at: http://www.upperside.fr/basip.htm =20 ------=_NextPart_000_0082_01BF5C28.C79F0D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SIP 2000: beyond H.323? =
Discussing and debating in Paris May = 10-12.
A CFP is online at:
http://www.upperside.fr/basip.= htm
 
 
------=_NextPart_000_0082_01BF5C28.C79F0D00-- From owner-tcp-impl@lerc.nasa.gov Mon Jan 17 16:19:16 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09042 for ; Mon, 17 Jan 2000 16:19:15 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA24021 for tcp-impl-outgoing; Mon, 17 Jan 2000 13:15:27 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA24001 for ; Mon, 17 Jan 2000 13:15:25 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA24284; Mon, 17 Jan 2000 13:15:24 -0500 (EST) Received: from mailhost.iprg.nokia.com(205.226.5.12) by seraph3.lerc.nasa.gov via smap (V5.0) id xma024252; Mon, 17 Jan 00 13:14:58 -0500 Received: from vienna.iprg.nokia.com (vienna.iprg.nokia.com [205.226.11.35]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id KAA23686 for ; Mon, 17 Jan 2000 10:14:57 -0800 (PST) From: Fred Bauer Received: (fred@localhost) by vienna.iprg.nokia.com (8.8.8/8.6.12) id KAA04404 for tcp-impl@lerc.nasa.gov; Mon, 17 Jan 2000 10:14:57 -0800 (PST) Date: Mon, 17 Jan 2000 10:14:57 -0800 (PST) Message-Id: <200001171814.KAA04404@vienna.iprg.nokia.com> To: tcp-impl@lerc.nasa.gov Subject: INFOCOM 2000 Call For Participation Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk CALL FOR PARTICIPATION ------------------------ IEEE Infocom 2000 (Israel) http://www.comnet.technion.ac.il/infocom2000 (U.S.A.) http://www.cse.ucsc.edu/~rom/infocom2000 (Japan) http://halo.kuamp.kyoto-u.ac.jp/~infocom Dan Panorama Hotel, Tel Aviv, Israel March 26-30, 2000 Sponsored by the IEEE Communications and Computer Societies IMPORTANT DATES =============== Cut-off dates for special lower rates: Hotel reservation cut-off date* January 24, 2000 (only ONE more week to go) Early registration cut-off date February 28, 2000 Infocom 2000 dates: Tutorials March 26-27, 2000 Conference March 28-30, 2000 * Israel is expected to be crowded with tourists during the year 2000. Furthermore, the Pope is scheduled to visit Israel the week before the conference. Hence, it is advised to make HOTEL and FLIGHT reservations for the conference as soon as possible. HOTEL RATES =========== Double Occupancy $157.50 Single Occupancy $139.00 Rates are per room per night and include full Israeli buffet breakfast. The rates also include all taxes for non-israelis. For more details consult the web pages. http://www.comnet.technion.ac.il/infocom2000/reservation.html REGISTRATION FEES ================= Registration fees for an IEEE member prior to February 28, 2000 will be $500 and it will include all technical sessions, open receptions, proceedings (CD) and three lunches. For other fees consult the web pages. ------------- On-line registration: https://secure.computer.org/conf/infocom/register.htm VENUE ===== For the last 18 years, Infocom has been the major conference on computer communications and networking, bringing together researchers and implementors of every aspect of data communications and networks presenting the most up-to-date results and achievements in the field. The 19th annual conference on Computer Communications, Infocom 2000, will be held at the Dan Panorama Hotel in Tel-Aviv, Israel, during the week of March 26-30, 2000. Overlooking the Mediterranean, the Dan Panorama Tel Aviv is a city hotel in a resort setting. Just a few steps away are fine shops, theaters, restaurants and the corporate world of Tel Aviv, contrasted by the ancient port city of Jaffa with its picturesque corners and flea markets for bargain hunters. The hotel features a large swimming pool, beach access and a fully equipped health & fitness center. SCOPE ===== Original papers and panel discussions describing state-of-the-art research and development in all areas of computer networking and data communications will be presented. Browse the excellent technical program and see the papers at http://www.comnet.technion.ac.il/infocom2000/program.html KEYNOTE SPEAKER =============== Prof. Leonard Kleinrock, Chairman, Nomadix, Inc. Keynote title: Nomadic Computing and Smart Spaces http://www.comnet.technion.ac.il/infocom2000/key.html TUTORIALS ========= Full Day -------- - Wavelength-routing optical networks (Kumar Sivarajan, Indian Institute of Science) - The evolution of QoS in the Internet standards community (Jon Crowcroft, University College London) - Overview of network security (Radia Perlman, Sun Microsystems) - Teletraffic Models and Tools: From Basics to Advanced(Khosrow Sohraby, University of Missouri, Kansas City) - IP Multicast: past, present and future (Radia Perlman, Sun Microsystems & Christophe Diot, Sprint) Half Day -------- - MPLS (Loa Andersson, Nortel Networks) - New technologies for LAN systems (Dono Van-Mierop, IBM Israel) - Satellite IP networking (Catherine Rosenberg, Purdue University) - Mobile IP: adding mobility to the Internet (Charles Perkins, Nokia Research) http://www.comnet.technion.ac.il/infocom2000/tutorial.html QUESTIONS? =========================== Write to infocom@comnet.technion.ac.il] From owner-tcp-impl@lerc.nasa.gov Tue Jan 18 21:30:13 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08626 for ; Tue, 18 Jan 2000 21:30:06 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA03492 for tcp-impl-outgoing; Tue, 18 Jan 2000 15:33:21 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA03452 for ; Tue, 18 Jan 2000 15:33:18 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA02138; Tue, 18 Jan 2000 15:33:16 -0500 (EST) Received: from motgate2.mot.com(136.182.1.10) by seraph3.lerc.nasa.gov via smap (V5.0) id xma002110; Tue, 18 Jan 00 15:33:12 -0500 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (VWALL-IN-motgate2 2.0) with ESMTP id NAA06380 for ; Tue, 18 Jan 2000 13:33:11 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA16009 for ; Tue, 18 Jan 2000 13:33:11 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 18 Jan 2000 14:33:10 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9AE56BB4@il27exm02.cig.mot.com> From: Ali Irfan-FIA225 To: "'tcp-impl@grc.nasa.gov'" Subject: BSD 4.4 TCP header prediction code error - Secondary Effect Date: Tue, 18 Jan 2000 14:33:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk In [Brakmo95], the authors identified the error in the Header Prediction Code due to which TCP fails to deflate the window after fast recovery causing an inappropriate amount of data to be sent into the network after recovery. This error has also been noted in [TCPImplErr] section 2.8, "Failure of window deflation after loss recovery". There is a secondary effect of the error in the header prediction code leading to inconsistent fast-retransmit behavior, which is outlined here. In BSD4.4 TCP, during fast-recovery/fast-retransmit behavior, if cwnd exceeds ssthresh and a new ack arrives, the header-prediction part of the code gets exercised. This leads to failure to "deflate" the window causing large amount of data to be sent, as documented previously. Another consequence is that the dupack count (t_dupacks) does not get reset. The dupack count is above re-transmission threshold (usually 3). Subsequently, the code does not go into fast recovery/fast retransmit when three dupacks arrive. The dupack count gets reset after the arrival of a new ack following a timeout retransmission. A snippet of a trace from a simulation showing this behavior is included. The simulation is for bulk transfer. Source always sends 512 byte segments and the advertised window is for 8 (4096 bytes). The configuration for the forward path is Src(B) ->10 ms latency -> router (6 buffers) -> 8 kbps link -> dest(A). Return path for acks: Dest(A) -> 10 ms latency -> Src(B). The configuration is for low speed wireless/cellular links. (cwnd and ssthresh are expressed in #segments) No. Time(s) Src Dest Seq No. Ack No. cwnd ssthresh Comments 1 21.399 A B . 18433 6.879 4 2 21.399 B A 20993 . . . 3 21.911 A B . 18945 7.025 4 4 21.911 B A 21505 . . . 5 21.911 B A 22017 . . . pkt dropped 6 22.423 A B . 19457 7.167 4 7 22.423 B A 22529 . . . 8 22.935 A B . 19969 7.306 4 9 22.935 B A 23041 . . . 10 23.447 A B . 20481 7.443 4 11 23.447 B A 23553 . . . 12 23.959 A B . 20993 7.578 4 13 23.959 B A 24065 . . . 14 24.471 A B . 21505 7.710 4 15 24.471 B A 24577 . . . 16 24.983 A B . 22017 7.839 4 17 24.983 B A 25089 . . . 18 25.495 A B . 22017 7.839 4 19 26.007 A B . 22017 7.839 4 20 26.519 A B . 22017 6 3 21 26.519 B A 22017 . . . 22 27.031 A B . 22017 7 3 23 27.543 A B . 22017 8 3 24 27.543 B A 25601 . . . 25 28.055 A B . 22017 9 3 26 28.567 A B . 25601 9 3 27 28.567 B A 26113 . . . 28 28.567 B A 26625 . . . 29 28.567 B A 27137 . . . primary symptom 30 28.567 B A 27649 . . . (excessive xmission) 31 28.567 B A 28161 . . . 32 28.567 B A 28673 . . . pkt dropped 33 28.567 B A 29185 . . . pkt dropped 34 29.079 A B . 26113 9 3 35 29.079 B A 29697 . . . 36 29.591 A B . 26625 9 3 37 29.591 B A 30209 . . . 38 30.103 A B . 27137 9 3 39 30.103 B A 30721 . . . 40 30.615 A B . 27649 9 3 41 30.615 B A 31233 . . . 42 31.127 A B . 28161 9 3 43 31.127 B A 31745 . . . 44 31.639 A B . 28673 9 3 45 31.639 B A 32257 . . . 46 32.151 A B . 28673 10 3 47 32.663 A B . 28673 11 3 48 33.175 A B . 28673 12 3 secondary symptom 49 33.687 A B . 28673 13 3 (no fast retransmit) 50 34.199 A B . 28673 14 3 51 34.711 A B . 28673 15 3 52 36.679 B A 28673 . 1 4 53 37.211 A B . 29185 2 4 54 37.211 B A 29185 . . . 55 37.211 B A 29697 . . . 56 37.743 A B . 32769 3 4 References [Brakmo95] L.S. Brakmo and L.L. Peterson, "Performance Problems in BDS4.4 TCP," Computer Communication Review , Vol 25, No. 5, October 1995, pg. 69-86. http://www.cs.arizona.edu/xkernel/people/brakmo.html [TCPImplErr] RFC2525, Known TCP Implementation Problems, March 1999. Irfan Ali Motorola, Network Solutions Sector 1501 Shure Drive Arlington Heights, IL 60004 Phone: (847)632-3281 email: fia225@email.mot.com From owner-tcp-impl@lerc.nasa.gov Wed Jan 19 06:04:49 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25605 for ; Wed, 19 Jan 2000 06:04:48 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA22544 for tcp-impl-outgoing; Wed, 19 Jan 2000 03:17:48 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id DAA22527 for ; Wed, 19 Jan 2000 03:17:45 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA00231; Wed, 19 Jan 2000 03:17:45 -0500 (EST) Received: from daffy.ee.lbl.gov(131.243.1.31) by seraph3.lerc.nasa.gov via smap (V5.0) id xma000216; Wed, 19 Jan 00 03:17:43 -0500 Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id AAA23293; Wed, 19 Jan 2000 00:17:40 -0800 (PST) Message-Id: <200001190817.AAA23293@daffy.ee.lbl.gov> To: Ali Irfan-FIA225 Cc: "'tcp-impl@grc.nasa.gov'" Subject: Re: BSD 4.4 TCP header prediction code error - Secondary Effect In-reply-to: Your message of Tue, 18 Jan 2000 14:33:07 PST. Date: Wed, 19 Jan 2000 00:17:40 PST From: Vern Paxson Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Thanks, I've filed this away in my notes for the eventual revision of RFC 2525. Vern From owner-tcp-impl@lerc.nasa.gov Wed Jan 19 06:53:54 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25980 for ; Wed, 19 Jan 2000 06:53:54 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA25974 for tcp-impl-outgoing; Wed, 19 Jan 2000 04:11:48 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA25957 for ; Wed, 19 Jan 2000 04:11:46 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA03496; Wed, 19 Jan 2000 04:11:46 -0500 (EST) Received: from info.iet.unipi.it(131.114.9.184) by seraph3.lerc.nasa.gov via smap (V5.0) id xma003350; Wed, 19 Jan 00 04:10:15 -0500 Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id KAA04332; Wed, 19 Jan 2000 10:10:15 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200001190910.KAA04332@info.iet.unipi.it> Subject: Re: BSD 4.4 TCP header prediction code error - Secondary Effect In-Reply-To: <0DF9920C9AD8D211AB0C0008C7CF1C9AE56BB4@il27exm02.cig.mot.com> from Ali Irfan-FIA225 at "Jan 18, 2000 02:33:07 pm" To: Ali Irfan-FIA225 Date: Wed, 19 Jan 2000 10:10:15 +0100 (CET) CC: "'tcp-impl@grc.nasa.gov'" X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > A snippet of a trace from a simulation showing this behavior is included. > The simulation is for bulk transfer. Source always sends 512 byte segments > and the advertised window is for 8 (4096 bytes). The configuration for the > forward path is Src(B) ->10 ms latency -> router (6 buffers) -> 8 kbps link > -> dest(A). Return path for acks: Dest(A) -> 10 ms latency -> Src(B). The > configuration is for low speed wireless/cellular links. can't help noticing one thing, which people do all the times when modeling slow-speed links. In your system the packet transmission time is 512/560ms (not sure if you count headers in your 512 bytes), for a total queueing delay (one way) of over 3 seconds, so what is the meaning of putting 10ms latency in the path! > (cwnd and ssthresh are expressed in #segments) > > > No. Time(s) Src Dest Seq No. Ack No. cwnd ssthresh Comments > 1 21.399 A B . 18433 6.879 4 > 2 21.399 B A 20993 . . . ... > 12 23.959 A B . 20993 7.578 4 cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- From owner-tcp-impl@lerc.nasa.gov Wed Jan 19 14:30:06 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04103 for ; Wed, 19 Jan 2000 14:30:04 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA06096 for tcp-impl-outgoing; Wed, 19 Jan 2000 11:08:14 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA06059 for ; Wed, 19 Jan 2000 11:08:10 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA08418; Wed, 19 Jan 2000 11:08:10 -0500 (EST) Received: from motgate.mot.com(129.188.136.100) by seraph3.lerc.nasa.gov via smap (V5.0) id xma008390; Wed, 19 Jan 00 11:08:01 -0500 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (VWALL-IN-motgate 2.0) with ESMTP id JAA07306 for ; Wed, 19 Jan 2000 09:07:47 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA09197 for ; Wed, 19 Jan 2000 09:07:46 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Jan 2000 10:07:46 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9AE56BBB@il27exm02.cig.mot.com> From: Ali Irfan-FIA225 To: "'Luigi Rizzo'" , Ali Irfan-FIA225 Cc: "'tcp-impl@grc.nasa.gov'" Subject: RE: BSD 4.4 TCP header prediction code error - Secondary Effect Date: Wed, 19 Jan 2000 10:07:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Luigi, You are right that the 10 ms latency is totally inconsequential and non-realistic in this setup. Wanted to build-in an arbitrary latency capability on both forward and return path in the simulation. Never got around to changing the latency number to a more realistic case. I re-ran the simulations with latencies of 150 ms and 400 ms, still resulting in the same behavior. Irfan -----Original Message----- From: Luigi Rizzo [mailto:luigi@info.iet.unipi.it] Sent: Wednesday, January 19, 2000 3:10 AM To: Ali Irfan-FIA225 Cc: 'tcp-impl@grc.nasa.gov' Subject: Re: BSD 4.4 TCP header prediction code error - Secondary Effect > A snippet of a trace from a simulation showing this behavior is included. > The simulation is for bulk transfer. Source always sends 512 byte segments > and the advertised window is for 8 (4096 bytes). The configuration for the > forward path is Src(B) ->10 ms latency -> router (6 buffers) -> 8 kbps link > -> dest(A). Return path for acks: Dest(A) -> 10 ms latency -> Src(B). The > configuration is for low speed wireless/cellular links. can't help noticing one thing, which people do all the times when modeling slow-speed links. In your system the packet transmission time is 512/560ms (not sure if you count headers in your 512 bytes), for a total queueing delay (one way) of over 3 seconds, so what is the meaning of putting 10ms latency in the path! > (cwnd and ssthresh are expressed in #segments) > > > No. Time(s) Src Dest Seq No. Ack No. cwnd ssthresh Comments > 1 21.399 A B . 18433 6.879 4 > 2 21.399 B A 20993 . . . ... > 12 23.959 A B . 20993 7.578 4 cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- From owner-tcp-impl@lerc.nasa.gov Thu Jan 20 20:26:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17873 for ; Thu, 20 Jan 2000 20:26:02 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA25187 for tcp-impl-outgoing; Thu, 20 Jan 2000 16:36:51 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA25168 for ; Thu, 20 Jan 2000 16:36:49 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA20281; Thu, 20 Jan 2000 16:36:48 -0500 (EST) Received: from exchsrv1.cs.washington.edu(128.95.3.128) by seraph3.lerc.nasa.gov via smap (V5.0) id xma020254; Thu, 20 Jan 00 16:36:18 -0500 Received: by exchsrv1.cs.washington.edu with Internet Mail Service (5.5.2650.21) id ; Thu, 20 Jan 2000 13:36:16 -0800 Message-ID: <055A195871E5D1119F8100A0C9499B5FF00D30@exchsrv1.cs.washington.edu> From: Stefan Savage To: "'tcp-impl@grc.nasa.gov'" Cc: Stefan Savage Subject: strange duplicate ack behavior Date: Thu, 20 Jan 2000 13:36:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk A few months ago I released a tool for estimating one-way loss by exploiting TCP's fast retransmit behavior (see http://www.cs.washington.edu/homes/savage/sting/ for details). Most of my users have been quite happy with it, but I've received one report of spurious results that is stumping me. It appears that under certain configurations, modern Solaris TCP stacks (nmap suggests between 2.5 and 2.7) will generate up to TWO duplicate acknowledgements per out-of-order packet. I say "up to" because if the out-of-order packets are not spaced far enough apart, only a single duplicate ack is sent. For this reason I suspect an interaction with the delayed ack timer. Here's an excerpt from a tcpdump to show what I mean: 13:11:01.023694 A.11155 > B.http: S 4096623726:4096623726(0) win 0 (DF) 13:11:01.221263 B.http > A.11155: S 3198574868:3198574868(0) ack 4096623727 win 4096 13:11:01.224463 A.11155 > B.http: P 4:5(1) ack 1 win 0 (DF) 13:11:01.422993 B.http > A.11155: . ack 1 win 4096 13:11:01.536986 B.http > A.11155: . ack 1 win 4096 13:11:02.233622 A.11155 > B.http: P 5:6(1) ack 1 win 0 (DF) 13:11:02.431472 B.http > A.11155: . ack 1 win 4096 13:11:02.535080 B.http > A.11155: . ack 1 win 4096 13:11:03.233471 A.11155 > B.http: P 6:7(1) ack 1 win 0 (DF) 13:11:03.432267 B.http > A.11155: . ack 1 win 4096 13:11:03.540995 B.http > A.11155: . ack 1 win 4096 13:11:04.233312 A.11155 > B.http: P 7:8(1) ack 1 win 0 (DF) 13:11:04.433672 B.http > A.11155: . ack 1 win 4096 13:11:04.535917 B.http > A.11155: . ack 1 win 4096 13:11:05.233163 A.11155 > B.http: P 8:9(1) ack 1 win 0 (DF) 13:11:05.439115 B.http > A.11155: . ack 1 win 4096 13:11:05.534234 B.http > A.11155: . ack 1 win 4096 Its pretty suspicious that the second ack is 100ms after the first... Two other clues: This does not occur with all services (for instance, if I go to port 25 on the same box I will see normal behavior) so presumably it may reflect some interaction between the delayed ack timer and select. Second, this doesn't seem to happen with all solaris boxes... only some of them (so it may reflect a combination of application characteristics, stack and configuration options). Unfortunately, I don't have Solaris source code or I'd check this out myself. Has anyone seen this before or have any insight into what's happening? Thanks. - Stefan From owner-tcp-impl@lerc.nasa.gov Thu Jan 20 23:00:07 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20906 for ; Thu, 20 Jan 2000 23:00:07 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA11693 for tcp-impl-outgoing; Thu, 20 Jan 2000 20:12:08 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAA11684 for ; Thu, 20 Jan 2000 20:12:07 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id UAA10001; Thu, 20 Jan 2000 20:12:05 -0500 (EST) Received: from prv-mail25.provo.novell.com(137.65.82.196) by seraph3.lerc.nasa.gov via smap (V5.0) id xma009977; Thu, 20 Jan 00 20:11:43 -0500 Received: from INET-PRV1-Message_Server by prv-mail25.provo.novell.com with Novell_GroupWise; Thu, 20 Jan 2000 18:11:11 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 20 Jan 2000 18:10:53 -0700 From: "Ramesh Shankar" To: Subject: Re: BSD 4.4 TCP header prediction code error - Secondary Effect Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id UAA11687 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Here is a stupid question related to the original Bramko fix: The new check described in Brakmo is: && tp->t_dupacks < tcprexmtthresh Why shouldn't this simply be: && (tp->t_dupacks == 0) instead? BTW, t_dupacks is set to 0 when the window is deflatd in NetBSD 1.41 (TCP_INPUT.C line # 1234), FreeBSD3.31 (TCP_INPUT.C, line # 1388) and even in TCP/IP Illustrated vol2. (page 974, Fig 29.5, line # 895). Should t_dupacks be reset to 0 in some other place also? Thanks, S.R. >>> Ali Irfan-FIA225 01/18/00 01:33PM >>> In [Brakmo95], the authors identified the error in the Header Prediction Code due to which TCP fails to deflate the window after fast recovery causing an inappropriate amount of data to be sent into the network after recovery. This error has also been noted in [TCPImplErr] section 2.8, "Failure of window deflation after loss recovery". There is a secondary effect of the error in the header prediction code leading to inconsistent fast-retransmit behavior, which is outlined here. In BSD4.4 TCP, during fast-recovery/fast-retransmit behavior, if cwnd exceeds ssthresh and a new ack arrives, the header-prediction part of the code gets exercised. This leads to failure to "deflate" the window causing large amount of data to be sent, as documented previously. Another consequence is that the dupack count (t_dupacks) does not get reset. The dupack count is above re-transmission threshold (usually 3). Subsequently, the code does not go into fast recovery/fast retransmit when three dupacks arrive. The dupack count gets reset after the arrival of a new ack following a timeout retransmission. A snippet of a trace from a simulation showing this behavior is included. The simulation is for bulk transfer. Source always sends 512 byte segments and the advertised window is for 8 (4096 bytes). The configuration for the forward path is Src(B) ->10 ms latency -> router (6 buffers) -> 8 kbps link -> dest(A). Return path for acks: Dest(A) -> 10 ms latency -> Src(B). The configuration is for low speed wireless/cellular links. (cwnd and ssthresh are expressed in #segments) No. Time(s) Src Dest Seq No. Ack No. cwnd ssthresh Comments 1 21.399 A B . 18433 6.879 4 2 21.399 B A 20993 . . . 3 21.911 A B . 18945 7.025 4 4 21.911 B A 21505 . . . 5 21.911 B A 22017 . . . pkt dropped 6 22.423 A B . 19457 7.167 4 7 22.423 B A 22529 . . . 8 22.935 A B . 19969 7.306 4 9 22.935 B A 23041 . . . 10 23.447 A B . 20481 7.443 4 11 23.447 B A 23553 . . . 12 23.959 A B . 20993 7.578 4 13 23.959 B A 24065 . . . 14 24.471 A B . 21505 7.710 4 15 24.471 B A 24577 . . . 16 24.983 A B . 22017 7.839 4 17 24.983 B A 25089 . . . 18 25.495 A B . 22017 7.839 4 19 26.007 A B . 22017 7.839 4 20 26.519 A B . 22017 6 3 21 26.519 B A 22017 . . . 22 27.031 A B . 22017 7 3 23 27.543 A B . 22017 8 3 24 27.543 B A 25601 . . . 25 28.055 A B . 22017 9 3 26 28.567 A B . 25601 9 3 27 28.567 B A 26113 . . . 28 28.567 B A 26625 . . . 29 28.567 B A 27137 . . . primary symptom 30 28.567 B A 27649 . . . (excessive xmission) 31 28.567 B A 28161 . . . 32 28.567 B A 28673 . . . pkt dropped 33 28.567 B A 29185 . . . pkt dropped 34 29.079 A B . 26113 9 3 35 29.079 B A 29697 . . . 36 29.591 A B . 26625 9 3 37 29.591 B A 30209 . . . 38 30.103 A B . 27137 9 3 39 30.103 B A 30721 . . . 40 30.615 A B . 27649 9 3 41 30.615 B A 31233 . . . 42 31.127 A B . 28161 9 3 43 31.127 B A 31745 . . . 44 31.639 A B . 28673 9 3 45 31.639 B A 32257 . . . 46 32.151 A B . 28673 10 3 47 32.663 A B . 28673 11 3 48 33.175 A B . 28673 12 3 secondary symptom 49 33.687 A B . 28673 13 3 (no fast retransmit) 50 34.199 A B . 28673 14 3 51 34.711 A B . 28673 15 3 52 36.679 B A 28673 . 1 4 53 37.211 A B . 29185 2 4 54 37.211 B A 29185 . . . 55 37.211 B A 29697 . . . 56 37.743 A B . 32769 3 4 References [Brakmo95] L.S. Brakmo and L.L. Peterson, "Performance Problems in BDS4.4 TCP," Computer Communication Review , Vol 25, No. 5, October 1995, pg. 69-86. http://www.cs.arizona.edu/xkernel/people/brakmo.html [TCPImplErr] RFC2525, Known TCP Implementation Problems, March 1999. Irfan Ali Motorola, Network Solutions Sector 1501 Shure Drive Arlington Heights, IL 60004 Phone: (847)632-3281 email: fia225@email.mot.com From owner-tcp-impl@lerc.nasa.gov Fri Jan 21 17:50:46 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18329 for ; Fri, 21 Jan 2000 17:50:45 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA12717 for tcp-impl-outgoing; Fri, 21 Jan 2000 14:34:55 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA12701 for ; Fri, 21 Jan 2000 14:34:53 -0500 (EST) From: brittone@us.ibm.com Received: by seraph3.lerc.nasa.gov; id OAA09561; Fri, 21 Jan 2000 14:34:52 -0500 (EST) Received: from e22.nc.us.ibm.com(32.97.136.228) by seraph3.lerc.nasa.gov via smap (V5.0) id xma009457; Fri, 21 Jan 00 14:34:33 -0500 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA32998 for ; Fri, 21 Jan 2000 14:21:22 -0600 Received: from d54mta05.raleigh.ibm.com (d54mta05.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id OAA32192 for ; Fri, 21 Jan 2000 14:34:30 -0500 Received: by d54mta05.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525686D.006B85E2 ; Fri, 21 Jan 2000 14:34:26 -0500 X-Lotus-FromDomain: IBMUS To: tcp-impl@grc.nasa.gov Message-ID: <8525686D.006B83AF.00@d54mta05.raleigh.ibm.com> Date: Fri, 21 Jan 2000 14:34:19 -0500 Subject: TCP MSS option value Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Please help me understand what RFC2581 intends regarding the value advertised in the MSS option when other options (e.g., Timestamp) are going to be used. Suppose the MTU is 1500 bytes, and after the 3-way handshake a host is going to be sending on each segment 12 bytes of TCP options: Timestamp plus two NOPs. RFC879, "TCP Maximum Segment Size," says "THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE MINUS FORTY" (all capital letters in RFC879). This implies that the host should advertise MSS=1460, but as RFC 879 notes, when it was written there were "no TCP header options ... defined that would normally be sent at the same time as data segments." RFC 1011 states "The TCP Maximum Segment Size is the IP Maximum Datagram Size minus forty," but sending TCP options with data segments was still an obscure subject when that was written. Section 4.2.2.6, "Maximum Segment Size Option," of RFC1122, "Host Requirements -- Communications Layers," does not explicitly say what value to advertise in the MSS option, but it gives a formula for Eff.snd.MSS, "the maximum size of a segment that TCP really sends," that is based on SendMSS, "the MSS value received from the remote host," and the TCPhdrsize. If one solves that formula for SendMSS, and notes the RFC's comment that "TCPhdrsize is the size of the TCP header; this is normally 20, but may be larger if TCP options are to be sent," then it seems to say for a 1500 byte MTU the MSS option value should be 1460, and each segment will carry 1448 byte of data in addition to the 12 bytes of options. Section 2.18, "Options missing from TCP MSS calculation," of RFC 2525, "Known TCP Implementation Problems," reiterates that RFC1122's formula for effective send MSS should be applied in order to avoid fragmentation (or worse problems if Path MTU is being used). Most of the implementations with which I am familiar do indeed send MSS option value of 1460 when the MTU is 1500 and Timestamp option is being used. Similarly, section 18.4, "Maximum Segment Size," of W. Richard Stevens's "TCP/IP Illustrated, Vol. 1" says, "When TCP sends a SYN segment ... it can send an MSS value up to the outgoing interface's MTU, minus the size of the fixed TCP and IP headers." However, RFC2581, "TCP Congestion Control," says "RECEIVER MAXIMUM SEGMENT SIZE (RMSS): The RMSS is the size of the largest segment the receiver is willing to accept. This is the value specified in the MSS option sent by the receiver during connection startup. ... The size does not include the TCP/IP headers and options." This seems to say that if the MTU is 1500 bytes, the IP header is 20, the TCP header is 20, and the TCP option field is 12, then the RMSS (and therefore the MSS option value to advertise) should be 1448. Furthermore, RFC2581 also says "SENDER MAXIMUM SEGMENT SIZE (SMSS): The SMSS is the size of the largest segment that the sender can transmit. This value can be based on the maximum transmission unit of the network, the path MTU discovery [MD90] algorithm, RMSS ... , or other factors. The size does not include the TCP/IP headers and options." Is SMSS the same as RFC1122's Eff.snd.MSS? If so, then if the received MSS advertisement is 1448, wouldn't the SMSS be 1436 (i.e., min (1448+20,1480)-32)? If I understand correctly that RFC2851 says TCP should advertise MSS opt value of 1448 when MTU=1500 and TCPoptionLength=12, then I have some further questions about how to calculate Eff.snd.MSS, the number of data bytes to send in a segment along with the headers and options: 1) Does the effective send MSS calculation of RFC1122 still apply? If so, then when the local host advertises MSS option value of 1448, the remote host will calculate an effective send MSS of 1436 (=min(1448+20,1480)--32), and therefore send segments with 1436 bytes of data even though the local host can handle segments of 1448 bytes of data. While I heartily agree with the suggestion later in RFC2851 that implementations should be liberal in interpreting what constitutes two full-sized segments when deciding when to ACK, I am concerned that existing implementations are not so liberal and that hosts sending 1436 bytes of data to them will get into the Nagel-DelayedAck standoff described on page 204 of Stevens's second edition of UNIX Network Programming. 2) If the effective send MSS calculation of RFC1122 no longer should be used, and the remote host has an old implementation that calculates the MSS value to advertise by merely subtracting 40 from its MTU, then the local host could wind up sending datagrams larger than the remote host's MTU. For example, suppose the local host has MTU=2000 and the remote host has MTU=1500. If the remote host advertises MSS option=1460 (i.e., MTU-40, ignoring the TCP option bytes), and the local host interprets that received MSS option value of 1460 per RFC2581, i.e., as if it did not include TCP header and TCP option bytes, then the local host would send datagrams 1512 bytes long (20 for IPheader + 20 for TCPfixedHeader+12 for TCPoptions+1460 for data). That of course can lead to performance-reducing fragmentation or even complete communication failure. I hope I have misinterpreted RFC2581's intentions regarding MSS option value. If not, can you give me any advice on how to interoperate with the existing implementations that calculate MSS option value by subtracting 40 from the MTU even when other TCP options are going to be used. Regards, Ed Britton From owner-tcp-impl@lerc.nasa.gov Fri Jan 21 22:27:49 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21633 for ; Fri, 21 Jan 2000 22:27:49 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA16509 for tcp-impl-outgoing; Fri, 21 Jan 2000 19:11:47 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA16492 for ; Fri, 21 Jan 2000 19:11:45 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA10879; Fri, 21 Jan 2000 19:11:43 -0500 (EST) Received: from tnt.isi.edu(128.9.128.128) by seraph3.lerc.nasa.gov via smap (V5.0) id xma010853; Fri, 21 Jan 00 19:11:21 -0500 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA02072; Fri, 21 Jan 2000 16:11:16 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id AAA07222; Sat, 22 Jan 2000 00:11:15 GMT Date: Sat, 22 Jan 2000 00:11:15 GMT Message-Id: <200001220011.AAA07222@gra.isi.edu> To: tcp-impl@grc.nasa.gov, brittone@us.ibm.com Subject: Re: TCP MSS option value X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk *> *> *> Please help me understand what RFC2581 intends regarding the value *> advertised in the MSS option when other options (e.g., Timestamp) are going *> to be used. *> *> Suppose the MTU is 1500 bytes, and after the 3-way handshake a host is *> going to be sending on each segment 12 bytes of TCP options: Timestamp *> plus two NOPs. RFC879, "TCP Maximum Segment Size," says "THE TCP MAXIMUM *> SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE MINUS FORTY" (all capital *> letters in RFC879). This implies that the host should advertise MSS=1460, *> but as RFC 879 notes, when it was written there were "no TCP header *> options ... defined that would normally be sent at the same time as data *> segments." RFC 1011 states "The TCP Maximum Segment Size is the IP Maximum *> Datagram Size minus forty," but sending TCP options with data segments was *> still an obscure subject when that was written. Section 4.2.2.6, "Maximum *> Segment Size Option," of RFC1122, "Host Requirements -- Communications *> Layers," does not explicitly say what value to advertise in the MSS *> option, but it gives a formula for Eff.snd.MSS, "the maximum size of a *> segment that TCP really sends," that is based on SendMSS, "the MSS value *> received from the remote host," and the TCPhdrsize. If one solves that Ed, The MSS option is NOT intended as an MTU discovery mechanism. It gives the max segment size the TCP receive and reassemble. It does not, and is not intended to, tell the sender how large a segment to send. It is strictly true, but perhaps irrelevant, that RFC 1122 does not specify what value to send in an MSS option. However, it DOES give an upper bound on the value (MMS_R - 40) and a recommendation: determine MMS_R as specified in sections 3.3.3 and 3.4 (I see it should have referenced 3.3.2 also.) When you dig down through all that, you find that MMS_R = EMTU_R - 20, where EMTU_R is the largest datagram IP can receive and reassemble... in other words, 65532. So the recommended answer is: 65532 - 20 - 20 bytes should be sent in an MSS option. So, back in the early days (early 1980s) the Berkeley Unix folks were trying to make TCP work well, and they (re-)discovered that IP fragmentation was a Bad Idea. Rather than fix the protocol (by inventing MTU Path Discovery), they put in a hack: set the MSS down to the local interface MTU and hope. This worked OK for awhile but was not really the right answer. The (perhaps painful) discussion in RFC 1122 was an attempt by a bunch of IETFers to set this business straight. Note that the value you should send in the MSS option has no relation to the appearance of TCP options. That is the problem of the sender only. What the sender has to do is complex. When I implemented the 1323 extensions and also T/TCP, I had to do considerable hacking on the BSD TCP machinery to get right the logic that determines a segment size to send. (I thought this was written up somewhere, but I cannot find it in any of the relevant RFCs now; maybe it was a comment in the T/TCP code). Hope this helps, Bob Braden From owner-tcp-impl@lerc.nasa.gov Sun Jan 23 21:58:23 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14406 for ; Sun, 23 Jan 2000 21:58:17 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA01123 for tcp-impl-outgoing; Sun, 23 Jan 2000 19:00:46 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA01111 for ; Sun, 23 Jan 2000 19:00:44 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA06515; Sun, 23 Jan 2000 19:00:44 -0500 (EST) Received: from mailhost.iprg.nokia.com(205.226.5.12) by seraph3.lerc.nasa.gov via smap (V5.0) id xma006507; Sun, 23 Jan 00 19:00:30 -0500 Received: from aspen.iprg.nokia.com ([205.226.14.73]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id QAA01606 for ; Sun, 23 Jan 2000 16:00:29 -0800 (PST) From: Fred Bauer Received: (fred@localhost) by aspen.iprg.nokia.com (8.8.8/8.6.12) id QAA00392 for tcp-impl@lerc.nasa.gov; Sun, 23 Jan 2000 16:00:28 -0800 (PST) Date: Sun, 23 Jan 2000 16:00:28 -0800 (PST) Message-Id: <200001240000.QAA00392@aspen.iprg.nokia.com> To: tcp-impl@lerc.nasa.gov Subject: INFOCOM 2000: LAST DAY for special-rate hotel reservation Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk >>>>> LAST DAY for special-rate hotel reservation - INFOCOM 2000 <<<<< CALL FOR PARTICIPATION ------------------------ IEEE Infocom 2000 (Israel) http://www.comnet.technion.ac.il/infocom2000 (U.S.A.) http://www.cse.ucsc.edu/~rom/infocom2000 (Japan) http://halo.kuamp.kyoto-u.ac.jp/~infocom Dan Panorama Hotel, Tel Aviv, Israel March 26-30, 2000 Sponsored by the IEEE Communications and Computer Societies IMPORTANT DATES =============== Cut-off dates for special lower rates: Hotel reservation cut-off date* January 24, 2000 (LAST DAY!) Early registration cut-off date February 28, 2000 Infocom 2000 dates: Tutorials March 26-27, 2000 Conference March 28-30, 2000 * Israel is expected to be crowded with tourists during the year 2000. Furthermore, the Pope is scheduled to visit Israel the week before the conference. Hence, it is advised to make HOTEL and FLIGHT reservations for the conference as soon as possible. HOTEL RATES =========== Double Occupancy $157.50 Single Occupancy $139.00 Rates are per room per night and include full Israeli buffet breakfast. The rates also include all taxes for non-israelis. For more details consult the web pages. http://www.comnet.technion.ac.il/infocom2000/reservation.html REGISTRATION FEES ================= Registration fees for an IEEE member prior to February 28, 2000 will be $500 and it will include all technical sessions, open receptions, proceedings (CD) and three lunches. For other fees consult the web pages. ------------- On-line registration: https://secure.computer.org/conf/infocom/register.htm VENUE ===== For the last 18 years, Infocom has been the major conference on computer communications and networking, bringing together researchers and implementors of every aspect of data communications and networks presenting the most up-to-date results and achievements in the field. The 19th annual conference on Computer Communications, Infocom 2000, will be held at the Dan Panorama Hotel in Tel-Aviv, Israel, during the week of March 26-30, 2000. Overlooking the Mediterranean, the Dan Panorama Tel Aviv is a city hotel in a resort setting. Just a few steps away are fine shops, theaters, restaurants and the corporate world of Tel Aviv, contrasted by the ancient port city of Jaffa with its picturesque corners and flea markets for bargain hunters. The hotel features a large swimming pool, beach access and a fully equipped health & fitness center. SCOPE ===== Original papers and panel discussions describing state-of-the-art research and development in all areas of computer networking and data communications will be presented. Browse the excellent technical program and see the papers at http://www.comnet.technion.ac.il/infocom2000/program.html KEYNOTE SPEAKER =============== Prof. Leonard Kleinrock, Chairman, Nomadix, Inc. Keynote title: Nomadic Computing and Smart Spaces http://www.comnet.technion.ac.il/infocom2000/key.html TUTORIALS ========= Full Day -------- - Wavelength-routing optical networks (Kumar Sivarajan, Indian Institute of Science) - The evolution of QoS in the Internet standards community (Jon Crowcroft, University College London) - Overview of network security (Radia Perlman, Sun Microsystems) - Teletraffic Models and Tools: From Basics to Advanced(Khosrow Sohraby, University of Missouri, Kansas City) - IP Multicast: past, present and future (Radia Perlman, Sun Microsystems & Christophe Diot, Sprint) Half Day -------- - MPLS (Loa Andersson, Nortel Networks) - New technologies for LAN systems (Dono Van-Mierop, IBM Israel) - Satellite IP networking (Catherine Rosenberg, Purdue University) - Mobile IP: adding mobility to the Internet (Charles Perkins, Nokia Research) http://www.comnet.technion.ac.il/infocom2000/tutorial.html QUESTIONS? =========================== Write to infocom@comnet.technion.ac.il] From owner-tcp-impl@lerc.nasa.gov Tue Jan 25 01:43:07 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10224 for ; Tue, 25 Jan 2000 01:43:06 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA20414 for tcp-impl-outgoing; Mon, 24 Jan 2000 22:08:44 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA20401 for ; Mon, 24 Jan 2000 22:08:42 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id WAA21240; Mon, 24 Jan 2000 22:08:41 -0500 (EST) Received: from stephens.ittc.ukans.edu(129.237.125.220) by seraph3.lerc.nasa.gov via smap (V5.0) id xma021214; Mon, 24 Jan 00 22:08:16 -0500 Received: from mill.ittc.ukans.edu (mill.ittc.ukans.edu [129.237.125.192]) by stephens.ittc.ukans.edu (8.9.3/8.9.3/ITTC-NOSPAM-1.0) with ESMTP id VAA01120 for ; Mon, 24 Jan 2000 21:08:15 -0600 (CST) Received: from localhost by mill.ittc.ukans.edu (8.8.5/KU-4.0-client) id VAA19326; Mon, 24 Jan 2000 21:08:14 -0600 (CST) Date: Mon, 24 Jan 2000 21:08:14 -0600 (CST) From: Anupama Sundaresan To: tcp-impl@lerc.nasa.gov Subject: Anomalous TCP behaviour? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hello, Is it normal for TCP to skip a certain number of bytes and send them later when it receives dup acks? The following tcpdump o/p illustrates that TCP sends packets in sequence upto a certain point but suddenly skips a certain number of bytes and after receiving 5 duplicate acks transmits not 'retransmits' the missing bytes... # comments inline. testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 1:1449(1448) ack testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 1449:2897(1448) ack testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 1449 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 5793:7241(1448) ack testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 7241:8689(1448) ack testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 8689:10137(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 10137:11585(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 11585:13033(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 2897:4345(1448) ack testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 4345:5793(1448) ack testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 4345 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 13033 testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 13033:14481(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 14481:15929(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 15929:17377(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 17377:18825(1448) testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 15929 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 18825 testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 18825:20273(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 20273:21721(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 21721:23169(1448) testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 21721 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 23169 testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 23169:24617(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 24617:26065(1448) testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 26065 testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 26065:27513(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 27513:28961(1448) testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 ## till now it was Txing it in sequence but now after 28961 it goes off to 30409 so it starts getting dup acks... testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 30409:31857(1448) testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 31857:33305(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 33305:34753(1448) testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 34753:36201(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 36201:37649(1448) testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 ## again after 5 dupacks (if u leave out the original ack) it transmits NOT retransmits that block between 28961 and 30409. This happens many times... Is this normal TCP behaviour? testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 28961:30409(1448) testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 37649 testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 40545:41993(1448) ## Also it is obvious from the tcpdump o/p that the Fast retransmit mechanism doesnt get kicked off after 3 dup acks - is this normal behaviour? Here, the segment from 53577 to 55025 is not transmitted so we start getting dup acks for 53577 testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 52129:53577(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 46337:47785(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 55025:56473(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 56473:57921(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 57921:59369(1448) testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 1 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 2 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 3 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 4 testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 59369:60817(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 60817:62265(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 62265:63713(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 63713:65161(1448) testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 5 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 6 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 7 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 8 testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 65161:66609(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 66609:68057(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 68057:69505(1448) testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 9 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 10 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 11 testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 70953:72401(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 72401:73849(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 73849:75297(1448) testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 12 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 13 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 14 testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 69505:70953(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 75297:76745(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 76745:78193(1448) testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 78193:79641(1448) testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 15 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 16 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 17 testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 18 testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 53577:55025(1448) Around 18 dup acks are received before that segment is transmitted. again this is a case of out of order packets tcptrace o/p for the same tcpdump o/p a->b: b->a: total packets: 22457 total packets: 7601 ack pkts sent: 22456 ack pkts sent: 7601 pure acks sent: 1 pure acks sent: 7599 unique bytes sent: 30000000 unique bytes sent: 0 actual data pkts: 22455 actual data pkts: 0 actual data bytes: 30000000 actual data bytes: 0 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 outoforder pkts: 9 outoforder pkts: 0 pushed data pkts: 15067 pushed data pkts: 0 Infact the outoforder packets is pretty large in some cases. Is this normal? Thanks, -anu. From owner-tcp-impl@lerc.nasa.gov Tue Jan 25 07:40:49 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22594 for ; Tue, 25 Jan 2000 07:40:49 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA06405 for tcp-impl-outgoing; Tue, 25 Jan 2000 04:36:30 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA06396 for ; Tue, 25 Jan 2000 04:36:29 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA17270; Tue, 25 Jan 2000 04:36:28 -0500 (EST) Received: from daffy.ee.lbl.gov(131.243.1.31) by seraph3.lerc.nasa.gov via smap (V5.0) id xma017167; Tue, 25 Jan 00 04:35:48 -0500 Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id BAA12909; Tue, 25 Jan 2000 01:35:46 -0800 (PST) Message-Id: <200001250935.BAA12909@daffy.ee.lbl.gov> To: Anupama Sundaresan Cc: tcp-impl@lerc.nasa.gov Subject: Re: Anomalous TCP behaviour? In-reply-to: Your message of Mon, 24 Jan 2000 21:08:14 PST. Date: Tue, 25 Jan 2000 01:35:46 PST From: Vern Paxson Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Is it normal for TCP to skip a certain number of bytes and send > them later when it receives dup acks? No, it isn't. But, depending on how you recorded the traffic, it's possible that it's sending in order but the packets are being lost before they make it to the packet filter (e.g., because the NIC card is dropping them). > ## Also it is obvious from the tcpdump o/p that the Fast retransmit > mechanism doesnt get kicked off after 3 dup acks - is this normal > behaviour? Again, no, but you need to check the advertised window on each of the dups. If it changes, then the counting for # of duplicates starts over. > outoforder pkts: 9 outoforder pkts: 0 What does outoforder pkts mean here? Vern From owner-tcp-impl@lerc.nasa.gov Tue Jan 25 08:38:14 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25182 for ; Tue, 25 Jan 2000 08:38:13 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA06165 for tcp-impl-outgoing; Tue, 25 Jan 2000 04:29:49 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA06152 for ; Tue, 25 Jan 2000 04:29:43 -0500 (EST) From: jonas.haggard.ljungquist@teracom.se Received: by seraph3.lerc.nasa.gov; id EAA16828; Tue, 25 Jan 2000 04:29:43 -0500 (EST) Received: from gateway.teracom.se(195.84.7.221) by seraph3.lerc.nasa.gov via smap (V5.0) id xma016820; Tue, 25 Jan 00 04:29:12 -0500 Received: by gateway with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Jan 2000 10:29:07 +0100 Message-ID: To: anu@ittc.ukans.edu Cc: tcp-impl@grc.nasa.gov Subject: SV: Anomalous TCP behaviour? Date: Tue, 25 Jan 2000 10:26:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id EAA06162 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Hi, What TCP implementation are you testing? I have encountered a similar problem with FreeBSD (after messing it up by disabling slow start). What happened was that the Ethernet driver dropped packets, this because we used rather large windows. When dupacks arrived and TCP tried to retransmit the lost packet the driver queue was still full and the new packet was also dropped. I dont know if this could be your problem as well, a bit more information of how and what you are testing would help. /Jonas Haggård Ljungquist > ---------- > Från: Anupama Sundaresan[SMTP:anu@ittc.ukans.edu] > Skickat: den 25 januari 2000 04:08 > Till: tcp-impl@lerc.nasa.gov > Angående: Anomalous TCP behaviour? > > Hello, > > Is it normal for TCP to skip a certain number of bytes and send > them later when it receives dup acks? > > The following tcpdump o/p illustrates that TCP sends packets in sequence > upto a certain point but suddenly skips a certain number of bytes and > after receiving 5 duplicate acks transmits not 'retransmits' the missing > bytes... > > # comments inline. > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 1:1449(1448) > ack > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 1449:2897(1448) > ack > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 1449 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 5793:7241(1448) > ack > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 7241:8689(1448) > ack > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 8689:10137(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 10137:11585(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 11585:13033(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 2897:4345(1448) > ack > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 4345:5793(1448) > ack > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 4345 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 13033 > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 13033:14481(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 14481:15929(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 15929:17377(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 17377:18825(1448) > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 15929 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 18825 > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 18825:20273(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 20273:21721(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 21721:23169(1448) > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 21721 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 23169 > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 23169:24617(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 24617:26065(1448) > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 26065 > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 26065:27513(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 27513:28961(1448) > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 > > ## till now it was Txing it in sequence but now after 28961 it > goes off to 30409 so it starts getting dup acks... > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 30409:31857(1448) > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 31857:33305(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 33305:34753(1448) > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 34753:36201(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 36201:37649(1448) > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 > > ## again after 5 dupacks (if u leave out the original ack) it transmits > NOT > retransmits that block between 28961 and 30409. This happens many times... > Is this normal TCP behaviour? > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 28961:30409(1448) > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 37649 > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 40545:41993(1448) > > ## Also it is obvious from the tcpdump o/p that the Fast retransmit > mechanism doesnt get kicked off after 3 dup acks - is this normal > behaviour? > > Here, the segment from 53577 to 55025 is not transmitted so we start > getting dup acks for 53577 > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 52129:53577(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 46337:47785(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 55025:56473(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 56473:57921(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 57921:59369(1448) > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 1 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 2 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 3 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 4 > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 59369:60817(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 60817:62265(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 62265:63713(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 63713:65161(1448) > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 5 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 6 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 7 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 8 > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 65161:66609(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 66609:68057(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 68057:69505(1448) > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 9 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 10 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 11 > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 70953:72401(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 72401:73849(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 73849:75297(1448) > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 12 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 13 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 14 > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 69505:70953(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 75297:76745(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 76745:78193(1448) > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 78193:79641(1448) > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 15 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 16 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 17 > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 18 > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > 53577:55025(1448) > > Around 18 dup acks are received before that segment is transmitted. again > this is a case of out of order packets > > > tcptrace o/p for the same tcpdump o/p > a->b: b->a: > total packets: 22457 total packets: 7601 > > ack pkts sent: 22456 ack pkts sent: 7601 > > pure acks sent: 1 pure acks sent: 7599 > > unique bytes sent: 30000000 unique bytes sent: 0 > > actual data pkts: 22455 actual data pkts: 0 > > actual data bytes: 30000000 actual data bytes: 0 > > rexmt data pkts: 0 rexmt data pkts: 0 > > rexmt data bytes: 0 rexmt data bytes: 0 > > outoforder pkts: 9 outoforder pkts: 0 > > pushed data pkts: 15067 pushed data pkts: 0 > > > Infact the outoforder packets is pretty large in some cases. > Is this normal? > > Thanks, > -anu. > > > > > From owner-tcp-impl@lerc.nasa.gov Tue Jan 25 12:19:01 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03997 for ; Tue, 25 Jan 2000 12:18:58 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA24718 for tcp-impl-outgoing; Tue, 25 Jan 2000 09:05:01 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA24701 for ; Tue, 25 Jan 2000 09:04:59 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA05791; Tue, 25 Jan 2000 09:04:59 -0500 (EST) Received: from smtprich.nortel.com(192.135.215.8) by seraph3.lerc.nasa.gov via smap (V5.0) id xma005776; Tue, 25 Jan 00 09:04:34 -0500 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprich.nortel.com; Tue, 25 Jan 2000 08:04:15 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 25 Jan 2000 08:03:33 -0600 Message-ID: <417CF9E6B325D3119DA90000F81FAE16D5D6C7@zrchb201.us.nortel.com> From: "Spencer Dawkins" To: tcp-impl@lerc.nasa.gov Subject: RE: Anomalous TCP behaviour? Date: Tue, 25 Jan 2000 08:03:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF673C.F4071CCE" X-Orig: Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF673C.F4071CCE Content-Type: text/plain; charset="ISO-8859-1" Anupama, are you measuring this on the sending system, the receiving system, or somewhere in between? Just curious. (Once the packets leave the sending system, they can be dropped due to link errors or checksum errors, for instance, so your measurement system may not be seeing these errored packets.) Spencer -----Original Message----- From: Anupama Sundaresan [mailto:anu@ittc.ukans.edu] Sent: Monday, January 24, 2000 10:08 PM To: tcp-impl@lerc.nasa.gov Subject: Anomalous TCP behaviour? Hello, Is it normal for TCP to skip a certain number of bytes and send them later when it receives dup acks? ------_=_NextPart_001_01BF673C.F4071CCE Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Anomalous TCP behaviour?

Anupama, are you measuring this on the sending = system, the receiving system, or somewhere in between? Just = curious.

(Once the packets leave the sending system, they can = be dropped due to link errors or checksum errors, for instance, so your = measurement system may not be seeing these errored packets.)

Spencer

-----Original Message-----
From: Anupama Sundaresan [mailto:anu@ittc.ukans.edu]=
Sent: Monday, January 24, 2000 10:08 PM
To: tcp-impl@lerc.nasa.gov
Subject: Anomalous TCP behaviour?


Hello,

        Is it = normal for TCP to skip a certain number of bytes and send
them later when it receives dup acks?

------_=_NextPart_001_01BF673C.F4071CCE-- From owner-tcp-impl@lerc.nasa.gov Tue Jan 25 12:23:48 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04119 for ; Tue, 25 Jan 2000 12:23:46 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA22292 for tcp-impl-outgoing; Tue, 25 Jan 2000 08:47:47 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA22276 for ; Tue, 25 Jan 2000 08:47:45 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA04054; Tue, 25 Jan 2000 08:47:44 -0500 (EST) Received: from picard.cs.ohiou.edu(132.235.3.128) by seraph3.lerc.nasa.gov via smap (V5.0) id xma004044; Tue, 25 Jan 00 08:47:39 -0500 Received: from picard.cs.ohiou.edu (localhost [127.0.0.1]) by picard.cs.ohiou.edu (8.8.8+Sun/8.7.1) with ESMTP id IAA12473; Tue, 25 Jan 2000 08:42:58 -0500 (EST) Message-Id: <200001251342.IAA12473@picard.cs.ohiou.edu> To: Vern Paxson Cc: tcp-impl@lerc.nasa.gov In-Reply-To: <200001250935.BAA12909@daffy.ee.lbl.gov> Reply-To: ostermann@cs.ohiou.edu From: "Shawn Ostermann" cc: Anupama Sundaresan Subject: Re: Anomalous TCP behaviour? Date: Tue, 25 Jan 2000 08:42:58 -0500 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > > outoforder pkts: 9 outoforder pkts: 0 > > What does outoforder pkts mean here? That's what you'll see with tcptrace when it sees a retransmitted segment without having seen the original. It could be caused by missing packets in the trace file, but it's more commonly the case that you're grabbing the packets near the receiver rather than near the sender. In either case, you can't tell for sure whether the segments are out of order or a retransmission (although it's almost always the latter, of course). --sdo ------------------------------------------------------------------------- Dr. Shawn Ostermann - Associate Professor - Ohio University 322 Stocker Center, Ohio University, Athens, Ohio 45701-2979 ostermann@cs.ohiou.edu -- FAX: (740)593-0007 -- Voice: (740)593-1234 http://ace.cs.ohiou.edu/~osterman http://jarok.cs.ohiou.edu From owner-tcp-impl@lerc.nasa.gov Tue Jan 25 13:21:32 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05620 for ; Tue, 25 Jan 2000 13:21:30 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA05581 for tcp-impl-outgoing; Tue, 25 Jan 2000 10:17:06 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA05544 for ; Tue, 25 Jan 2000 10:17:03 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA13954; Tue, 25 Jan 2000 10:17:02 -0500 (EST) Received: from twig.rodents.montreal.qc.ca(216.46.5.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma013724; Tue, 25 Jan 00 10:16:00 -0500 Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id KAA19610; Tue, 25 Jan 2000 10:15:25 -0500 (EST) Date: Tue, 25 Jan 2000 10:15:25 -0500 (EST) From: der Mouse Message-Id: <200001251515.KAA19610@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: Anupama Sundaresan Cc: tcp-impl@lerc.nasa.gov Subject: Re: Anomalous TCP behaviour? Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > Is it normal for TCP to skip a certain number of bytes and send them > later when it receives dup acks? No. Without knowing where this tcpdump was taken I can't be sure what the cause is, but this looks a whole lot like dropped packets - on the sending system, on the receiving system, or anywhere in between, as long as it's before the tcpdump point. > ## Also it is obvious from the tcpdump o/p that the Fast retransmit > mechanism doesnt get kicked off after 3 dup acks - is this normal > behaviour? Maybe. Fast retransmit could be happening; all we know is that *tcpdump* doesn't see the retransmit before it sees the other acks. Again, it depends heavily on the network characteristics. If you're sniffing close to the receiving host, and there's relatively high latency between the two principals, this behavior would not surprise me at all. der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@lerc.nasa.gov Tue Jan 25 13:44:20 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06044 for ; Tue, 25 Jan 2000 13:44:19 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA10516 for tcp-impl-outgoing; Tue, 25 Jan 2000 10:46:24 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA10486 for ; Tue, 25 Jan 2000 10:46:21 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA17491; Tue, 25 Jan 2000 10:46:20 -0500 (EST) Received: from stephens.ittc.ukans.edu(129.237.125.220) by seraph3.lerc.nasa.gov via smap (V5.0) id xma017463; Tue, 25 Jan 00 10:46:07 -0500 Received: from spacely.ittc.ukans.edu (spacely.ittc.ukans.edu [129.237.126.116]) by stephens.ittc.ukans.edu (8.9.3/8.9.3/ITTC-NOSPAM-1.0) with ESMTP id JAA21701; Tue, 25 Jan 2000 09:46:06 -0600 (CST) Received: from localhost by spacely.ittc.ukans.edu (8.9.3/KU-4.0-client) id JAA14554; Tue, 25 Jan 2000 09:46:06 -0600 Date: Tue, 25 Jan 2000 09:46:06 -0600 (CST) From: Yoganandhini Janarthanan To: Anupama Sundaresan cc: tcp-impl@lerc.nasa.gov Subject: Re: Anomalous TCP behaviour? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk i think the address is tcp-impl@grc.nasa.gov... where did you get this address? bcos all other mails seem to have that address... With luv, J.Yogi. From owner-tcp-impl@lerc.nasa.gov Tue Jan 25 14:59:20 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07034 for ; Tue, 25 Jan 2000 14:59:18 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA18869 for tcp-impl-outgoing; Tue, 25 Jan 2000 11:39:13 -0500 (EST) Received: from guns (guns.lerc.nasa.gov [139.88.44.160]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA18842; Tue, 25 Jan 2000 11:39:01 -0500 (EST) Message-Id: <200001251639.LAA18842@lombok-fi.lerc.nasa.gov> To: Yoganandhini Janarthanan From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: Anupama Sundaresan , tcp-impl@lerc.nasa.gov Subject: Re: Anomalous TCP behaviour? Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Blow Up the Outside World Date: Tue, 25 Jan 2000 11:39:00 -0500 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > i think the address is tcp-impl@grc.nasa.gov... where did you get > this address? We changed domain names (from "lerc.nasa.gov" to "grc.nasa.gov"). Both still work, however the GRC form is preferred (as the LeRC form may not work at some point). allman From owner-tcp-impl@lerc.nasa.gov Tue Jan 25 15:14:13 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07270 for ; Tue, 25 Jan 2000 15:14:12 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA23235 for tcp-impl-outgoing; Tue, 25 Jan 2000 12:10:34 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA23203 for ; Tue, 25 Jan 2000 12:10:32 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA28300; Tue, 25 Jan 2000 12:10:31 -0500 (EST) Received: from stephens.ittc.ukans.edu(129.237.125.220) by seraph3.lerc.nasa.gov via smap (V5.0) id xma028208; Tue, 25 Jan 00 12:09:54 -0500 Received: from mill.ittc.ukans.edu (mill.ittc.ukans.edu [129.237.125.192]) by stephens.ittc.ukans.edu (8.9.3/8.9.3/ITTC-NOSPAM-1.0) with ESMTP id LAA24657; Tue, 25 Jan 2000 11:09:53 -0600 (CST) Received: from localhost by mill.ittc.ukans.edu (8.8.5/KU-4.0-client) id LAA19863; Tue, 25 Jan 2000 11:09:52 -0600 (CST) Date: Tue, 25 Jan 2000 11:09:52 -0600 (CST) From: Anupama Sundaresan To: jonas.haggard.ljungquist@teracom.se cc: tcp-impl@grc.nasa.gov Subject: Re: SV: Anomalous TCP behaviour? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by lombok-fi.lerc.nasa.gov id MAA23227 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Hi, The tcpdump o/p which I sent was taken at the transmitter. I'm testing a linux 2.2.13 implemetation. I want to observe the behaviour of TCP under normal conditions bcoz I too want to test the behaviour of TCP after disabling congestion control. > because we used rather large windows. When dupacks arrived > and TCP tried to retransmit the lost packet the driver queue was still > full and the new packet was also dropped. ## So, is that the reason why the receiver is sending so many Dup acks and in the tcpdump o/p we cant see the transmitter making any effort to transmit the missing segment? Thanks, -Anu. > > > ---------- > > Från: Anupama Sundaresan[SMTP:anu@ittc.ukans.edu] > > Skickat: den 25 januari 2000 04:08 > > Till: tcp-impl@lerc.nasa.gov > > Angående: Anomalous TCP behaviour? > > > > Hello, > > > > Is it normal for TCP to skip a certain number of bytes and send > > them later when it receives dup acks? > > > > The following tcpdump o/p illustrates that TCP sends packets in sequence > > upto a certain point but suddenly skips a certain number of bytes and > > after receiving 5 duplicate acks transmits not 'retransmits' the missing > > bytes... > > > > # comments inline. > > > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 1:1449(1448) > > ack > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 1449:2897(1448) > > ack > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 1449 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 5793:7241(1448) > > ack > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 7241:8689(1448) > > ack > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 8689:10137(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 10137:11585(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 11585:13033(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 2897:4345(1448) > > ack > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 4345:5793(1448) > > ack > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 4345 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 13033 > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 13033:14481(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 14481:15929(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 15929:17377(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 17377:18825(1448) > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 15929 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 18825 > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 18825:20273(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 20273:21721(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 21721:23169(1448) > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 21721 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 23169 > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 23169:24617(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 24617:26065(1448) > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 26065 > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 26065:27513(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 27513:28961(1448) > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 > > > > ## till now it was Txing it in sequence but now after 28961 it > > goes off to 30409 so it starts getting dup acks... > > > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 30409:31857(1448) > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 31857:33305(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 33305:34753(1448) > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 34753:36201(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 36201:37649(1448) > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961 > > > > ## again after 5 dupacks (if u leave out the original ack) it transmits > > NOT > > retransmits that block between 28961 and 30409. This happens many times... > > Is this normal TCP behaviour? > > > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 28961:30409(1448) > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 37649 > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 40545:41993(1448) > > > > ## Also it is obvious from the tcpdump o/p that the Fast retransmit > > mechanism doesnt get kicked off after 3 dup acks - is this normal > > behaviour? > > > > Here, the segment from 53577 to 55025 is not transmitted so we start > > getting dup acks for 53577 > > > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 52129:53577(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 46337:47785(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 55025:56473(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 56473:57921(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 57921:59369(1448) > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 1 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 2 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 3 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 4 > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 59369:60817(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 60817:62265(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 62265:63713(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 63713:65161(1448) > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 5 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 6 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 7 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 8 > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 65161:66609(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 66609:68057(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 68057:69505(1448) > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 9 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 10 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 11 > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 70953:72401(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 72401:73849(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 73849:75297(1448) > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 12 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 13 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 14 > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 69505:70953(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 75297:76745(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 76745:78193(1448) > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 78193:79641(1448) > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 15 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 16 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 17 > > testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 18 > > testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: > > 53577:55025(1448) > > > > Around 18 dup acks are received before that segment is transmitted. again > > this is a case of out of order packets > > > > > > tcptrace o/p for the same tcpdump o/p > > a->b: b->a: > > total packets: 22457 total packets: 7601 > > > > ack pkts sent: 22456 ack pkts sent: 7601 > > > > pure acks sent: 1 pure acks sent: 7599 > > > > unique bytes sent: 30000000 unique bytes sent: 0 > > > > actual data pkts: 22455 actual data pkts: 0 > > > > actual data bytes: 30000000 actual data bytes: 0 > > > > rexmt data pkts: 0 rexmt data pkts: 0 > > > > rexmt data bytes: 0 rexmt data bytes: 0 > > > > outoforder pkts: 9 outoforder pkts: 0 > > > > pushed data pkts: 15067 pushed data pkts: 0 > > > > > > Infact the outoforder packets is pretty large in some cases. > > Is this normal? > > > > Thanks, > > -anu. > > > > > > > > > > > From owner-tcp-impl@lerc.nasa.gov Tue Jan 25 15:58:17 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07681 for ; Tue, 25 Jan 2000 15:58:14 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA28483 for tcp-impl-outgoing; Tue, 25 Jan 2000 12:48:04 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA28448 for ; Tue, 25 Jan 2000 12:48:01 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA03397; Tue, 25 Jan 2000 12:48:01 -0500 (EST) Received: from stephens.ittc.ukans.edu(129.237.125.220) by seraph3.lerc.nasa.gov via smap (V5.0) id xma003361; Tue, 25 Jan 00 12:47:43 -0500 Received: from mill.ittc.ukans.edu (mill.ittc.ukans.edu [129.237.125.192]) by stephens.ittc.ukans.edu (8.9.3/8.9.3/ITTC-NOSPAM-1.0) with ESMTP id LAA24420; Tue, 25 Jan 2000 11:47:42 -0600 (CST) Received: from localhost by mill.ittc.ukans.edu (8.8.5/KU-4.0-client) id LAA19958; Tue, 25 Jan 2000 11:47:42 -0600 (CST) Date: Tue, 25 Jan 2000 11:47:42 -0600 (CST) From: Anupama Sundaresan To: Spencer Dawkins cc: tcp-impl@grc.nasa.gov Subject: RE: Anomalous TCP behaviour? In-Reply-To: <417CF9E6B325D3119DA90000F81FAE16D5D6C7@zrchb201.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk The tcpdump o/p was taken at the eth0 interface of the transmitter. That was the reason I was baffled by the missing segment. I am still not convinced about why packets should be dropped at the transmitting end even before they come to the ethernet interface. If this were at the receiving end the behaviour of TCP is perfectly justified. Thanks, -anu. On Tue, 25 Jan 2000, Spencer Dawkins wrote: > Anupama, are you measuring this on the sending system, the receiving system, > or somewhere in between? Just curious. > > (Once the packets leave the sending system, they can be dropped due to link > errors or checksum errors, for instance, so your measurement system may not > be seeing these errored packets.) > > Spencer > > -----Original Message----- > From: Anupama Sundaresan [mailto:anu@ittc.ukans.edu] > Sent: Monday, January 24, 2000 10:08 PM > To: tcp-impl@lerc.nasa.gov > Subject: Anomalous TCP behaviour? > > > Hello, > > Is it normal for TCP to skip a certain number of bytes and send > them later when it receives dup acks? > From owner-tcp-impl@lerc.nasa.gov Tue Jan 25 16:40:28 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08126 for ; Tue, 25 Jan 2000 16:40:27 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA06307 for tcp-impl-outgoing; Tue, 25 Jan 2000 13:39:50 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA06282 for ; Tue, 25 Jan 2000 13:39:48 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA09822; Tue, 25 Jan 2000 13:39:47 -0500 (EST) Received: from stephens.ittc.ukans.edu(129.237.125.220) by seraph3.lerc.nasa.gov via smap (V5.0) id xma009800; Tue, 25 Jan 00 13:39:15 -0500 Received: from mill.ittc.ukans.edu (mill.ittc.ukans.edu [129.237.125.192]) by stephens.ittc.ukans.edu (8.9.3/8.9.3/ITTC-NOSPAM-1.0) with ESMTP id MAA27277; Tue, 25 Jan 2000 12:39:14 -0600 (CST) Received: from localhost by mill.ittc.ukans.edu (8.8.5/KU-4.0-client) id MAA20021; Tue, 25 Jan 2000 12:39:14 -0600 (CST) Date: Tue, 25 Jan 2000 12:39:13 -0600 (CST) From: Anupama Sundaresan To: Shawn Ostermann cc: Vern Paxson , tcp-impl@lerc.nasa.gov Subject: Re: Anomalous TCP behaviour? In-Reply-To: <200001251342.IAA12473@picard.cs.ohiou.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > > > > outoforder pkts: 9 outoforder pkts: 0 > > > > What does outoforder pkts mean here? > > That's what you'll see with tcptrace when it sees a retransmitted > segment without having seen the original. It could be caused by > missing packets in the trace file, but it's more commonly the case > that you're grabbing the packets near the receiver rather than near > the sender. In either case, you can't tell for sure whether the > segments are out of order or a retransmission (although it's almost > always the latter, of course). > If Tcptrace displays the statistics for both the transmitter and the receiver and if this is the sender side statistics then what does the out of order packets mean? Does it mean that the packet gets lost even before it comes to tcpdump or does it mean that tcpdump somehow missed the first transmission and what was recorded as an outoforder packet is actually a retransmission? From owner-tcp-impl@lerc.nasa.gov Tue Jan 25 16:40:53 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08139 for ; Tue, 25 Jan 2000 16:40:52 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA04355 for tcp-impl-outgoing; Tue, 25 Jan 2000 13:27:06 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA04326 for ; Tue, 25 Jan 2000 13:27:04 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA08392; Tue, 25 Jan 2000 13:27:02 -0500 (EST) Received: from exchsrv1.cs.washington.edu(128.95.3.128) by seraph3.lerc.nasa.gov via smap (V5.0) id xma008266; Tue, 25 Jan 00 13:26:29 -0500 Received: by exchsrv1.cs.washington.edu with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Jan 2000 10:26:28 -0800 Message-ID: <055A195871E5D1119F8100A0C9499B5FF00D7A@exchsrv1.cs.washington.edu> From: Stefan Savage To: "'ostermann@cs.ohiou.edu'" , Vern Paxson Cc: tcp-impl@lerc.nasa.gov, Anupama Sundaresan Subject: RE: Anomalous TCP behaviour? Date: Tue, 25 Jan 2000 10:26:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Minor tangential point: you can usually disambiguate re-ordering from retransmissions at the receiver by observing ip_id. Most OSs provide monotonicity in ip_id (at least per-flow) so re-ordered segments will have in-order ip_id values, and retransmitted segments will not (excluding a few special cases). Tweak, add some glue, watch what gets ack'd, and you can estimate one-way reordering rates from a single endpoint :-) - Stefan -----Original Message----- From: Shawn Ostermann [mailto:ostermann@cs.ohiou.edu] Sent: Tuesday, January 25, 2000 5:43 AM To: Vern Paxson Cc: tcp-impl@lerc.nasa.gov; Anupama Sundaresan Subject: Re: Anomalous TCP behaviour? > > outoforder pkts: 9 outoforder pkts: 0 > > What does outoforder pkts mean here? That's what you'll see with tcptrace when it sees a retransmitted segment without having seen the original. It could be caused by missing packets in the trace file, but it's more commonly the case that you're grabbing the packets near the receiver rather than near the sender. In either case, you can't tell for sure whether the segments are out of order or a retransmission (although it's almost always the latter, of course). --sdo ------------------------------------------------------------------------- Dr. Shawn Ostermann - Associate Professor - Ohio University 322 Stocker Center, Ohio University, Athens, Ohio 45701-2979 ostermann@cs.ohiou.edu -- FAX: (740)593-0007 -- Voice: (740)593-1234 http://ace.cs.ohiou.edu/~osterman http://jarok.cs.ohiou.edu From owner-tcp-impl@lerc.nasa.gov Wed Jan 26 14:00:37 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09404 for ; Wed, 26 Jan 2000 14:00:36 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA24713 for tcp-impl-outgoing; Wed, 26 Jan 2000 10:19:05 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA24652 for ; Wed, 26 Jan 2000 10:19:02 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA05828; Wed, 26 Jan 2000 10:18:59 -0500 (EST) Received: from picard.cs.ohiou.edu(132.235.3.128) by seraph3.lerc.nasa.gov via smap (V5.0) id xma005788; Wed, 26 Jan 00 10:18:15 -0500 Received: from picard.cs.ohiou.edu (localhost [127.0.0.1]) by picard.cs.ohiou.edu (8.8.8+Sun/8.7.1) with ESMTP id KAA02045; Wed, 26 Jan 2000 10:17:15 -0500 (EST) Message-Id: <200001261517.KAA02045@picard.cs.ohiou.edu> To: Stefan Savage In-Reply-To: <055A195871E5D1119F8100A0C9499B5FF00D7A@exchsrv1.cs.washington.edu> Reply-To: ostermann@cs.ohiou.edu From: "Shawn Ostermann" cc: "'ostermann@cs.ohiou.edu'" , Vern Paxson , tcp-impl@lerc.nasa.gov, Anupama Sundaresan Subject: Re: Anomalous TCP behaviour (using ip_id to disambiguate reordering) Date: Wed, 26 Jan 2000 10:17:15 -0500 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Minor tangential point: you can usually disambiguate re-ordering > from retransmissions at the receiver by observing ip_id. Most OSs > provide monotonicity in ip_id (at least per-flow) so re-ordered > segments will have in-order ip_id values, and retransmitted segments > will not (excluding a few special cases). I can't dispute your claim, but I'm skeptical how safe it would be. As far as I can tell, the protocol standard (791 at least) only requires that the identifier field be unique: Thus, the sender must choose the Identifier to be unique for this source, destination pair and protocol for the time the datagram (or any fragment of it) could be alive in the internet. Of course, with today's fast networks, even that requirement is difficult (impossible) to meet. I'd be hesitant to rely on a heuristic that isn't guaranteed to hold for all IP stacks and that would definitely not work with IPv6. It's an interesting idea, though. It would be very useful for an set of experiments. Shawn ------------------------------------------------------------------------- Dr. Shawn Ostermann - Associate Professor - Ohio University 322 Stocker Center, Ohio University, Athens, Ohio 45701-2979 ostermann@cs.ohiou.edu -- FAX: (740)593-0007 -- Voice: (740)593-1234 http://ace.cs.ohiou.edu/~osterman http://jarok.cs.ohiou.edu From owner-tcp-impl@lerc.nasa.gov Wed Jan 26 15:01:39 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10671 for ; Wed, 26 Jan 2000 15:01:38 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA11403 for tcp-impl-outgoing; Wed, 26 Jan 2000 12:06:27 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA11379 for ; Wed, 26 Jan 2000 12:06:23 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA19029; Wed, 26 Jan 2000 12:06:22 -0500 (EST) Received: from exchsrv1.cs.washington.edu(128.95.3.128) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018992; Wed, 26 Jan 00 12:05:53 -0500 Received: by exchsrv1.cs.washington.edu with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jan 2000 09:05:52 -0800 Message-ID: <055A195871E5D1119F8100A0C9499B5FF00D8C@exchsrv1.cs.washington.edu> From: Stefan Savage To: "'ostermann@cs.ohiou.edu'" , Stefan Savage Cc: Vern Paxson , tcp-impl@lerc.nasa.gov, Anupama Sundaresan Subject: RE: Anomalous TCP behaviour (using ip_id to disambiguate reorderi ng) Date: Wed, 26 Jan 2000 09:05:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Absolutely correct. In fact, it doesn't work for OpenBSD (they use a pseudo-random nonrepeating sequence). This is one of those tricks that goes in the "works alot of the time, but don't depend on it" toolbox. Of course... that's true about just about every measurement technology out there :-) - Stefan -----Original Message----- From: Shawn Ostermann [mailto:ostermann@cs.ohiou.edu] Sent: Wednesday, January 26, 2000 7:17 AM To: Stefan Savage Cc: 'ostermann@cs.ohiou.edu'; Vern Paxson; tcp-impl@lerc.nasa.gov; Anupama Sundaresan Subject: Re: Anomalous TCP behaviour (using ip_id to disambiguate reordering) > Minor tangential point: you can usually disambiguate re-ordering > from retransmissions at the receiver by observing ip_id. Most OSs > provide monotonicity in ip_id (at least per-flow) so re-ordered > segments will have in-order ip_id values, and retransmitted segments > will not (excluding a few special cases). I can't dispute your claim, but I'm skeptical how safe it would be. As far as I can tell, the protocol standard (791 at least) only requires that the identifier field be unique: Thus, the sender must choose the Identifier to be unique for this source, destination pair and protocol for the time the datagram (or any fragment of it) could be alive in the internet. Of course, with today's fast networks, even that requirement is difficult (impossible) to meet. I'd be hesitant to rely on a heuristic that isn't guaranteed to hold for all IP stacks and that would definitely not work with IPv6. It's an interesting idea, though. It would be very useful for an set of experiments. Shawn ------------------------------------------------------------------------- Dr. Shawn Ostermann - Associate Professor - Ohio University 322 Stocker Center, Ohio University, Athens, Ohio 45701-2979 ostermann@cs.ohiou.edu -- FAX: (740)593-0007 -- Voice: (740)593-1234 http://ace.cs.ohiou.edu/~osterman http://jarok.cs.ohiou.edu From owner-tcp-impl@lerc.nasa.gov Wed Jan 26 17:39:53 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12821 for ; Wed, 26 Jan 2000 17:39:52 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA00653 for tcp-impl-outgoing; Wed, 26 Jan 2000 14:04:16 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA00629 for ; Wed, 26 Jan 2000 14:04:13 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA03669; Wed, 26 Jan 2000 14:04:11 -0500 (EST) Received: from orchard.hamachi.org(4.255.0.98) by seraph3.lerc.nasa.gov via smap (V5.0) id xma003649; Wed, 26 Jan 00 14:04:04 -0500 Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id TAA08209; Wed, 26 Jan 2000 19:03:42 GMT Message-Id: <200001261903.TAA08209@orchard.arlington.ma.us> To: Anupama Sundaresan cc: jonas.haggard.ljungquist@teracom.se, tcp-impl@grc.nasa.gov Subject: Re: SV: Anomalous TCP behaviour? In-Reply-To: Message from Anupama Sundaresan of "Tue, 25 Jan 2000 11:09:52 CST." Date: Wed, 26 Jan 2000 14:03:42 -0500 From: Bill Sommerfeld Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk It's possible that you're seeing measurement error.. the packet capture subsystem may have limited buffering and may miss some output packets if there's a burst. Also, depending on exactly how the transport layer, ip layer, and driver are glued together, a sufficiently large burst of packets might get dropped in the driver if the output queue gets too large.. - Bill From owner-tcp-impl@lerc.nasa.gov Wed Jan 26 18:57:50 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13501 for ; Wed, 26 Jan 2000 18:57:49 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA19265 for tcp-impl-outgoing; Wed, 26 Jan 2000 15:57:34 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA19227 for ; Wed, 26 Jan 2000 15:57:30 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA17252; Wed, 26 Jan 2000 15:57:30 -0500 (EST) Received: from mail3.burlee.com(199.93.70.20) by seraph3.lerc.nasa.gov via smap (V5.0) id xma017235; Wed, 26 Jan 00 15:57:09 -0500 Received: from lotus [203.180.144.36] by mail3.burlee.com (SMTPD32-6.00) id AF9F6BF0242; Wed, 26 Jan 2000 15:57:03 -0500 Message-ID: <008201bf683f$d0e28e00$ec4910ac@c2sc.catv.ne.jp> From: "Prem Anand" To: Date: Thu, 27 Jan 2000 05:56:25 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007E_01BF688B.3EE4FB40" 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@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_007E_01BF688B.3EE4FB40 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit ------=_NextPart_000_007E_01BF688B.3EE4FB40 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_007E_01BF688B.3EE4FB40-- From owner-tcp-impl@lerc.nasa.gov Thu Jan 27 01:26:23 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20287 for ; Thu, 27 Jan 2000 01:26:23 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA25819 for tcp-impl-outgoing; Wed, 26 Jan 2000 22:22:21 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA25796 for ; Wed, 26 Jan 2000 22:22:19 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id WAA22514; Wed, 26 Jan 2000 22:22:18 -0500 (EST) Received: from prv-mail25.provo.novell.com(137.65.82.196) by seraph3.lerc.nasa.gov via smap (V5.0) id xma022493; Wed, 26 Jan 00 22:22:17 -0500 Received: from INET-PRV1-Message_Server by prv-mail25.provo.novell.com with Novell_GroupWise; Wed, 26 Jan 2000 20:22:14 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 26 Jan 2000 20:22:08 -0700 From: "Ramesh Shankar" To: Subject: TCP Port reuse related ... Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id WAA25805 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit While trying to figure out the details related to SO_REUSEADDR/SO_REUSEPORT, I found that there are considerable differences between Linux, NetBSD/FreeBSD, Winsock. While looking at Linux v2.2.14 source, (and in the previous versions of the source), there are some comments related to port reuse and FTP servers which I don't seem to understand. Specifically, if I bind <*, port #> to socket1 and bind <*, port #> to socket2 (Port #s are the same, * is INADDR_ANY) and specify SO_REUSEADDR for both bind operations, then the bind()s succeed. However, if I call listen() for socket1 before binding socket2, then socket2's bind() *fails* (even if we use SO_REUSEADDR). This is somewhat understandable. (Note: The same operation succeeds in NetBSD/FreeBSD). Any combination of IP address (one being *, other not being * or vice versa or both being the same IP address) when socket1 is put on listen fails. When listen() is used on socket1, the only allowed way seems to be: socket1: bind(IP1, port #) listen(socket1) socket2: bind(IP2, port#) (Where IP1 and IP2 are valid local IP addresses) I don't understand why the following combination should not be allowed: socket1: bind(*, port #) listen(socket1) socket2: bind(IP1, port #) For a multihomed host, socket2 (if put on listen()), would field all packets destined for IP1, while socket1 will field the others. (Refer tcp_v4_get_port() in net/ipv4/tcp_ipv4.c) Thanks, S.R. P.S.: If anyone can explain me what the comments in the file include/net/tcp.h near the definition of the structure tcp_bind_bucket really mean, it would be greatly appreciated! Even though this is kind of a Linux question, it still is related to TCP implementation, and hence I posted on this list. From owner-tcp-impl@lerc.nasa.gov Thu Jan 27 19:53:37 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17335 for ; Thu, 27 Jan 2000 19:53:37 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA16086 for tcp-impl-outgoing; Thu, 27 Jan 2000 17:04:44 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA16082 for ; Thu, 27 Jan 2000 17:04:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA07420; Thu, 27 Jan 2000 17:04:42 -0500 (EST) Received: from mercury.sun.com(192.9.25.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007401; Thu, 27 Jan 00 17:03:59 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA27616 for ; Thu, 27 Jan 2000 14:03:57 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id OAA09548; Thu, 27 Jan 2000 14:03:57 -0800 (PST) Received: from shield (shield.Eng.Sun.COM [129.146.85.114]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA24930; Thu, 27 Jan 2000 14:03:56 -0800 (PST) Date: Thu, 27 Jan 2000 14:03:55 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: TCP Port reuse related ... To: Ramesh Shankar Cc: tcp-impl@grc.nasa.gov In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > socket1: bind(*, port #) > listen(socket1) > socket2: bind(IP1, port #) > > For a multihomed host, socket2 (if put on listen()), would field all packets > destined for IP1, while socket1 will field the others. Suppose this is allowed and assume that socket1 belongs to a server app. Then socket2, which belongs to a malicious app, can steal all service requests originated from IP1. Further assume that the malicious app does the above for all "known" IP addresses in that network, then it basically hijacks all service requests from the server app. The bad thing is the server app does not even know about this... > If anyone can explain me what the comments in the file include/net/tcp.h > near the definition of the structure tcp_bind_bucket really mean, it would > be greatly appreciated! It is a nice optimization. What is not clear in that? K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@lerc.nasa.gov Thu Jan 27 20:00:46 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17362 for ; Thu, 27 Jan 2000 20:00:46 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA19453 for tcp-impl-outgoing; Thu, 27 Jan 2000 17:37:48 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA19426 for ; Thu, 27 Jan 2000 17:37:47 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA11238; Thu, 27 Jan 2000 17:37:45 -0500 (EST) Received: from prv-mail20.provo.novell.com(137.65.82.195) by seraph3.lerc.nasa.gov via smap (V5.0) id xma011215; Thu, 27 Jan 00 17:37:42 -0500 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 27 Jan 2000 15:37:39 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 27 Jan 2000 15:37:28 -0700 From: "Ramesh Shankar" To: Cc: Subject: Re: TCP Port reuse related ... Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id RAA19446 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Well, if one is talking about well known ports, (0 - 1024), then you have the standard protection that comes with it: only super user can bind to such ports. In *any case*, if I had done this: socket1: bind(*, port #) (SO_REUSEADDR) socket2: bind(*, port #) (SO_REUSEADDR) listen(socket1) Then the sequence would have succeeded. Nothing prevents this from happening. Also, the standard behaviour is to allow the reuse of ports as long as SO_REUSEADDR has been used (i.e. it works this way in BSD, Winsock). With the UNIX variants, every one using a port has to use SO_REUSEADDR. Hence, if the first server that started off didn't use SO_REUSEADDR, this port stealing can't happen anyway. (With Winsock, only the later bind()ers have to specify SO_REUSEADDR, the first one doesn't have to). There was only one explanation that I could think of on why the Linux folks decided to do this way: If someone tries to reuse a tuple in the SYN received state for a connect(), then the connect should fail. This is ensured automatically in the way FreeBSD/NetBSD handles inpcbs. Linux has open_request structures for embryonic connections in the listening socket's queue and these consist of SYN received state connections. These are NOT checked for invalid tuple usage when a connect() is made. Also, with SYN cookies, we won't even have these open_request structures and hence there is no real way to identify whether the tuple being used by a connect is valid or not. Hence, the only way to disallow the connect is to prevent the second bind() from using the same port (except in the case metioned) when the first socket is doing a listen(). About clarification of FTP related comments in the code: I am not sure what case is being optimised here. Obviously there are two important cases - one is bind() time determination whether a port can be used or not - this is based on SO_REUSEADDR and the second one is at connect() time to decide whether a particular tuple can be used in the connect(). In the first case, the tcp_bhash is consulted and in the second case, tcp_ehash (both non-TIME_WAIT part and TIME_WAIT part) are consulted. (Actually the tcp_listening_hash is also consulted without any use!) What I don't get it is the comments about O(1) allocation for FTP servers etc. The implementation there seems to be related to standard SO_REUSEADDR case and I don't understand how an FTP server fits into this picture. (I even tried to check whether the Linux FTP server gives the same passive port # to multiple FTP clients, it doesn't seem to). Thanks, S.R. >>> Kacheong Poon 01/27/00 03:03PM >>> > socket1: bind(*, port #) > listen(socket1) > socket2: bind(IP1, port #) > > For a multihomed host, socket2 (if put on listen()), would field all packets > destined for IP1, while socket1 will field the others. Suppose this is allowed and assume that socket1 belongs to a server app. Then socket2, which belongs to a malicious app, can steal all service requests originated from IP1. Further assume that the malicious app does the above for all "known" IP addresses in that network, then it basically hijacks all service requests from the server app. The bad thing is the server app does not even know about this... > If anyone can explain me what the comments in the file include/net/tcp.h > near the definition of the structure tcp_bind_bucket really mean, it would > be greatly appreciated! It is a nice optimization. What is not clear in that? K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@lerc.nasa.gov Thu Jan 27 21:12:12 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17815 for ; Thu, 27 Jan 2000 21:12:12 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA24965 for tcp-impl-outgoing; Thu, 27 Jan 2000 18:47:35 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA24941 for ; Thu, 27 Jan 2000 18:47:32 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA17961; Thu, 27 Jan 2000 18:47:30 -0500 (EST) Received: from mercury.sun.com(192.9.25.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma017922; Thu, 27 Jan 00 18:46:54 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA11474 for ; Thu, 27 Jan 2000 15:46:47 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id PAA00828; Thu, 27 Jan 2000 15:46:43 -0800 (PST) Received: from shield (shield.Eng.Sun.COM [129.146.85.114]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA16304; Thu, 27 Jan 2000 15:46:41 -0800 (PST) Date: Thu, 27 Jan 2000 15:46:41 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: TCP Port reuse related ... To: Ramesh Shankar Cc: tcp-impl@grc.nasa.gov In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Well, if one is talking about well known ports, (0 - 1024), then you have > the standard protection that comes with it: only super user can bind to such > ports. For example, nfsd is not listening on the above "well known" ports. It is listening on 2049, which is still well known to nfs clients. There are more well known services than the above 1-1024 port range can allow. Anyway, the kernel should provide a way to allow an app to make sure that all requests to the port it bind() to should be sent to it only. > In *any case*, if I had done this: > > socket1: bind(*, port #) (SO_REUSEADDR) > socket2: bind(*, port #) (SO_REUSEADDR) > listen(socket1) Yup, this is a hole a server app can make. It should not set SO_REUSEADDR before doing a listen() if it wants to prevent this from happening. But this does not mean that the kernel should not enforce such a rule. What the kernel provides is a mechanism for apps to use. Use it or not depends on what the app wants to do. > Then the sequence would have succeeded. Nothing prevents this from > happening. Also, the standard behaviour is to allow the reuse of ports as > long as SO_REUSEADDR has been used (i.e. it works this way in BSD, Winsock). > With the UNIX variants, every one using a port has to use SO_REUSEADDR. > Hence, if the first server that started off didn't use SO_REUSEADDR, this > port stealing can't happen anyway. (With Winsock, only the later bind()ers > have to specify SO_REUSEADDR, the first one doesn't have to). Correct me if I am wrong. Last time I checked FreeBSD code, it did not check whether the original socket has SO_REUSEADDR set or not. I think what you mentioned above was not the way it worked. Is it changed? I think it uses the user id to prevent the port stealing problem. I am not sure about Winsock. Anyway, different OSes use different mechanisms to fill this hole. > What I don't get it is the comments about O(1) allocation for FTP servers > etc. The implementation there seems to be related to standard SO_REUSEADDR > case and I don't understand how an FTP server fits into this picture. (I > even tried to check whether the Linux FTP server gives the same passive port > # to multiple FTP clients, it doesn't seem to). I think ftp server needs to create a data (port 20) connection. So it has to bind to port 20 repeatedly and it has to set SO_REUSEADDR. Think of it if there are a lot of such data connections in TIME_WAIT state. K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@lerc.nasa.gov Thu Jan 27 21:54:58 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18987 for ; Thu, 27 Jan 2000 21:54:57 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA28553 for tcp-impl-outgoing; Thu, 27 Jan 2000 19:38:33 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA28540 for ; Thu, 27 Jan 2000 19:38:31 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA22737; Thu, 27 Jan 2000 19:38:31 -0500 (EST) Received: from prv-mail20.provo.novell.com(137.65.82.195) by seraph3.lerc.nasa.gov via smap (V5.0) id xma022718; Thu, 27 Jan 00 19:38:07 -0500 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 27 Jan 2000 17:38:04 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 27 Jan 2000 17:37:55 -0700 From: "Ramesh Shankar" To: Cc: Subject: Re: TCP Port reuse related ... Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id TAA28544 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Hmm, looks like I was considering only the "passive mode" FTP cases and trying to figure out what the comments meant wrt it :-)). Thanks, S.R. >>> Kacheong Poon 01/27/00 04:46PM >>> > Well, if one is talking about well known ports, (0 - 1024), then you have > the standard protection that comes with it: only super user can bind to such > ports. For example, nfsd is not listening on the above "well known" ports. It is listening on 2049, which is still well known to nfs clients. There are more well known services than the above 1-1024 port range can allow. Anyway, the kernel should provide a way to allow an app to make sure that all requests to the port it bind() to should be sent to it only. > In *any case*, if I had done this: > > socket1: bind(*, port #) (SO_REUSEADDR) > socket2: bind(*, port #) (SO_REUSEADDR) > listen(socket1) Yup, this is a hole a server app can make. It should not set SO_REUSEADDR before doing a listen() if it wants to prevent this from happening. But this does not mean that the kernel should not enforce such a rule. What the kernel provides is a mechanism for apps to use. Use it or not depends on what the app wants to do. > Then the sequence would have succeeded. Nothing prevents this from > happening. Also, the standard behaviour is to allow the reuse of ports as > long as SO_REUSEADDR has been used (i.e. it works this way in BSD, Winsock). > With the UNIX variants, every one using a port has to use SO_REUSEADDR. > Hence, if the first server that started off didn't use SO_REUSEADDR, this > port stealing can't happen anyway. (With Winsock, only the later bind()ers > have to specify SO_REUSEADDR, the first one doesn't have to). Correct me if I am wrong. Last time I checked FreeBSD code, it did not check whether the original socket has SO_REUSEADDR set or not. I think what you mentioned above was not the way it worked. Is it changed? I think it uses the user id to prevent the port stealing problem. I am not sure about Winsock. Anyway, different OSes use different mechanisms to fill this hole. > What I don't get it is the comments about O(1) allocation for FTP servers > etc. The implementation there seems to be related to standard SO_REUSEADDR > case and I don't understand how an FTP server fits into this picture. (I > even tried to check whether the Linux FTP server gives the same passive port > # to multiple FTP clients, it doesn't seem to). I think ftp server needs to create a data (port 20) connection. So it has to bind to port 20 repeatedly and it has to set SO_REUSEADDR. Think of it if there are a lot of such data connections in TIME_WAIT state. K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@lerc.nasa.gov Thu Jan 27 23:43:01 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20931 for ; Thu, 27 Jan 2000 23:43:00 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA06292 for tcp-impl-outgoing; Thu, 27 Jan 2000 21:13:50 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA06288 for ; Thu, 27 Jan 2000 21:13:49 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id VAA00748; Thu, 27 Jan 2000 21:13:49 -0500 (EST) Received: from twig.rodents.montreal.qc.ca(216.46.5.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma000743; Thu, 27 Jan 00 21:13:18 -0500 Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id VAA02144; Thu, 27 Jan 2000 21:13:08 -0500 (EST) Date: Thu, 27 Jan 2000 21:13:08 -0500 (EST) From: der Mouse Message-Id: <200001280213.VAA02144@Twig.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: TCP Port reuse related ... Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit >> socket1: bind(*, port #) >> listen(socket1) >> socket2: bind(IP1, port #) > Suppose this is allowed and assume that socket1 belongs to a server > app. Then socket2, which belongs to a malicious app, can steal all > service requests originated from IP1. Right. There is at least one server (either an NTP daemon or a DNS daemon, I think) that binds not only a wildcard socket but also a socket on each local address it can find, specifically to defeat this attack. Note that if the OS in question has the BSD notion of "privileged ports", and the server in question is using such a port (and hence must be running privileged), the malicious program must also be running privileged to bind its socket - and if malicious programs are running privileged, we've got worse problems than stolen network requests. der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@lerc.nasa.gov Fri Jan 28 03:41:34 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04442 for ; Fri, 28 Jan 2000 03:41:34 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA18057 for tcp-impl-outgoing; Fri, 28 Jan 2000 01:04:55 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA18051 for ; Fri, 28 Jan 2000 01:04:54 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id BAA18074; Fri, 28 Jan 2000 01:04:53 -0500 (EST) Received: from databus.databus.com(198.186.154.34) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018068; Fri, 28 Jan 00 01:04:16 -0500 From: Barney Wolff To: tcp-impl@grc.nasa.gov Date: Fri, 28 Jan 2000 01:01 EST Subject: Re: TCP Port reuse related ... Content-Type: text/plain Message-ID: <3891315d0.315c@databus.databus.com> Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk I think the reason for binding to each address is so the (UDP) server can send the response from the same address to which the request was sent, which is otherwise difficult. Barney Wolff > Date: Thu, 27 Jan 2000 21:13:08 -0500 (EST) > From: der Mouse > > Right. There is at least one server (either an NTP daemon or a DNS > daemon, I think) that binds not only a wildcard socket but also a > socket on each local address it can find, specifically to defeat this > attack. From owner-tcp-impl@lerc.nasa.gov Fri Jan 28 14:41:29 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24998 for ; Fri, 28 Jan 2000 14:41:18 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA08807 for tcp-impl-outgoing; Fri, 28 Jan 2000 11:15:42 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA08753 for ; Fri, 28 Jan 2000 11:15:40 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA05396; Fri, 28 Jan 2000 11:15:35 -0500 (EST) Received: from orchard.hamachi.org(4.255.0.98) by seraph3.lerc.nasa.gov via smap (V5.0) id xma005370; Fri, 28 Jan 00 11:15:20 -0500 Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id QAA25696; Fri, 28 Jan 2000 16:15:18 GMT Message-Id: <200001281615.QAA25696@orchard.arlington.ma.us> To: Bob Braden cc: tcp-impl@grc.nasa.gov, brittone@us.ibm.com Subject: Re: TCP MSS option value In-Reply-To: Message from Bob Braden of "Fri, 21 Jan 2000 22:42:28 EST." <200001220011.AAA07222@gra.isi.edu> Date: Fri, 28 Jan 2000 11:15:17 -0500 From: Bill Sommerfeld Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > The MSS option is NOT intended as an MTU discovery mechanism. It > gives the max segment size the TCP receive and reassemble. It does > not, and is not intended to, tell the sender how large a segment to > send. Well, given that it provides an upper bound on segment size, it is *pragmatically* the only knob you can use when attempting to interoperate with systems not under your control with broken PMTUd blackhole detection living in PMTUd black holes (like many web servers living behind firewalls which block all ICMP). Try surfing the web from behind a path with a bottleneck IP MTU of 1480 some time.. if you advertise an MSS greater than 1440, you'll never see a full page from many servers.. - Bill From owner-tcp-impl@lerc.nasa.gov Fri Jan 28 17:57:49 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29092 for ; Fri, 28 Jan 2000 17:57:47 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA24746 for tcp-impl-outgoing; Fri, 28 Jan 2000 13:14:13 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA24715 for ; Fri, 28 Jan 2000 13:14:10 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA19283; Fri, 28 Jan 2000 13:14:10 -0500 (EST) Received: from twig.rodents.montreal.qc.ca(216.46.5.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma019244; Fri, 28 Jan 00 13:13:45 -0500 Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA04386; Fri, 28 Jan 2000 13:13:34 -0500 (EST) Date: Fri, 28 Jan 2000 13:13:34 -0500 (EST) From: der Mouse Message-Id: <200001281813.NAA04386@Twig.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: TCP MSS option value Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > Try surfing the web from behind a path with a bottleneck IP MTU of > 1480 some time.. if you advertise an MSS greater than 1440, you'll > never see a full page from many servers.. I'm behind a link with an MTU of either 1024 or 1400, depending on which address I use, and I've found a couple of websites I never see anything back from. Snooping on the far side of the choke point shows too-large packets coming in with DF set and need-frag ICMPs going back, with no sign the ICMPs are being listened to. I sent mail to the owners of one of the websites; no response, and last time I checked no fix. I'm seriously considering having the low-MTU link effectively ignore DF, broken as that would be. Anyone have any hint of a working clue-by-four to thwack such bozos with? der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@lerc.nasa.gov Fri Jan 28 18:36:08 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29691 for ; Fri, 28 Jan 2000 18:36:07 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA01176 for tcp-impl-outgoing; Fri, 28 Jan 2000 13:54:47 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA01151 for ; Fri, 28 Jan 2000 13:54:44 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA24420; Fri, 28 Jan 2000 13:54:43 -0500 (EST) Received: from frantic.weston.bsdi.com(209.173.194.254) by seraph3.lerc.nasa.gov via smap (V5.0) id xma024406; Fri, 28 Jan 00 13:54:40 -0500 Received: (from dab@localhost) by frantic.bsdi.com (8.9.3/8.9.0) id MAA12312; Fri, 28 Jan 2000 12:53:16 -0600 (CST) Date: Fri, 28 Jan 2000 12:53:16 -0600 (CST) From: David Borman Message-Id: <200001281853.MAA12312@frantic.bsdi.com> To: braden@ISI.EDU, sommerfeld@orchard.arlington.ma.us Subject: Re: TCP MSS option value Cc: brittone@us.ibm.com, tcp-impl@grc.nasa.gov Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From owner-tcp-impl@lerc.nasa.gov Fri Jan 28 11:40:55 2000 > To: Bob Braden > cc: tcp-impl@grc.nasa.gov, brittone@us.ibm.com > Subject: Re: TCP MSS option value > Date: Fri, 28 Jan 2000 11:15:17 -0500 > From: Bill Sommerfeld > > > The MSS option is NOT intended as an MTU discovery mechanism. It > > gives the max segment size the TCP receive and reassemble. It does > > not, and is not intended to, tell the sender how large a segment to > > send. > > Well, given that it provides an upper bound on segment size, it is > *pragmatically* the only knob you can use when attempting to > interoperate with systems not under your control with broken PMTUd > blackhole detection living in PMTUd black holes (like many web servers > living behind firewalls which block all ICMP). > > Try surfing the web from behind a path with a bottleneck IP MTU of > 1480 some time.. if you advertise an MSS greater than 1440, you'll > never see a full page from many servers.. A lot of the time when we've seen this, it has been due to a misconfiguration in a Cisco router that the local ISP uses to connect to the backbone. For example, UUNET defaults to using a 4K or so MTU across the HDLC connection. Cisco boxes have a default 1500 MTU for HDLC connections. If the local ISP box gets changed/replaced/reset/whatever, and the configuration for the connection goes back to the default 1500 MTU, you get the classic black-hole. If you connect to a web server that has a 4K path to the back-bone, and you advertise a 4K MSS, then it will attempt to send 4K packets. They make it to the far side of the ISP connection, but then get dropped by the Cisco box at the ISP because the packet is too long. UUNET thinks 4K is just fine and sends the packet, the ISP box drops it in hardware. Because it doesn't get dropped by IP, no ICMP message gets generated, and you have a black hole. There are various tests you can do from your local side to verify that this is indeed what is happening, and then you can call up and complain to your ISP about having their hardware misconfigured. 1) Ping the web server, if that works: 2) ping again with large packets (-s 10000) 3) Try the test to your ISP's router 4) try "traceroute www.XXX.com 10000", because the return packets are small, that will succeed where pint -s 10000 won't. -David Borman, dab@bsdi.com From owner-tcp-impl@lerc.nasa.gov Fri Jan 28 19:12:16 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00163 for ; Fri, 28 Jan 2000 19:12:16 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA06572 for tcp-impl-outgoing; Fri, 28 Jan 2000 14:24:52 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA06537 for ; Fri, 28 Jan 2000 14:24:49 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA28815; Fri, 28 Jan 2000 14:24:48 -0500 (EST) Received: from jhawk-foo.bbnplanet.com(199.94.208.163) by seraph3.lerc.nasa.gov via smap (V5.0) id xma028787; Fri, 28 Jan 00 14:24:16 -0500 Received: (from jhawk@localhost) by jhawk-foo.bbnplanet.com (8.8.8+Sun/8.8.8) id OAA12635; Fri, 28 Jan 2000 14:24:11 -0500 (EST) Date: Fri, 28 Jan 2000 14:24:11 -0500 From: John Hawkinson To: David Borman Cc: tcp-impl@grc.nasa.gov Subject: Re: TCP MSS option value Message-ID: <20000128142411.I19709@jhawk-foo.bbnplanet.com> References: <200001281853.MAA12312@frantic.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.1i In-Reply-To: <200001281853.MAA12312@frantic.bsdi.com>; from dab@bsdi.com on Fri, Jan 28, 2000 at 12:53:16PM -0600 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This sounds kind of confusing. dab writes: > A lot of the time when we've seen this, it has been due to a > misconfiguration in a Cisco router that the local ISP uses to > connect to the backbone. For example, UUNET defaults to using > a 4K or so MTU across the HDLC connection. Cisco boxes have a > default 1500 MTU for HDLC connections. Actually, it depends on the interface type. DS3 HDLC connections have a 4470 MTU, f'rinstance. T1s are 1500. > If the local ISP box gets changed/replaced/reset/whatever, and the > configuration for the connection goes back to the default 1500 MTU, > you get the classic black-hole. I'm not certain why an ICMP frag failure doesn't get sent, let me see if I have the scenario correct: > If you connect to a web server that has a 4K path to the back-bone, > and you advertise a 4K MSS, then it will attempt to send 4K packets. > They make it to the far side of the ISP connection, but then get > dropped by the Cisco box at the ISP because the packet is too long. Err, you're saying that an the MTU of one side of the interface does not agree with the MTU of the other side of the interface, and because IOS assumes it will never get a packet on an interface that is larger than the MTU for that interface, it has a problem when it receives such a packet? > UUNET thinks 4K is just fine and sends the packet, the ISP box drops > it in hardware. Because it doesn't get dropped by IP, no ICMP > message gets generated, and you have a black hole. Hmm...yes, though a counter does get incremented, I think. I don't know whether it is reasonable to explore solutions to this problem that involve layering violations or handing partial packets to IP. Some routing protocols attempt to look for problems like this, e.g. OSPF neighbors comparing MTUs and refusing to neighbor if this happens. Of course, presumably you have an interdomain case where the routing protocol is either "static" or "BGP". Perhaps, if it were not considered too ugly, a BGP option could be added to try to detect this misconfiguration and inform the administrator; this seems easier than trying to mandate a new protocol to check for this, or a PPP option (since so many links use "cisco HDLC"). It seems kind of odd, incidently, that cisco's CDP ("cisco discovery protocol", which exchanges information about the name/version/ipaddress of routers on common links) fails to include MTU information.... > There are various tests you can do from your local side to > verify that this is indeed what is happening, and then you > can call up and complain to your ISP about having their > hardware misconfigured. > 1) Ping the web server, if that works: > 2) ping again with large packets (-s 10000) > 3) Try the test to your ISP's router > 4) try "traceroute www.XXX.com 10000", because > the return packets are small, that will > succeed where pint -s 10000 won't. This is indistinguishable from an ICMP-filtering-induced PMTU blackhole, though. --jhawk From owner-tcp-impl@lerc.nasa.gov Fri Jan 28 19:25:29 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00294 for ; Fri, 28 Jan 2000 19:25:29 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA13140 for tcp-impl-outgoing; Fri, 28 Jan 2000 15:02:26 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA13092 for ; Fri, 28 Jan 2000 15:02:24 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA04325; Fri, 28 Jan 2000 15:02:23 -0500 (EST) Received: from frantic.weston.bsdi.com(209.173.194.254) by seraph3.lerc.nasa.gov via smap (V5.0) id xma004272; Fri, 28 Jan 00 15:01:49 -0500 Received: (from dab@localhost) by frantic.bsdi.com (8.9.3/8.9.0) id OAA12473; Fri, 28 Jan 2000 14:01:30 -0600 (CST) Date: Fri, 28 Jan 2000 14:01:30 -0600 (CST) From: David Borman Message-Id: <200001282001.OAA12473@frantic.bsdi.com> To: jhawk@bbnplanet.com Subject: Re: TCP MSS option value Cc: tcp-impl@grc.nasa.gov Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk John, > Date: Fri, 28 Jan 2000 14:24:11 -0500 > From: John Hawkinson > Subject: Re: TCP MSS option value ... > Err, you're saying that an the MTU of one side of the interface does > not agree with the MTU of the other side of the interface, and because > IOS assumes it will never get a packet on an interface that is larger > than the MTU for that interface, it has a problem when it receives > such a packet? Yes, they get tossed. > > UUNET thinks 4K is just fine and sends the packet, the ISP box drops > > it in hardware. Because it doesn't get dropped by IP, no ICMP > > message gets generated, and you have a black hole. > > Hmm...yes, though a counter does get incremented, I think. On Cisco routers, there is a "giants" statistic that gets incremented when this happens. But you need access to the router to see that... ... > > There are various tests you can do from your local side to > > verify that this is indeed what is happening, and then you > > can call up and complain to your ISP about having their > > hardware misconfigured. > > 1) Ping the web server, if that works: > > 2) ping again with large packets (-s 10000) > > 3) Try the test to your ISP's router > > 4) try "traceroute www.XXX.com 10000", because > > the return packets are small, that will > > succeed where pint -s 10000 won't. > > This is indistinguishable from an ICMP-filtering-induced > PMTU blackhole, though. Not neccessarily. If the web site is behind an ICMP-filtering router at the remote end, you'll be able to do "ping -s 10000" to the machines in front of the firewall. If it is the ISP's router that is misconfigured, the "ping -s 10000" will fail on anything after your local ISP router, but the traceroute will succeed. -David Borman, dab@bsdi.com From owner-tcp-impl@lerc.nasa.gov Fri Jan 28 20:59:22 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00934 for ; Fri, 28 Jan 2000 20:59:22 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA07540 for tcp-impl-outgoing; Fri, 28 Jan 2000 17:45:15 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA07507 for ; Fri, 28 Jan 2000 17:45:13 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA23678; Fri, 28 Jan 2000 17:45:11 -0500 (EST) Received: from atlrel2.hp.com(156.153.255.202) by seraph3.lerc.nasa.gov via smap (V5.0) id xma023622; Fri, 28 Jan 00 17:44:51 -0500 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by atlrel2.hp.com (Postfix) with ESMTP id E8AA41C81 for ; Fri, 28 Jan 2000 17:44:49 -0500 (EST) Received: from cup.hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.7.3 TIS 5.0.1) id OAA28403 for ; Fri, 28 Jan 2000 14:44:49 -0800 (PST) Message-ID: <38921BE1.D3A12E66@cup.hp.com> Date: Fri, 28 Jan 2000 14:44:49 -0800 From: Rick Jones Organization: the Unofficial HP X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Re: TCP MSS option value References: <200001281813.NAA04386@Twig.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit der Mouse wrote: > I'm behind a link with an MTU of either 1024 or 1400, depending on > which address I use, and I've found a couple of websites I never see > anything back from. Snooping on the far side of the choke point shows > too-large packets coming in with DF set and need-frag ICMPs going back, > with no sign the ICMPs are being listened to. ah, the joys of someone, somewhere in the middle of the path, or even at one end or the other deciding to block ICMP traffic. an example of what happens when a mechanism is designed based on being able to believe in the goodness of ones fellow participants meets a network that "evolves" to include nefarious types. > I'm seriously considering having the low-MTU link effectively ignore > DF, broken as that would be. Anyone have any hint of a working > clue-by-four to thwack such bozos with? I forget, do any of the Host requirements RFC's say that a host must try a smaller PTMU as part of their retransmission strategies? rick jones -- these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, OR post, but please do NOT do BOTH... my email address is raj in the cup.hp.com domain... From owner-tcp-impl@lerc.nasa.gov Fri Jan 28 21:03:18 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01013 for ; Fri, 28 Jan 2000 21:03:17 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA11392 for tcp-impl-outgoing; Fri, 28 Jan 2000 18:30:17 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA11363 for ; Fri, 28 Jan 2000 18:30:15 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA28652; Fri, 28 Jan 2000 18:30:13 -0500 (EST) Received: from ren.netconnect.com.au(203.7.198.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma028571; Fri, 28 Jan 00 18:29:34 -0500 Received: (qmail 1078 invoked from network); 28 Jan 2000 23:32:45 -0000 Received: from unknown (HELO cvs.com.au) (203.87.14.203) by mail.netconnect.com.au with SMTP; 28 Jan 2000 23:32:45 -0000 Message-ID: <3891E822.11939FE0@cvs.com.au> Date: Sat, 29 Jan 2000 06:04:02 +1100 From: Charles Esson X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: tcp-impl@grc.nasa.gov Subject: Re: TCP MSS option value References: <200001281615.QAA25696@orchard.arlington.ma.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > > The MSS option is NOT intended as an MTU discovery mechanism. There is a relationship given in, rfc879 page 5, maybe it is a game man that relies on it. But rfc879 does make it pretty clear the MSS should be less than the MTU. > > gives the max segment size the TCP receive and reassemble. But if the rules given in rfc879 page 5 are followed the sender should be able to assume the MTU is greater than the supplied MSS. So at least fragmentation is avoided. To know that the MTU is greater than the MSS is surely wasted knowledge, you limit is still the MSS anyway. Or has rfc879 been deprecated? > It does > > not, and is not intended to, tell the sender how large a segment to > > send. Why? is there a rfc to back this statement up. > > > Well, given that it provides an upper bound on segment size, it is > *pragmatically* the only knob you can use when attempting to > interoperate with systems not under your control with broken PMTUd > blackhole detection living in PMTUd black holes (like many web servers > living behind firewalls which block all ICMP). > > Try surfing the web from behind a path with a bottleneck IP MTU of > 1480 some time.. if you advertise an MSS greater than 1440, you'll > never see a full page from many servers.. > > - Bill From owner-tcp-impl@lerc.nasa.gov Fri Jan 28 22:39:54 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03600 for ; Fri, 28 Jan 2000 22:39:54 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA14912 for tcp-impl-outgoing; Fri, 28 Jan 2000 19:25:00 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA14894 for ; Fri, 28 Jan 2000 19:24:58 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA04220; Fri, 28 Jan 2000 19:24:57 -0500 (EST) Received: from fw.siara.com(209.10.58.69) by seraph3.lerc.nasa.gov via smap (V5.0) id xma004206; Fri, 28 Jan 00 19:24:44 -0500 Received: from gateway2.mtv.siara.com (gateway2.mtv.siara.com [192.168.1.1]) by siara.com (8.9.3-LCCHA/8.9.3/lccha Siara hub 1.4) with SMTP id QAA00730; Fri, 28 Jan 2000 16:23:52 -0800 (PST) Received: from 66.161.131.zocalo.net ([131.161.253.66]) by gateway2.mtv.siara.com via smtpd (for siara-serv1.mtv.siara.com [192.168.1.48]) with SMTP; 29 Jan 2000 00:29:28 UT Received: from green.mtv.siara.com by green.mtv.siara.com (8.9.3) id QAA53776; Fri, 28 Jan 2000 16:23:50 -0800 (PST) Message-Id: <200001290023.QAA53776@green.mtv.siara.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: David Borman Cc: braden@ISI.EDU, sommerfeld@orchard.arlington.ma.us, brittone@us.ibm.com, tcp-impl@grc.nasa.gov Subject: Re: TCP MSS option value In-Reply-To: Your message of "Fri, 28 Jan 2000 12:53:16 CST." <200001281853.MAA12312@frantic.bsdi.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-578874592P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 28 Jan 2000 16:23:50 -0800 From: Greg Minshall Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk --==_Exmh_-578874592P Content-Type: text/plain; charset=us-ascii Dave, Isn't the problem, as Bill Sommerfeld said, that some firewall is blocking the "ICMP dest unreachable" packets, so pmtu isn't working? Greg (yep, i'm so old that i even remember when there really *was* an end-to-end internet...) --==_Exmh_-578874592P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: DJ9YmR03A1aAALs6jWN0AOWlmNtcKent iQA/AwUBOJIzFm1GBZxTyU5lEQKTpACg7kfM3hh9bDTiApujJrh0Pzh5LFQAni8m 7bLZn/aj5UYZuV8fyzixtOIT =Zame -----END PGP SIGNATURE----- --==_Exmh_-578874592P--