From owner-tcp-impl@lerc.nasa.gov Sat Jul 1 13:00:05 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 NAA21034 for ; Sat, 1 Jul 2000 13:00:05 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA21770 for tcp-impl-outgoing; Sat, 1 Jul 2000 10:28:26 -0400 (EDT) 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 SMTP id KAA21762 for ; Sat, 1 Jul 2000 10:28:25 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA00599; Sat, 1 Jul 2000 10:28:24 -0400 Received: from prv-mail21.provo.novell.com(137.65.81.126) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000589; Sat, 1 Jul 00 10:28:17 -0400 Received: from Novell.COM (hema.dnsdhcp.provo.novell.com [137.65.57.9]) by prv-mail21.provo.novell.com; Sat, 01 Jul 2000 08:27:56 -0600 Message-ID: <395DFFEB.134BCC72@Novell.COM> Date: Sat, 01 Jul 2000 08:27:55 -0600 From: Ramesh Shankar X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kacheong Poon CC: tcp-impl@grc.nasa.gov Subject: Re: Send window update algorithm ... References: Content-Type: multipart/mixed; boundary="------------DE2449CFF11EFF56792FD217" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. --------------DE2449CFF11EFF56792FD217 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit That's exactly correct. Thanks, S.R. Kacheong Poon wrote: > > > I knew you would say this :-)). If you were doing "keep alive" style > > window probes, you would run into the problem that I mentioned. I > > personally don't like the 1-byte window probe scheme. > > On a second thought, I guess by keep alive style, you mean sending a fake > byte or use old sequence number to send the zero window probe. Do I guess > correctly? > > K. Poon. > kcpoon@eng.sun.com --------------DE2449CFF11EFF56792FD217 Content-Type: text/x-vcard; charset=us-ascii; name="RShankar.vcf" Content-Description: Card for Ramesh Shankar Content-Disposition: attachment; filename="RShankar.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shankar;Ramesh x-mozilla-html:FALSE org:Novell Inc. version:2.1 email;internet:RShankar@Novell.COM title:Sr. Software Engineer adr;quoted-printable:;;MS: PRV-H-311=0D=0A1800 South Novell Place;Provo;UT;84606;USA fn:Ramesh Shankar end:vcard --------------DE2449CFF11EFF56792FD217-- From owner-tcp-impl@lerc.nasa.gov Sat Jul 1 16:42:31 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 QAA22203 for ; Sat, 1 Jul 2000 16:42:30 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA28421 for tcp-impl-outgoing; Sat, 1 Jul 2000 14:24:27 -0400 (EDT) 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 SMTP id OAA28414 for ; Sat, 1 Jul 2000 14:24:25 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA14273; Sat, 1 Jul 2000 14:24:24 -0400 Received: from prv-mail21.provo.novell.com(137.65.81.126) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014227; Sat, 1 Jul 00 14:23:34 -0400 Received: from Novell.COM (hema.dnsdhcp.provo.novell.com [137.65.57.9]) by prv-mail21.provo.novell.com; Sat, 01 Jul 2000 12:22:01 -0600 Message-ID: <395E36C7.ADEE042E@Novell.COM> Date: Sat, 01 Jul 2000 12:21:59 -0600 From: Ramesh Shankar X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: TCP-IMPL CC: Ramesh Shankar Subject: Fast retransmit/recovery (RFC 2581) ... Content-Type: multipart/mixed; boundary="------------158CA979404A22170BC16C9F" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. --------------158CA979404A22170BC16C9F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Okay, this time it is related to RFC 2581 ("Reno") style fast retransmit recovery :-)). Clearing of t_dupacks in FreeBSD/NetBSD: Assume that we have started getting dup ACKs. We may or may not have done a fast retransmit and we may or may not be in fast recovery. t_dupacks is cleared in the following cases: CASE 1: When a partial or a full ACK is received. CASE 2: On a retransmit timeout. CASE 3: Got a dup ACK [SEG.ACK == SND.UNA], but has a window update [SEG.WND != SND.WND]. CASE 4: Dup ACK, but has data. CASE 5: SEG.ACK < SND.UNA. RFC 2581, page 6 says, "The retransmit algorithm uses the arrival of 3 duplicate ACKs (4 identical ACKs *without* the arrival of any other intervening packets) as an indication that a segment has been lost". Interpreting the RFC strictly, CASES 3, 4 and 5 seem okay. However, it is not entirely clear why these cases have to reset t_dupacks. I can understand if t_dupacks doesn't get bumped up by such segments, but why clear it? Is there any specific reason for this or just plain paranoia? The issue, however, is that this would cause grief during bidirectional data transfer (here we go again!). Between the time the first dup ACK comes in and a partial or full ACK is received, if CASE 3, 4, or 5 is encountered, we reset t_dupacks. Interestingly, CWND doesn't get deflated! There is a break statement which skips the CWND deflation in CASES 3,4 and 5. The second confusion is related to Peterson and Brakmo's fix to the header prediction code to deflate the window. It is not clear to me what happens when t_dupacks != 0, but t_dupacks < tcprexmtthresh. The header prediction code handles such an ACK, but doesn't seem to set t_dupacks to 0. Isn't possible that we may end up doing a false fast retransmit sometime later? It is hard to see from the code whether this case is correctly handled or not. Any clarification would be greatly appreciated. Thanks, S.R. --------------158CA979404A22170BC16C9F Content-Type: text/x-vcard; charset=us-ascii; name="RShankar.vcf" Content-Description: Card for Ramesh Shankar Content-Disposition: attachment; filename="RShankar.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shankar;Ramesh x-mozilla-html:FALSE org:Novell Inc. version:2.1 email;internet:RShankar@Novell.COM title:Sr. Software Engineer adr;quoted-printable:;;MS: PRV-H-311=0D=0A1800 South Novell Place;Provo;UT;84606;USA fn:Ramesh Shankar end:vcard --------------158CA979404A22170BC16C9F-- From owner-tcp-impl@lerc.nasa.gov Mon Jul 3 01:55:33 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 BAA20428 for ; Mon, 3 Jul 2000 01:55:32 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA24951 for tcp-impl-outgoing; Sun, 2 Jul 2000 22:51:54 -0400 (EDT) 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 SMTP id WAA24943 for ; Sun, 2 Jul 2000 22:51:52 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id WAA00721; Sun, 2 Jul 2000 22:51:52 -0400 Received: from tc023.bbn.com(128.33.238.23) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000685; Sun, 2 Jul 00 22:51:32 -0400 Received: from lawyers (IDENT:mallman@localhost [127.0.0.1]) by lawyers.lerc.nasa.gov (8.9.3/8.9.3) with ESMTP id XAA14659; Sat, 1 Jul 2000 23:57:31 -0400 Message-Id: <200007020357.XAA14659@lawyers.lerc.nasa.gov> To: Ramesh Shankar From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: TCP-IMPL Subject: Re: Fast retransmit/recovery (RFC 2581) ... Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Things to Do in Denver When You're Dead Date: Sat, 01 Jul 2000 23:57:29 -0400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Interpreting the RFC strictly, CASES 3, 4 and 5 seem > okay. However, it is not entirely clear why these cases have to > reset t_dupacks. I can understand if t_dupacks doesn't get bumped > up by such segments, but why clear it? Is there any specific > reason for this or just plain paranoia? The problem is the ACKs are ambiguous when deciding if they are "duplicates" or not. I.e., is this a pure window update or is it a real duplicate ACK that also happens to update the window? Does this data segment that includes a delayed ACK really convey a delayed ACK or was the data just sent before a new data segment was received (i.e., the ACK number has to be duplicate)? It would seem to me that the conservative thing to do is to reset things and wait for clear signals that something is lost. (A side note: I would think SACK would help this situation a bit. For example, an ACK with a duplicate ACK number, data and no SACK information (in a SACK enabled flow) can easily be ignored as it is quite obviously just a data segment and does not signal the arrival of out-of-order data.) allman --- http://roland.grc.nasa.gov/~mallman/ From owner-tcp-impl@lerc.nasa.gov Tue Jul 4 07:35:25 2000 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26691 for ; Tue, 4 Jul 2000 07:35:24 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA00704 for tcp-impl-outgoing; Tue, 4 Jul 2000 04:38:02 -0400 (EDT) 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 SMTP id EAA00641 for ; Tue, 4 Jul 2000 04:38:01 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id EAA04196; Tue, 4 Jul 2000 04:37:59 -0400 Received: from cepc30.ce.chalmers.se(129.16.20.144) by seraph3.lerc.nasa.gov via smap (V5.5) id xma004166; Tue, 4 Jul 00 04:37:02 -0400 Received: (from otel@localhost) by yup.ce.chalmers.se (8.9.3/8.9.3) id KAA00636; Tue, 4 Jul 2000 10:37:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14689.41568.127497.298612@localhost.localdomain> Date: Tue, 4 Jul 2000 10:37:52 +0200 (CEST) From: Florian-Daniel Otel To: end2end-interest@ISI.EDU, tcp-impl@grc.nasa.gov Cc: otel@ce.chalmers.se Subject: RFC 2581 statement X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-To: Florian-Daniel Otel , otel@ce.chalmers.se Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, I have a question pertaining to the statement regarding incrementing cwnd in congestion avoidance (section 3.1, end of page 3). [...] cwnd += SMSS*SMSS/cwnd (2) This adjustment is executed on every incoming non-duplicate ACK. Equation (2) provides an acceptable approximation to the underlying principle of increasing cwnd by 1 full-sized segment per RTT. (Note that for a connection in which the receiver acknowledges every data segment, (2) proves slightly more aggressive than 1 segment per RTT, and for a receiver acknowledging every-other packet, [...] My question is that, assuming: -That equation (2) increases cwnd with SMSS*(1/cwnd_modulo_SMSS) per ACK. -The receiver does generate one ACK for each data segment. Can someone explain (or point me to a reference) why this increase is more aggressive than 1 segment per RTT ? Is that due to the rounding errors in the computation of cwnd_modulo_SMSS i.e. rounding up the integral division cwnd/SMSS ? Thanks in advance, Florian. From owner-tcp-impl@lerc.nasa.gov Wed Jul 5 16:15:09 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 QAA16134 for ; Wed, 5 Jul 2000 16:15:08 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA23108 for tcp-impl-outgoing; Wed, 5 Jul 2000 13:13:22 -0400 (EDT) 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 SMTP id NAA23025 for ; Wed, 5 Jul 2000 13:13:15 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA24175; Wed, 5 Jul 2000 13:13:13 -0400 Received: from mg03.austin.ibm.com(192.35.232.20) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024034; Wed, 5 Jul 00 13:12:12 -0400 Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96]) by mailgate3.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id LAA31838 for ; Wed, 5 Jul 2000 11:52:29 -0500 Received: from austin.ibm.com (ambika.austin.ibm.com [9.53.150.77]) by netmail1.austin.ibm.com (8.8.5/8.8.5) with ESMTP id MAA34626; Wed, 5 Jul 2000 12:12:09 -0500 Message-ID: <39636C68.C38DE549@austin.ibm.com> Date: Wed, 05 Jul 2000 12:12:08 -0500 From: venkat venkatsubra Organization: IBM X-Mailer: Mozilla 4.61 [en] (X11; U; AIX 4.3) X-Accept-Language: en MIME-Version: 1.0 To: Ramesh Shankar CC: kuznet@ms2.inr.ac.ru, tcp-impl@grc.nasa.gov, Kacheong.Poon@Eng.Sun.COM Subject: Re: Send window update algorithm ... References: <200006301845.WAA25907@ms2.inr.ac.ru> <395D0456.CAF0613A@Novell.COM> Content-Type: multipart/mixed; boundary="------------09EEAB638F464CEFB12AC73C" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. --------------09EEAB638F464CEFB12AC73C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------09EEAB638F464CEFB12AC73C Content-Type: text/plain; charset=us-ascii; name="xx" Content-Disposition: inline; filename="xx" Content-Transfer-Encoding: 7bit While on SND.WL1 and SND.WL2 on BSD implementations, shouldn't these need to be updated in the Header Prediction path too ? Otherwise, when the sequence number wraps around - for example on a data transfer of > 2GBytes, and if the receiver slows down and you go into tcp slow path processing, window updates are not going to be picked up. And you will start sending 1 byte packets (window probes). Atleast the 4.4 BSD code explained in the TCP/IP Illustrated Vol.2 (Wright & Stevens) doesn't do it. Does something prevent this problem from happening ? Linux may not have this problem. Thanks! Venkat --------------09EEAB638F464CEFB12AC73C-- From owner-tcp-impl@lerc.nasa.gov Wed Jul 12 09:02: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 JAA20508 for ; Wed, 12 Jul 2000 09:02:02 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA04438 for tcp-impl-outgoing; Wed, 12 Jul 2000 06:34:08 -0400 (EDT) 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 SMTP id GAA04433 for ; Wed, 12 Jul 2000 06:34:06 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA16926; Wed, 12 Jul 2000 06:34:04 -0400 Received: from isis.lip6.fr(132.227.60.2) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016876; Wed, 12 Jul 00 06:33:06 -0400 Received: from mobstar (174.ext.jussieu.fr [134.157.81.174]) by isis.lip6.fr (8.9.3/jtpda-5.3.2) with SMTP id MAA22443 for ; Wed, 12 Jul 2000 12:33:02 +0200 Reply-To: From: "Ahmed Karmouch" To: Subject: Mobile Agents for Telecommunication Applications, Paris, France Date: Wed, 12 Jul 2000 12:36:04 +0200 Message-ID: <000a01bfebec$fabd1c50$ae519d86@uottawa.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit ============================================================== [My apologies if you receive this more than once] ============================================================== CALL FOR PARTICIPATION MATA'2000 Second International Workshop on Mobile Agents for Telecommunication Applications ========================================================================= September 18-20, 2000 Paris, France http://netconf.lip6.fr/mata00/ MATA '2000 presents a unique opportunity for researchers, software and Application developers, and computer network technologists to discuss new developments on the mobile agent technology and applications. This is also an opportunity for the current and future users of FIPA-OS (the Nortel Networks' Agent Platform) to discuss and share their experience with other users and with the FIPA-OS architects. Grasshopper representatives will also be present to report on the features of the latest version and share with you their experience. The technical sessions will focus on mobile agent issues across the areas of network management; mobile applications; Nomadic computing; Active networks; Ad-hoc networks and applications; Internet applications; QoS management; E-commerce and Computer Telephony Integration. For complete program information, registration fees, or online registration form please visit http://netconf.lip6.fr/mata00/ From owner-tcp-impl@lerc.nasa.gov Wed Jul 12 09:55:09 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 JAA22898 for ; Wed, 12 Jul 2000 09:55:08 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA11412 for tcp-impl-outgoing; Wed, 12 Jul 2000 07:59:14 -0400 (EDT) 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 SMTP id HAA11385 for ; Wed, 12 Jul 2000 07:59:11 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id HAA23145; Wed, 12 Jul 2000 07:59:10 -0400 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma023102; Wed, 12 Jul 00 07:58:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17819; Wed, 12 Jul 2000 07:58:39 -0400 (EDT) Message-Id: <200007121158.HAA17819@ietf.org> To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: tcp-impl@grc.nasa.gov From: The IESG Subject: Document Action: TCP Problems with Path MTU Discovery to Informational Date: Wed, 12 Jul 2000 07:58:39 -0400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk The IESG has approved the Internet-Draft 'TCP Problems with Path MTU Discovery' as an Informational RFC. This document is the product of the TCP Implementation Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. From owner-tcp-impl@lerc.nasa.gov Sun Jul 23 03:10: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 DAA00963 for ; Sun, 23 Jul 2000 03:10:14 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA00004 for tcp-impl-outgoing; Sun, 23 Jul 2000 00:40:54 -0400 (EDT) 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 SMTP id AAA29996 for ; Sun, 23 Jul 2000 00:40:53 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id AAA12047; Sun, 23 Jul 2000 00:40:52 -0400 Received: from mail.policyone.com(63.199.81.149) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012028; Sun, 23 Jul 00 00:40:21 -0400 Received: (from root@localhost) by duet.duettech.com (8.8.8/8.8.8) id VAA14927 for ; Sat, 22 Jul 2000 21:40:20 -0700 (PDT) Received: from snt002(199.172.181.2) by duet.duettech.com via smap (V2.1) id xma014922; Sat, 22 Jul 00 21:40:16 -0700 Received: from policyone.com ([199.172.181.91]) by casnt.ca.duettech.com (8.9.0/8.9.0) with ESMTP id VAA13888 for ; Sat, 22 Jul 2000 21:43:21 -0700 (PDT) Message-ID: <397A766C.A7E00DBC@policyone.com> Date: Sat, 22 Jul 2000 21:37:00 -0700 From: Proneet biswas X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Basic Query Content-Type: multipart/mixed; boundary="------------3AC3AB6A93124B0C3208EF60" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. --------------3AC3AB6A93124B0C3208EF60 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I had a very basic question.Can TCP resend segments which have more data than the original one and if yes, how common is this scenario ? Thanks. Proneet. --------------3AC3AB6A93124B0C3208EF60 Content-Type: text/x-vcard; charset=us-ascii; name="pbiswas.vcf" Content-Description: Card for Proneet biswas Content-Disposition: attachment; filename="pbiswas.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Biswas;Proneet tel;home:408-586-9632 tel;work:510-687-3152 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:pbiswas@duettech.com fn:Proneet Biswas end:vcard --------------3AC3AB6A93124B0C3208EF60-- From owner-tcp-impl@lerc.nasa.gov Sun Jul 23 07:01: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 HAA19116 for ; Sun, 23 Jul 2000 07:01:17 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA10180 for tcp-impl-outgoing; Sun, 23 Jul 2000 04:56:06 -0400 (EDT) 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 SMTP id EAA10175 for ; Sun, 23 Jul 2000 04:56:04 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id EAA25825; Sun, 23 Jul 2000 04:56:03 -0400 Received: from unknown(164.164.10.219) by seraph3.lerc.nasa.gov via smap (V5.5) id xma025752; Sun, 23 Jul 00 04:55:09 -0400 Received: FROM teil.soft.net BY mailscan.teil.soft.net ; Sun Jul 23 14:24:16 2000 +0500 Received: from localhost (manish@localhost) by teil.soft.net (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA30348; Sun, 23 Jul 2000 14:21:22 +0530 (IST) Date: Sun, 23 Jul 2000 14:21:22 +0530 From: Manish Thakur To: Proneet biswas cc: tcp-impl@grc.nasa.gov Subject: Re: Basic Query In-Reply-To: <397A766C.A7E00DBC@policyone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hi, this is very much a possibility. Retransmit does not imply that the same segment has to be retransmited, when the retransmit timer expires the snd.nxt is brought to snd.una and it forms a segment from the unacked data in the send buffer. This is the line most implementations take. manish On Sat, 22 Jul 2000, Proneet biswas wrote: > Hi, > I had a very basic question.Can TCP resend segments which have more > data than the original one > and if yes, how common is this scenario ? > > Thanks. > Proneet. > From owner-tcp-impl@lerc.nasa.gov Sun Jul 23 12:15:00 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 MAA05151 for ; Sun, 23 Jul 2000 12:14:59 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA16562 for tcp-impl-outgoing; Sun, 23 Jul 2000 09:59:25 -0400 (EDT) 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 SMTP id JAA16551; Sun, 23 Jul 2000 09:59:18 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA12232; Sun, 23 Jul 2000 09:59:18 -0400 Received: from ns.r-net.sk(193.58.193.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012168; Sun, 23 Jul 00 09:58:22 -0400 Received: from jakab (Kosice53.r-net.sk [193.58.192.181]) by NS.r-net.sk (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id PAA25552; Sun, 23 Jul 2000 15:57:02 +0200 X-Authentication-Warning: NS.r-net.sk: Host Kosice53.r-net.sk [193.58.192.181] claimed to be jakab Message-ID: <051a01bff4af$84384e80$b5c03ac1@jakab> From: "jakab frantisek" To: Cc: , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Symposium ATMTU 2000 - Second Announcement and Call for Participation, Kosice, Slovakia Date: Sun, 23 Jul 2000 14:16:55 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04C2_01BFF4B0.A7E6B780" 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_04C2_01BFF4B0.A7E6B780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Please accept our apologies if you receive this mail more than once...] Dear Sirs, you can find the second announcement on our web serever: = www.elfa.sk/index-4-en.html and new information about the international symposium ATMTU 2000 (Second ATM Technology Users Symposium) , which is = held on 13 - 15 September 2000 in Kosice, Slovak Republic. In = particular, you will find the registration forms there. It is just another two months until the ATMTU 2000 will take place here = in Kosice, Slovakia. Therefore, we want to invite you to join us and participate at the symposium. We are looking forward to seeing you! Best regards, Frantisek Jakab ATMTU 2000 Symposium Org. Comm. Chair ___________________________ Preliminary List of presentations: 1. Broadband wireless access systems based on ATM Raks=E1ny P., Hargas J., Ericsson Slovakia, Bratislava, Slovakia 2. Broadband fixed line access Raks=E1ny P., Kostrej A., Ericsson Slovakia, Bratislava, Slovakia 3. Information about facts and experiences from the integration of ATM networks with IP protocol Francisci C., VUS, Bansk=E1 Bystrica, Slovakia 4. IP versus ATM Kukura P., Lucent Technologies Slovensko, Bratislava, Slovakia 5. Channels versus packets - conflict or symbiosis Chal=E1s P., ICN Siemens, Bratislava, Slovakia 6. Signalisation at the estabilishment of connection between broadband = and narrowband end-users Janetka A., Martinec L., Kevick=FD F., SWH Siemens Business Services, = Bratislava, Slovakia 7. VoIP or VoATM Lunter P., SWH Siemens Business Services, Bratislava, Slovakia 8. QOS in IP versus ATM Dekan R., SWH Siemens Business Services, Bratislava, Slovakia 9. ATM solutions in end-to-end solutions at the Alcatel 2iP Fiacan I., Alcatel Slovakia, Liptovsk=FD Hr=E1dok, Slovakia 10. Applications of ATM technologies in wireless LMDS access systems Kub=EDk E., Alcatel Slovakia, Liptovsk=FD Hr=E1dok, Slovakia 11. Telematics Services over ATM Networks: The case of Teleteaching Bouras Ch., Gkamas A., Kapoulas V., Tsiatsos Th., Computer Technology = Institute Patras, Greece 12. Migration to Broadband Networks Baron=E1k I., Poliak P., Department of Telecommunications, Faculty of Electrical Engineering and Informatics, Slovak University of Technology, = Bratislava, Slovakia 13. ATM access equipment of the RAD manufacturer Man=E1k V., ITM Bratislava, Slovakia 14. Design of an ATM Network Control and Monitoring System Gizelis C., National Technical University of Athens, Greece 15. Plasma PNNI 1.0: ATMIPNNI network simulation program Somogyi H., Ericsson Hungary, Hungary 16. Videoconferencing and applications of the TTC Telecom based on PictureTel Salzer E., TTC Telecom, Kosice, Slovakia 17. The utilisation of the ATM in the access technologies Koprda L., BGS Bratislava, Slovakia 18. Broadening of the activities of the Z-ATM in Slovakia with the = accesses to the end-users Sebo J., The ATM Association in the Slovak Republic Bratislava, Slovakia 19. MPLS (Multiprotocol Label Switching) and IP QoS in Service Provider = ATMNeworks Janovic R., Cisco Systems Slovakia 20. Perspectives for QoS in IP Public Networks Basso E., TTC Marconi, Prague, Czech Republic 21. Distribution MPEG2 streams in ATM end-to-end environments Danthine O., TOLMA SA, Paris, France 22. Liberalisation versus regulation in electronic communication = networks and services Scehovic A., V=DAS Bansk=E1 Bystrica, Slovakia 23. Steps Towards a World-Wide Broadband Multimedia Network Finley Marion R. Jr., Asahi University, Japan 24. ATM services and applications integration access to a large = community of users in the region of Aveiro Fontes F., Portugal Telecom, Aveiro, Portugal 25. The necessity of the building of academic "information = superhighways" Horvath P., SANET Bratislava, Slovakia 26. The effectivity of the extranets in companies Lavrin A., Zelko M., Technical University of Kosice, Slovakia 27. Operator of the broadband services - the vision Zirko M1., Jakab F2., Cizm=E1r A2., Slovak Telecom Bratislava1, = Technical University of Kosice, Slovakia 28. Some remarks to the implementation maintance of the ST-ATM network Trstensk=FD D., et al., Slovak Telecom, Bansk=E1 Bystrica, Slovakia 29. Presentation 1 Ambasador ATM FORUM 30. Presentation 2 Ambasador ATM FORUM 31. Preparation and developing strategy of the information society in = the Slovak Republic Podhorsk=FD V., Ministry of Transport, Post and Telecommunications in = SR, Bratislava. Slovakia 32. Information highways in information society Karovic K., SAV Bratislava, Slovakia 33. Experiences of the Corinex company with the ATM technologies Sl=E1nicka, CORINEX Group, Slovakia 34. Experiences of the IBM company with the ATM technologies Labanc, IBM Slovensko, Slovakia 35. IP net next generation - voice/multimedia transport Linhart Z., CONTACTEL, Czech Republic 36. Next Generation Networks and Services - ATM and IP Asatani K., Kogakuin University, Tokyo, Japan 37. Secure services Tomasov P., University of Zilina, Slovakia 38. Algoritmics and tool for virtual audience training Tsejtlin G.T., International Solomon University, Kiev, Ukraine 39. Expert estimations of validity and reliability of programme and technical maintance of computer networks Grygorovych V.F., Oleksiivna M.O., Uzhgorod State Institute of = Informatics Science, Ukraine 40. The algebraic approach to minimization of computing Expences in = computer networks Olegovich N.M., Uzhgorod State Institute of Informatics Science, Ukraine 41. ATM Subscriber Access Multiplexer: the complete ADSL solution Lizuch P., Alcatel Slovakia, Liptovsk=FD Hr=E1dok, Slovakia 42. Design of an Input-queueded ATM Switch supporting multicast and = research on its Scheduling Policy Minguy Z., Nanjing University, China 43. Videoconferencing room=20 Baron=E1k I., Moln=E1r M., Department of Telecommunications, Faculty of Electrical Engineering and Informatics, Slovak University of Technology, = Bratislava, Slovakia 44. Application of the implementation models of the broadband networks Zabka J., Faculty of Mechatronics, University of Trenc=EDn, Slovakia 45. VPN networks based on MPLS Kollar S., BGS, Bratislava, Slovakia 46. Virtual networks in ATM Skorpil V., FEI, VUT, Brno, Czech Republic 47. Distributed Speech Recognition Syst=E9m over ATM Cizm=E1r A., Dobos L., Hintos L., Juh=E1r J., Faculty of Electrical = Engineering and Informatics of the Technical University of Kosice, Slovakia 48. Wireles ATM Physical Layer Simulation Dobos L., Palifetka R., Cizm=E1r A., Juh=E1r J., Faculty of Electrical Engineering and Informatics of the Technical University of Kosice, = Slovakia 49. Teleeducation services in broadband networks Jakab F., Samuelis L., Faculty of Electrical Engineering and Informatics = of the Technical University of Kosice, Slovakia 50. Methods of the evaluation of the QoS in ATM networks Jakab F., Faculty of Electrical Engineering and Informatics of the = Technical University of Kosice, Slovakia ______________________________________ ATMTU 2000 Symposium Symposium Secretariat elfa, s.r.o., Letna 9 042 00 Kosice, Slovakia Tel./fax.: +421 95 6253839, 6253200, 6253202 e-mail: elfa@elfa.sk www.elfa.sk/index-4-en.html ------=_NextPart_000_04C2_01BFF4B0.A7E6B780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[Please accept our apologies if you receive this = mail more=20 than once...]

Dear Sirs,

you can find the second = announcement on=20 our web serever: www.elfa.sk/index-4-en.html and=20 new information about the international
symposium ATMTU 2000 (Second = ATM=20 Technology Users Symposium)  , which is held on 13 - 15 September = 2000 in=20 Kosice, Slovak Republic. In particular,
you will find the = registration forms=20 there.

It is just another two months until the ATMTU 2000 will = take place=20 here in Kosice, Slovakia. Therefore, we want to invite you to join us=20 and
participate at the symposium.

We are looking forward to = seeing=20 you!

 Best regards,

Frantisek Jakab
ATMTU 2000 = Symposium=20 Org. Comm. Chair
___________________________

Preliminary List = of=20 presentations:

1. Broadband wireless access systems based on=20 ATM
Rakš=E1ny P., Hargaš J., Ericsson Slovakia, Bratislava, = Slovakia

2.=20 Broadband fixed line access
Rakš=E1ny P., Kostrej A., Ericsson = Slovakia,=20 Bratislava, Slovakia

3. Information about facts and experiences = from the=20 integration of ATM
networks with IP protocol
Francisci C., VUS, = Bansk=E1=20 Bystrica, Slovakia

4. IP versus ATM
Kukura P., Lucent = Technologies=20 Slovensko, Bratislava, Slovakia

5. Channels versus packets - = conflict or=20 symbiosis
Chal=E1s P., ICN Siemens, Bratislava, Slovakia

6.=20 Signalisation at the estabilishment of connection between broadband and=20 narrowband end-users
Janetka A., Martinec Ľ., Kevick=FD F., SWH = Siemens=20 Business Services, Bratislava, Slovakia

7. VoIP or = VoATM
Lunter P.,=20 SWH Siemens Business Services, Bratislava, Slovakia

8. QOS in IP = versus=20 ATM
Dekan R., SWH Siemens Business Services, Bratislava, = Slovakia

9.=20 ATM solutions in end-to-end solutions at the Alcatel 2iP
Fiačan = I., Alcatel=20 Slovakia, Liptovsk=FD Hr=E1dok, Slovakia

10. Applications of ATM = technologies=20 in wireless LMDS access systems
Kub=EDk E., Alcatel Slovakia, = Liptovsk=FD Hr=E1dok,=20 Slovakia

11. Telematics Services over ATM Networks: The case of=20 Teleteaching
Bouras Ch., Gkamas A., Kapoulas V., Tsiatsos Th., = Computer=20 Technology Institute Patras, Greece

12. Migration to Broadband=20 Networks
Baroň=E1k I., Poliak P., Department of = Telecommunications, Faculty=20 of
Electrical Engineering and Informatics, Slovak University of = Technology,=20 Bratislava, Slovakia

13. ATM access equipment of the RAD=20 manufacturer
Man=E1k V., ITM Bratislava, Slovakia

14. Design = of an ATM=20 Network Control and Monitoring System
Gizelis C., National Technical=20 University of Athens, Greece

15. Plasma PNNI 1.0: ATMIPNNI = network=20 simulation program
Somogyi H., Ericsson Hungary, Hungary

16.=20 Videoconferencing and applications of the TTC Telecom based=20 on
PictureTel
Salzer E., TTC Telecom, Košice, = Slovakia

17. The=20 utilisation of the ATM in the access technologies
Koprda L., BGS = Bratislava,=20 Slovakia

18. Broadening of the activities of the Z-ATM in = Slovakia with=20 the accesses to the end-users
Šebo J., The ATM Association in = the Slovak=20 Republic Bratislava, Slovakia

19. MPLS (Multiprotocol Label = Switching)=20 and IP QoS in Service Provider ATMNeworks
Janovic R., Cisco Systems=20 Slovakia

20. Perspectives for QoS in IP Public Networks
Basso = E., TTC=20 Marconi, Prague, Czech Republic

21. Distribution MPEG2 streams in = ATM=20 end-to-end environments
Danthine O., TOLMA SA, Paris, = France

22.=20 Liberalisation versus regulation in electronic communication networks = and=20 services
Ščehovič A., V=DAS Bansk=E1 Bystrica, = Slovakia

23. Steps Towards=20 a World-Wide Broadband Multimedia Network
Finley Marion R. Jr., Asahi = University, Japan

24. ATM services and applications integration = access to=20 a large community of
users in the region of Aveiro
Fontes F., = Portugal=20 Telecom, Aveiro, Portugal

25. The necessity of the building of = academic=20 "information superhighways"
Horvath P., SANET Bratislava, = Slovakia

26.=20 The effectivity of the extranets in companies
Lavrin A., Zelko M., = Technical=20 University of Košice, Slovakia

27. Operator of the broadband = services -=20 the vision
Žirko M1., Jakab F2., Čižm=E1r A2., Slovak = Telecom Bratislava1,=20 Technical
University of Košice, Slovakia

28. Some remarks = to the=20 implementation maintance of the ST-ATM network
Trstensk=FD D., et = al., Slovak=20 Telecom, Bansk=E1 Bystrica, Slovakia

29. Presentation = 1
Ambasador ATM=20 FORUM

30. Presentation 2
Ambasador ATM FORUM

31. = Preparation=20 and developing strategy of the information society in the Slovak=20 Republic
Podhorsk=FD V., Ministry of Transport, Post and = Telecommunications in=20 SR, Bratislava. Slovakia

32. Information highways in information=20 society
Karovič K., SAV Bratislava, Slovakia

33. = Experiences of the=20 Corinex company with the ATM technologies
Sl=E1nička, CORINEX = Group,=20 Slovakia

34. Experiences of the IBM company with the ATM=20 technologies
Labanc, IBM Slovensko, Slovakia

35. IP net next=20 generation - voice/multimedia transport
Linhart Z., CONTACTEL, Czech=20 Republic

36. Next Generation Networks and Services - ATM and=20 IP
Asatani K., Kogakuin University, Tokyo, Japan

37. Secure=20 services
Tomašov P., University of Žilina, = Slovakia

38. Algoritmics=20 and tool for virtual audience training
Tsejtlin G.T., International = Solomon=20 University, Kiev, Ukraine

39. Expert estimations of validity and=20 reliability of programme and
technical maintance of computer=20 networks
Grygorovych V.F., Oleksiivna M.O., Uzhgorod State Institute = of=20 Informatics Science, Ukraine

40. The algebraic approach to = minimization=20 of computing Expences in computer networks
Olegovich N.M., Uzhgorod = State=20 Institute of Informatics Science, Ukraine

41. ATM Subscriber = Access=20 Multiplexer: the complete ADSL solution
Lizuch P., Alcatel Slovakia,=20 Liptovsk=FD Hr=E1dok, Slovakia

42. Design of an Input-queueded = ATM Switch=20 supporting multicast and research on its Scheduling Policy
Minguy Z., = Nanjing=20 University, China

43. Videoconferencing room
Baroň=E1k = I., Moln=E1r M.,=20 Department of Telecommunications, Faculty of
Electrical Engineering = and=20 Informatics, Slovak University of Technology, Bratislava, = Slovakia

44.=20 Application of the implementation models of the broadband = networks
Žabka J.,=20 Faculty of Mechatronics, University of Trenč=EDn, = Slovakia

45. VPN networks=20 based on MPLS
Kollar S., BGS, Bratislava, Slovakia

46. Virtual = networks in ATM
Škorpil V., FEI, VUT, Brno, Czech = Republic

47.=20 Distributed Speech Recognition Syst=E9m over ATM
Čižm=E1r = A., Doboš Ľ., Hintoš=20 L., Juh=E1r J., Faculty of Electrical Engineering
and Informatics of = the=20 Technical University of Košice, Slovakia

48. Wireles ATM = Physical Layer=20 Simulation
Doboš Ľ., Palifetka R., Čižm=E1r A., = Juh=E1r J., Faculty of=20 Electrical
Engineering and Informatics of the Technical University of = Košice,=20 Slovakia

49. Teleeducation services in broadband = networks
Jakab F.,=20 Samuelis L., Faculty of Electrical Engineering and Informatics of
the = Technical University of Košice, Slovakia

50.  Methods = of the=20 evaluation of the QoS in ATM networks
Jakab F., Faculty of Electrical = Engineering and Informatics of the Technical
University of = Košice,=20 Slovakia
______________________________________

ATMTU 2000=20 Symposium
Symposium Secretariat
elfa, s.r.o., Letna 9
042 00 = Kosice,=20 Slovakia
Tel./fax.: +421 95 6253839, 6253200, 6253202
e-mail: elfa@elfa.sk
www.elfa.sk/index-4-en.html

------=_NextPart_000_04C2_01BFF4B0.A7E6B780-- From owner-tcp-impl@lerc.nasa.gov Wed Jul 26 15:52:09 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 PAA27356 for ; Wed, 26 Jul 2000 15:52:04 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA28102 for tcp-impl-outgoing; Wed, 26 Jul 2000 13:23:13 -0400 (EDT) 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 SMTP id NAA28017 for ; Wed, 26 Jul 2000 13:23:07 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA20652; Wed, 26 Jul 2000 13:23:02 -0400 Received: from lightning.swansea.uk.linux.org(194.168.151.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020582; Wed, 26 Jul 00 13:22:19 -0400 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 13HUnu-0000IY-00; Wed, 26 Jul 2000 18:17:11 +0100 Subject: Re: Basic Query To: pbiswas@ipolicynet.com (Proneet biswas) Date: Wed, 26 Jul 2000 18:17:05 +0100 (BST) Cc: tcp-impl@grc.nasa.gov In-Reply-To: <397A766C.A7E00DBC@policyone.com> from "Proneet biswas" at Jul 22, 2000 09:37:00 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > I had a very basic question.Can TCP resend segments which have more > data than the original one Yes > and if yes, how common is this scenario ? Unknown, but I see it in traces From owner-tcp-impl@lerc.nasa.gov Wed Jul 26 18:52:36 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 SAA19296 for ; Wed, 26 Jul 2000 18:52:35 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA10232 for tcp-impl-outgoing; Wed, 26 Jul 2000 16:20:36 -0400 (EDT) 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 SMTP id QAA10172 for ; Wed, 26 Jul 2000 16:20:34 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA12968; Wed, 26 Jul 2000 16:20:29 -0400 Received: from prv-mail25.provo.novell.com(137.65.81.121) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012924; Wed, 26 Jul 00 16:20:07 -0400 Received: from Novell.COM (hema.dnsdhcp.provo.novell.com [137.65.57.9]) by prv-mail25.provo.novell.com; Wed, 26 Jul 2000 14:19:35 -0600 Message-ID: <397F47EB.D5D336E2@Novell.COM> Date: Wed, 26 Jul 2000 14:19:55 -0600 From: Ramesh Shankar X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov CC: Proneet biswas Subject: Re: Basic Query References: Content-Type: multipart/mixed; boundary="------------EBF90337BF2EF716C2F9387A" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. --------------EBF90337BF2EF716C2F9387A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The most trivial case would be with an application sending small segments with Nagle disabled. A fast retransmit/retransmit would send more data than was sent by the original segment. Alan Cox wrote: > > > I had a very basic question.Can TCP resend segments which have more > > data than the original one > > Yes > > > and if yes, how common is this scenario ? > > Unknown, but I see it in traces --------------EBF90337BF2EF716C2F9387A Content-Type: text/x-vcard; charset=us-ascii; name="RShankar.vcf" Content-Description: Card for Ramesh Shankar Content-Disposition: attachment; filename="RShankar.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shankar;Ramesh x-mozilla-html:FALSE org:Novell Inc. version:2.1 email;internet:RShankar@Novell.COM title:Sr. Software Engineer adr;quoted-printable:;;MS: PRV-H-311=0D=0A1800 South Novell Place;Provo;UT;84606;USA fn:Ramesh Shankar end:vcard --------------EBF90337BF2EF716C2F9387A-- From owner-tcp-impl@lerc.nasa.gov Thu Jul 27 12:24: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 MAA27158 for ; Thu, 27 Jul 2000 12:24:48 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA06433 for tcp-impl-outgoing; Thu, 27 Jul 2000 10:00:10 -0400 (EDT) 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 SMTP id KAA06399 for ; Thu, 27 Jul 2000 10:00:07 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA10062; Thu, 27 Jul 2000 10:00:05 -0400 Received: from philos.philosys.de(193.100.254.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma009967; Thu, 27 Jul 00 09:59:36 -0400 Received: from philosys.de (intranet.philosys.de [193.100.254.65]) by philos.philosys.de (8.8.8/8.8.8) with ESMTP id QAA24532; Thu, 27 Jul 2000 16:01:39 +0200 (MET DST) Message-ID: <398040C1.7B357EE0@philosys.de> Date: Thu, 27 Jul 2000 16:01:37 +0200 From: Roland Geier Organization: Philosys Software GmbH X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: syn received on half open connection Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I've got a question concerning the fits-to-specs-behaviour of BSD derived tcp implementations when a syn is received on half open connections. Therefore, please assume the scenario that is pointed out in rfc793, section 'Half-Open Connections and Other Anomalies': --------------- excerpt from rfc793 --------------- Assume that two user processes A and B are communicating with one another when a crash occurs causing loss of memory to A's TCP. Depending on the operating system supporting A's TCP, it is likely that some error recovery mechanism exists. When the TCP is up again, A is likely to start again from the beginning or from a recovery point. As a result, A will probably try to OPEN the connection again or try to SEND on the connection it believes open. In the latter case, it receives the error message "connection not open" from the local (A's) TCP. In an attempt to establish the connection, A's TCP will send a segment containing SYN. This scenario leads to the example shown in figure 10. After TCP A crashes, the user attempts to re-open the connection. TCP B, in the meantime, thinks the connection is open. TCP A TCP B 1. (CRASH) (send 300,receive 100) 2. CLOSED ESTABLISHED 3. SYN-SENT --> --> (??) 4. (!!) <-- <-- ESTABLISHED 5. SYN-SENT --> --> (Abort!!) 6. SYN-SENT CLOSED 7. SYN-SENT --> --> When the SYN arrives at line 3, TCP B, being in a synchronized state, and the incoming segment outside the window, responds with an acknowledgment indicating what sequence it next expects to hear (ACK 100). TCP A sees that this segment does not acknowledge anything it sent and, being unsynchronized, sends a reset (RST) because it has detected a half-open connection. TCP B aborts at line 5. TCP A will continue to try to establish the connection; the problem is now reduced to the basic 3-way handshake. --------------- end of excerpt --------------- The scenario does not differentiate between the following cases when the SYN arrives at line 3: (a) the SYN packet's ISS is *within* the receive window of TCP B (b) the SYN packet's ISS is *not* within the receive window of TCP B AS shown in [Code A] (see TCP/IP Illustrated Vol. II, Fig. 28.37), case (a) is considered to be an error and BSD implementations will send a RST and drop the connection: ----- [Code A] ----- /* * If a SYN is in the window, then this is an * error and we send an RST and drop the connection. */ if (tiflags & TH_SYN) { tp = tcp_drop(tp, ECONNRESET); goto dropwithreset; } Let's now assume case (b), i.e. the syn is *not* in the window. In this case the SYN-Flag is explicitly switched off (see [Code B], taken from Fig. 28.24): ----- [Code B] ----- todrop = tp->rcv_nxt - ti->ti_seq; if (todrop > 0) { if (tiflags & TH_SYN) { tiflags &= ~TH_SYN; ti->ti_seq++; : } As [Code B] is located before [Code A], BSD won't send a reset if the syn is *not* within the window as the SYN bit won't be set when coming along [Code A]. Furthermore, [Code C] (see Fig. 28.37 again), directly following [Code A], states: ----- [Code C] ----- /* * If the ACK bit is off we drop the segment and return. */ if ((tiflags & TH_ACK) == 0) goto drop; As in an initial SYN request the ACK bit isn't set, a SYN request that does not fall into the window will be silently dropped in BSD, at least accoding to Rich Stevens and the FreeBSD implementation. If I did not miss the point that would violate the spec, wouldn't it? Any comments on that would be highly appreciated, Roland. -- Roland Geier Philosys Software GmbH geier@philosys.de Edisonstr. 6 tel: +49 89 321407 56 D-85716 Unterschleissheim fax: +49 89 321407 12 http://www.philosys.de From owner-tcp-impl@lerc.nasa.gov Thu Jul 27 14:08:25 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 OAA15451 for ; Thu, 27 Jul 2000 14:08:25 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA25272 for tcp-impl-outgoing; Thu, 27 Jul 2000 11:47:17 -0400 (EDT) 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 SMTP id LAA25224 for ; Thu, 27 Jul 2000 11:47:15 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA24256; Thu, 27 Jul 2000 11:47:09 -0400 Received: from mg03.austin.ibm.com(192.35.232.20) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024138; Thu, 27 Jul 00 11:46:59 -0400 Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96]) by mailgate3.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA03502 for ; Thu, 27 Jul 2000 10:26:55 -0500 Received: from austin.ibm.com (ambika.austin.ibm.com [9.53.150.77]) by netmail1.austin.ibm.com (8.8.5/8.8.5) with ESMTP id KAA66198; Thu, 27 Jul 2000 10:46:57 -0500 Message-ID: <39805970.CEC3E943@austin.ibm.com> Date: Thu, 27 Jul 2000 10:46:56 -0500 From: venkat venkatsubra Organization: IBM X-Mailer: Mozilla 4.61 [en] (X11; U; AIX 4.3) X-Accept-Language: en MIME-Version: 1.0 To: Roland Geier CC: tcp-impl@grc.nasa.gov Subject: Re: syn received on half open connection References: <398040C1.7B357EE0@philosys.de> Content-Type: multipart/mixed; boundary="------------25ED224DEF25832621C0E9C6" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. --------------25ED224DEF25832621C0E9C6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Roland Geier wrote: > Hello, > > I've got a question concerning the fits-to-specs-behaviour of BSD > derived tcp implementations when a syn is received on half open > connections. Therefore, please assume the scenario that is pointed out > in rfc793, section 'Half-Open Connections and Other Anomalies': > > --------------- excerpt from rfc793 --------------- > > Assume that two user processes A and B are communicating with one > another when a crash occurs causing loss of memory to A's TCP. Depending > on the operating system supporting A's TCP, it is likely that some error > recovery mechanism exists. When the TCP is up again, A is likely to > start again from the beginning or from a recovery point. As a result, A > will probably try to OPEN the connection again or try to SEND on the > connection it believes open. In the latter case, it receives the error > message "connection not open" from the local (A's) TCP. In an attempt > to establish the connection, A's TCP will send a segment containing > SYN. This scenario leads to the example shown in figure 10. After TCP > A crashes, the user attempts to re-open the connection. TCP B, in the > meantime, thinks the connection is open. > > TCP A TCP B > > 1. (CRASH) (send 300,receive 100) > 2. CLOSED ESTABLISHED > 3. SYN-SENT --> --> (??) > 4. (!!) <-- <-- ESTABLISHED > 5. SYN-SENT --> --> (Abort!!) > 6. SYN-SENT CLOSED > 7. SYN-SENT --> --> > > When the SYN arrives at line 3, TCP B, being in a synchronized state, > and the incoming segment outside the window, responds with an > acknowledgment indicating what sequence it next expects to hear (ACK > 100). TCP A sees that this segment does not acknowledge anything it > sent and, being unsynchronized, sends a reset (RST) because it has > detected a half-open connection. TCP B aborts at line 5. TCP A will > continue to try to establish the connection; the problem is now reduced > to the basic 3-way handshake. > > --------------- end of excerpt --------------- > > The scenario does not differentiate between the following cases when the > SYN arrives at line 3: > > (a) the SYN packet's ISS is *within* the receive window of TCP B > (b) the SYN packet's ISS is *not* within the receive window of TCP B > > AS shown in [Code A] (see TCP/IP Illustrated Vol. II, Fig. 28.37), case > (a) is considered to be an error and BSD implementations will send a RST > and drop the connection: > > ----- [Code A] ----- > > /* > * If a SYN is in the window, then this is an > * error and we send an RST and drop the connection. > */ > if (tiflags & TH_SYN) { > tp = tcp_drop(tp, ECONNRESET); > goto dropwithreset; > } > > Let's now assume case (b), i.e. the syn is *not* in the window. In this > case the SYN-Flag is explicitly switched off (see [Code B], taken from > Fig. 28.24): > > ----- [Code B] ----- > > todrop = tp->rcv_nxt - ti->ti_seq; > if (todrop > 0) { > if (tiflags & TH_SYN) { > tiflags &= ~TH_SYN; > ti->ti_seq++; > : > } > > As [Code B] is located before [Code A], BSD won't send a reset if the > syn is *not* within the window as the SYN bit won't be set when coming > along [Code A]. > > Furthermore, [Code C] (see Fig. 28.37 again), directly following [Code > A], states: > > ----- [Code C] ----- > > /* > * If the ACK bit is off we drop the segment and return. > */ > if ((tiflags & TH_ACK) == 0) > goto drop; > > As in an initial SYN request the ACK bit isn't set, a SYN request that > does not fall into the window will be silently dropped in BSD, at least > accoding to Rich Stevens and the FreeBSD implementation. If I did not > miss the point that would violate the spec, wouldn't it? > > Any comments on that would be highly appreciated, > > Roland. > > -- > Roland Geier Philosys Software GmbH > geier@philosys.de Edisonstr. 6 > tel: +49 89 321407 56 D-85716 Unterschleissheim > fax: +49 89 321407 12 http://www.philosys.de --------------25ED224DEF25832621C0E9C6 Content-Type: text/plain; charset=us-ascii; name="xx" Content-Disposition: inline; filename="xx" Content-Transfer-Encoding: 7bit Roland, The rfc does differentiate case (a) and (b). In page 70 of rfc793 it says this: -------------------------------------------- fourth, check the SYN bit, SYN-RECEIVED ESTABLISHED STATE FIN-WAIT STATE-1 FIN-WAIT STATE-2 CLOSE-WAIT STATE CLOSING STATE LAST-ACK STATE TIME-WAIT STATE If the SYN is in the window it is an error, send a reset, any outstanding RECEIVEs and SEND should receive "reset" responses, all segment queues should be flushed, the user should also receive an unsolicited general "connection reset" signal, enter the CLOSED state, delete the TCB, and return. If the SYN is not in the window this step would not be reached and an ack would have been sent in the first step (sequence number check). --------------------------------------------- And the code fragment [C] is according to the next line in the spec (page 71): ------------------------------------------- fifth check the ACK field, if the ACK bit is off drop the segment and return ------------------------------------------ Venkat --------------25ED224DEF25832621C0E9C6-- From owner-tcp-impl@lerc.nasa.gov Sat Jul 29 15:19: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 PAA06404 for ; Sat, 29 Jul 2000 15:19:29 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA18637 for tcp-impl-outgoing; Sat, 29 Jul 2000 12:43:05 -0400 (EDT) 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 SMTP id MAA18625; Sat, 29 Jul 2000 12:43:03 -0400 (EDT) From: callback123@altavistausa.com Received: by seraph3.lerc.nasa.gov; id MAA05372; Sat, 29 Jul 2000 12:43:02 -0400 Received: from max1-3.newyork.corecomm.net(209.81.238.131) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005322; Sat, 29 Jul 00 12:42:27 -0400 Subject: Re: From Lorraine,as promised,I can lower your bill Date: Sat, 29 Jul 2000 13:38:49 Message-Id: <775.204003.395214@altavistausa.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Untitled Document


Today, everyone knows the impact of the Internet.
But not everyone nows how to cut their phone bill in 1/2. Just a Few examples!!!!

Uk $.04     France $.06    UAE  $.31    Saudi Arabia $.59     Denmark $.04      Sweden $.05

Click Here Now.

If you do not have flash please go to
www.macromedia.com
to download it.

From owner-tcp-impl@lerc.nasa.gov Mon Jul 31 20:51: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 UAA19464 for ; Mon, 31 Jul 2000 20:51:21 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA24470 for tcp-impl-outgoing; Mon, 31 Jul 2000 15:55:13 -0400 (EDT) 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 SMTP id PAA24442 for ; Mon, 31 Jul 2000 15:55:09 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA05668; Mon, 31 Jul 2000 15:55:07 -0400 Received: from unknown(194.217.109.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005562; Mon, 31 Jul 00 15:54:35 -0400 Received: from asimov.spider.com (asimov.spider.com [212.240.99.66]) by mercury.spider.com (8.8.8/8.8.8) with ESMTP id UAA01056 for ; Mon, 31 Jul 2000 20:54:28 +0100 (BST) (envelope-from ian@asimov.spider.com) Received: from malatesta.spider.com (malatesta.spider.com [212.240.99.93]) by asimov.spider.com (8.9.1b+Sun/8.9.1) with ESMTP id UAA09981; Mon, 31 Jul 2000 20:54:27 +0100 (BST) Received: (from ian@localhost) by malatesta.spider.com (8.9.1b+Sun/8.9.1) id UAA28473; Mon, 31 Jul 2000 20:54:27 +0100 (BST) Date: Mon, 31 Jul 2000 20:54:27 +0100 From: Ian Heavens To: tcp-impl@grc.nasa.gov Subject: The TCP RST Message-ID: <20000731205427.B28460@malatesta.spider.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk hi TCP implementors, Anyone at the IETF want to talk about TCP RSTs? I'm here in Pittsburgh. Issues have come up with application behaviour and RFC 1122 half duplex close, and various others. I guess if there is any interest we could list the issues for now, with a view to pursuing them on this mailing list. cheers ian -- Ian Heavens, Spider Software Ltd., http://www.spider.com/ 8 John's Place, Leith, Edinburgh EH6 7EL. Tel +44 131 475 7015 fax. +44 131 475 7001 ian@spider.com