From owner-tcp-impl@lerc.nasa.gov Sun Apr 1 01:55:03 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16213 for ; Sun, 1 Apr 2001 01:55:02 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id BAA20543; Sun, 1 Apr 2001 01:55:00 -0500 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma019799; Sun, 1 Apr 01 01:53:38 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA19745 for tcp-impl-outgoing; Sun, 1 Apr 2001 01:34:45 -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 SMTP id BAA19734 for ; Sun, 1 Apr 2001 01:34:44 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id BAA29345; Sun, 1 Apr 2001 01:34:42 -0500 Received: from f54.law7.hotmail.com(216.33.237.54) by seraph3.lerc.nasa.gov via smap (V5.5) id xma029185; Sun, 1 Apr 01 01:34:11 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 31 Mar 2001 22:34:10 -0800 Received: from 172.143.222.115 by lw7fd.law7.hotmail.msn.com with HTTP; Sun, 01 Apr 2001 06:34:10 GMT X-Originating-IP: [172.143.222.115] From: "M B" To: tcp-impl@lerc.nasa.gov Subject: Re: Lost connection Date: Sun, 01 Apr 2001 01:34:10 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Apr 2001 06:34:10.0660 (UTC) FILETIME=[C2AF9240:01C0BA75] Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk At the time the problem fall on my lap I had no access to any of the implicated servers! But I can answer your question: The Sun server is an E450 running Solaris 2.6. The client is an x86 running NT 4. On Monday once I get access to these machines, I will put a sniffer on the NT side, then run a snoop on the Sun server. Here is all the information I have so far: LAN1.....T1.....LAN2.....FR.....LAN3 . T1 = T1 link. . FR = Frame Relay. . LAN1 = Network where the NT machine resides. . LAN3 = Network where the Sun machine resides. . LAN2 = The network between the two Networks. LAN2 and LAN3 are privately connected. No other possible path from LAN1 to LAN3 other than LAN2. . LAN1, LAN2 and LAN 3 are 100Base-T. . FTP transfers between LAN1 and LAN2 succeed. . FTP transfers between LAN2 and LAN3 succeed. . FTP transfers between LAN1 and LAN3 fail. 1- Here is the log of a typical ftp session (look at the time stamps): Mar 30 10:44:54 oh44ux01 ftpd[21340]: FTPD: connection from 172.28.2.7 at Fri Mar 30 10:44:54 2001 Mar 30 10:44:54 oh44ux01 ftpd[21340]: <--- 220 Mar 30 10:44:54 oh44ux01 ftpd[21340]: oh44ux01 FTP server (SunOS 5.6) ready. Mar 30 10:44:59 oh44ux01 ftpd[21340]: FTPD: command: USER test Mar 30 10:44:59 oh44ux01 ftpd[21340]: <--- 331 Mar 30 10:44:59 oh44ux01 ftpd[21340]: Password required for test. Mar 30 10:45:04 oh44ux01 ftpd[21340]: FTPD: command: PASS Mar 30 10:45:04 oh44ux01 ftpd[21340]: <--- 230 Mar 30 10:45:04 oh44ux01 ftpd[21340]: User test logged in. Mar 30 10:45:14 oh44ux01 ftpd[21340]: FTPD: command: TYPE I Mar 30 10:45:14 oh44ux01 ftpd[21340]: <--- 200 Mar 30 10:45:14 oh44ux01 ftpd[21340]: Type set to I. Mar 30 10:45:22 oh44ux01 ftpd[21340]: FTPD: command: PORT 172,28,2,7,10,64 Mar 30 10:45:22 oh44ux01 ftpd[21340]: <--- 200 Mar 30 10:45:22 oh44ux01 ftpd[21340]: PORT command successful. Mar 30 10:45:22 oh44ux01 ftpd[21340]: FTPD: command: STOR 00000100006002.pdf Mar 30 10:45:23 oh44ux01 ftpd[21340]: <--- 150 Mar 30 10:45:23 oh44ux01 ftpd[21340]: Binary data connection for 00000100006002.pdf (172.28.2.7,2624). Mar 30 12:56:51 oh44ux01 ftpd[21340]: lost connection 2- Another session where several files were transfered then there was a time out: [cut] Mar 27 17:09:49 oh44ux01 ftpd[6915]: <--- 150 Mar 27 17:09:49 oh44ux01 ftpd[6915]: ASCII data connection for /bin/ls (172.28.2.7,2115) (0 bytes). Mar 27 17:09:49 oh44ux01 ftpd[6915]: <--- 226 Mar 27 17:09:49 oh44ux01 ftpd[6915]: ASCII Transfer complete. Mar 27 17:12:49 oh44ux01 ftpd[6915]: FTPD: command: NOOP Mar 27 17:12:49 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:12:49 oh44ux01 ftpd[6915]: NOOP command successful. Mar 27 17:15:49 oh44ux01 ftpd[6915]: FTPD: command: NOOP Mar 27 17:15:49 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:15:49 oh44ux01 ftpd[6915]: NOOP command successful. Mar 27 17:15:55 oh44ux01 ftpd[6915]: FTPD: command: TYPE I Mar 27 17:15:55 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:15:55 oh44ux01 ftpd[6915]: Type set to I. Mar 27 17:15:55 oh44ux01 ftpd[6915]: FTPD: command: PORT 172,28,2,7,8,214 Mar 27 17:15:55 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:15:55 oh44ux01 ftpd[6915]: PORT command successful. Mar 27 17:15:55 oh44ux01 ftpd[6915]: FTPD: command: STOR 00000184159044.pdf Mar 27 17:15:56 oh44ux01 ftpd[6915]: <--- 150 Mar 27 17:15:56 oh44ux01 ftpd[6915]: Binary data connection for 00000184159044.pdf (172.28.2.7,2262). Mar 27 17:15:56 oh44ux01 ftpd[6915]: <--- 226 Mar 27 17:15:56 oh44ux01 ftpd[6915]: Transfer complete. Mar 27 17:15:56 oh44ux01 ftpd[6915]: FTPD: command: TYPE I Mar 27 17:15:56 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:15:56 oh44ux01 ftpd[6915]: Type set to I. Mar 27 17:15:56 oh44ux01 ftpd[6915]: FTPD: command: PORT 172,28,2,7,8,215 Mar 27 17:15:56 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:15:56 oh44ux01 ftpd[6915]: PORT command successful. Mar 27 17:15:56 oh44ux01 ftpd[6915]: FTPD: command: STOR 00000190101016.pdf Mar 27 17:15:56 oh44ux01 ftpd[6915]: <--- 150 Mar 27 17:15:56 oh44ux01 ftpd[6915]: Binary data connection for 00000190101016.pdf (172.28.2.7,2263). Mar 27 17:15:57 oh44ux01 ftpd[6915]: <--- 226 Mar 27 17:15:57 oh44ux01 ftpd[6915]: Transfer complete. Mar 27 17:15:57 oh44ux01 ftpd[6915]: FTPD: command: TYPE I Mar 27 17:15:57 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:15:57 oh44ux01 ftpd[6915]: Type set to I. Mar 27 17:15:57 oh44ux01 ftpd[6915]: FTPD: command: PORT 172,28,2,7,8,216 Mar 27 17:15:57 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:15:57 oh44ux01 ftpd[6915]: PORT command successful. Mar 27 17:15:57 oh44ux01 ftpd[6915]: FTPD: command: STOR 00000192097033.pdf Mar 27 17:15:57 oh44ux01 ftpd[6915]: <--- 150 Mar 27 17:15:57 oh44ux01 ftpd[6915]: Binary data connection for 00000192097033.pdf (172.28.2.7,2264). Mar 27 17:15:58 oh44ux01 ftpd[6915]: <--- 226 Mar 27 17:15:58 oh44ux01 ftpd[6915]: Transfer complete. Mar 27 17:15:58 oh44ux01 ftpd[6915]: FTPD: command: TYPE I Mar 27 17:15:58 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:15:58 oh44ux01 ftpd[6915]: Type set to I. Mar 27 17:15:58 oh44ux01 ftpd[6915]: FTPD: command: PORT 172,28,2,7,8,217 Mar 27 17:15:58 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:15:58 oh44ux01 ftpd[6915]: PORT command successful. Mar 27 17:15:58 oh44ux01 ftpd[6915]: FTPD: command: STOR 00000192213008.pdf Mar 27 17:15:58 oh44ux01 ftpd[6915]: <--- 150 Mar 27 17:15:58 oh44ux01 ftpd[6915]: Binary data connection for 00000192213008.pdf (172.28.2.7,2265). Mar 27 17:15:59 oh44ux01 ftpd[6915]: <--- 226 Mar 27 17:15:59 oh44ux01 ftpd[6915]: Transfer complete. Mar 27 17:15:59 oh44ux01 ftpd[6915]: FTPD: command: TYPE I Mar 27 17:15:59 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:15:59 oh44ux01 ftpd[6915]: Type set to I. Mar 27 17:15:59 oh44ux01 ftpd[6915]: FTPD: command: PORT 172,28,2,7,8,219 Mar 27 17:15:59 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:15:59 oh44ux01 ftpd[6915]: PORT command successful. Mar 27 17:15:59 oh44ux01 ftpd[6915]: FTPD: command: STOR 00000196271002.pdf Mar 27 17:15:59 oh44ux01 ftpd[6915]: <--- 150 Mar 27 17:15:59 oh44ux01 ftpd[6915]: Binary data connection for 00000196271002.pdf (172.28.2.7,2267). Mar 27 17:16:00 oh44ux01 ftpd[6915]: <--- 226 Mar 27 17:16:00 oh44ux01 ftpd[6915]: Transfer complete. Mar 27 17:16:00 oh44ux01 ftpd[6915]: FTPD: command: TYPE I Mar 27 17:16:00 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:16:00 oh44ux01 ftpd[6915]: Type set to I. Mar 27 17:16:00 oh44ux01 ftpd[6915]: FTPD: command: PORT 172,28,2,7,8,220 Mar 27 17:16:00 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:16:00 oh44ux01 ftpd[6915]: PORT command successful. Mar 27 17:16:00 oh44ux01 ftpd[6915]: FTPD: command: STOR 00000198177007.pdf Mar 27 17:16:00 oh44ux01 ftpd[6915]: <--- 150 Mar 27 17:16:00 oh44ux01 ftpd[6915]: Binary data connection for 00000198177007.pdf (172.28.2.7,2268). Mar 27 17:16:01 oh44ux01 ftpd[6915]: <--- 226 Mar 27 17:16:01 oh44ux01 ftpd[6915]: Transfer complete. Mar 27 17:16:01 oh44ux01 ftpd[6915]: FTPD: command: TYPE I Mar 27 17:16:01 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:16:01 oh44ux01 ftpd[6915]: Type set to I. Mar 27 17:16:01 oh44ux01 ftpd[6915]: FTPD: command: PORT 172,28,2,7,8,221 Mar 27 17:16:01 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:16:01 oh44ux01 ftpd[6915]: PORT command successful. Mar 27 17:16:01 oh44ux01 ftpd[6915]: FTPD: command: STOR 00000198191008.pdf Mar 27 17:16:01 oh44ux01 ftpd[6915]: <--- 150 Mar 27 17:16:01 oh44ux01 ftpd[6915]: Binary data connection for 00000198191008.pdf (172.28.2.7,2269). Mar 27 17:16:02 oh44ux01 ftpd[6915]: <--- 226 Mar 27 17:16:02 oh44ux01 ftpd[6915]: Transfer complete. Mar 27 17:16:02 oh44ux01 ftpd[6915]: FTPD: command: TYPE I Mar 27 17:16:02 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:16:02 oh44ux01 ftpd[6915]: Type set to I. Mar 27 17:16:02 oh44ux01 ftpd[6915]: FTPD: command: PORT 172,28,2,7,8,223 Mar 27 17:16:02 oh44ux01 ftpd[6915]: <--- 200 Mar 27 17:16:02 oh44ux01 ftpd[6915]: PORT command successful. Mar 27 17:16:02 oh44ux01 ftpd[6915]: FTPD: command: STOR 00000199138008.pdf Mar 27 17:16:02 oh44ux01 ftpd[6915]: <--- 150 Mar 27 17:16:02 oh44ux01 ftpd[6915]: Binary data connection for 00000199138008.pdf (172.28.2.7,2271). Mar 27 19:27:28 oh44ux01 ftpd[6915]: <--- 552 Mar 27 19:27:28 oh44ux01 ftpd[6915]: 00000199138008.pdf: Connection timed out. Mar 27 19:27:28 oh44ux01 ftpd[6915]: FTPD: command: TYPE I Mar 27 19:27:28 oh44ux01 ftpd[6915]: <--- 200 Mar 27 19:27:28 oh44ux01 ftpd[6915]: Type set to I. Mar 27 19:27:28 oh44ux01 ftpd[6915]: <--- 221 Mar 27 19:27:28 oh44ux01 ftpd[6915]: You could at least say goodbye. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-tcp-impl@lerc.nasa.gov Sun Apr 1 10:47:38 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28683 for ; Sun, 1 Apr 2001 10:47:37 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id KAA16189; Sun, 1 Apr 2001 10:47:37 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma015303; Sun, 1 Apr 01 10:46:01 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA08179 for tcp-impl-outgoing; Sun, 1 Apr 2001 10:23:03 -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 KAA08169 for ; Sun, 1 Apr 2001 10:23:02 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA28546; Sun, 1 Apr 2001 10:23:00 -0400 Received: from 50-209.235.22.dellhost.com(209.235.22.50) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028524; Sun, 1 Apr 01 10:22:29 -0400 Received: from hal [24.240.187.186] by atlmail3.sagenetworks.com (SMTPD32-6.05) id A9C6A83014A; Sun, 01 Apr 2001 10:23:02 -0400 Message-ID: <001b01c0bab7$48b9ede0$babbf018@hal> From: "Hal F. Gottfried" To: "M B" , References: Subject: Re: Lost connection Date: Sun, 1 Apr 2001 10:23:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I am heading out on business all next week, I'll connect from the hotel on my laptop and look over your session and information. I have Windows and Solaris on my laptop so maybe I can check a few things I am thinking off. Also on Monday send me your syslogs from the Scoop and Sniffer if you can so I check my theories. - H ----- Original Message ----- From: "M B" To: Sent: Sunday, April 01, 2001 2:34 AM Subject: Re: Lost connection > > At the time the problem fall on my lap I had no access to any of the > implicated servers! But I can answer your question: The Sun server is > an E450 running Solaris 2.6. The client is an x86 running NT 4. > > On Monday once I get access to these machines, I will put a sniffer > on the NT side, then run a snoop on the Sun server. Here is all the > information I have so far: > > LAN1.....T1.....LAN2.....FR.....LAN3 > > . T1 = T1 link. > . FR = Frame Relay. > . LAN1 = Network where the NT machine resides. > . LAN3 = Network where the Sun machine resides. > . LAN2 = The network between the two Networks. LAN2 and LAN3 > are privately connected. No other possible path from LAN1 > to LAN3 other than LAN2. > . LAN1, LAN2 and LAN 3 are 100Base-T. > . FTP transfers between LAN1 and LAN2 succeed. > . FTP transfers between LAN2 and LAN3 succeed. > . FTP transfers between LAN1 and LAN3 fail. > > 1- Here is the log of a typical ftp session (look at the time stamps): > > Mar 30 10:44:54 oh44ux01 ftpd[21340]: FTPD: connection from 172.28.2.7 at > Fri Mar 30 10:44:54 2001 > Mar 30 10:44:54 oh44ux01 ftpd[21340]: <--- 220 > Mar 30 10:44:54 oh44ux01 ftpd[21340]: oh44ux01 FTP server (SunOS 5.6) ready. > Mar 30 10:44:59 oh44ux01 ftpd[21340]: FTPD: command: USER test > Mar 30 10:44:59 oh44ux01 ftpd[21340]: <--- 331 > Mar 30 10:44:59 oh44ux01 ftpd[21340]: Password required for test. > Mar 30 10:45:04 oh44ux01 ftpd[21340]: FTPD: command: PASS > Mar 30 10:45:04 oh44ux01 ftpd[21340]: <--- 230 > Mar 30 10:45:04 oh44ux01 ftpd[21340]: User test logged in. > Mar 30 10:45:14 oh44ux01 ftpd[21340]: FTPD: command: TYPE I > Mar 30 10:45:14 oh44ux01 ftpd[21340]: <--- 200 > Mar 30 10:45:14 oh44ux01 ftpd[21340]: Type set to I. > Mar 30 10:45:22 oh44ux01 ftpd[21340]: FTPD: command: PORT 172,28,2,7,10,64 > Mar 30 10:45:22 oh44ux01 ftpd[21340]: <--- 200 > Mar 30 10:45:22 oh44ux01 ftpd[21340]: PORT command successful. > Mar 30 10:45:22 oh44ux01 ftpd[21340]: FTPD: command: STOR 00000100006002.pdf > Mar 30 10:45:23 oh44ux01 ftpd[21340]: <--- 150 > Mar 30 10:45:23 oh44ux01 ftpd[21340]: Binary data connection for > 00000100006002.pdf (172.28.2.7,2624). > Mar 30 12:56:51 oh44ux01 ftpd[21340]: lost connection > > > 2- Another session where several files were transfered then there was a time > out: > > [cut] > Mar 27 17:09:49 oh44ux01 ftpd[6915]: <--- 150 > Mar 27 17:09:49 oh44ux01 ftpd[6915]: ASCII data connection for /bin/ls > (172.28.2.7,2115) (0 bytes). > Mar 27 17:09:49 oh44ux01 ftpd[6915]: <--- 226 > Mar 27 17:09:49 oh44ux01 ftpd[6915]: ASCII Transfer complete. > Mar 27 17:12:49 oh44ux01 ftpd[6915]: FTPD: command: NOOP > Mar 27 17:12:49 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:12:49 oh44ux01 ftpd[6915]: NOOP command successful. > Mar 27 17:15:49 oh44ux01 ftpd[6915]: FTPD: command: NOOP > Mar 27 17:15:49 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:15:49 oh44ux01 ftpd[6915]: NOOP command successful. > Mar 27 17:15:55 oh44ux01 ftpd[6915]: FTPD: command: TYPE I > Mar 27 17:15:55 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:15:55 oh44ux01 ftpd[6915]: Type set to I. > Mar 27 17:15:55 oh44ux01 ftpd[6915]: FTPD: command: PORT 172,28,2,7,8,214 > Mar 27 17:15:55 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:15:55 oh44ux01 ftpd[6915]: PORT command successful. > Mar 27 17:15:55 oh44ux01 ftpd[6915]: FTPD: command: STOR 00000184159044.pdf > Mar 27 17:15:56 oh44ux01 ftpd[6915]: <--- 150 > Mar 27 17:15:56 oh44ux01 ftpd[6915]: Binary data connection for > 00000184159044.pdf (172.28.2.7,2262). > Mar 27 17:15:56 oh44ux01 ftpd[6915]: <--- 226 > Mar 27 17:15:56 oh44ux01 ftpd[6915]: Transfer complete. > Mar 27 17:15:56 oh44ux01 ftpd[6915]: FTPD: command: TYPE I > Mar 27 17:15:56 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:15:56 oh44ux01 ftpd[6915]: Type set to I. > Mar 27 17:15:56 oh44ux01 ftpd[6915]: FTPD: command: PORT 172,28,2,7,8,215 > Mar 27 17:15:56 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:15:56 oh44ux01 ftpd[6915]: PORT command successful. > Mar 27 17:15:56 oh44ux01 ftpd[6915]: FTPD: command: STOR 00000190101016.pdf > Mar 27 17:15:56 oh44ux01 ftpd[6915]: <--- 150 > Mar 27 17:15:56 oh44ux01 ftpd[6915]: Binary data connection for > 00000190101016.pdf (172.28.2.7,2263). > Mar 27 17:15:57 oh44ux01 ftpd[6915]: <--- 226 > Mar 27 17:15:57 oh44ux01 ftpd[6915]: Transfer complete. > Mar 27 17:15:57 oh44ux01 ftpd[6915]: FTPD: command: TYPE I > Mar 27 17:15:57 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:15:57 oh44ux01 ftpd[6915]: Type set to I. > Mar 27 17:15:57 oh44ux01 ftpd[6915]: FTPD: command: PORT 172,28,2,7,8,216 > Mar 27 17:15:57 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:15:57 oh44ux01 ftpd[6915]: PORT command successful. > Mar 27 17:15:57 oh44ux01 ftpd[6915]: FTPD: command: STOR 00000192097033.pdf > Mar 27 17:15:57 oh44ux01 ftpd[6915]: <--- 150 > Mar 27 17:15:57 oh44ux01 ftpd[6915]: Binary data connection for > 00000192097033.pdf (172.28.2.7,2264). > Mar 27 17:15:58 oh44ux01 ftpd[6915]: <--- 226 > Mar 27 17:15:58 oh44ux01 ftpd[6915]: Transfer complete. > Mar 27 17:15:58 oh44ux01 ftpd[6915]: FTPD: command: TYPE I > Mar 27 17:15:58 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:15:58 oh44ux01 ftpd[6915]: Type set to I. > Mar 27 17:15:58 oh44ux01 ftpd[6915]: FTPD: command: PORT 172,28,2,7,8,217 > Mar 27 17:15:58 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:15:58 oh44ux01 ftpd[6915]: PORT command successful. > Mar 27 17:15:58 oh44ux01 ftpd[6915]: FTPD: command: STOR 00000192213008.pdf > Mar 27 17:15:58 oh44ux01 ftpd[6915]: <--- 150 > Mar 27 17:15:58 oh44ux01 ftpd[6915]: Binary data connection for > 00000192213008.pdf (172.28.2.7,2265). > Mar 27 17:15:59 oh44ux01 ftpd[6915]: <--- 226 > Mar 27 17:15:59 oh44ux01 ftpd[6915]: Transfer complete. > Mar 27 17:15:59 oh44ux01 ftpd[6915]: FTPD: command: TYPE I > Mar 27 17:15:59 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:15:59 oh44ux01 ftpd[6915]: Type set to I. > Mar 27 17:15:59 oh44ux01 ftpd[6915]: FTPD: command: PORT 172,28,2,7,8,219 > Mar 27 17:15:59 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:15:59 oh44ux01 ftpd[6915]: PORT command successful. > Mar 27 17:15:59 oh44ux01 ftpd[6915]: FTPD: command: STOR 00000196271002.pdf > Mar 27 17:15:59 oh44ux01 ftpd[6915]: <--- 150 > Mar 27 17:15:59 oh44ux01 ftpd[6915]: Binary data connection for > 00000196271002.pdf (172.28.2.7,2267). > Mar 27 17:16:00 oh44ux01 ftpd[6915]: <--- 226 > Mar 27 17:16:00 oh44ux01 ftpd[6915]: Transfer complete. > Mar 27 17:16:00 oh44ux01 ftpd[6915]: FTPD: command: TYPE I > Mar 27 17:16:00 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:16:00 oh44ux01 ftpd[6915]: Type set to I. > Mar 27 17:16:00 oh44ux01 ftpd[6915]: FTPD: command: PORT 172,28,2,7,8,220 > Mar 27 17:16:00 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:16:00 oh44ux01 ftpd[6915]: PORT command successful. > Mar 27 17:16:00 oh44ux01 ftpd[6915]: FTPD: command: STOR 00000198177007.pdf > Mar 27 17:16:00 oh44ux01 ftpd[6915]: <--- 150 > Mar 27 17:16:00 oh44ux01 ftpd[6915]: Binary data connection for > 00000198177007.pdf (172.28.2.7,2268). > Mar 27 17:16:01 oh44ux01 ftpd[6915]: <--- 226 > Mar 27 17:16:01 oh44ux01 ftpd[6915]: Transfer complete. > Mar 27 17:16:01 oh44ux01 ftpd[6915]: FTPD: command: TYPE I > Mar 27 17:16:01 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:16:01 oh44ux01 ftpd[6915]: Type set to I. > Mar 27 17:16:01 oh44ux01 ftpd[6915]: FTPD: command: PORT 172,28,2,7,8,221 > Mar 27 17:16:01 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:16:01 oh44ux01 ftpd[6915]: PORT command successful. > Mar 27 17:16:01 oh44ux01 ftpd[6915]: FTPD: command: STOR 00000198191008.pdf > Mar 27 17:16:01 oh44ux01 ftpd[6915]: <--- 150 > Mar 27 17:16:01 oh44ux01 ftpd[6915]: Binary data connection for > 00000198191008.pdf (172.28.2.7,2269). > Mar 27 17:16:02 oh44ux01 ftpd[6915]: <--- 226 > Mar 27 17:16:02 oh44ux01 ftpd[6915]: Transfer complete. > Mar 27 17:16:02 oh44ux01 ftpd[6915]: FTPD: command: TYPE I > Mar 27 17:16:02 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:16:02 oh44ux01 ftpd[6915]: Type set to I. > Mar 27 17:16:02 oh44ux01 ftpd[6915]: FTPD: command: PORT 172,28,2,7,8,223 > Mar 27 17:16:02 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 17:16:02 oh44ux01 ftpd[6915]: PORT command successful. > Mar 27 17:16:02 oh44ux01 ftpd[6915]: FTPD: command: STOR 00000199138008.pdf > Mar 27 17:16:02 oh44ux01 ftpd[6915]: <--- 150 > Mar 27 17:16:02 oh44ux01 ftpd[6915]: Binary data connection for > 00000199138008.pdf (172.28.2.7,2271). > Mar 27 19:27:28 oh44ux01 ftpd[6915]: <--- 552 > Mar 27 19:27:28 oh44ux01 ftpd[6915]: 00000199138008.pdf: Connection timed > out. > Mar 27 19:27:28 oh44ux01 ftpd[6915]: FTPD: command: TYPE I > Mar 27 19:27:28 oh44ux01 ftpd[6915]: <--- 200 > Mar 27 19:27:28 oh44ux01 ftpd[6915]: Type set to I. > Mar 27 19:27:28 oh44ux01 ftpd[6915]: <--- 221 > Mar 27 19:27:28 oh44ux01 ftpd[6915]: You could at least say goodbye. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > From owner-tcp-impl@lerc.nasa.gov Sun Apr 1 12:39:10 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20234 for ; Sun, 1 Apr 2001 12:39:09 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id MAA24053; Sun, 1 Apr 2001 12:39:09 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma023115; Sun, 1 Apr 01 12:38:05 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA13493 for tcp-impl-outgoing; Sun, 1 Apr 2001 12:19:33 -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 MAA13468 for ; Sun, 1 Apr 2001 12:19:32 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA07697; Sun, 1 Apr 2001 12:19:31 -0400 Received: from granger.mail.mindspring.net(207.69.200.148) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007663; Sun, 1 Apr 01 12:18:37 -0400 Received: from bsd.jcs.com (user-33qtsj4.dialup.mindspring.com [199.174.242.100]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA09336; Sun, 1 Apr 2001 12:18:34 -0400 (EDT) Received: (from jcs@localhost) by bsd.jcs.com (8.11.1/8.11.1) id f31GJei15036; Sun, 1 Apr 2001 12:19:40 -0400 (EDT) (envelope-from jsnader@ix.netcom.com) X-Authentication-Warning: bsd.jcs.com: jcs set sender to jsnader@ix.netcom.com using -f Date: Sun, 1 Apr 2001 12:19:36 -0400 From: Jon Snader To: M B Cc: tcp-impl@lerc.nasa.gov Subject: Re: Lost connection Message-ID: <20010401121936.B14978@ix.netcom.com> Mail-Followup-To: Jon Snader , M B , tcp-impl@lerc.nasa.gov References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from moncef2@hotmail.com on Sun, Apr 01, 2001 at 01:34:10AM -0500 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Sun, Apr 01, 2001 at 01:34:10AM -0500, M B wrote: > > At the time the problem fall on my lap I had no access to any of the > implicated servers! But I can answer your question: The Sun server is > an E450 running Solaris 2.6. The client is an x86 running NT 4. > > On Monday once I get access to these machines, I will put a sniffer > on the NT side, then run a snoop on the Sun server. Here is all the > information I have so far: > > LAN1.....T1.....LAN2.....FR.....LAN3 > > . T1 = T1 link. > . FR = Frame Relay. > . LAN1 = Network where the NT machine resides. > . LAN3 = Network where the Sun machine resides. > . LAN2 = The network between the two Networks. LAN2 and LAN3 > are privately connected. No other possible path from LAN1 > to LAN3 other than LAN2. > . LAN1, LAN2 and LAN 3 are 100Base-T. > . FTP transfers between LAN1 and LAN2 succeed. > . FTP transfers between LAN2 and LAN3 succeed. > . FTP transfers between LAN1 and LAN3 fail. > > 1- Here is the log of a typical ftp session (look at the time stamps): > > Mar 30 10:44:54 oh44ux01 ftpd[21340]: FTPD: connection from 172.28.2.7 at > Fri Mar 30 10:44:54 2001 > Mar 30 10:44:54 oh44ux01 ftpd[21340]: <--- 220 > Mar 30 10:44:54 oh44ux01 ftpd[21340]: oh44ux01 FTP server (SunOS 5.6) ready. > Mar 30 10:44:59 oh44ux01 ftpd[21340]: FTPD: command: USER test > Mar 30 10:44:59 oh44ux01 ftpd[21340]: <--- 331 > Mar 30 10:44:59 oh44ux01 ftpd[21340]: Password required for test. > Mar 30 10:45:04 oh44ux01 ftpd[21340]: FTPD: command: PASS > Mar 30 10:45:04 oh44ux01 ftpd[21340]: <--- 230 > Mar 30 10:45:04 oh44ux01 ftpd[21340]: User test logged in. > Mar 30 10:45:14 oh44ux01 ftpd[21340]: FTPD: command: TYPE I > Mar 30 10:45:14 oh44ux01 ftpd[21340]: <--- 200 > Mar 30 10:45:14 oh44ux01 ftpd[21340]: Type set to I. > Mar 30 10:45:22 oh44ux01 ftpd[21340]: FTPD: command: PORT 172,28,2,7,10,64 > Mar 30 10:45:22 oh44ux01 ftpd[21340]: <--- 200 > Mar 30 10:45:22 oh44ux01 ftpd[21340]: PORT command successful. > Mar 30 10:45:22 oh44ux01 ftpd[21340]: FTPD: command: STOR 00000100006002.pdf > Mar 30 10:45:23 oh44ux01 ftpd[21340]: <--- 150 > Mar 30 10:45:23 oh44ux01 ftpd[21340]: Binary data connection for > 00000100006002.pdf (172.28.2.7,2624). > Mar 30 12:56:51 oh44ux01 ftpd[21340]: lost connection > > [another example deleted] I notice that in both cases the connection drops after about 2 hours into a data transfer, and that the control connection appears to be idle for that time. I have seen examples where stateful firewalls or NAT devices will time out idle connections after time intervals that are typically in the 2 hour range. Have you investigated this possibility? Jon Snader From owner-tcp-impl@lerc.nasa.gov Sun Apr 1 15:52:55 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25795 for ; Sun, 1 Apr 2001 15:52:55 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id PAA06178; Sun, 1 Apr 2001 15:52:54 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma005175; Sun, 1 Apr 01 15:51:44 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA22493 for tcp-impl-outgoing; Sun, 1 Apr 2001 15:33:09 -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 PAA22484 for ; Sun, 1 Apr 2001 15:33:08 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA22945; Sun, 1 Apr 2001 15:33:07 -0400 Received: from f313.law7.hotmail.com(216.33.236.191) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022911; Sun, 1 Apr 01 15:32:18 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 1 Apr 2001 12:32:17 -0700 Received: from 172.147.130.157 by lw7fd.law7.hotmail.msn.com with HTTP; Sun, 01 Apr 2001 19:32:17 GMT X-Originating-IP: [172.147.130.157] From: "M B" To: tcp-impl@lerc.nasa.gov Subject: Re: Lost connection Date: Sun, 01 Apr 2001 15:32:17 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Apr 2001 19:32:17.0286 (UTC) FILETIME=[76155A60:01C0BAE2] Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Jon, You're right. There is a Check Point firewall between LAN2 and LAN3. And it translates all IPs coming from LAN1 and LAN2. As you said, that would explain why a connection gets dropped after being idle for 2 hours or so. LAN1....T1.....LAN2-FW-......FR.....LAN3 But why would an FTP transfer go idle if it's coming from LAN1, while FTP transfers from LAN2 finish normally? More info: . LAN1 and LAN2 don't have any firewall between them. . The problem started to occur only after the NT machine was moved from LAN2 to LAN1. Thanks guys for your contributions. It's helpful to brainstorm before zeroing on something. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-tcp-impl@lerc.nasa.gov Mon Apr 2 03:48:32 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04250 for ; Mon, 2 Apr 2001 03:48:31 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id DAA14816; Mon, 2 Apr 2001 03:48:31 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma014187; Mon, 2 Apr 01 03:47:15 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA23936 for tcp-impl-outgoing; Mon, 2 Apr 2001 03:25:31 -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 DAA23931 for ; Mon, 2 Apr 2001 03:25:30 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id DAA13666; Mon, 2 Apr 2001 03:25:30 -0400 Received: from ihemail2.lucent.com(192.11.222.163) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013489; Mon, 2 Apr 01 03:24:33 -0400 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA15619 for ; Mon, 2 Apr 2001 03:24:32 -0400 (EDT) Received: from ii0015exch001u.wins.lucent.com (h135-254-248-252.lucent.com [135.254.248.252]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA15615 for ; Mon, 2 Apr 2001 03:24:30 -0400 (EDT) Received: by II0015EXCH001U with Internet Mail Service (5.5.2650.21) id <2B44X7QK>; Mon, 2 Apr 2001 12:54:28 +0530 Message-ID: From: "Tirumala, Srivathsa (Srivathsa)" To: "'M B'" , tcp-impl@lerc.nasa.gov Subject: RE: Lost connection Date: Mon, 2 Apr 2001 12:54:27 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > > Jon, > You're right. There is a Check Point firewall between LAN2 and LAN3. > And it translates all IPs coming from LAN1 and LAN2. As you said, > that would explain why a connection gets dropped after being idle > for 2 hours or so. > > LAN1....T1.....LAN2-FW-......FR.....LAN3 From your examples, its not clear that the control connection is the one that's being closed. Your example 2 shows that after one file xfer fails, you still send a TYPE command on the control connection.. and this is accepted by the server!! So the control connection is still up. And obviously, the data connection is not idle. > > But why would an FTP transfer go idle if it's coming from LAN1, while > FTP transfers from LAN2 finish normally? More info: > . LAN1 and LAN2 don't have any firewall between them. > . The problem started to occur only after the NT machine was moved > from LAN2 to LAN1. I guess LAN2 to LAN3 transfers take less than 2 hours. Bye Srivathsa From owner-tcp-impl@lerc.nasa.gov Tue Apr 3 12:06:28 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05681 for ; Tue, 3 Apr 2001 12:06:27 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id MAA26442; Tue, 3 Apr 2001 12:06:28 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma025561; Tue, 3 Apr 01 12:05:09 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA06970 for tcp-impl-outgoing; Tue, 3 Apr 2001 11:37:43 -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 LAA06902 for ; Tue, 3 Apr 2001 11:37:41 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA02301; Tue, 3 Apr 2001 11:37:37 -0400 Received: from ada.cs.ucy.ac.cy(194.42.7.2) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002265; Tue, 3 Apr 01 11:37:06 -0400 Received: from cs144 (cs144.cs.ucy.ac.cy [194.42.7.56]) by ada.cs.ucy.ac.cy (8.8.8/8.8.8) with SMTP id SAA38574 for ; Tue, 3 Apr 2001 18:43:02 +0300 Message-ID: <027f01c0bc54$befe5e70$38072ac2@cs.ucy.ac.cy> From: "Andreas Pitsillides" To: Subject: Call for participation -- Infocom 2001, April 22-26, 2001, Anchorage, Alaska Date: Tue, 3 Apr 2001 18:42:52 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1253" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit OUR SINCERE APOLOGIES FOR MULTIPLE COPIES C A L L F O R P A R T I C I P A T I O N I E E E I N F O C O M 2 0 0 1 http://www.ieee-infocom.org/2001 April 22-26, 2001 - Anchorage, Alaska TRAIN CHARTER: This year we are chartering a train for our welcome reception. This train ride will take you through the Kenai fjords and will include food and drinks. April 24, 6-11 pm. Seats are limited, and will be given out on the basis of registration date. CONFERENCE REGISTRATION: The deadline for advance registration is April 2, 2001 (5pm Eastern Standard Time). Please register early to ensure that you have a seat in the train charter. On-line registration is possible at our website at http://www.ieee-infocom.org/2001 and then clicking on "Registration Information". Your dinner code is 530T. Enter this code while registering and you may be a lucky winner of a $100 dinner at INFOCOM 2001. HOTEL REGISTRATION: Please book your hotel room early at the Marriott Anchorage Downtown. The Hilton is now completely sold out. The conference rates at both hotels are the same and the two hotels are within a 5 minute walking distance of each other. TOURS: Several tours of Alaska's natural treasures are planned. Please visit our website at http://www.ieee-infocom.org/2001 and look for "On-line tour registration". AIRLINE TICKETS: Please book your flights to Anchorage early, so that you can get reasonably priced tickets. TECHNICAL SESSIONS: 48 technical sessions featuring the latest research and trends in the field of computer communications and netwroking. TUTORIALS: Wireless Home Networks: Technologies and Applications Quality of Service (QoS) Support for Broadband Wireless Networks Traffic Engineering in IP/MPLS Networks TCP Congestion Controls: Algorithms and Models Video Over IP Bluetooth and Pervasive Wireless Networking Control and Management for Optical Networks: An IP-Centric Approach Principles of Multicast Protocols and Services PANELS: All-Optical Networks: Fact or Fiction Next Generation Wireless Networks: Radio, Networking and Applications Modeling of the Shrew: the Quest for a "Model" Network Model From owner-tcp-impl@lerc.nasa.gov Wed Apr 4 21:43:02 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06738 for ; Wed, 4 Apr 2001 21:43:01 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id VAA00486; Wed, 4 Apr 2001 21:43:02 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma029627; Wed, 4 Apr 01 21:41:41 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA19176 for tcp-impl-outgoing; Wed, 4 Apr 2001 21:18:33 -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 VAA19155 for ; Wed, 4 Apr 2001 21:18:31 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id VAA29472; Wed, 4 Apr 2001 21:18:29 -0400 Received: from mail.cs.umn.edu(128.101.32.200) by seraph3.lerc.nasa.gov via smap (V5.5) id xma029443; Wed, 4 Apr 01 21:17:39 -0400 Received: from kepler.cs.umn.edu (zhzhang@kepler.cs.umn.edu [128.101.34.78]) by mail.cs.umn.edu (8.11.3/8.11.3) with ESMTP id f351Hc708264 for ; Wed, 4 Apr 2001 20:17:38 -0500 (CDT) From: Zhi-Li Zhang Received: (from zhzhang@localhost) by kepler.cs.umn.edu (8.9.1/8.9.0) id UAA09499 for tcp-impl@lerc.nasa.gov; Wed, 4 Apr 2001 20:17:38 -0500 (CDT) Message-Id: <200104050117.UAA09499@kepler.cs.umn.edu> Subject: Deadline for Hot Interconnects 2001 Paper Submission Is Fast Approaching! To: tcp-impl@lerc.nasa.gov Date: Wed, 4 Apr 2001 20:17:38 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL60 (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 We apologize if you receive multiple copies. ============================================== CALL FOR PAPERS HOT INTERCONNECTS 9 A Symposium on High Performance Interconnects Memorial Auditorium, Stanford University, Aug. 22-24, 2001 (Sponsored by the IEEE Computer Society) http://www.hoti.org Hot Interconnects is an international symposium focusing on the hardware and software architecture and implementation of high-performance interconnects of all scales. Its themes include cross-cutting issues spanning computer systems and networking technologies for providing universal services over packet networks. Examples of relevant topics include network-attached storage, transport of voice and video over packet networks, high-performance network interfaces, novel switching and routing technologies capable of providing differentiated services, plug-and-play network interfaces, and active network architectures. The conference is directed particularly at new and exciting product and technology innovations in these areas. Contributions should focus on real products, prototypes, or experimental systems and their performance evaluation. In addition to those subscribing to the main theme of the conference, contributions are also solicited on the following topics: - Gb/sec and Tb/sec switching and routing technologies - High-speed packet processing engines - Serial link technologies - xDSL, HFC, and wireless access technologies - Mobility-enabling technologies - Seamless appliance interconnectivity - Network-attached storage devices and interfaces - Video and voice over packet networks - Wireless and mobile network interfaces - Network security - Next-generation networking chip sets - Network protocols on a chip - Low-power networking and interconnect technologies - Network appliance technologies - Optical Interconnects Submission Guidelines: --------------------------------- Submissions must be in the form of extended summaries and should not exceed 5 pages (double-column format). The summary should have sufficient technical detail to judge its quality and suitability for presentation at the conference. Guidelines for submission are available at http://www.hoti.org. Inquires about the conference should be directed to the TPC chairs. Important Dates: ----------------------- - Submission deadline: April 15, 2001. - Notification of acceptance: May 15, 2001. - Camera-ready due: July 1, 2001. Organizing Committee: --------------------------------- - General Chair: Fred Bauer, Nokia (fred@iprg.nokia.com) - Technical Program Chairs: - Marwan Krunz, University of Arizona (krunz@ece.arizona.edu) - John Lockwood, Washington University in St. Louis (lockwood@arl.wustl.edu) - Tutorial/Panel: Ibrahim Matta, Boston University (matta@cs.bu.edu) - Treasurer: Melanie Swan, MS Financial Consulting (melanie.swan@wharton.upenn.edu) - Registration: Bob Wedig, Wedig Consulting (bob@wedig.com) - Webmaster: Raymond Lee, IP Dynamics (raymondl@ipdynamics.com) - Local arrangements: Liz Rogers, Liz Rogers Design (liz@lizrogersdesign.com) - Publicity: Zhi-Li Zhang, University of Minnesota (zhzhang@cs.umn.edu) Technical Program Committee: Anujan Varma, University of California Santa Cruz Balaji Prabhakar, Stanford University Dan Pitt, Nortel Networks Ian Akyildiz, Georgia Institute of Technology James Yee, Pacific Broadband Peter Newman, Ensim Zhi-Li Zhang, University of Minnesota Nina Taft, Sprint Labs Christopher Diot, Sprint Labs George Apostolopoulos, Reback Networks Andrew Cambell, Columbia University Parameswaran Ramanathan, University of Wisconsin Mohan Kumar, University of Texas at Arlington Ron Srodawa, Oakland University James P.G. Sterbenz, BBN Edward Knightly, Rice University From owner-tcp-impl@lerc.nasa.gov Tue Apr 10 17:03:50 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26095 for ; Tue, 10 Apr 2001 17:03:50 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id RAA08416; Tue, 10 Apr 2001 17:03:46 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma007589; Tue, 10 Apr 01 17:02:25 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA05207 for tcp-impl-outgoing; Tue, 10 Apr 2001 16:38:24 -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 QAA05158; Tue, 10 Apr 2001 16:38:21 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA05331; Tue, 10 Apr 2001 16:38:20 -0400 Received: from louie.udel.edu(128.175.2.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005138; Tue, 10 Apr 01 16:37:28 -0400 Received: from calypso.cis.udel.edu by mail.eecis.udel.edu id aa00743; 10 Apr 2001 16:34 EDT Date: Tue, 10 Apr 2001 16:34:11 -0400 (EDT) From: Constantinos Dovrolis To: Constantinos Dovrolis Subject: ICNP 2001 - CFP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk -------------------------------------------------------------------------- CALL FOR PAPERS -------------------------------------------------------------------------- 9th International Conference on Network Protocols (ICNP 2001) Mission Inn, Riverside, California November 11-14, 2001 http://www.cis.udel.edu/icnp2001/ In just eight years, ICNP has established itself as one of the premier conferences in the computer networking field. ICNP deals with all aspects of communication protocols, from design and specification, to verification, testing, performance analysis, and implementation. Protocol functions of interest include network access, switching, routing, flow and congestion control, multimedia transport, wireless and mobile networks, network security, web protocols and applications, electronic commerce, network management, interoperability, internetworking, home computing and networks and digital broadcasting. ICNP 2001 will be held in Riverside, California, at the Mission Inn, a place filled with history. Riverside is located in the Sunny Southern California, 60 miles from Los Angeles, 45 miles from Palm Springs and 40 miles from Disney Land. The city is served by three nearby airports: Los Angeles, Ontario (California) and Orange County Airport. Topics of interest include, but are not limited to: - network access - switching - routing - flow and congestion control - multimedia transport protocols - wireless and mobile networks - network security - web protocols and applications - electronic commerce - network management - interoperability, internetworking - home computing and networking - digital broadcasting - QoS and service differentiation - network measurements - protocols for distributed games - peer-to-peer communication protocols Important Dates: Paper Submission Deadline: May 7, 2001 Tutorial Submission Deadline: May 7, 2001 Notification of Acceptance: July 13, 2001 Camera Ready Due: August 8, 2001 Tutorials: November 11, 2001 Conference: November 12 - 14, 2001 Information for authors: Papers must be written in English, and they have to be in Postscript, PDF, or Word format. The complete manuscript should be no more than 12 pages of double-spaced text with 11pt fonts. If you have any questions, you can contact us at icnp@ics.uci.edu. To register and submit your paper, visit the URL: http://violin.ics.uci.edu/~icnp/ConfMan/REG-paper/ General Chair Satish K. Tripathi, University of California - Riverside Technical Program Co-Chairs Magda El Zarki, University of California, Irvine Klara Narhstedt, University of Illinois, Urbana-Champaign Tutorial Co-Chairs Pravin Bhagwat, ReefEdge, Inc Ed Knightly, Rice University Local Arrangement and Registration Co-Chairs Michalis Faloutsos, University of California - Riverside Srikant Krishnamurthy, University of California - Riverside Publicity Co-Chairs Constantinos Dovrolis, University of Delaware Samar Singh, La Trobe University, Australia Technical Program Committee Alex Petrenko (CRIM, Computer Research Institute of Montreal) Ana Rosa CAVALLI (Institut National des Telecommunications, France) Mart, Molle (University of California, Riverside) Andrew T. Campbell (Columbia University) Bobby Bhattacharjee (University of Maryland) Christophe Diot (Sprint) Cormac J. Sreenan (University College, Cork, Ireland) David Hutchison (Lancaster University) David Su (National Institute of Standards and Technology) David, Yau (Computer Science, Purdue University) Edward Knightly (Rice University ) Ellen L. Hahne (AT&T Labs - Research) Geert Heijenk (Ericsson) Gene Tsudik (UC, Irvine) Geoffrey Xie (Naval Postgraduate School) Ernst W. Biersack (Institut EURECOM) Gunnar Karlsson (KTH Dpt. of Microelectronics and Info.Technology, Sweden) Hartmut Koenig (BTU Cottbus, Germany Hasan Ural (University of Ottawa, Canada) Ibrahim Matta (Boston University) Jennifer Hou (Ohio State University) Jorg Lieberherr (University of Virginia) Jorge Cobb (The University of Texas at Dallas) Ken Calvert (University of Kentucky) Kevin Almeroth (UC-Santa Barbara) Kirshna Sivalingam (Washington State University / Jasmine Networks) Lars Wolf (University of Karlsruhe, Germany) Lixia Zhang (UCLA) Ljiljana Trajkovic (Simon Fraser University) Luigi RIZZO (Dip. Ingegneria dell'Informazione, Univ. di Pisa (ITALY)) Marco Schneider (SBC Technology Resources Inc.) Martha Steenstrup (Stow Research L.L.C.) Martina Zittterbart (University of Karlsruhe, Germany) Masayuki Murata (Osaka University, Japan) Melody Moh (Dept. of Math. and Computer Science, San Jose State Univ.) Mohamed G. Gouda (University of Texas at Austin) Nalini Venkatasubramanian (University of California, Irvine) Chris Edmondson-Yurkanan (University of Texas) Ness B. Shroff (Purdue University) Nina Bhatti (Nokia) Robin Kravets (University of Illinois at Urbana-Champaign) Shigang Chen (Cisco Systems) Songwu Lu (UCLA) Stanislaw Budkowski (Institut National des Telecommunications (INT), France) Terry Todd (McMaster University, Canada) Teruo Higashino (Osaka University, Japan) Timothy Roscoe (Sprint Advanced Technology Labs) William Tezlaff (IBM T. J. Watson Research Center) Yoshiaki Kakuda (Hiroshima City University, Japan) Yow-Jian Lin (Bell Labs Research, Lucent Technologies) Yuval Shavitt (Bell Labs and Tel-Aviv University , Israel) ICNP Steering Committee Mostafa Ammar, Georgia Insitute of Technology Mohamed Gouda, University of Texas at Austin Simon Lam, University of Texas at Austin David Lee, Bell Labs Ming T. (Mike) Liu, Ohio State University Raymond Miller, University of Maryland, College Park Krishan Sabnani, Bell Labs From owner-tcp-impl@lerc.nasa.gov Wed Apr 11 14:40:08 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00748 for ; Wed, 11 Apr 2001 14:40:08 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id OAA13455; Wed, 11 Apr 2001 14:40:04 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma012792; Wed, 11 Apr 01 14:39:17 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA29454 for tcp-impl-outgoing; Wed, 11 Apr 2001 14:17:43 -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 OAA29393 for ; Wed, 11 Apr 2001 14:17:40 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA25911; Wed, 11 Apr 2001 14:17:38 -0400 Received: from mail.cs.umn.edu(128.101.35.200) by seraph3.lerc.nasa.gov via smap (V5.5) id xma025858; Wed, 11 Apr 01 14:17:09 -0400 Received: from kepler.cs.umn.edu (zhzhang@kepler.cs.umn.edu [128.101.34.78]) by mail.cs.umn.edu (8.11.3/8.11.3) with ESMTP id f3BIH8o22909 for ; Wed, 11 Apr 2001 13:17:08 -0500 (CDT) From: Zhi-Li Zhang Received: (from zhzhang@localhost) by kepler.cs.umn.edu (8.9.1/8.9.0) id NAA28762 for tcp-impl@lerc.nasa.gov; Wed, 11 Apr 2001 13:17:08 -0500 (CDT) Message-Id: <200104111817.NAA28762@kepler.cs.umn.edu> Subject: Deadline for Hot Interconnects 2001 Paper Submission Has Been Extended to May 1, 2001! To: tcp-impl@lerc.nasa.gov Date: Wed, 11 Apr 2001 13:17:08 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL60 (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 We apologize if you receive multiple copies. The deadline has been extended to May 1, 2001 !!! ************************************************* ============================================== CALL FOR PAPERS HOT INTERCONNECTS 9 A Symposium on High Performance Interconnects Memorial Auditorium, Stanford University, Aug. 22-24, 2001 (Sponsored by the IEEE Computer Society) http://www.hoti.org Hot Interconnects is an international symposium focusing on the hardware and software architecture and implementation of high-performance interconnects of all scales. Its themes include cross-cutting issues spanning computer systems and networking technologies for providing universal services over packet networks. Examples of relevant topics include network-attached storage, transport of voice and video over packet networks, high-performance network interfaces, novel switching and routing technologies capable of providing differentiated services, plug-and-play network interfaces, and active network architectures. The conference is directed particularly at new and exciting product and technology innovations in these areas. Contributions should focus on real products, prototypes, or experimental systems and their performance evaluation. In addition to those subscribing to the main theme of the conference, contributions are also solicited on the following topics: - Gb/sec and Tb/sec switching and routing technologies - High-speed packet processing engines - Serial link technologies - xDSL, HFC, and wireless access technologies - Mobility-enabling technologies - Seamless appliance interconnectivity - Network-attached storage devices and interfaces - Video and voice over packet networks - Wireless and mobile network interfaces - Network security - Next-generation networking chip sets - Network protocols on a chip - Low-power networking and interconnect technologies - Network appliance technologies - Optical Interconnects Submission Guidelines: --------------------------------- Submissions must be in the form of extended summaries and should not exceed 5 pages (double-column format). The summary should have sufficient technical detail to judge its quality and suitability for presentation at the conference. Guidelines for submission are available at http://www.hoti.org. Inquires about the conference should be directed to the TPC chairs. Important Dates: ----------------------- - Submission deadline: May 1, 2001. - Notification of acceptance: May 15, 2001. - Camera-ready due: July 1, 2001. Organizing Committee: --------------------------------- - General Chair: Fred Bauer, Nokia (fred@iprg.nokia.com) - Technical Program Chairs: - Marwan Krunz, University of Arizona (krunz@ece.arizona.edu) - John Lockwood, Washington University in St. Louis (lockwood@arl.wustl.edu) - Tutorial/Panel: Ibrahim Matta, Boston University (matta@cs.bu.edu) - Treasurer: Melanie Swan, MS Financial Consulting (melanie.swan@wharton.upenn.edu) - Registration: Bob Wedig, Wedig Consulting (bob@wedig.com) - Webmaster: Raymond Lee, IP Dynamics (raymondl@ipdynamics.com) - Local arrangements: Liz Rogers, Liz Rogers Design (liz@lizrogersdesign.com) - Publicity: Zhi-Li Zhang, University of Minnesota (zhzhang@cs.umn.edu) Technical Program Committee: Anujan Varma, University of California Santa Cruz Balaji Prabhakar, Stanford University Dan Pitt, Nortel Networks Ian Akyildiz, Georgia Institute of Technology James Yee, Pacific Broadband Peter Newman, Ensim Zhi-Li Zhang, University of Minnesota Nina Taft, Sprint Labs Christopher Diot, Sprint Labs George Apostolopoulos, Reback Networks Andrew Cambell, Columbia University Parameswaran Ramanathan, University of Wisconsin Mohan Kumar, University of Texas at Arlington Ron Srodawa, Oakland University James P.G. Sterbenz, BBN Edward Knightly, Rice University From owner-tcp-impl@lerc.nasa.gov Wed Apr 11 16:36:33 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02962 for ; Wed, 11 Apr 2001 16:36:32 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id QAA29896; Wed, 11 Apr 2001 16:36:33 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma029407; Wed, 11 Apr 01 16:35:34 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA25297 for tcp-impl-outgoing; Wed, 11 Apr 2001 16:18:40 -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 QAA25260; Wed, 11 Apr 2001 16:18:38 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA14290; Wed, 11 Apr 2001 16:18:37 -0400 Received: from chopin.cti.depaul.edu(140.192.32.73) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014256; Wed, 11 Apr 01 16:18:17 -0400 Received: from ehab2000 ([64.254.195.28]) by chopin.cti.depaul.edu with Microsoft SMTPSVC(5.0.2195.2345); Wed, 11 Apr 2001 15:18:10 -0500 Message-ID: <019b01c0c2c4$bd1c7030$1cc3fe40@cti.depaul.edu> Reply-To: "MMNS'2001" From: "MMNS'2001" To: "MMNS2001" Subject: Final CFP: IEEE/IFIP MMNS'2001 Date: Wed, 11 Apr 2001 15:19:38 -0500 Organization: DePaul University, MNLAB MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 11 Apr 2001 20:18:10.0419 (UTC) FILETIME=[87359C30:01C0C2C4] Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit << OUR APOLOGIES FOR MULTIPLE COPIES >> CALL FOR PAPERS Fourth IFIP/IEEE International Conference on Management of Multimedia Networks and Services (MMNS'2001) October 29- November 1, 2001 Chicago, Illinois, USA (http://www.mnlab.cs.depaul.edu/mmns2001) IMPORTANT DATES Submission deadline: April 20, 2001 Notification of acceptance: July 1, 2001 Final version due: July 21, 2001 Conference: October 29 to Nov 1, 2001 The IFIP/IEEE MMNS is the premier IEEE/IFIP conferences focusing on management of multimedia networks and services. The conference is known for its high-quality papers from various research communities. Selected papers will also be considered for publication as a special issue of the Journal of High Speed Networking and Journal of Networks and Information Systems. MMNS 2001 will provide Travel and Conference Scholarships for students. Topics of interest include, but are not limited to, the following: Distributed multimedia service management Integration of network control and management Network management models and architectures Distributed event correlation Monitoring QoS management Multimedia traffic management Resource, performance and fault management for broadband networks Configuration management of edge and core services for enabling multimedia traffic management Multi-point and multicast services management Resource management in wireless multimedia Wireless and mobile network management Mobility management Management of ad-hoc networks Multimedia content protection Deployment of multimedia services Active network management Network programmability for multimedia services Middleware support for management Multimedia session management Packet scheduling and dropping techniques Multimedia service Engineering Billing and security for broadband networks Policy-based management for multimedia service PAPER SUBMISSION PROCEDURE See . From owner-tcp-impl@lerc.nasa.gov Fri Apr 13 04:37:47 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03552 for ; Fri, 13 Apr 2001 04:37:47 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id EAA27603; Fri, 13 Apr 2001 04:37:47 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma027119; Fri, 13 Apr 01 04:36:55 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA06021 for tcp-impl-outgoing; Fri, 13 Apr 2001 04:15:32 -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 EAA06005; Fri, 13 Apr 2001 04:15:30 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id EAA27728; Fri, 13 Apr 2001 04:15:29 -0400 Received: from chopin.cti.depaul.edu(140.192.32.72) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027684; Fri, 13 Apr 01 04:14:58 -0400 Received: from ehab2000 ([64.254.195.78]) by chopin.cti.depaul.edu with Microsoft SMTPSVC(5.0.2195.2345); Fri, 13 Apr 2001 03:14:53 -0500 Message-ID: <01d801c0c3f2$06e13ba0$65c3fe40@cti.depaul.edu> Reply-To: "MMNS'2001" From: "MMNS'2001" To: "MMNS2001" Subject: CFP: MMNS'2001 Special Sessions Date: Fri, 13 Apr 2001 03:16:18 -0500 Organization: DePaul University, MNLAB MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 13 Apr 2001 08:14:53.0491 (UTC) FILETIME=[D1736830:01C0C3F1] Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit << OUR APOLOGIES FOR MULTIPLE COPIES >> CALL FOR PAPERS for Special Sessions in the Fourth IFIP/IEEE International Conference on Management of Multimedia Networks and Services (MMNS'2001) October 29- November 1, 2001, Chicago, Illinois, USA (http://www.mnlab.cs.depaul.edu/mmns2001) IMPORTANT DATES Submission deadline: April 20, 2001 Notification of acceptance: July 1, 2001 Final version due: July 21, 2001 MMNS has identified a number ``focus topics'' that are of particular relevance and importance to the field of multimedia network and service management. MMNS plans to conduct special sessions to address such hot issues. Papers submitted to these special sessions will go through the normal submission and review procedure. The goal is to build special sessions of exceptional papers all dealing with a closely related theme. The set of focus topics include the following: * INTERNET TRAFFIC MONITORING: The focus of this special session is on techniques and methodologies for collecting Internet traffic statistics, descriptions of collection systems implemented and deployed in the Internet, results from these systems, and analyses of these results describing how multimedia networks and services can be better managed. For questions about this special session, contact Kevin Almeroth (almeroth@cs.ucsb.edu). * Multimedia in AD-HOC NETWORKS: Networks of the future are envisioned to integrate the Internet with wireless mobile embedded devices and ad-hoc networks. Ad-hoc networks are collections of wireless mobile nodes that can be deployed rapidly without pre-existing or centralized communication infrastructure. These networks should support various types of multimedia traffic, including audio, video, TC-based data, and sensory data. Due to the nature of ad-hoc networks, number of new challenges must be addressed in order to facilitate seamless services of Ad-hoc networks. This includes unicast and multicast routing protocols, power-aware protocols in almost all layers of the network stack, quality and guarantee of service provisioning for multimedia traffic, self-configuring hierarchies and architectures, address allocation and naming, data dissemination techniques, efficient mobility support, fault and performance management tools, performance analysis of end-to-end protocols such as TCP and reliable multicast over ad-hoc networks. For questions about this special session, contact Ahmed Helmy (helmy@ceng.usc.edu) * RESOURCE MANAGEMENT FOR WIRELESS MULTIMEDIA: Broadband wireless multimedia services are becoming very popular. This special session will focus on architectures and techniques for supporting QoS Internet wireless multimedia. The session is looking for original contributions in this demanding area that address related issues. This includes integration of personal wireless multimedia into the Internet, efficient resource management techniques that consider the limited resources in wireless systems, such as spectrum resource and transmitter power, mobility management, bandwidth allocation, location and handoff procedures, channel access and assignment, call admission control, and end-to-end adaptive control for wireless multimedia. For questions about this special session, contact Muhammad Jaseemuddin (jaseem@nortelnetworks.com) * MOBILE AGENT-BASED NETWORK MANAGEMENT: Research and development on various forms of agents and mobile agents is continuing to grow in a staggering fashion in recent years. Agent-based telecommunication applications and services such as active networks, Qos and bandwidth brokers, E-commerce, information gathering on Internet, and feature interactions are becoming increasingly popular and are largely contributing to the development and to the success of distributed multimedia technology. This session will focus on research and development activities related to the field of agents in the area of active networks, and QoS agent-based architectures for managing multimedia networks and distributed services. The objective is to provide the audiences with a clear background into the opportunities and the challenges that the mobile agent emerging paradigm brings about For questions about this special session, contact Ahmed Karmouch (karmouch@site.uottawa.ca), Nazism Agoulmine (nazim@rp.lip6.fr) or Allan Marshall (a.marshall@ee.qub.ac) From owner-tcp-impl@lerc.nasa.gov Sun Apr 15 20:39:31 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13098 for ; Sun, 15 Apr 2001 20:39:31 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id UAA09335; Sun, 15 Apr 2001 20:39:25 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma008540; Sun, 15 Apr 01 20:38:44 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA03386 for tcp-impl-outgoing; Sun, 15 Apr 2001 20:10: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 TAA02862; Sun, 15 Apr 2001 19:57:30 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA10190; Sun, 15 Apr 2001 19:57:29 -0400 Received: from cm20816625250.coralsprings.ispchannel.com(208.166.25.250) by seraph3.lerc.nasa.gov via smap (V5.5) id xma010166; Sun, 15 Apr 01 19:56:33 -0400 X-Mailer: ALPHA_XMR75_00001SLBL Subject: RE: Biz To Business Database Disc Message-Id: <01m41pokm16f1n4h6b7c.2rd31f0k7pilos8cub5@yahoo.com> From: jerryrice@myplace.com To: jerryrice@address.com Reply-To: helena12@lovemail.com Date: Sun, 15 Apr 2001 20:01:03 -0500 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit As a dot.com professional you know that it is essential to your teams' success to advertise your web site, business, product, service, or your organizations' cause to the masses. You also know that your marketing and advertising budget limits your options. If you are a Fortune 500 corporation, you have the advantage of being able to book 30 second TV spots during the SuperBowl. Most of us are not in that position though. Besides, did you know that something on the order of 92% of TV viewers run to the washroom at commercial breaks during the program, thereby missing the expensive commercial spot. Q: Of all the various advertising mediums which do you feel is most effective, in cases when you require your prospect to remember your telephone number or web address? Let's outline and agree on a list of the main advertising and marketing mediums first: - Television Commercial - Television Infomercial - Internet Banner Ads (paid for on a click-through basis) - Internet Banner Ads (paid for on an impression basis) - So-Called opted-in email list rental and broadcast - Radio Commercial - Print Media (Newspapers, Magazines) - Print Media (Hand-Outs) - Trade Shows - News or Media organization story or profile on your project - Affiliate Links - Signage - Telemarketing - Direct Mail - Broadcast Fax (not personalized to its recipients) - Broadcast Fax (personalized and to the Attention of its recipients) - Targeted Broadcast Email (personalized or not) Now consider the effectiveness of each advertising choice, remembering that in many cases your audience must still remember a telephone number in order to contact you. Q: Which is the least costly and most effective? E-mail marketing works! Why? There are many reasons, but primarily because people are focused on their monitors while checking their e-mail. Totally focused. In addition, they have a hard copy of your ad on their hard drive, and it is simple for them to forward the ad to their friends and associates as well. You can tell your story with more words and target your list to particular types of recipients or geographical areas. We offer some of the best delivery and bulk e-mail prices on the Internet. Bulk e-mail can get you the best exposure on the net. What makes this kind of advertising so effective is the fact that you go to the potential customer. Not like search engines or print ads that the potential customer has to do all the searching. Dollar for dollar bulk e-mailing is also the most economical. We do all the mailing for you. You just provide us with the ad! It's that simple! What we offer is simple: *General Lists or other ISPs #100,000 Emails $495.00 #250,000 Emails $995.00 #500,000 Emails $1,495.00 #1,000,000 Emails $2,495.00 #2,500,000 Emails $4,995.00 #5,000,000+ Emails (Call for Quote) WE ALSO HAVE LARGER PACKAGES! *Targeted Lists (Starting @): #100,000 Emails $995.00 #250,000 Emails $1,495.00 #500,000 Emails $2,995.00 #1,000,000 Emails (Call for Quote) METHOD OF PAYMENT, CASHIERS CHECK MONEY ORDER OR BANK WIRE. $$$GET AN ADDITIONAL FREE 25% ON TOP OF EVERY ORDER... IF YOU ORDER WITHIN 5 DAYS OF RECIEVING THIS MESSAGE! Call for bigger packages! ORDER NOW!!! AND GET THE RIGHT EXPOSURE! For more details on Email Services, please call: #954.340.1628 (US & International) IF YOU ARE THE DO IT YOURSLF TYPE OR ARE STILL USING TRADITONAL MARKETING TECHNICS, YOU MUST TAKE A LOOK AT THE 8 1/2 MILLION BUSINESS TO BUSINESS DATABASE!! Our 3.0 Version B2B Database Will Go Online and Sell For 2.5 to 25 Cents Per Record in early July! (Extended Due to Delays From The 1st) You can now access contact data for over 8.5 Million Records. All of them have their own .com .org or .net domain name, making them serious prospects for Internet business. Our data base readily accessible on CD-Rom, list the Names, Contact Information, Physical Address, Phone #, Fax #, SIC Industry Code, URL (Domain Name), and Contact Email Address which you can use to efficiently target companies worldwide. Over 8.5 Million Physical Addresses let you target businesses by Country, State, City, Province, Zip Code, Area Code or by using the SIC Industry Code. The data comes in a Comma-Delimited ASCII format which makes it easy to manipulate and Import/Export records to your Contact-Management, Spreadsheet, analysis and Broadcasting Applications. We’d be happy to give you rough counts for your industry target market. We also build databases to order and carry more than a dozen other data bases both Domestic and International ( B2B and B2C). Please send me more info about: [ ] Master Disc 2000 8.5 Million Records, Cost US$799.00 [ ] Online Updates & Download Access Cost US$199.00 (Annually) [ ] Commercial Email Services & Products Note: Not all records contain complete data, call for breakdowns. For more details on Database, please call: #954.340.1628 (US & International) or fax form below to: #954.753.2846 (Make Sure To Mention Reseller Id #1789 When Calling) Company name: ___________________________________________ Web Site Url: ___________________________________________ Contact name: ___________________________________________ Email: __________________________________________________ Phone: __________________________________________________ Fax: ___________________________________________________ Street address: _________________________________________ City, Zip, State: _______________________________________ Country: ________________________________________________ Check the following that apply: _____ Please Notify Me Of Online Web Site & Register Me For Access Using The Information Above. Also Please, Send Additional Information on: _____ Online Adult & Gaming Owner/Operaters _____ Online Adult Subscribers & Online Gamers Databases _____ Online Billing/Credit Card Processing _____ Emailing Services and Databases _____ Search Engine Positioning _____ International Contact Lists _____ Buying / Selling Traffic _____ Web Site Hosting Services _____ Internet Bandwidth Services (T-1's Starting at $999.00) _____ Other:_______________________________ ############################################################################## ############################################# THIS MESSAGE IS BEING SENT IN COMPLIANCE OF THE EMAIL BILL: SECTION 301. PER SECTION, PARAGRAPH (a) (2) (c) of S. 1618. To discontinue receipt of further notice at not cost and to be removed from our database, please reply with the word "Remove" in subject. Or call us at #954.340.1628 leave your email address for removal from the database and future mailings. Any attempts to disrupt the removal email address etc., will not allow us to be able to retrieve and process the remove requests. ############################################################################## ############################################# .0401601 From owner-tcp-impl@lerc.nasa.gov Wed Apr 18 15:56:01 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@[198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16779 for ; Wed, 18 Apr 2001 15:56:00 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA13109; Wed, 18 Apr 2001 15:55:58 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011520; Wed, 18 Apr 01 15:54:31 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA29718 for tcp-impl-outgoing; Wed, 18 Apr 2001 15:33:04 -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 PAA29691 for ; Wed, 18 Apr 2001 15:33:03 -0400 (EDT) From: bp@terran.org Received: by seraph3.lerc.nasa.gov; id PAA06344; Wed, 18 Apr 2001 15:33:02 -0400 Received: from klawatti.watchguard.com(64.74.30.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006269; Wed, 18 Apr 01 15:32:18 -0400 Date: Wed, 18 Apr 2001 12:29:45 -0700 (PDT) To: IETF TCP WG Subject: SYN-flood protection - in a router Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, First let me provide a bit of background behind the motivation for this post. I first stumbled on the archive of this WG mailing list a few days ago, and have been busily reading as much of the history as possible (particularly the existing threads on SYN-flood protection, including SYN-cookies). I have also read the code for SYN/RST-cookies in Linux-2.0 (dated). It is quite a fascinating subject. :-) I believe I have a relatively sound (though not complete) grasp on the subject, where the point of implementation is the server TCP. However, I could find no reference to prevention (or hindrance) of SYN-flood attacks at the router, for the benefit of client TCP's on the other side. I have given considerable thought over the last few weeks to how such a solution could be implemented with the least amount of state-tracking and latency. I am curious to know if there have been any other such (documented) projects, and if anyone would be interested to discuss the idea further. Cordially, - -bp - -- # bp at terran dot org # http://www.terran.org/~bryan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE63estqAGIoYtXZJERAhntAKDlHUE2LsNpZqZ9J8ftGJmAOc8ZDQCeJUT/ MH2sf4UYW90vCkJMIBQpQMI= =t7O9 -----END PGP SIGNATURE----- From owner-tcp-impl@lerc.nasa.gov Wed Apr 18 16:28:00 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@[198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17360 for ; Wed, 18 Apr 2001 16:27:58 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA28194; Wed, 18 Apr 2001 16:27:53 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027099; Wed, 18 Apr 01 16:26:49 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA08633 for tcp-impl-outgoing; Wed, 18 Apr 2001 16:12:21 -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 QAA08619 for ; Wed, 18 Apr 2001 16:12:20 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA24101; Wed, 18 Apr 2001 16:12:19 -0400 Received: from router-100m.swansea.linux.org.uk(194.168.151.17) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024015; Wed, 18 Apr 01 16:12:09 -0400 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 14pyKT-0005cv-00; Wed, 18 Apr 2001 21:13:33 +0100 Subject: Re: SYN-flood protection - in a router To: bp@terran.org Date: Wed, 18 Apr 2001 21:13:31 +0100 (BST) Cc: tcp-impl@grc.nasa.gov (IETF TCP WG) In-Reply-To: from "bp@terran.org" at Apr 18, 2001 12:29:45 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 > subject, where the point of implementation is the server TCP. However, I > could find no reference to prevention (or hindrance) of SYN-flood attacks > at the router, for the benefit of client TCP's on the other side. I have Why bother ? Its solved at the client now > could be implemented with the least amount of state-tracking and latency. And multipath handling, and failover and ... All of a sudden the router one looks extremely unattractive. As is normally the case. From owner-tcp-impl@lerc.nasa.gov Wed Apr 18 16:59:17 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@[198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17867 for ; Wed, 18 Apr 2001 16:59:16 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA07219; Wed, 18 Apr 2001 16:59:14 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006247; Wed, 18 Apr 01 16:57:48 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA14347 for tcp-impl-outgoing; Wed, 18 Apr 2001 16:40:43 -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 QAA14321 for ; Wed, 18 Apr 2001 16:40:41 -0400 (EDT) From: bp@terran.org Received: by seraph3.lerc.nasa.gov; id QAA02455; Wed, 18 Apr 2001 16:40:40 -0400 Received: from klawatti.watchguard.com(64.74.30.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002395; Wed, 18 Apr 01 16:40:08 -0400 Date: Wed, 18 Apr 2001 13:37:35 -0700 (PDT) To: Alan Cox cc: IETF TCP WG Subject: Re: SYN-flood protection - in a router 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 18 Apr 2001, Alan Cox wrote: > > subject, where the point of implementation is the server TCP. However, > > I could find no reference to prevention (or hindrance) of SYN-flood > > attacks at the router, for the benefit of client TCP's on the other > > side. I have > > Why bother ? Its solved at the client now [correction on my part: s/client/server/ above, though the discussion is not affected by said substituion] If the server is too lame to provide SYN-flood countermeasures itself, then the router [read: firewall] could provide it, and protect multiple such lame systems at once. I have read documentation on how at least one rather large vendor designed such a solution in their firewall product. > > could be implemented with the least amount of state-tracking and > > latency. > > And multipath handling, and failover and ... > > All of a sudden the router one looks extremely unattractive. As is normally > the case. SYN-flood countermeasures in a firewall are quite common today (IINM, more offer it than don't). I am not arguing that it is the ideal solution (or even a preferable one), only that it can be done and does seem to offer some advantages. I am hoping to learn more about the practical and technical aspects of such designs. Respectfully, - -bp - -- # bp at terran dot org # http://www.terran.org/~bryan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE63fsSqAGIoYtXZJERAnz/AKCAJcAxcshk9cQ8le2YjeFcRYVIXwCgtkC5 t0dhAyo12cc+2G7pGki4+iI= =LiVh -----END PGP SIGNATURE----- From owner-tcp-impl@lerc.nasa.gov Wed Apr 18 17:44:49 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@[198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18461 for ; Wed, 18 Apr 2001 17:44:48 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA17058; Wed, 18 Apr 2001 17:44:46 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015795; Wed, 18 Apr 01 17:42:57 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA21964 for tcp-impl-outgoing; Wed, 18 Apr 2001 17:28:31 -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 RAA21923 for ; Wed, 18 Apr 2001 17:28:29 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA13172; Wed, 18 Apr 2001 17:28:28 -0400 Received: from janeway.comnets.rwth-aachen.de(137.226.4.228) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013117; Wed, 18 Apr 01 17:28:25 -0400 Received: from comnets.rwth-aachen.de (nigrita [137.226.4.188]) by janeway.comnets.rwth-aachen.de (8.9.3+Sun/8.9.1) with ESMTP id XAA06173 for ; Wed, 18 Apr 2001 23:28:19 +0200 (MET DST) Message-ID: <3ADE06F3.F4697FF3@comnets.rwth-aachen.de> Date: Wed, 18 Apr 2001 23:28:19 +0200 From: Jan-Oliver Rock X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Selective ACKs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi out there! I'm working on a SACK implementation in SDL and came across something that has me a little confused. My main sources are the following papers: (1) RFC 2018 (SACK) (2) "Simulation-based Comparisons of Tahoe, Reno and SACK TCP" by Fall/Floyd (2) "A Conservative SACK-based Loss Recovery Algorithm for TCP" by Allman (1) and (2) state that adding SACK to TCP does not change the basic underlying congestion control algorithms. My concern is about the CWND variable (congestion window). On entering the loss recovery phase (after receiving 3 dupAcks), the Reno TCP halves SSTHRESH, retransmits the lost packet and then halves CWND and adds 3*MSS (I'm not taking into account the advertised window here). More incoming dupAcks will increase CWND by one MSS (fast recovery). From my understanding of (2) and (3), on entering loss recovery phase in SACK, the CWND is first halved but then frozen and *not* increased afterwards (as in fast recovery in Reno), because incoming dupAcks are now handled by the PIPE variable. When SACK leaves loss recovery, CWND is handled as in Reno, e.g. congestion avoidance takes over. Is my view on this correct ? Thank you, Olli From owner-tcp-impl@lerc.nasa.gov Thu Apr 19 15:00:20 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@[198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16507 for ; Thu, 19 Apr 2001 15:00:19 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA03978; Thu, 19 Apr 2001 15:00:17 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002909; Thu, 19 Apr 01 14:58:46 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA06544 for tcp-impl-outgoing; Thu, 19 Apr 2001 14:39:11 -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 OAA06523 for ; Thu, 19 Apr 2001 14:39:10 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA28147; Thu, 19 Apr 2001 14:39:09 -0400 Received: from albatross.mail.pas.earthlink.net(207.217.120.120) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028011; Thu, 19 Apr 01 14:38:55 -0400 Received: from myself.com (ip192.tampa7.fl.pub-ip.psi.net [38.37.6.192]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id LAA29087; Thu, 19 Apr 2001 11:38:52 -0700 (PDT) Message-ID: <3ADF317D.B80670FB@myself.com> Date: Thu, 19 Apr 2001 14:42:05 -0400 From: Drew Simonis X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: bp@terran.org CC: IETF TCP WG Subject: Re: SYN-flood protection - in a router References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit bp@terran.org wrote: > > I believe I have a relatively sound (though not complete) grasp on the > subject, where the point of implementation is the server TCP. However, I > could find no reference to prevention (or hindrance) of SYN-flood attacks > at the router, for the benefit of client TCP's on the other side. I'm surprised at this. Cisco routers have been dealing with SYN floods for some time now. Maybe not in the way you imagine, but it is somewhat effective. One can choose from several methods, includind using QoS and WFQ, or you can use other traffic shaping methods. Most people, however, use Commited Access Rate, or CAR filtering. Furthermore, Cisco router models > 4000 support TCP Intercept, which is designed specifically to combat SYN floods. Other vendors, I don't know, but there are well documented and well known methods for combating SYN flooding at the transit level. From owner-tcp-impl@lerc.nasa.gov Mon Apr 23 05:00:20 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@[198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02756 for ; Mon, 23 Apr 2001 05:00:20 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id FAA13743; Mon, 23 Apr 2001 05:00:20 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011432; Mon, 23 Apr 01 04:57:34 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA02328 for tcp-impl-outgoing; Mon, 23 Apr 2001 04:33:12 -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 EAA02319; Mon, 23 Apr 2001 04:33:10 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id EAA08885; Mon, 23 Apr 2001 04:33:09 -0400 Received: from chopin.cti.depaul.edu(140.192.32.72) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008860; Mon, 23 Apr 01 04:32:52 -0400 Received: from ehab2000 ([64.254.195.52]) by chopin.cti.depaul.edu with Microsoft SMTPSVC(5.0.2195.2345); Mon, 23 Apr 2001 03:32:35 -0500 Message-ID: <00b501c0cbd0$2cdc8720$9fc3fe40@cti.depaul.edu> From: "Ehab Al-Shaer" To: "MMNS2001" Subject: IEEE/IFIP MMNS2001 Deadline Extension Date: Mon, 23 Apr 2001 03:34:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 23 Apr 2001 08:32:35.0139 (UTC) FILETIME=[F25F8930:01C0CBCF] Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Due to the numerous requests, the Submission Deadline of MMNS2001 (www.mnlab.cs.depaul.edu/mmns2001) will be extended to MAY 6, 2001. ---------------------------------------------------------------------------- ---------- CALL FOR PAPERS Fourth IFIP/IEEE International Conference on Management of Multimedia Networks and Services (MMNS'2001) October 29- November 1, 2001 Chicago, Illinois, USA IMPORTANT DATES Submission deadline: May 6, 2001 Notification of acceptance: July 1, 2001 Final version due: July 21, 2001 Conference: October 29 to Nov 1, 2001 The IFIP/IEEE MMNS is the premier IEEE/IFIP conferences focusing on management of multimedia networks and services. The conference is known for its high-quality papers from various research communities. Selected papers will also be considered for publication as a special issue of the Journal of High Speed Networking and Journal of Networks and Information Systems. MMNS 2001 will provide Travel and Conference Scholarships for students. Topics of interest include, but are not limited to, the following: Distributed multimedia service management Integration of network control and management Network management models and architectures Distributed event correlation Monitoring QoS management Multimedia traffic management Resource, performance and fault management for broadband networks Configuration management of edge and core services for enabling multimedia traffic management Multi-point and multicast services management Resource management in wireless multimedia Wireless and mobile network management Mobility management Management of ad-hoc networks Multimedia content protection Deployment of multimedia services Active network management Network programmability for multimedia services Middleware support for management Multimedia session management Packet scheduling and dropping techniques Multimedia service Engineering Billing and security for broadband networks Policy-based management for multimedia service PAPER SUBMISSION PROCEDURE See . From owner-tcp-impl@lerc.nasa.gov Mon Apr 23 05:17:35 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@[198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02827 for ; Mon, 23 Apr 2001 05:17:34 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id FAA17677; Mon, 23 Apr 2001 05:17:34 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016654; Mon, 23 Apr 01 05:16:33 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA03921 for tcp-impl-outgoing; Mon, 23 Apr 2001 05:02: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 FAA03889 for ; Mon, 23 Apr 2001 05:02:34 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id FAA15301; Mon, 23 Apr 2001 05:02:32 -0400 Received: from tc092.bbn.com(128.33.238.92) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015160; Mon, 23 Apr 01 05:01:31 -0400 Received: from lawyers (mallman@localhost) by lawyers.grc.nasa.gov (8.9.3/8.9.3) with ESMTP id FAA08253; Mon, 23 Apr 2001 05:01:06 -0400 Message-Id: <200104230901.FAA08253@lawyers.grc.nasa.gov> To: Jan-Oliver Rock From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tcp-impl@grc.nasa.gov, "Ethan Blanton" Subject: Re: Selective ACKs Organization: BBN Technologies/NASA GRC Song-of-the-Day: Piano Man Date: Mon, 23 Apr 2001 05:01:06 -0400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > (2) "A Conservative SACK-based Loss Recovery Algorithm for TCP" by > Allman (Actually most of the credit goes to Ethan Blanton, but anyway...) > (1) and (2) state that adding SACK to TCP does not change the > basic underlying congestion control algorithms. My concern is > about the CWND variable (congestion window). On entering the loss > recovery phase (after receiving 3 dupAcks), the Reno TCP halves > SSTHRESH, retransmits the lost packet and then halves CWND and > adds 3*MSS (I'm not taking into account the advertised window > here). More incoming dupAcks will increase CWND by one MSS (fast > recovery). >From my understanding of (2) and (3), on entering > loss recovery phase in SACK, the CWND is first halved but then > frozen and *not* increased afterwards (as in fast recovery in > Reno), because incoming dupAcks are now handled by the PIPE > variable. When SACK leaves loss recovery, CWND is handled as in > Reno, e.g. congestion avoidance takes over. Is my view on this > correct ? Right. Immediatly after recovery is finished cwnd should be the same in both cases. Fast recovery just sort of overloads cwnd during recovery to accomplish what pipe does during SACK-based recovery. allman --- Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ From owner-tcp-impl@lerc.nasa.gov Mon Apr 23 21:54:43 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@[198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17071 for ; Mon, 23 Apr 2001 21:54:42 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id VAA25015; Mon, 23 Apr 2001 21:54:42 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024050; Mon, 23 Apr 01 21:53:38 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA24432 for tcp-impl-outgoing; Mon, 23 Apr 2001 21:34:41 -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 VAA24425 for ; Mon, 23 Apr 2001 21:34:40 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id VAA21949; Mon, 23 Apr 2001 21:34:39 -0400 Received: from mail.cs.umn.edu(128.101.32.200) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021941; Mon, 23 Apr 01 21:34:03 -0400 Received: from kepler.cs.umn.edu (zhzhang@kepler.cs.umn.edu [128.101.34.78]) by mail.cs.umn.edu (8.11.3/8.11.3) with ESMTP id f3O1Y2R13343 for ; Mon, 23 Apr 2001 20:34:02 -0500 (CDT) From: Zhi-Li Zhang Received: (from zhzhang@localhost) by kepler.cs.umn.edu (8.9.1/8.9.0) id UAA26579 for tcp-impl@lerc.nasa.gov; Mon, 23 Apr 2001 20:34:02 -0500 (CDT) Message-Id: <200104240134.UAA26579@kepler.cs.umn.edu> Subject: Deadline for Hot Interconnects 2001 Paper Submission (May 1) Is Again Fast Approach! To: tcp-impl@lerc.nasa.gov Date: Mon, 23 Apr 2001 20:34:02 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL60 (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 We apologize if you receive multiple copies. *********************************************************************** Deadline for Hot Interconnects 2001 for Paper Submission: May 1 2001!!! *********************************************************************** ======================================================================= CALL FOR PAPERS HOT INTERCONNECTS 9 A Symposium on High Performance Interconnects Memorial Auditorium, Stanford University, Aug. 22-24, 2001 (Sponsored by the IEEE Computer Society) http://www.hoti.org Hot Interconnects is an international symposium focusing on the hardware and software architecture and implementation of high-performance interconnects of all scales. Its themes include cross-cutting issues spanning computer systems and networking technologies for providing universal services over packet networks. Examples of relevant topics include network-attached storage, transport of voice and video over packet networks, high-performance network interfaces, novel switching and routing technologies capable of providing differentiated services, plug-and-play network interfaces, and active network architectures. The conference is directed particularly at new and exciting product and technology innovations in these areas. Contributions should focus on real products, prototypes, or experimental systems and their performance evaluation. In addition to those subscribing to the main theme of the conference, contributions are also solicited on the following topics: - Gb/sec and Tb/sec switching and routing technologies - High-speed packet processing engines - Serial link technologies - xDSL, HFC, and wireless access technologies - Mobility-enabling technologies - Seamless appliance interconnectivity - Network-attached storage devices and interfaces - Video and voice over packet networks - Wireless and mobile network interfaces - Network security - Next-generation networking chip sets - Network protocols on a chip - Low-power networking and interconnect technologies - Network appliance technologies - Optical Interconnects Submission Guidelines: --------------------------------- Submissions must be in the form of extended summaries and should not exceed 5 pages (double-column format). The summary should have sufficient technical detail to judge its quality and suitability for presentation at the conference. Guidelines for submission are available at http://www.hoti.org. Inquires about the conference should be directed to the TPC chairs. Important Dates: ----------------------- - Submission deadline: May 1, 2001. - Notification of acceptance: May 15, 2001. - Camera-ready due: July 1, 2001. Organizing Committee: --------------------------------- - General Chair: Fred Bauer, Nokia (fred@iprg.nokia.com) - Technical Program Chairs: - Marwan Krunz, University of Arizona (krunz@ece.arizona.edu) - John Lockwood, Washington University in St. Louis (lockwood@arl.wustl.edu) - Tutorial/Panel: Ibrahim Matta, Boston University (matta@cs.bu.edu) - Publicity: Zhi-Li Zhang, University of Minnesota (zhzhang@cs.umn.edu) - Treasurer: Melanie Swan, MS Financial Consulting (melanie.swan@wharton.upenn.edu) - Registration: Bob Wedig, Wedig Consulting (bob@wedig.com) - Webmaster: Raymond Lee, IP Dynamics (raymondl@ipdynamics.com) - Local arrangements: Liz Rogers, Liz Rogers Design (liz@lizrogersdesign.com) Technical Program Committee: Ian Akyildiz, Georgia Institute of Technology George Apostolopoulos, Redback Networks Mohammed Atiquzzaman, University of Oklahoma Andrew Cambell, Columbia University Christopher Diot, Sprint Labs S. Keshav, Ensim Edward Knightly, Rice University Mohan Kumar, University of Texas at Arlington Bryan Lyles, Sprint Labs Peter Newman, Ensim James P.G. Sterbenz, BBN Dan Pitt, Nortel Networks Balaji Prabhakar, Stanford University Parameswaran Ramanathan, University of Wisconsin Ron Srodawa, Oakland University Nina Taft, Sprint Labs Anujan Varma, University of California Santa Cruz Marcel Waldvogel, Washington University in Saint Louis James Yee, Pacific Broadband Zhi-Li Zhang, University of Minnesota