From owner-tcp-impl@lerc.nasa.gov Fri Sep 3 22:08:30 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16273 for ; Fri, 3 Sep 1999 22:08:29 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA06570 for tcp-impl-outgoing; Fri, 3 Sep 1999 19:13:21 -0400 (EDT) Received: from dangle.wins.hrl.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA06554; Fri, 3 Sep 1999 19:13:15 -0400 (EDT) Received: from ambrose.wins.hrl.com by dangle.wins.hrl.com (5.65v3.2/1.1.10.5/24Apr98-0905PM) id AA22999; Fri, 3 Sep 1999 16:09:41 -0700 Message-Id: <37D054B1.BF2DA6E3@hrl.com> Date: Fri, 03 Sep 1999 16:07:29 -0700 From: Dennis Connors Organization: Networking and Media Computing Group at HRL Laboratories X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: Michael.J.Zernic@lerc.nasa.gov, Huzy-Ing Liu , tcpsat , tcpimpl , end2end Cc: Son Dao , Srikanth Krishnamurthy , "Ron P. Smith" , Shirley Tseng , "Falk, Aaron" , Tom Henderson , "Randy H. Katz" , Jason Neale , nkarafol@estec.esa.nl, Hassan Peyravi , Kul Bhasin , " =?iso-8859-1?Q?Marie=2DJos=E9?= Montpetit" , Sastri Kota , Andrea Baiocchi , "Walter J.Ciesluk" , Anthony Ephremides Subject: Deadline Extended For WOSBIS 99 Content-Type: multipart/mixed; boundary="------------56E1596476C7A352C37D8CB3" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. --------------56E1596476C7A352C37D8CB3 Content-Type: multipart/alternative; boundary="------------F0CB23C97E8EE31D70DB326A" --------------F0CB23C97E8EE31D70DB326A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Colleges, The deadline for WOSBIS 99 , the Workshop on Satellite Based Information Systems to be held in conjunction with Globecom, has been extended until September 24, 1999. Please consider submitting a paper to our conference. I apologize in advance if you receive multiple copies of this CFP. Dennis -- Dennis P. Connors email: connors@hrl.com Research Staff Member Information Sciences Laboratory fax: (310) 317-5695 HRL Laboratories, L.L.C. (formerly Hughes Research Labs) BLDG 254, M/S RL96 3011 Malibu Canyon Road Malibu, CA 90265 URL: http://www.wins.hrl.com/3.0/people/connors --------------F0CB23C97E8EE31D70DB326A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Dear Colleges,

The deadline for WOSBIS 99 , the Workshop on Satellite Based Information Systems to be held in conjunction with Globecom, has been extended until September 24, 1999.  Please consider submitting a paper to our conference.

I apologize in advance if you receive multiple copies of this CFP.

Dennis
 
 
  

-- 
Dennis P. Connors                               email: connors@hrl.com
Research Staff Member                           
Information Sciences Laboratory                 fax: (310) 317-5695
HRL Laboratories, L.L.C. 
(formerly Hughes Research Labs)
BLDG 254, M/S RL96
3011 Malibu Canyon Road
Malibu, CA  90265
URL: http://www.wins.hrl.com/3.0/people/connors
  --------------F0CB23C97E8EE31D70DB326A-- --------------56E1596476C7A352C37D8CB3 Content-Type: text/plain; charset=us-ascii; name="call-for-papers-wosbis99.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="call-for-papers-wosbis99.txt" Content-Transfer-Encoding: 7bit * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * CALL FOR PAPERS * * * * WOSBIS 99 * * * * Fourth IEEE International Workshop on * * Satellite-Based Information Systems * * Wednesday, December 8th, 1999 * * Rio de Janeiro, Brazil * * * * In conjunction with IEEE Globecom 99 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * SCOPE Satellite communications will play an increasingly important role in our future information-based society. This is evidenced by the systems currently in operation (e.g., DirecTV(TM), DirecPC, GPS, and Iridium) as well as those to offer broadband, interactive, and multimedia Internet services around the next millenium (SpaceWay, Teledesic, Astrolink, etc.). WOSBIS, held three times in 96, 97, 98 in conjunction with MobiCOM, is a premier workshop on satellite networks and services and provides a forum for exploratory research contributions on lifting the technological barriers to achieve innovative satellite applications and services. This year, WOSBIS will be held in conjunction with GLOBECOM'99 and focuses on the communication aspect of satellite-based information services, more specifically in the network layer, data link layer, and medium access sub-layer. We are interested in work that is relevant to both ongoing systems (i.e. current LEO deployment, high bandwidth GEO systems, etc.) and future satellite networks. TOPICS Papers are solicited in all research and applied areas related to satellite-based information systems (including, but not limited to): * Datalink technology for satellites, ATM over satellites * Resource management and network management * Inter-satellite link communications * Constellation planning and LEO routing * Bandwidth and latency management * Quality of Service support in satellite networks * Medium Access Control protocols for LEO/MEO/GEO or hybrid networks * IP protocols for satellite * High-data rate terminals * Architectures of high speed satellite networks * Satellite on-broad processing architectures * Algorithms for packet scheduling in satellite networks * Routing protocols in satellite networks * Satellite network control and management * Mobile satellite services SUBMISSION GUIDELINES All submissions will be handled electronically. Authors should e-mail a PostScript version of their paper to connors@hrl.com In order to ensure that the PostScript versions of the papers can be printed, authors should be careful that their papers meet the following restrictions: - PostScript version 2 or later. - Within 5 to 10 pages. - Fits properly on "US Letter" size paper (8.5X11 inches) - Reference only Computer Modern or standard Adobe printer fonts (i.e. Courier, Times, Roman, or Helvetica); other fonts may be used but must be included in the PostScript file. It is expected that all accepted papers will be presented at the workshop. IMPORTANT DATES Submissions due: September 24, 1999 Notification of acceptance: October 24, 1999 Final papers due: November 12, 1999 Workshop: December 8, 1999 ORGANIZATION TECHNICAL PROGRAM CO-CHAIRS Srikanth Krishnamurthy, HRL Labs, USA Dennis Connors, HRL Labs, USA PROGRAM COMMITTEE Anthony Acampora, University of California, San Diego Andrea Baiocchi, University of Roma "La Sapienza" Kul Bhasin, NASA Glen Research Center Walter Ciesluk, The MITRE Corporation Mario Gerla, University of California, Los Angeles Shuzo Kato, MWCI/Mobile Communications Technology Center Sastri Kota, Lockheed Martin Corporation Marie-Jose Montpetit, Teledesic Corporation Clayton Okino, Dartmouth College Hassan Peyravi, Kent State University Gregory J. Pottie, University of California, Los Angeles Leandros Tassiulas, University of Marlyand, College Park Desmond P. Taylor, University of Canterbury Bharghavan Vaduvur, University of Illinois, Urbana Michele Zorzi, University Ferrara, Italy GENERAL CO-CHAIRS Son K. Dao, HRL Labs, USA Randy Katz, UC Berkeley, USA --------------56E1596476C7A352C37D8CB3-- From owner-tcp-impl@lerc.nasa.gov Mon Sep 6 11:50:44 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13407 for ; Mon, 6 Sep 1999 11:50:42 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA07002 for tcp-impl-outgoing; Mon, 6 Sep 1999 08:28:34 -0400 (EDT) Received: from soleil.uvsq.fr (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA06760; Mon, 6 Sep 1999 08:14:32 -0400 (EDT) Received: from lucifer.prism.uvsq.fr (lucifer.prism.uvsq.fr [193.51.25.7]) by soleil.uvsq.fr (8.9.3/jtpda-5.3.2) with ESMTP id OAA54857 ; Mon, 6 Sep 1999 14:12:57 +0200 (CEST) Received: from prism.uvsq.fr (bernadotte.prism.uvsq.fr [193.51.25.141]) by lucifer.prism.uvsq.fr (8.9.3/jtpda-5.3.2) with ESMTP id OAA24391 ; Mon, 6 Sep 1999 14:12:45 +0200 (MET DST) Message-ID: <37D3B232.8E790437@prism.uvsq.fr> Date: Mon, 06 Sep 1999 14:23:15 +0200 From: Rebecca Morales Reply-To: Rebecca.Morales@prism.uvsq.fr Organization: PRiSM X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Subject: Networking2000-Deadline Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit !! DEADLINE: September 24 !! /////////////////////////////////////// Call for Papers Networking 2000 May 14-19, 2000 Paris, France ////////////////////////////////////// More information and submission: http://www.noc.uoa.gr/net2000 http://www.prism.uvsq.fr/~net2000 Networking 2000 conference is a joint conference of: HPN (High Performance Networking) Aaren 1987, Liège 1988, Berlin 1990, Liège 1992, Grenoble 1994, Palma 1995, New York 1997, Vienna 1998, Paris 2000. BC (Broadband Communications) Paris 1995, Montreal 1996, Lisboa 1997, Stuttgart 1998, Hong-Kong 1999, Paris 2000. PCN (Performance of Communication Networks) Paris 1981, Zürich 1984, Rio de Janeiro 1987, Barcelona 1990, Raleigh 1993, Lund 1998, Paris 2000. From owner-tcp-impl@lerc.nasa.gov Wed Sep 8 02:57:10 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04267 for ; Wed, 8 Sep 1999 02:57:09 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id XAA13882 for tcp-impl-outgoing; Tue, 7 Sep 1999 23:42:49 -0400 (EDT) Received: from smtprtp1.ntcom.nortel.net (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id XAA13872 for ; Tue, 7 Sep 1999 23:42:47 -0400 (EDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprtp1.ntcom.nortel.net; Tue, 7 Sep 1999 23:42:40 -0400 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 7 Sep 1999 22:42:40 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E801D609AB@zwdld001.ca.nortel.com> From: "Dabin Wang" To: tcp-impl@grc.nasa.gov Subject: loss rate due to congestion Date: Tue, 7 Sep 1999 22:42:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Anyone can give me some references about the packet loss rate due to congestion? When I did some test two years ago, I found the loss rate of IP packets in the Internet is high between 10:00am and 3:00pm, usually around 10%. It is about zero between 0:30am and 3:00am. Is there any statistics about that? Thank you Dabin Wang From owner-tcp-impl@lerc.nasa.gov Fri Sep 10 00:07:33 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13651 for ; Fri, 10 Sep 1999 00:07:32 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA26210 for tcp-impl-outgoing; Thu, 9 Sep 1999 20:34:05 -0400 (EDT) Received: from crufty.research.bell-labs.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA26206 for ; Thu, 9 Sep 1999 20:34:04 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Thu Sep 9 20:32:06 EDT 1999 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by scummy; Thu Sep 9 20:32:05 EDT 1999 Received: from research.bell-labs.com (dhcp-6-67.pa.bell-labs.com [135.250.6.67]) by mail1.pa.bell-labs.com with ESMTP id ACT02789 Thu, 9 Sep 1999 17:32:00 -0700 (PDT) Message-ID: <37D852B4.4541F183@research.bell-labs.com> Date: Thu, 09 Sep 1999 17:37:08 -0700 From: John Leong X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en,zh-CN MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Congestion avoidance Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I wonder if anyone on this list can verify if the following is true ...... Once we are in the congestion avoidance phase (where cwnd is being increased linearly), it will essentialy stay in that state until something worse happens .... packet loss as indentified by time out when we return to the slow start phase ... which will still end up eventually back in congestion avoidance phase when ssthresh is reached. There are no other events (such as no packets being sent for a long time) that will otherwise ends the congestion avoidance phase and let the cwnd get back to increasing expoentially towards the advertised window. Regards, John Leong -- --------------------------------------------------------- Bell Labs Research SV johnleong@lucent.com 3180 Porter Drive Tel: 650-565-7603 Palo Alto, CA 94304 Fax: 650-565-7676 From owner-tcp-impl@lerc.nasa.gov Fri Sep 10 04:50:31 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26398 for ; Fri, 10 Sep 1999 04:50:30 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA06946 for tcp-impl-outgoing; Fri, 10 Sep 1999 01:44:53 -0400 (EDT) Received: from saba.cs.washington.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA06940 for ; Fri, 10 Sep 1999 01:44:51 -0400 (EDT) Received: from localhost (cardwell@localhost) by saba.cs.washington.edu (8.9.3/8.9.3/0.2) with ESMTP id WAA06483; Thu, 9 Sep 1999 22:44:47 -0700 (envelope-from cardwell@cs.washington.edu) X-Authentication-Warning: saba.cs.washington.edu: cardwell owned process doing -bs Date: Thu, 9 Sep 1999 22:44:46 -0700 (PDT) From: Neal Cardwell To: John Leong cc: tcp-impl@grc.nasa.gov Subject: Re: Congestion avoidance In-Reply-To: <37D852B4.4541F183@research.bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk I believe that RFC 2581 says that TCP is supposed to reduce cwnd to the initial cwnd value ("IW") when the connection has been idle for a while (more than one RTO). Thus idleness is one thing that could end congestion avoidance and begin a slow start phase. From RFC 2581, section 4.1: For the purposes of this standard, we define RW = IW. ... a TCP SHOULD set cwnd to no more than RW before beginning transmission if the TCP has not sent data in an interval exceeding the retransmission timeout. cheers, neal On Thu, 9 Sep 1999, John Leong wrote: > I wonder if anyone on this list can verify if the following is true > ...... > > Once we are in the congestion avoidance phase (where cwnd is being > increased linearly), it will essentialy stay in that state until > something worse happens .... packet loss as indentified by time out when > we return to the slow start phase ... which will still end up eventually > back in congestion avoidance phase when ssthresh is reached. > > There are no other events (such as no packets being sent for a long > time) that will otherwise ends the congestion avoidance phase and let > the cwnd get back to increasing expoentially towards the advertised > window. > > Regards, > John Leong From owner-tcp-impl@lerc.nasa.gov Fri Sep 10 06:58:42 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27779 for ; Fri, 10 Sep 1999 06:58:37 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA11281 for tcp-impl-outgoing; Fri, 10 Sep 1999 03:59:31 -0400 (EDT) Received: from s2.smtp.oleane.net (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id DAA11277 for ; Fri, 10 Sep 1999 03:59:29 -0400 (EDT) Received: from nec.oleane.com (dyn-1-1-253.Cor.dialup.oleane.fr [62.161.8.253]) by s2.smtp.oleane.net with SMTP id JAA37224 for ; Fri, 10 Sep 1999 09:59:27 +0200 (CEST) Message-ID: <00b301befb62$8fca01e0$0201a8c0@nec.oleane.com> From: "Peter lewis" To: Subject: QoS Summit Date: Fri, 10 Sep 1999 10:00:34 +0200 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 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit QoS Summit: key requirements for advanced applications running on future networks. Technologies (MPLS, ATM, IntSev/DiffServ, Frame Relay). Managing, policing, billing, charging QoS. The annual rendez-vous with top senior specialists. Paris, France, 16-19 November 1999 Please see details at the following web address: http://www.upperside.fr/baqos.htm Sorry to post this message on the list. Thanks From owner-tcp-impl@lerc.nasa.gov Fri Sep 10 19:24:11 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24415 for ; Fri, 10 Sep 1999 19:23:56 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA12038 for tcp-impl-outgoing; Fri, 10 Sep 1999 15:24:04 -0400 (EDT) Received: from crufty.research.bell-labs.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA12034 for ; Fri, 10 Sep 1999 15:24:03 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Fri Sep 10 15:23:56 EDT 1999 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by grubby; Fri Sep 10 15:23:55 EDT 1999 Received: from research.bell-labs.com (dhcp-6-67.pa.bell-labs.com [135.250.6.67]) by mail1.pa.bell-labs.com with ESMTP id ACT03668 Fri, 10 Sep 1999 12:23:53 -0700 (PDT) Message-ID: <37D95BFC.EEAACDE4@research.bell-labs.com> Date: Fri, 10 Sep 1999 12:29:00 -0700 From: John Leong X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en,zh-CN MIME-Version: 1.0 To: Neal Cardwell CC: tcp-impl@grc.nasa.gov Subject: Re: Congestion avoidance 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 > I believe that RFC 2581 says that TCP is supposed to reduce cwnd to the > initial cwnd value ("IW") when the connection has been idle for a while > (more than one RTO). Thus idleness is one thing that could end congestion > avoidance and begin a slow start phase. From RFC 2581, section 4.1: That is somewhat orthogonal to the puzzle I have in mind for which I must apologize of being misleading with the bad example (idleness) I used. ... >> There are no other events (such as no packets being sent for a long >> time) that will otherwise ends the congestion avoidance phase and let >> the cwnd get back to increasing expoentially towards the advertised >> window. With RFC 2581, after idleness, it will reenter slow start mode after resetting cwnd back to IW ... i.e. treat it as a fresh start. Waht I was wondering was whether there is any event that would cause cwnd to switch back from linear increase to exponential increase (by 1 segment per ACK) without first resetting cwnd ... as in declaring congestion is over and back to normal. Regards, John Leong --------------------------------------------------------- Bell Labs Research SV johnleong@lucent.com 3180 Porter Drive Tel: 650-565-7603 Palo Alto, CA 94304 Fax: 650-565-7676 From owner-tcp-impl@lerc.nasa.gov Fri Sep 10 21:04:08 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24909 for ; Fri, 10 Sep 1999 21:04:07 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA28326 for tcp-impl-outgoing; Fri, 10 Sep 1999 17:56:30 -0400 (EDT) Received: from star.cirrus.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA28322 for ; Fri, 10 Sep 1999 17:56:28 -0400 (EDT) Received: from ss563.corp.cirrus.com (ss563.corp.cirrus.com [141.131.8.55]) by star.cirrus.com (8.9.3/8.8.8) with ESMTP id OAA07699 for ; Fri, 10 Sep 1999 14:56:27 -0700 (PDT) Received: from u230-192.corp.cirrus.com (u230-192.corp.cirrus.com [141.131.68.232]) by ss563.corp.cirrus.com with SMTP id OAA26948 (8.7.5/IDA-1.6 for ); Fri, 10 Sep 1999 14:56:25 -0700 (PDT) Received: from ssu036.corp.cirrus.com by u230-192.corp.cirrus.com (SMI-8.6/Corp-2.20) id OAA27215; Fri, 10 Sep 1999 14:56:16 -0700 Received: by ssu036.corp.cirrus.com (SMI-8.6/Corp-2.20) id OAA11833; Fri, 10 Sep 1999 14:56:14 -0700 From: bhaveshp@corp.cirrus.com (Bhavesh Pathak - BasisComm) Message-Id: <199909102156.OAA11833@ssu036.corp.cirrus.com> Subject: denial of service attack To: tcp-impl@grc.nasa.gov Date: Fri, 10 Sep 1999 14:56:14 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24alpha3] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Dear everyone, can someone tell me what is "denial of service attack" and how it can be prevented? bhavesh From owner-tcp-impl@lerc.nasa.gov Sat Sep 11 01:44:13 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02954 for ; Sat, 11 Sep 1999 01:44:12 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA06107 for tcp-impl-outgoing; Fri, 10 Sep 1999 22:02:59 -0400 (EDT) Received: from lint.cisco.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA06103 for ; Fri, 10 Sep 1999 22:02:57 -0400 (EDT) Received: from big-dawgs ([171.70.114.134] (may be forged)) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id TAA28387; Fri, 10 Sep 1999 19:02:19 -0700 (PDT) Message-Id: <3.0.5.32.19990910220153.007c2440@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 10 Sep 1999 22:01:53 -0400 To: bhaveshp@corp.cirrus.com (Bhavesh Pathak - BasisComm) From: Paul Ferguson Subject: Re: denial of service attack Cc: tcp-impl@grc.nasa.gov In-Reply-To: <199909102156.OAA11833@ssu036.corp.cirrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This might help: http://users.quadrunner.com/chuegen/smurf.cgi - paul At 02:56 PM 09/10/1999 -0700, Bhavesh Pathak - BasisComm wrote: > >Dear everyone, > >can someone tell me what is "denial of service attack" and how it can >be prevented? > >bhavesh > > > From owner-tcp-impl@lerc.nasa.gov Sat Sep 11 18:41:35 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13867 for ; Sat, 11 Sep 1999 18:41:33 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA25631 for tcp-impl-outgoing; Sat, 11 Sep 1999 15:23:15 -0400 (EDT) Received: from elk.aciri.org (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA25627 for ; Sat, 11 Sep 1999 15:23:13 -0400 (EDT) Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.9.3/8.9.2) with ESMTP id MAA72913; Sat, 11 Sep 1999 12:22:34 -0700 (PDT) (envelope-from floyd@elk.aciri.org) Message-Id: <199909111922.MAA72913@elk.aciri.org> To: John Leong cc: tcp-impl@grc.nasa.gov From: Sally Floyd Subject: Re: Congestion avoidance Date: Sat, 11 Sep 1999 12:22:33 -0700 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk >Waht I was wondering was whether there is any event that would cause >cwnd to switch back from linear increase to exponential increase (by 1 >segment per ACK) without first resetting cwnd ... as in declaring >congestion is over and back to normal. Nope. "Normal" means congestion avoidance, not exponential increase. The exponential increase phase applies only when cwnd < ssthresh. And such an exponential increase phase only begins at the start of the connection, or after cwnd is decreased. (That is, ssthresh is never increased unless it is accompanied by a decrease in cwnd.) - Sally From owner-tcp-impl@lerc.nasa.gov Mon Sep 13 15:24:01 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08537 for ; Mon, 13 Sep 1999 15:23:59 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA02183 for tcp-impl-outgoing; Mon, 13 Sep 1999 11:09:54 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.44.160]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA02178 for ; Mon, 13 Sep 1999 11:09:53 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id LAA08378; Mon, 13 Sep 1999 11:09:52 -0400 (EDT) Message-Id: <199909131509.LAA08378@guns.lerc.nasa.gov> To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: small bug in BSD timestamp code Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: The Bug Date: Mon, 13 Sep 1999 11:09:52 -0400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk While poking into a problem we were having with an experimental version of TCP I stubbled across what I think is a bug in the BSD timestamp code. I found the bug in NetBSD (and have reported it to those folks), but it seems to be present in TCP/IP Illustrated, Volume 2, so I assume that it might be in other systems and therefore other folks might be interested, as well. One instance of the problem appears on page 976 of TCP/IP Illustrated, Volume 2 (although, there are probably others, but that is left as an exercise). As shown, if the timestamp option is present in the received ACK an RTT sample is taken (and SRTT and RTTVAR are updated). However, I think a check is missing. RFC 1323 states that if the timestamp received is zero it is invalid and therefore should be ignored. There is no check in the code for a timestamp of zero. So, if a zero is received the SRTT and RTTVAR end up getting really hosed. (Of course, the TCP that generated the zero timestamp was in error. But, I believe that is a problem with the experimental kernel I have been playing with.). allman --- http://roland.grc.nasa.gov/~mallman/ From owner-tcp-impl@lerc.nasa.gov Mon Sep 13 19:42:45 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10754 for ; Mon, 13 Sep 1999 19:42:40 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA08378 for tcp-impl-outgoing; Mon, 13 Sep 1999 16:15:50 -0400 (EDT) Received: from red.juniper.net (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA08374; Mon, 13 Sep 1999 16:15:47 -0400 (EDT) Received: from juniper.net (shark.juniper.net [207.79.80.43]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id NAA16476; Mon, 13 Sep 1999 13:15:46 -0700 (PDT) Message-Id: <199909132015.NAA16476@red.juniper.net> X-Mailer: exmh version 2.0.2 2/24/98 To: mallman@grc.nasa.gov Cc: tcp-impl@grc.nasa.gov Subject: Re: small bug in BSD timestamp code In-Reply-To: Message from Mark Allman of "Mon, 13 Sep 1999 11:09:52 EDT." <199909131509.LAA08378@guns.lerc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Sep 1999 13:15:45 -0700 From: Thomas Skibo Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Ideally, the ECR should be ignored if it's zero because that's what the other guy uses if he doesn't have a valid TS.recent (for a SYN or if the "24 day connection" timeout occurred). But, in all cases where you're going to use an ACK to update the RTT (the ACK acks new data), the peer ought to have a valid TS.recent from the segment for which you're trying to get acknowledgement. ...unless there's some other way that TS.recent is discarded that I can't remember. -- Thomas Skibo Juniper Networks, Inc. skibo@juniper.net From owner-tcp-impl@lerc.nasa.gov Mon Sep 13 19:43:19 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10774 for ; Mon, 13 Sep 1999 19:43:13 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA09595 for tcp-impl-outgoing; Mon, 13 Sep 1999 16:25:26 -0400 (EDT) Received: from red.juniper.net (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA09585; Mon, 13 Sep 1999 16:25:24 -0400 (EDT) Received: from juniper.net (shark.juniper.net [207.79.80.43]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id NAA17159; Mon, 13 Sep 1999 13:25:24 -0700 (PDT) Message-Id: <199909132025.NAA17159@red.juniper.net> X-Mailer: exmh version 2.0.2 2/24/98 To: mallman@grc.nasa.gov cc: tcp-impl@grc.nasa.gov Subject: Re: small bug in BSD timestamp code In-Reply-To: Message from Mark Allman of "Mon, 13 Sep 1999 16:20:25 EDT." <199909132020.QAA10574@guns.lerc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Sep 1999 13:25:23 -0700 From: Thomas Skibo Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Or, there is a bug in the other guy's stack... A bug could corrupt the echo-reply in a lot of ways (2^32-1 different ways :-) ), all of which would screw up RTT measurements. -- Thomas Skibo Juniper Networks, Inc. skibo@juniper.net From owner-tcp-impl@lerc.nasa.gov Mon Sep 13 19:43:23 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10785 for ; Mon, 13 Sep 1999 19:43:23 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA09007 for tcp-impl-outgoing; Mon, 13 Sep 1999 16:20:29 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.44.160]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA09003; Mon, 13 Sep 1999 16:20:26 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id QAA10574; Mon, 13 Sep 1999 16:20:26 -0400 (EDT) Message-Id: <199909132020.QAA10574@guns.lerc.nasa.gov> To: Thomas Skibo From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tcp-impl@grc.nasa.gov Subject: Re: small bug in BSD timestamp code Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: The Bug Date: Mon, 13 Sep 1999 16:20:25 -0400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Ideally, the ECR should be ignored if it's zero because that's what the > other guy uses if he doesn't have a valid TS.recent (for a SYN or if > the "24 day connection" timeout occurred). But, in all cases where > you're going to use an ACK to update the RTT (the ACK acks new data), > the peer ought to have a valid TS.recent from the segment for which > you're trying to get acknowledgement. > > ...unless there's some other way that TS.recent is discarded that I > can't remember. Or, there is a bug in the other guy's stack... It still seems like a good sanity check to me. allman From owner-tcp-impl@lerc.nasa.gov Tue Sep 14 01:17:19 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16760 for ; Tue, 14 Sep 1999 01:17:18 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA26853 for tcp-impl-outgoing; Mon, 13 Sep 1999 22:00:44 -0400 (EDT) Received: from tuvok.lerc.nasa.gov (ras139.lerc.nasa.gov [139.88.123.139]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA26836; Mon, 13 Sep 1999 22:00:19 -0400 (EDT) Received: from tuvok.lerc.nasa.gov (localhost [127.0.0.1]) by tuvok.lerc.nasa.gov (8.8.5/8.8.5) with ESMTP id WAA01162; Mon, 13 Sep 1999 22:02:28 -0400 (EDT) Message-Id: <199909140202.WAA01162@tuvok.lerc.nasa.gov> To: tcp-impl@grc.nasa.gov Cc: "Vern Paxson" , kml@novell.com From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: TCP Problems with Path MTU Discovery Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: The Bug Date: Mon, 13 Sep 1999 22:02:28 -0400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Vern and I believe the pmtud I-D is nearing the point where we can issue a last call and boot it up to the IESG. However, there has been very little discussion recently on the draft. So, we'd like to encourage folks to take a look at the draft and send any comments you might have. Unless there is a large amount of discussion we'll probably issue the last call very soon. The draft can be retrieved via: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpimpl-pmtud-02.txt Thanks, allman From owner-tcp-impl@lerc.nasa.gov Tue Sep 14 01:36:18 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19140 for ; Tue, 14 Sep 1999 01:36:18 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA28284 for tcp-impl-outgoing; Mon, 13 Sep 1999 22:45:15 -0400 (EDT) Received: from elk.aciri.org (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA28280 for ; Mon, 13 Sep 1999 22:45:14 -0400 (EDT) Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.9.3/8.9.2) with ESMTP id TAA80146; Mon, 13 Sep 1999 19:44:30 -0700 (PDT) (envelope-from floyd@elk.aciri.org) Message-Id: <199909140244.TAA80146@elk.aciri.org> To: tcp-impl@grc.nasa.gov cc: mathis@psc.edu, Jamshid Mahdavi , allyn@cisco.com, Matt Podolsky From: Sally Floyd Subject: A proposed extension to the SACK Option for TCP Date: Mon, 13 Sep 1999 19:44:30 -0700 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Jamshid Mahdavi, Matt Mathis, Matthew Podolsky, Allyn Romanow and I have written an internet-draft about "An Extension to the Selective Acknowledgement (SACK) Option for TCP", and we are sending it to the tcp-impl list for a final round of feedback before we submit it to the area directors for consideration as an Experimental RFC. (The draft has already incorporated feedback from the end2end-interest mailing list.) The abstract is appended below, and the internet-draft itself is available at "http://search.ietf.org/internet-drafts/draft-floyd-sack-00.txt". The main point of the extension is for the TCP data receiver to use SACK blocks to give the TCP data sender more information about duplicate packets that have been received. Our hope is that this proposed draft itself, to add a new type of SACK block in the SACK option, will be relatively uncontroversial. Our belief is that this extension does not introduce any backwards-compatibility issues with existing implementations of SACK TCP (RFC 2018, now at Proposed Standard). I would note that all of the co-authors of RFC 2018 are also co-authors of this proposed extension. My own expectation is that later research and proposals on specific algorithms for the TCP data sender to in fact *make use of* this SACK option could generate more discussion (and possibly controvery, it is hard to say). I would hope that this proposal would enable additional work on algorithms for making TCP more robust to reordered packets, ACK loss, packet replication, and/or early retransmit timeouts. Feedback would be appreciated. - Sally -------------------------------- http://www.aciri.org/floyd/ -------------------------------- An Extension to the Selective Acknowledgement (SACK) Option for TCP by Sally Floyd, Jamshid Mahdavi, Matt Mathis, Matthew Podolsky, and Allyn Romanow Abstract This note defines an extension of the Selective Acknowledgement (SACK) Option [RFC 2018] for TCP. RFC 2018 specified the use of the SACK option for acknowledging out-of-sequence data not covered by TCP's cumulative acknowledgement field. This note extends RFC 2018 by specifying the use of the SACK option for acknowledging duplicate packets. This note suggests that when duplicate packets are received, the first block of the SACK option field can be used to report the sequence numbers of the packet that triggered the acknowledgement. This extension to the SACK option allows the TCP sender to infer the order of packets received at the receiver, allowing the sender to infer when it has unnecessarily retransmitted a packet. A TCP sender could then use this information for more robust operation in an environment of reordered packets, ACK loss, packet replication, and/or early retransmit timeouts. URL "http://search.ietf.org/internet-drafts/draft-floyd-sack-00.txt". From owner-tcp-impl@lerc.nasa.gov Tue Sep 14 13:51:08 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02131 for ; Tue, 14 Sep 1999 13:51:03 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA01714 for tcp-impl-outgoing; Tue, 14 Sep 1999 10:16:05 -0400 (EDT) Received: from calcite.rhyolite.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA01708 for ; Tue, 14 Sep 1999 10:16:03 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id IAA21077 for tcp-impl@grc.nasa.gov env-from ; Tue, 14 Sep 1999 08:15:58 -0600 (MDT) Date: Tue, 14 Sep 1999 08:15:58 -0600 (MDT) From: Vernon Schryver Message-Id: <199909141415.IAA21077@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: TCP Problems with Path MTU Discovery Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: Mark Allman > Vern and I believe the pmtud I-D is nearing the point where we can > issue a last call and boot it up to the IESG. However, there has > been very little discussion recently on the draft. So, we'd like to > encourage folks to take a look at the draft and send any comments > you might have. Unless there is a large amount of discussion we'll > probably issue the last call very soon. ... I have a nit you might wisely ignore. Some versions of `ping` can also set the DF bit to probe for broken routers that do not generate the ICMP message or that filter ICMP messages. The `ping` in IRIX is one. I think the `ping` in NetBSD is another. Perhaps someday the `ping` in BSD/OS will be still another. In other words, I've been flogging the hacks in ftp.rhyolite.com:src/ping.tar.Z. I suggest you *not* mention my vanity domain. There is a specific case of the first problem in the draft that needs to be explicitly mentioned, because idiots are too stupid to understand the implications of their brain-dead actions. A significant number of people who consider themselves expert administrators configure their routers to discard all ICMP packets because ICMP packets are a security risk. Even after you point out the effects such nonsense has on systems that ahve PMTUD, turned on by default, they don't or refuse to understand. This RFC seems like a good place to discuss the worst case security risks of the Fragmentation Message ICMP message (reduced TCP throughput), the likely results of discarding them ("Non-interoperation -- connectivity failure"), and a better way to deal with the minor security problem (hosts should refuse to shrink the MTU to less than a reasonable limit, such as 500). This ICMP-is-a-security-risk nonsense predates the "smurf attack." Years ago I encountered an "internet security expert" who had "fixed" a commercial version of Gauntlet to discard all ICMP because of the dangers of Redirects received by typical firewalls, (then) singled homed and behind (potentially filtering) routers. There is another activity that is related to discarding ICMP packets, but not exactly stupid. Some major retail ISP's use something like NAT in their routers to redirect all client SMTP traffic from their end-user customers to their own SMTP servers that then filter for spam and potentially other things. Since they redirect only some packets based on TCP port number, I doubt they do the right thing if there happens to be a narrow pipe in the path, such as the ever popular misconconfigured PPP link with an MTU of 500. (That people insist on spending money on "tuning" products that misconfigure Windows 95/98 PPP to use an MTU of 500 based on rumors of ancient computations of the effects of 2400 bit/sec modems is another sad tale of woe that ought to be mentioned somewhere.) Also, the document should mention the effects of the many NAT boxes in the Intenret today on PMTUD. Those that manage to forwad the ICMP messages are not a problem, but judging from the many complaints about `ping` not working, some do not. Yes, I realize that three of these are merely specific cases of the first explicit problem in the draft. Still, the median willingness and ability to understand protocols and the effects of "improvements" is so low that without explicit words in RFCs, most of the experts Won't Get It. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Tue Sep 14 15:35:31 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07496 for ; Tue, 14 Sep 1999 15:35:18 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA16277 for tcp-impl-outgoing; Tue, 14 Sep 1999 12:07:26 -0400 (EDT) Received: from by.genie.uottawa.ca (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA16216 for ; Tue, 14 Sep 1999 12:07:03 -0400 (EDT) Received: from mobstar ([137.122.107.157]) by by.genie.uottawa.ca (8.9.1/8.9.1) with SMTP id LAA28333 for ; Tue, 14 Sep 1999 11:10:13 -0400 (EDT) Reply-To: From: "Ahmed Karmouch" To: Subject: Workshop on Mobile Agents for Telecommunication Applications, Ottawa-Canada Date: Tue, 14 Sep 1999 09:16:45 -0400 Message-ID: <002101befeb3$646bf3b0$9d6b7a89@mobstar.uottawa.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit ====================================== [My apologies if you receive this more than once] ============================================================== CALL FOR PARTICIPATION MATA'99 First International Workshop on Mobile Agents for Telecommunication Applications =============================================================== 6-8 October 1999, Ottawa, Canada More information on MATA'99 is available at http://ocri.genie.uottawa.ca/mata99 SCOPE: Mobile agents refer to self-contained and identifiable computer programs that can move within he network and can act on behalf of the user or another entity. Most of the current research work on the mobile agent paradigm has two general goals: reduction of network traffic and asynchronous interaction. These two goals stem directly from the desire to reduce information overload and to efficiently use network resources. There are certainly many motivations for the use of mobile agent paradigm; however, intelligent information retrieval, network and mobility management, and network services are currently the three most cited application targets for a mobile agent system. The aim of the workshop is to provide a unique opportunity for researchers, software and application developers, and computer network technologists to discuss new developments on the mobile agent technology and applications. The workshop will focus on mobile agent issues across the areas of network management, mobile applications, Nomadic computing, feature interactions, Internet applications, QoS management, policy-based management, interactive multimedia, Tele-learning applications, and Computer Telephony Integration. --------------------------------------------- Tutorials (Wednesday October 6) --------------------------------------------- Introduction to Extensible Markup Language XML (half-day) Lloyd Rutledge and Jacco van Ossenbruggen, CWI, Netherlands Mobile Agent Development Using Concordia (half-day) David Wong, Joe DiCelie, Mitsubishi, USA --------------------------------------------------- Technical Program (Thursday October 7) ---------------------------------------------------- Keynote: Chairperson: Ahmed Karmouch, University of Ottawa, Canada Speaker: T. Magedanz, IKV++ GmbH, Germany An Open Agent Platform for Telecommunications and its Role in the European ACTS CLIMATE Initiative Session 1: Mobile Agent Architecture and Models Chairperson: Roger Impey, National Research Council of Canada Advanced Mobile Agent Architectures for H.323 IP Telephony Jinrong Tang, Tony White, Bernard Pagurek, Carleton University, Canada Roch Glitho, Ericsson Research Canada Mobile Software Agent Model and Architecture of JMSAS Chen Chong, Huo Jiwen, Bi Kai, Mai Zhongfan, Beijing University of Aeronautics and Astronautics, China Business Mobile Agent Platform (BMAP) Kamel Sadi, Alcatel Corporate Research Center, France Farah Belaidi, INRIA, France Client-Server and mobile agent: performances comparative study in the management of MIBs A.Outtagarts, M. Kadoch, Ecole de technologie superieure, Canada S. Soulhi, Centre de Recherche Informatique de Montreal, Canada Session 2: Active Networks and Mobile Agents Chairperson: Tom Gray, Mitel Corp. Canada An Active Network Architecture allowing Mobile Agents Construction to Improve Quality of Service Sebastien Allongue, Roger Impey, National Research Council of Canada Eric Horlait, Universite Pierre et Marie Curie, France A Design of Security Services for Active Networks Kitt Tientanopajai, Kanchana Kanchanasut, Asian Institute of Technology, Thailand Intelligent and Mobile Agents over Legacy, Present and Future Telecommunication Networks Romel A. Tintin, Dong Ik Lee, Kwangju Institute of Science and Technology, Republic of Korea MAGNET: Ad-hoc Network System based on Mobile Agents Nobuo Kawaguchi, Katsuhiko Toyama, Yasuyoshi Inagaki, Nagoya University, Japan Session 3: Agent Framework and Migration Strategies Chairperson: Clifford Grossner, Nortel Networks, Canada Adding Mobility to CORBA Magdi Amer, Ahmed Karmouch, University of Ottawa, Canada Tom Gray, Serguei Mankovski, Mitel Corp., Canada Optimizing the Migration of Mobile Agents Guilherme Soares, Luis Moura Silva, Universidade de Coimbra, Portugal A Converter Approach for Mobile Agent System Integration: a Case of Aglet to Voyager Djoni Tjung, Masahiko Tsukamoto, Shojiro Nishio, Osaka University, Japan Modeling and Comparison of Bandwidth Usage of three Migration Strategies of Mobile Agents Michel Barbeau, Universite de Sherbrooke, Canada Session 4: Agent-based Network Management Chairperson: Thomas Magedanz, IKV++ GmbH, Germany Methodologies for PVC Configuration in Heterogeneous ATM Environments Using Intelligent Mobile Agents John Boyer, Bernard Pagurek, Tony White, Carleton University, Canada Mobile Agents in the mobile telephone network management Igor Brusic, Vesna Hassler, Wolfgang Lugmayr, Technical University of Vienna, Austria Distributed Management based on Mobile Agents Jose Luis Oliveira, Universidade de Aveiro, Portugal Rui Pedro Lopes, Instituto Politecnico de Braganca, Portugal ----------------------------------------------------- Technical Program (Friday October 8) ----------------------------------------------------- Session 5: Agent-based Service Management Chairperson: Eric Horlait, University Pierre et Marie Curie, Canada Advanced Service Provisioning based on Mobile Agents Peyman Farjami, Carmelita Gorg, Frank Bell, Aachen University of Technology, Germany Service Profile guarding by mobile agents Erik De Blieck, Michel Van Ackere, Corporate Research Centre Alcatel, Belgium Luigi Ciminiera, Politecnico di Torino, Italy Tao Qi, University of Posts and Telecommunications, China Management Services for Distributed Application Management with Agent Technology William C. McLean, Michael A. Bauer, University of Western Ontario, Canada Multi-service negotiation with mobile agents Walter Merlat, BT Laboratories, U.K. Panel Discussion: Future of Mobile Agents Moderator: Suhayya Abu-Hakima, AmikaNow!, Canada Panelist: -Andre Vellino, Nortel Networks, Canada -T. Magedanz, IKV++ GmbH, Germany -Roch Glitho, Ericsson Research Canada -Tom Gray, Mitel Corp., Canada Session 6: Personal Mobility Management with Mobile Agents Chairperson: Roch Glitho, Ericsson Research Canada A Distribution Framework for a Messaging System Larry Korba, Ramiro Liscano, National Research Council of Canada An Agent-based Architecture for Inter-Sites Personal Mobility Management System Hamid Harroud, Ahmed Karmouch, University of Ottawa, Canada Tom Gray, Serguei Mankovski, Mitel Corporation, Canada Agents in Personal Mobility Stefano Campadello, Kimmo Raatikainen, University of Helsinki, Finland Ensuring Secure Communication for a Distributed Mobile Computing System based on MicMac Cui Zheng, Ahmed Karmouch, University of Ottawa, Canada Tom Gray, Serguei Mankovski, Mitel Corp. Canada Roger Impey, National Research Council of Canada Session 7: Applications of Mobile Agents I Chairperson: Marie-Pierre Gervais, University Pierre et Marie Curie, France An XML based Web mining agent Hicham Ouahid, Ahmed Karmouch, University of Ottawa, Canada Mobile Web Agents for Telemedicine Kevin D. Smith, Raman B. Paranjape, University of Regina, Canada Experiments with Mobile Agents and distributed Workflow Systems Guirong Cui, George M. White, University of Ottawa, Canada Session 8: Applications of Mobile Agents II Chairperson: Andre Vellino, Nortel Networks Canada Software Component Retrieval System Using Agents Y. S. Lee, C. J. Wang, Inha University, Republic of Korea Experiments in the Mobile Agents Technology Rosane Maria Martins, Magali Ribeiro Chaves, Luci Pirmez, Luiz Fernando Rust, Universidade Federal do Rio de Janeiro, Brazil A Distributed Query Service based on Mobile Agent Concept Nadia Boukhatem, Ecole Nationale Superieure de Telecommunications, France Session 9: Networked Multi-Agent Systems Chairperson: Ramiro Liscano, National Research Council of Canada A Negotiation Approach for Mobile Agents used in Managing Telecommunication network services L. Esmahi, P. Dini, Centre de Recherche Informatique de Montreal, Canada J.C. Bernard, Ecole Polytechnique de Montreal, Canada Policy-based Control Agents for Boundary Routers in Differentiated Services IP Salima Omari, University of Versailles, France Raouf Boutaba, University of Toronto, Canada Increasing the Dependability in a Multi-Agent System by Use of Known Scenarios Ralph Deters, University of Saskatchewan, Canada GenA: Multiplatform Generic Agents Laurent Magnin, El Hachemi Alikacem, Centre de Recherche Informatique de Montreal, Canada =============== end ============================ From owner-tcp-impl@lerc.nasa.gov Tue Sep 14 19:36:18 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15555 for ; Tue, 14 Sep 1999 19:36:13 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA13896 for tcp-impl-outgoing; Tue, 14 Sep 1999 16:11:51 -0400 (EDT) Received: from mailman.lanl.gov (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA13890 for ; Tue, 14 Sep 1999 16:11:50 -0400 (EDT) Received: from pescado.lanl.gov (pescado.lanl.gov [128.165.114.15]) by mailman.lanl.gov (8.9.3/8.9.3/(cic-5, 2/8/99)) with ESMTP id OAA22960; Tue, 14 Sep 1999 14:11:44 -0600 Date: Tue, 14 Sep 1999 14:11:43 -0600 (MDT) From: Mike Fisk To: Vernon Schryver cc: tcp-impl@grc.nasa.gov Subject: Re: TCP Problems with Path MTU Discovery In-Reply-To: <199909141415.IAA21077@calcite.rhyolite.com> Message-ID: X-Pager-URL: http://home.lanl.gov/mfisk/snpp/ X-Homepage: http://home.lanl.gov/mfisk/ MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1518334094-1467464121-937339903=:29510" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1518334094-1467464121-937339903=:29510 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 14 Sep 1999, Vernon Schryver wrote: > I have a nit you might wisely ignore. Some versions of `ping` can also > set the DF bit to probe for broken routers that do not generate the ICMP > message or that filter ICMP messages. The `ping` in IRIX is one. I think > the `ping` in NetBSD is another. Perhaps someday the `ping` in BSD/OS > will be still another. In other words, I've been flogging the hacks in > ftp.rhyolite.com:src/ping.tar.Z. I suggest you *not* mention my vanity > domain. As long as we're mentioning tools.... The LBL traceroute also has an option (-F) to set the DF bit. When used with small and large packets, this can be used to find PMTUD blackholes. First, there is a bug in the code for little endian machines that prevents that bit from actually being set. The second attachment to this message is the patch for that. Second, when it receives an ICMP Need Fragmentation reponse, it doesn't report what MTU the router will accept. As an aid for traversing networks with various MTUs, I also made a patch that not only prints that value, but will then continue the trace with the smaller MTU. That patch is the first attachment to this message. I sent these patches back to LBL in May, but never got a response. I don't know if anyone is listening to traceroute@ee.lbl.gov anymore. Here's a sample of the output: $ ./traceroute -F www.unm.edu 4352 traceroute to musca.unm.edu (129.24.57.2), 30 hops max, 4352 byte packets 1 lanl-gw.lanl.gov (192.16.1.1) 1.311 ms 1.166 ms 1.262 ms 2 esnet-rt1.lanl.gov (192.16.1.241) 2.003 ms 1.926 ms 2.029 ms 3 lanl-technet.lanl.gov (192.16.1.246) 3.176 ms 8.990 ms 2.981 ms 4 lanl-technet.lanl.gov (192.16.1.246) 3.098 ms !F<=1479 Resending with 1479 byte packets: 206.206.125.17 (206.206.125.17) 90.907 ms 69.811 ms 5 rtn.nm.org (129.121.1.1) 81.085 ms 48.157 ms 90.253 ms 6 198.59.130.49 (198.59.130.49) 94.900 ms 103.146 ms 95.326 ms 7 198.83.5.2 (198.83.5.2) 73.320 ms 73.084 ms 73.236 ms 8 198.83.226.33 (198.83.226.33) 124.882 ms 74.908 ms 74.436 ms 9 musca.unm.edu (129.24.57.2) 76.494 ms 75.609 ms 81.826 ms ===================================================================== Mike Fisk | (505)667-5119 | MS B255 Network Engineering (CIC-5) | | Los Alamos National Lab mfisk@lanl.gov | FAX: 665-7793 | Los Alamos, NM 87545 ---1518334094-1467464121-937339903=:29510 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="traceroute-1.4a5-pmtu.patch" Content-ID: Content-Description: traceroute-1.4a5-pmtu.patch Content-Disposition: attachment; filename="traceroute-1.4a5-pmtu.patch" Content-Transfer-Encoding: BASE64 ZGlmZiAtVTMgLXIgdHJhY2Vyb3V0ZS0xLjRhNS5vcmlnL3RyYWNlcm91dGUu YyB0cmFjZXJvdXRlLTEuNGE1L3RyYWNlcm91dGUuYw0KLS0tIHRyYWNlcm91 dGUtMS40YTUub3JpZy90cmFjZXJvdXRlLmMJTW9uIE1heSAxMCAxMjo0MToz OSAxOTk5DQorKysgdHJhY2Vyb3V0ZS0xLjRhNS90cmFjZXJvdXRlLmMJTW9u IE1heSAxMCAxMjo0MTowMSAxOTk5DQpAQCAtMzI1LDYgKzMyNSw4IEBADQog dm9pZAl0dnN1YihzdHJ1Y3QgdGltZXZhbCAqLCBzdHJ1Y3QgdGltZXZhbCAq KTsNCiBfX2RlYWQJdm9pZCB1c2FnZSh2b2lkKTsNCiBpbnQJd2FpdF9mb3Jf cmVwbHkoaW50LCBzdHJ1Y3Qgc29ja2FkZHJfaW4gKiwgc3RydWN0IHRpbWV2 YWwgKik7DQordm9pZAlhZGp1c3RQTVRVKGNvbnN0IHVfY2hhciAqKTsNCisN CiANCiBpbnQNCiBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndikNCkBAIC03 OTYsOCArNzk4LDggQEANCiAJCQkJCWJyZWFrOw0KIA0KIAkJCQljYXNlIElD TVBfVU5SRUFDSF9ORUVERlJBRzoNCisJCQkJCWFkanVzdFBNVFUocGFja2V0 KTsNCiAJCQkJCSsrdW5yZWFjaGFibGU7DQotCQkJCQlQcmludGYoIiAhRiIp Ow0KIAkJCQkJYnJlYWs7DQogDQogCQkJCWNhc2UgSUNNUF9VTlJFQUNIX1NS Q0ZBSUw6DQpAQCAtMTMwNiwzICsxMzA4LDMzIEBADQogCSAgICBwcm9nKTsN CiAJZXhpdCgxKTsNCiB9DQorDQordm9pZCANCithZGp1c3RQTVRVIChjb25z dCB1X2NoYXIgKiBwYWNrZXQpIA0KK3sNCisJc3RydWN0IGlwICogaXAgPSAo c3RydWN0IGlwKilwYWNrZXQ7DQorCXN0cnVjdCBpY21wKiBpY3AgPSAoc3Ry dWN0IGljbXAqKShwYWNrZXQgKyAoaXAtPmlwX2hsIDw8IDIpKTsNCisJaW50 IG10dSA9IChudG9obChpY3AtPmljbXBfdm9pZCkgJiAweGZmZmYpOw0KKw0K KwlQcmludGYoIiAhRjw9JWQgIiwgbXR1KTsNCisJaWYgKG10dSA+IHBhY2ts ZW4pIHsJDQorCQlGcHJpbnRmKHN0ZGVyciwgIlxuUGFja2V0IGFscmVhZHkg c21hbGxlciB0aGFuICVkIVxuIiwgbXR1KTsNCisJCWV4aXQoMSk7DQorCX0N CisJaWYgKG10dSA8IG1pbnBhY2tldCkgew0KKwkJRnByaW50ZihzdGRlcnIs ICJcblJlcXVlc3RlZCBNVFUgdG9vIHNtYWxsIVxuIik7DQorCQlleGl0KDEp Ow0KKwl9DQorCQkJCQ0KKwlwYWNrbGVuID0gbXR1Ow0KKwlQcmludGYoIlJl c2VuZGluZyB3aXRoICVkIGJ5dGUgcGFja2V0czpcbiAgICIsIHBhY2tsZW4p Ow0KKyNpZmRlZiBCWVRFU1dBUF9JUF9MRU4NCisJb3V0aXAtPmlwX2xlbiA9 IGh0b25zKHBhY2tsZW4pOw0KKyNlbHNlDQorCW91dGlwLT5pcF9sZW4gPSBw YWNrbGVuOw0KKyNlbmRpZg0KKwlpZiAoIXVzZWljbXApIA0KKwkgICAgICBv dXR1ZHAtPnVoX3VsZW4gPSBodG9ucygodV9zaG9ydCkocGFja2xlbiAtIChz aXplb2YoKm91dGlwKSArIG9wdGxlbikpKTsNCit9DQorDQorDQo= ---1518334094-1467464121-937339903=:29510 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="traceroute-1.4a5-df.patch" Content-ID: Content-Description: traceroute-1.4a5-df.patch Content-Disposition: attachment; filename="traceroute-1.4a5-df.patch" Content-Transfer-Encoding: BASE64 ZGlmZiAtciAtVTUgdHJhY2Vyb3V0ZS0xLjRhNS5vcmlnL3RyYWNlcm91dGUu YyB0cmFjZXJvdXRlLTEuNGE1L3RyYWNlcm91dGUuYw0KLS0tIHRyYWNlcm91 dGUtMS40YTUub3JpZy90cmFjZXJvdXRlLmMJRnJpIEp1biAxMyAwMzozMDoy NyAxOTk3DQorKysgdHJhY2Vyb3V0ZS0xLjRhNS90cmFjZXJvdXRlLmMJTW9u IE1heSAxMCAxMjozMToxOCAxOTk5DQpAQCAtNTA0LDExICs1MDYsMTEgQEAN CiAjaWZkZWYgQllURVNXQVBfSVBfTEVODQogCW91dGlwLT5pcF9sZW4gPSBo dG9ucyhwYWNrbGVuKTsNCiAjZWxzZQ0KIAlvdXRpcC0+aXBfbGVuID0gcGFj a2xlbjsNCiAjZW5kaWYNCi0Jb3V0aXAtPmlwX29mZiA9IG9mZjsNCisJb3V0 aXAtPmlwX29mZiA9IGh0b25zKG9mZik7DQogCW91dHAgPSAodV9jaGFyICop KG91dGlwICsgMSk7DQogI2lmZGVmIEhBVkVfUkFXX09QVElPTlMNCiAJaWYg KGxzcnIgPiAwKSB7DQogCQlyZWdpc3RlciB1X2NoYXIgKm9wdGxpc3Q7DQoN Cg== ---1518334094-1467464121-937339903=:29510-- From owner-tcp-impl@lerc.nasa.gov Wed Sep 15 13:46:00 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16597 for ; Wed, 15 Sep 1999 13:45:50 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA04307 for tcp-impl-outgoing; Wed, 15 Sep 1999 09:57:24 -0400 (EDT) Received: from calcite.rhyolite.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA04297 for ; Wed, 15 Sep 1999 09:57:21 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id HAA19174 env-from ; Wed, 15 Sep 1999 07:57:12 -0600 (MDT) Date: Wed, 15 Sep 1999 07:57:12 -0600 (MDT) From: Vernon Schryver Message-Id: <199909151357.HAA19174@calcite.rhyolite.com> To: end2end-interest@ISI.EDU, tcp-impl@grc.nasa.gov Subject: Re: TCP's handling of IP precedence Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: Vern Paxson > > > I would agree with Allyn that this sets a terrible precedent. > > In the past, whenever change to TCP was proposed, the answer has been that > > there are millions of existing TCP instances out there so we could not > > change it. > > I'm sorry to say it, but the time to have voiced concerns over this change > was during the IETF Last Call on the diffserv documents. It is too late now > to rescind the fact that the diffserv architecture allows for modification > of the TOS byte in flight. If you think about it for a momenet, that reasoning is obviously incorrect. It assumes that everyone is required to read all IETF documents. Since getting anything changed during Last Call is at best difficult, it requires that everyone participate in all working groups. It also assumes that no recent standards track document is ever wrong or ever needs significant revision. It assumes that DiffServ is more special and unchangable than TCP as defined in RFC 793, which can be freely changed, despite the fact that there are far more RFC 793 implementations and installations than RFC 2474. It provides a procedure for a small part of the IETF to make arbitrary changes to protocols that most of the IETF cares about, simply publish an RFC, sneak it through Last Call, and then make the claim of fait accompli. However, all of that observed, I'm not sure this problem requires major changes to TCP or DiffServ. > We just sent in the I-D on the proposed change to TCP. When it pops > out, I'll send a note to tcp-impl (not end2end-interest, since I think > this change is more closely related to TCP implementation) and we can > continue discussion there. (That said, those wanting an advance peek can > fetch a copy from http://www.aciri.org/vern/draft-xiao-tcp-prec-00.txt.) Instead of requiring changes to an unknown but apparently significant number of existing TCP implementations and literally uncountable TCP installations, why not strengthen the DiffServ words about upward compatibility? If the RFC 1349/RFC 1812 values of the IP TOS byte were required to be get through unchanged (after possibly having been mapped to other values and back again), would any existing combinations of applications and host break? For example, if the most common value, 0, were required to be handed to the receiver if 0 were sent by the sender, wouldn't things be a lot healthier? Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Wed Sep 15 15:37:18 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19084 for ; Wed, 15 Sep 1999 15:37:13 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA18744 for tcp-impl-outgoing; Wed, 15 Sep 1999 11:52:19 -0400 (EDT) Received: from bbmail1.unisys.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA18727 for ; Wed, 15 Sep 1999 11:52:07 -0400 (EDT) Received: from trsvrbk.tr.unisys.com (trsvrbk.tr.unisys.com [192.63.236.1]) by bbmail1.unisys.com (8.8.5/8.8.5) with ESMTP id PAA18553; Wed, 15 Sep 1999 15:51:59 GMT Received: from us-tr-exch-2.tr.unisys.com by trsvrbk.tr.unisys.com (8.8.5/8.8.5) id PAA22600 ; Wed, 15 Sep 1999 15:51:56 GMT Received: by us-tr-exch-2.tr.unisys.com with Internet Mail Service (5.5.2448.0) id ; Wed, 15 Sep 1999 11:49:22 -0400 Message-ID: <236F133B43F4D211A4B00090273C79DC0E0C96@rv-ex-2.rsvl.unisys.com> From: "Smith, Allyn D" To: "'Vernon Schryver'" Cc: end2end-interest@ISI.EDU, tcp-impl@grc.nasa.gov Subject: RE: TCP's handling of IP precedence Date: Wed, 15 Sep 1999 11:51:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk >> From: Vern Paxson >> >> > I would agree with Allyn that this sets a terrible precedent. >> > In the past, whenever change to TCP was proposed, the answer has been that >> > there are millions of existing TCP instances out there so we could not >> > change it. >> >> I'm sorry to say it, but the time to have voiced concerns over this change >> was during the IETF Last Call on the diffserv documents. It is too late now >> to rescind the fact that the diffserv architecture allows for modification >> of the TOS byte in flight. >If you think about it for a momenet, that reasoning is obviously incorrect. >It assumes that everyone is required to read all IETF documents. Since >getting anything changed during Last Call is at best difficult, it requires >that everyone participate in all working groups. It also assumes that no >recent standards track document is ever wrong or ever needs significant >revision. It assumes that DiffServ is more special and unchangable than >TCP as defined in RFC 793, which can be freely changed, despite the fact >that there are far more RFC 793 implementations and installations than >RFC 2474. It provides a procedure for a small part of the IETF to make >arbitrary changes to protocols that most of the IETF cares about, simply >publish an RFC, sneak it through Last Call, and then make the claim of >fait accompli. Nicely put, Vernon. My sentiments precisely. I don't think the precedence change to TCP is really a big deal, but the philosophy and the reasoning that is causing TCP to change bothers me: 1. Emerging DiffServ technology redefines a protocol header field (dangerous proposition at best). 2. It's discovered that header field redefinition in the DiffServ emerging technology (not a standard yet) causes TCPs (a well established, long existing standard) to send resets when they previously did not. 3. DiffServ bug causes undesirable TCP behavior. 4. Fix to DiffServ: change all existing TCPs. Very illogical. DiffServ should have formalized the TCP change before proceeding with the DiffServ implementation. They are very naughty network citizens. _______________________________ Al Smith Unisys 1.651.635.5769 NET 524.5769 Al.Smith@Unisys.Com _______________________________ From owner-tcp-impl@lerc.nasa.gov Wed Sep 15 15:52:37 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19335 for ; Wed, 15 Sep 1999 15:52:37 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA21341 for tcp-impl-outgoing; Wed, 15 Sep 1999 12:16:20 -0400 (EDT) Received: from daffy.ee.lbl.gov (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA21337 for ; Wed, 15 Sep 1999 12:16:19 -0400 (EDT) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id JAA18502; Wed, 15 Sep 1999 09:16:17 -0700 (PDT) Message-Id: <199909151616.JAA18502@daffy.ee.lbl.gov> To: tcp-impl@grc.nasa.gov Subject: Re: TCP's handling of IP precedence In-reply-to: Your message of Wed, 15 Sep 1999 07:57:12 PDT. Date: Wed, 15 Sep 1999 09:16:17 PDT From: Vern Paxson Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Vernon Schryver writes: > If you think about it for a momenet, that reasoning is obviously incorrect. > It assumes that everyone is required to read all IETF documents. That's the point of Last Call - if you care about where the IETF is going, you are supposed to read ietf-announce@ietf.org and see what is being proposed. You don't have to read all the documents, just the ones that appear relevant. The abstract of RFC 2474 is clear that the document is about redefining the TOS byte. > Since getting anything changed during Last Call is at best difficult The WG raised the issue of what depends on the current structure of the TOS byte at length, had considerable discussion, and no one brought up the TCP incompatibility. It's not as though it wasn't high profile - 400+ people attend each diffserv meeting. But even so, it was on the radar as a significant issue, and I think it would have been treated very seriously as a last call comment. > Instead of requiring changes to an unknown but apparently significant > number of existing TCP implementations and literally uncountable TCP > installations, why not strengthen the DiffServ words about upward > compatibility? One of the key questions is: is it really a significant number of TCP implementations? That's why this discussion should happen on tcp-impl. > If the RFC 1349/RFC 1812 values of the IP TOS byte were > required to be get through unchanged (after possibly having been mapped > to other values and back again), would any existing combinations of > applications and host break? How do you know what to map them back to? It's not a one-to-one mapping. Vern From owner-tcp-impl@lerc.nasa.gov Wed Sep 15 15:52:37 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19337 for ; Wed, 15 Sep 1999 15:52:37 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA22018 for tcp-impl-outgoing; Wed, 15 Sep 1999 12:23:12 -0400 (EDT) Received: from daffy.ee.lbl.gov (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA22001 for ; Wed, 15 Sep 1999 12:23:01 -0400 (EDT) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id JAA18565; Wed, 15 Sep 1999 09:22:51 -0700 (PDT) Message-Id: <199909151622.JAA18565@daffy.ee.lbl.gov> To: "Smith, Allyn D" Cc: tcp-impl@grc.nasa.gov Subject: Re: TCP's handling of IP precedence In-reply-to: Your message of Wed, 15 Sep 1999 11:51:53 PDT. Date: Wed, 15 Sep 1999 09:22:51 PDT From: Vern Paxson Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > 1. Emerging DiffServ technology redefines a protocol header field (dangerous > proposition at best). > 2. It's discovered that header field redefinition in the DiffServ emerging > technology (not a standard yet) causes TCPs (a well established, long > existing standard) to send resets when they previously did not. > 3. DiffServ bug causes undesirable TCP behavior. > 4. Fix to DiffServ: change all existing TCPs. > > Very illogical. DiffServ should have formalized the TCP change before > proceeding with the DiffServ implementation. They are very naughty network > citizens. That's not the sequence. It's: 1. Emerging DiffServ technology redefines a protocol header field (dangerous proposition at best). 2. This change is widely publicized and debated. 3. A formal IETF last call occurs saying "here's your last chance to comment on this before it becomes a Proposed Standard." No one raises the TCP problem. 4. Diffserv becomes a Proposed Standard. 5. 6 months later it's discvered that the redefinition causes one TCP to send resets. The email describing this says > As it turns out, this is an archaically (sp) known > problem, with a pre-existing patch. and elicits a reply: > MacTCP is *old*, and has many more problems than > this. Please tell your help desks that if they run > across users still using MacTCP, that they advise > them to upgrade to at least MacOS 7.5.3 (preferably > 7.5.5), which is free, and includes Open > Transport. 6. The question now is how many significant TCPs are actually effected, and, accordingly, how to fix the problem. - Vern From owner-tcp-impl@lerc.nasa.gov Wed Sep 15 16:18:43 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19741 for ; Wed, 15 Sep 1999 16:18:37 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA24805 for tcp-impl-outgoing; Wed, 15 Sep 1999 12:49:04 -0400 (EDT) Received: from eamail1-out.unisys.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA24799 for ; Wed, 15 Sep 1999 12:49:02 -0400 (EDT) Received: from ih85.ea.unisys.com (ih85.ea.unisys.com [192.61.103.85]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id QAA27360; Wed, 15 Sep 1999 16:48:47 GMT Received: from us-slc-exch-2.slc.unisys.com (us-slc-exch-2 [192.60.250.12] (may be forged)) by ih85.ea.unisys.com (8.9.3/8.9.3) with ESMTP id QAA19094; Wed, 15 Sep 1999 16:48:55 GMT Received: by us-slc-exch-2 with Internet Mail Service (5.5.2448.0) id ; Wed, 15 Sep 1999 10:52:38 -0600 Message-ID: <236F133B43F4D211A4B00090273C79DC0E0C99@rv-ex-2.rsvl.unisys.com> From: "Smith, Allyn D" To: "'Vern Paxson'" Cc: tcp-impl@grc.nasa.gov Subject: RE: TCP's handling of IP precedence Date: Wed, 15 Sep 1999 10:48:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Sorry for the sarcastic tone in my last message. I don't, and can't, read and debate everything that is published. I was blind-sided by the redefinition of the TOS byte, causing me to be defensive. The sequence of events I stated was as I saw them from my blind-sided perspective, however, I am aware of the official standards track. It appears that the TCP change to ignore the precedence is probably the compromise required to resolve this problem. Al Smith -----Original Message----- From: Vern Paxson [mailto:vern@ee.lbl.gov] Sent: Wednesday, September 15, 1999 11:23 AM To: Smith, Allyn D Cc: tcp-impl@grc.nasa.gov Subject: Re: TCP's handling of IP precedence > 1. Emerging DiffServ technology redefines a protocol header field (dangerous > proposition at best). > 2. It's discovered that header field redefinition in the DiffServ emerging > technology (not a standard yet) causes TCPs (a well established, long > existing standard) to send resets when they previously did not. > 3. DiffServ bug causes undesirable TCP behavior. > 4. Fix to DiffServ: change all existing TCPs. > > Very illogical. DiffServ should have formalized the TCP change before > proceeding with the DiffServ implementation. They are very naughty network > citizens. That's not the sequence. It's: 1. Emerging DiffServ technology redefines a protocol header field (dangerous proposition at best). 2. This change is widely publicized and debated. 3. A formal IETF last call occurs saying "here's your last chance to comment on this before it becomes a Proposed Standard." No one raises the TCP problem. 4. Diffserv becomes a Proposed Standard. 5. 6 months later it's discvered that the redefinition causes one TCP to send resets. The email describing this says > As it turns out, this is an archaically (sp) known > problem, with a pre-existing patch. and elicits a reply: > MacTCP is *old*, and has many more problems than > this. Please tell your help desks that if they run > across users still using MacTCP, that they advise > them to upgrade to at least MacOS 7.5.3 (preferably > 7.5.5), which is free, and includes Open > Transport. 6. The question now is how many significant TCPs are actually effected, and, accordingly, how to fix the problem. - Vern From owner-tcp-impl@lerc.nasa.gov Wed Sep 15 19:07:40 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21979 for ; Wed, 15 Sep 1999 19:07:27 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA15781 for tcp-impl-outgoing; Wed, 15 Sep 1999 15:33:35 -0400 (EDT) Received: from calcite.rhyolite.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA15758 for ; Wed, 15 Sep 1999 15:33:28 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id NAA25200 for tcp-impl@grc.nasa.gov env-from ; Wed, 15 Sep 1999 13:33:07 -0600 (MDT) Date: Wed, 15 Sep 1999 13:33:07 -0600 (MDT) From: Vernon Schryver Message-Id: <199909151933.NAA25200@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: TCP's handling of IP precedence Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: Vern Paxson > ... > 5. 6 months later it's discvered that the redefinition causes one > TCP to send resets. The email describing this says > > > As it turns out, this is an archaically (sp) known > > problem, with a pre-existing patch. > > and elicits a reply: > > > MacTCP is *old*, and has many more problems than > > this. Please tell your help desks that if they run > > across users still using MacTCP, that they advise > > them to upgrade to at least MacOS 7.5.3 (preferably > > 7.5.5), which is free, and includes Open > > Transport. See also the note this morning from someone reporting about what sounds like the same problem with some Windows TCP code. If only ancient MacTCP had the problem, you might, but only might get away with declaring old MacTCP non-conformant. That is basically what you are proposing, to break an unknown number of existing implementations and installations. > 6. The question now is how many significant TCPs are actually > effected, and, accordingly, how to fix the problem. Agreed. However, on general grounds the fait accompli argument is completely inadmissable. 400 people participating in DiffServ meetings are not a majority of the IETF, even if majorities mattered, which they don't. Even if you accept the history as you have stated it (which I don't quite), the onus for bearing fixing the problem lies with DiffServe, *NOT* TCP. If a painless change can be made to TCP, then that would be great, and would remove the burden from DiffServ. If there is no painless TCP fix, then the pain *MUST* be borne by DiffServ. ] From: Vern Paxson ] That's the point of Last Call - if you care about where the IETF is going, ] you are supposed to read ietf-announce@ietf.org and see what is being ] proposed. You don't have to read all the documents, just the ones that ] appear relevant. The abstract of RFC 2474 is clear that the document is ] about redefining the TOS byte. That is mistaken in several ways. Even if the Last Call had said something about breaking existing TCP, the onus would still be on DiffServ. However, given the established IETF culture and expectations, something that talks about redefining the TOS byte would be assumed by knowledgable people to upward compatiable and not break existing installations without explicitly saying so, and not without a lot more main IETF list discussion than the last call. By concidence, I had been trying to understand RFC 2474 before all of this broke, and had assumed the intent of RFC 2474 was to be upward compatible. The words in RFC 2474 are not entirely clear, but they do promise significant upward compatibility. Consider the start of section 4: The DS field will have a limited backwards compatibility with current practice, as described in this section. Backwards compatibility is addressed in two ways. First, there are per-hop behaviors that are already in widespread use (e.g., those satisfying the IPv4 Precedence queueing requirements specified in [RFC1812]), and we wish to permit their continued use in DS-compliant nodes. ... ] > Since getting anything changed during Last Call is at best difficult ] ] The WG raised the issue of what depends on the current structure of the TOS ] byte at length, had considerable discussion, and no one brought up the TCP ] incompatibility. It's not as though it wasn't high profile - 400+ people ] attend each diffserv meeting. But even so, it was on the radar as a ] significant issue, and I think it would have been treated very seriously ] as a last call comment. I am confident of the good intentions of all concerned. Still, when balancing painful changes, which sub-community (or if you prefer, chunks of code) must suffer most of the pain? ] > Instead of requiring changes to an unknown but apparently significant ] > number of existing TCP implementations and literally uncountable TCP ] > installations, why not strengthen the DiffServ words about upward ] > compatibility? ] ] One of the key questions is: is it really a significant number of TCP ] implementations? That's why this discussion should happen on tcp-impl. I agree that is a critical question. The note this morning about Windows 3.1 was extremely worrisome. ] > If the RFC 1349/RFC 1812 values of the IP TOS byte were ] > required to be get through unchanged (after possibly having been mapped ] > to other values and back again), would any existing combinations of ] > applications and host break? ] ] How do you know what to map them back to? It's not a one-to-one mapping. Which map is not 1:1 and does it matter? Since RFC 2474 defines a lot more potential behaviors than RFC 1812 and RFCX 1349, you obviously cannot map DiffServ 1:1 onto RFC 1349. However, in practice there are only about 3 different RFC 1349 values. It seems to me that requiring that DiffServ preserve 3 values would completely would be painless for DiffServ, and far wiser than declaring that an unknowable number of TCP implementations and installations non-conformant and requiring them to be changed. I think the only commonly used RFC 1349 values are 0 (extremely common), 0x10 (minimize delay), and 0x80 (maximize throughput). See your nearest BSD source trees. I found all of those in the first 4.4BSD-Lite CDROM, and I know that 0x10 has been creeping into other widely used applications, partly because I've helped push it. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Wed Sep 15 19:51:54 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22370 for ; Wed, 15 Sep 1999 19:51:54 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA23855 for tcp-impl-outgoing; Wed, 15 Sep 1999 16:50:38 -0400 (EDT) Received: from tnt.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA23849 for ; Wed, 15 Sep 1999 16:50:37 -0400 (EDT) Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA04154; Wed, 15 Sep 1999 13:50:33 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id NAA28963; Wed, 15 Sep 1999 13:50:33 -0700 (PDT) Date: Wed, 15 Sep 1999 13:50:33 -0700 (PDT) Message-Id: <199909152050.NAA28963@rum.isi.edu> To: tcp-impl@grc.nasa.gov, vjs@calcite.rhyolite.com Subject: Re: TCP's handling of IP precedence X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Date: Wed, 15 Sep 1999 13:33:07 -0600 (MDT) > From: Vernon Schryver > To: tcp-impl@grc.nasa.gov > Subject: Re: TCP's handling of IP precedence > > > From: Vern Paxson > > ... > > 5. 6 months later it's discvered that the redefinition causes one > > TCP to send resets. The email describing this says > > > > > As it turns out, this is an archaically (sp) known > > > problem, with a pre-existing patch. > > > > and elicits a reply: > > > > > MacTCP is *old*, and has many more problems than > > > this. I wouldn't describe implementing the existing standards correctly, as known at the time, and presently, as a problem. > > 6. The question now is how many significant TCPs are actually > > effected, and, accordingly, how to fix the problem. > > Agreed. > > However, on general grounds the fait accompli argument is completely > inadmissable. 400 people participating in DiffServ meetings are not a > majority of the IETF, even if majorities mattered, which they don't. > Even if you accept the history as you have stated it (which I don't quite), > the onus for bearing fixing the problem lies with DiffServe, *NOT* TCP. > If a painless change can be made to TCP, then that would be great, and > would remove the burden from DiffServ. If there is no painless TCP fix, > then the pain *MUST* be borne by DiffServ. I agree heartily. There are way too many groups in the IETF to follow all of what all groups are doing, even if they go to last call. It _must_ be the onus of the group proposing the change to inform and seek input from other communities that the change would affect. If this document proposes to change IP TOS and doesn't address how it affects existing standards, it is _they_ who should have read, understood, and addressed these problems _before_ going to proposed draft. Sounds like time to unravel the standards track chain a little and back up here. Joe From owner-tcp-impl@lerc.nasa.gov Wed Sep 15 19:52:26 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22382 for ; Wed, 15 Sep 1999 19:52:25 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA23429 for tcp-impl-outgoing; Wed, 15 Sep 1999 16:45:27 -0400 (EDT) Received: from eta.ghs.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA23425 for ; Wed, 15 Sep 1999 16:45:25 -0400 (EDT) Received: [from random.teraflop.com (random.teraflop.com [192.67.158.207]) by eta.ghs.com (eta-antispam 0.2) with ESMTP id NAA07949; Wed, 15 Sep 1999 13:45:01 -0700 (PDT)] Received: (from ross@localhost) by random.teraflop.com (8.8.8/8.8.8) id NAA04854; Wed, 15 Sep 1999 13:45:00 -0700 (PDT) Date: Wed, 15 Sep 1999 13:45:00 -0700 (PDT) From: Ross Harvey Message-Id: <199909152045.NAA04854@random.teraflop.com> To: Al.Smith@UNISYS.com, vjs@calcite.rhyolite.com Subject: RE: TCP's handling of IP precedence Cc: end2end-interest@ISI.EDU, tcp-impl@grc.nasa.gov Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: Vern Paxson > > > I would agree with Allyn that this sets a terrible precedent. > > In the past, whenever change to TCP was proposed, the answer has been that > > there are millions of existing TCP instances out there so we could not > > change it. > > I'm sorry to say it, but the time to have voiced concerns over this change > was during the IETF Last Call on the diffserv documents. It is too late now > to rescind the fact that the diffserv architecture allows for modification > of the TOS byte in flight. Speaking unofficially from an embedded-SW supplier with a network stack, I have to say "resolve this like engineers and scientists, not lawyers". I mean, others could respond with "the time to have voiced concerns over TCP TOS was in 1981". To attempt to squelch the technical complaints and interoperation concerns with a lawyer-type "sorry, too late" response is not, I hope, the way IETF debates will go in the future. The "just upgrade" argument is dangerous. A relatively new GHS product element is a TCP exclusively deployed in embedded systems. It doesn't have the MacTCP problem, but it could have. It's also annoying to hear "just upgrade" after all the hype about internet protocol appliances and networked embedded systems. If the IETF doesn't really mean that, come out and say it: "It's only for desktops and servers running supported and upgradable SW." Now, perhaps the diffserv steamroller is all worth it. My point isn't that diffserv should change and not TCP, it's that this argument needs to be decided on technical merits and not by hiding behind administrative procedure, and that the "just upgrade" argument should be used with care. How, exactly, do you propose to test compatibility with embedded systems? It's going to be hard, which is why we usually just make compatible extensions. Ross Harvey Green Hills Software From owner-tcp-impl@lerc.nasa.gov Wed Sep 15 20:26:51 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22635 for ; Wed, 15 Sep 1999 20:26:51 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA27288 for tcp-impl-outgoing; Wed, 15 Sep 1999 17:30:02 -0400 (EDT) Received: from bbmail1.unisys.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA27273 for ; Wed, 15 Sep 1999 17:30:00 -0400 (EDT) Received: from trsvrbk.tr.unisys.com (trsvrbk.tr.unisys.com [192.63.236.1]) by bbmail1.unisys.com (8.8.5/8.8.5) with ESMTP id VAA12859; Wed, 15 Sep 1999 21:29:54 GMT Received: from us-tr-exch-2.tr.unisys.com by trsvrbk.tr.unisys.com (8.8.5/8.8.5) id VAA26659 ; Wed, 15 Sep 1999 21:07:49 GMT Received: by us-tr-exch-2.tr.unisys.com with Internet Mail Service (5.5.2448.0) id ; Wed, 15 Sep 1999 17:05:14 -0400 Message-ID: <236F133B43F4D211A4B00090273C79DC0E0C9B@rv-ex-2.rsvl.unisys.com> From: "Smith, Allyn D" To: "'Vern Paxson'" Cc: tcp-impl@grc.nasa.gov Subject: RE: TCP's handling of IP precedence Date: Wed, 15 Sep 1999 17:07:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk All of the arguments presented on how DiffServ got to this point are good ones, yet, through all of the formal processes, postings, and debates, this one issue of TCPs handling of IP precedence still remains. The result of the formal process is that the DiffServ design overlooked/ignored/didn't-fully-comprehend the impact of something and now potentially many applications and TCP implementations may pay the penalty. I'm not saying the formal process was wrong, but maybe there was something missing from it. I understand that it's probably too late to change the DiffServ spec now, but perhaps we can learn something from this. From what I can tell, several red flags went up that should have caused a closer scrutiny on the impact of the DiffServ DS field: 1. Redefining a long existing protocol header byte. This one is a big red flag. This should rarely be allowed. Because the proper use of the precedence bits was somewhat weakly defined, you are bound to get many variations in the enforcement and handling of those bits. 2. Redefining a long existing protocol header byte defined by the DoD. Bigger red flag. 3. When it was discovered that even one TCP checked the precedence, it should have triggered the thought: "Hey, here's a TCP that enforces the precedence validation so, I wonder if there might be others?" I also monitor the end2end-interest and tcp-impl lists and don't recall seeing any mention of the redefinition of the TOS byte. Oh well. Sigh... I'm off to making sure my TCP's comply with the new definition. Al Smith -----Original Message----- From: Vern Paxson [mailto:vern@ee.lbl.gov] Sent: Wednesday, September 15, 1999 11:16 AM To: tcp-impl@grc.nasa.gov Subject: Re: TCP's handling of IP precedence Vernon Schryver writes: > If you think about it for a momenet, that reasoning is obviously incorrect. > It assumes that everyone is required to read all IETF documents. That's the point of Last Call - if you care about where the IETF is going, you are supposed to read ietf-announce@ietf.org and see what is being proposed. You don't have to read all the documents, just the ones that appear relevant. The abstract of RFC 2474 is clear that the document is about redefining the TOS byte. > Since getting anything changed during Last Call is at best difficult The WG raised the issue of what depends on the current structure of the TOS byte at length, had considerable discussion, and no one brought up the TCP incompatibility. It's not as though it wasn't high profile - 400+ people attend each diffserv meeting. But even so, it was on the radar as a significant issue, and I think it would have been treated very seriously as a last call comment. > Instead of requiring changes to an unknown but apparently significant > number of existing TCP implementations and literally uncountable TCP > installations, why not strengthen the DiffServ words about upward > compatibility? One of the key questions is: is it really a significant number of TCP implementations? That's why this discussion should happen on tcp-impl. > If the RFC 1349/RFC 1812 values of the IP TOS byte were > required to be get through unchanged (after possibly having been mapped > to other values and back again), would any existing combinations of > applications and host break? How do you know what to map them back to? It's not a one-to-one mapping. Vern From owner-tcp-impl@lerc.nasa.gov Wed Sep 15 22:17:31 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24265 for ; Wed, 15 Sep 1999 22:17:30 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA02878 for tcp-impl-outgoing; Wed, 15 Sep 1999 19:07:19 -0400 (EDT) Received: from newdev.harvard.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA02872 for ; Wed, 15 Sep 1999 19:07:17 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id TAA10035; Wed, 15 Sep 1999 19:07:16 -0400 (EDT) Date: Wed, 15 Sep 1999 19:07:16 -0400 (EDT) From: Scott Bradner Message-Id: <199909152307.TAA10035@newdev.harvard.edu> To: tcp-impl@grc.nasa.gov, vjs@calcite.rhyolite.com Subject: Re: TCP's handling of IP precedence Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > I think the only commonly used RFC 1349 values are 0 (extremely common), > 0x10 (minimize delay), and 0x80 (maximize throughput). what about the other side of the coin - what level of support is there in the current Internet infrastructure for these? Scott From owner-tcp-impl@lerc.nasa.gov Wed Sep 15 22:48:28 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25340 for ; Wed, 15 Sep 1999 22:48:28 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA05011 for tcp-impl-outgoing; Wed, 15 Sep 1999 19:53:30 -0400 (EDT) Received: from calcite.rhyolite.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA05006 for ; Wed, 15 Sep 1999 19:53:28 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id RAA29875 for tcp-impl@grc.nasa.gov env-from ; Wed, 15 Sep 1999 17:53:26 -0600 (MDT) Date: Wed, 15 Sep 1999 17:53:26 -0600 (MDT) From: Vernon Schryver Message-Id: <199909152353.RAA29875@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: TCP's handling of IP precedence Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: Scott Bradner > > I think the only commonly used RFC 1349 values are 0 (extremely common), > > 0x10 (minimize delay), and 0x80 (maximize throughput). > > what about the other side of the coin - what level of support is > there in the current Internet infrastructure for these? What do you mean by "current Internet infrastructure"? While what the 500-1000 biggest routers in the Internet might do is interesting, there are other important areas. I count at least the following: 1. corporate WANs 2. LANs ranging from a handful to a gross of 802.3, FDDI, HIPPI, etc. nets 3. embedded systems 4. paths between hosts on The Intenret. Surveying all of those sounds hard. However, if you look at the first 4.4BSD-Lite CDROM, you'll find that the SLIP driver looks for 0x10 (low delay). I think my PPP code is far from the only PPP to support TOS queuing. I think I've seen requirements documents for Tbit/sec routers that mentioned support for TOS queuing (but maybe they'll end up doing DiffServ). Cisco was slow to support TOS queuing, but I think it's been in the IOS for at least 2 and maybe 4 years. Note that where TOS queuing is most important in The Internet is the opposite of where (I think) DiffServ is important. People keep talking about charging different $$$ rates based on DiffServ bits, and that matters where streams from many customers meet. TOS queuing matters most where the queues are longest, and that happens where the link speed differences are highest, at the edges in the remote access servers. The owner of the canonical Ascend PPP ISDN or modem box won't care how the customer's bits are marked, but the customer does care about seeing telnet and NTP queued ahead of FTP data. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Wed Sep 15 23:01:28 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25464 for ; Wed, 15 Sep 1999 23:01:27 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA05978 for tcp-impl-outgoing; Wed, 15 Sep 1999 20:15:36 -0400 (EDT) Received: from calcite.rhyolite.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAA05970 for ; Wed, 15 Sep 1999 20:15:33 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id SAA00852 for tcp-impl@grc.nasa.gov env-from ; Wed, 15 Sep 1999 18:15:32 -0600 (MDT) Date: Wed, 15 Sep 1999 18:15:32 -0600 (MDT) From: Vernon Schryver Message-Id: <199909160015.SAA00852@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: RE: TCP's handling of IP precedence Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: "Smith, Allyn D" > .... I understand that it's probably too late to change the > DiffServ spec now, but perhaps we can learn something from this. > ... If it is not too late to change RFC 793, then how can it be too late to change RFC 2474? Does the fact that RFC 793 is about 10 times older and at least 10,000,000 times more widely implemented really mean that RFC 2474 is the one that cannot be changed? SHEESH! Let's agree that there is a problem, and set out to solve it with the minimum overall pain, but with the onus for bearing most of any unavoidable pain on DiffServ. ] From: Grenville Armitage ] ... ] Seems to me that the 'failure' is a TCP-based application believing ] it is operating over a path that uses Precedence values e2e to ] provide service differentiation, when in fact the path does not. That confuses the new notion of DiffServ with the old TOS definition. Under the old rules, it was perfectly reasonable for some routers in the path to pay attention to the TOS bits while other routers ignored them. ] There are also three 'solutions' that dont require TCP mods: ] ] - Apps dont get smart - leave precedence as 000, and DS ] regions default to re-mapping the lower 3 bits ] of the DSCP to 000 on egress. That solution is impossible, because there are already "smart," very widely deployed applications. Please note again what you will find if you search the nearest BSD source tree for "TOS_" That solution also does not help purely dumb applications whose TCP connections break because newfangled DiffServe routers in the path don't all agree on how to map 0x00, and the path varies as a result of dynamic routing. ] - Apps that want to be 'smart' take their chances. That also doesn't help those dumb applications whose TCP connections break. It also seems unfair to smart applications that have been deployed in the last seven (7) years to use TOS queuing as suggested by RFC 1349. ] - Apps request 'precedence bits' that happen to be the same ] as lower 3 bits of the DSCP the DS region will assign on ] ingress. ] ] Although the third option begs some obvious questions, all in ] all it might be easier to start with the above 'usage rules' than ] to insist all TCP stacks are upgraded. I'm not sure I understand what is meant by that. The talk of PHB's and router TOS bits in RFC 2474 also makes little sense to me. The words in RFC 2474 about mapping TOS values seems to be based on the obviously false notion that only 0 and the "router" TOS values were ever used. If you mean something that includes the idea that 0x00, 0x10, and 0x08 would be somehow carried unchange from host to host (but with possible intermediate changes to other values), then that's what I've been trying to say. ] There is also the ugly fourth option: ] ] - If a DS region sees packets arriving with non-zero ] precedence values, the packets are tunneled to the ] likely egress from the DS region, with only the outer ] header having its TOS/DS field twiddled. Let's not, if only because that doesn't help dumb applications using 0 whose TCP connections are broken when 0 is mapped to non-0. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Wed Sep 15 23:55:33 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26115 for ; Wed, 15 Sep 1999 23:55:32 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA07772 for tcp-impl-outgoing; Wed, 15 Sep 1999 21:06:05 -0400 (EDT) Received: from tnt.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA07767 for ; Wed, 15 Sep 1999 21:06:04 -0400 (EDT) Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA29846; Wed, 15 Sep 1999 18:06:01 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id SAA29807; Wed, 15 Sep 1999 18:06:01 -0700 (PDT) Date: Wed, 15 Sep 1999 18:06:01 -0700 (PDT) Message-Id: <199909160106.SAA29807@rum.isi.edu> To: touch@ISI.EDU, alan@globalcenter.net Subject: Re: TCP's handling of IP precedence Cc: tcp-impl@grc.nasa.gov, vjs@calcite.rhyolite.com X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From alan@vauxhall.isi.net Wed Sep 15 17:58:27 1999 > Delivery-Date: Wed, 15 Sep 1999 17:58:27 -0700 > Return-Path: alan@vauxhall.isi.net > Date: Wed, 15 Sep 1999 17:58:29 -0700 > From: Alan Hannan > To: Joe Touch > Cc: tcp-impl@grc.nasa.gov, vjs@calcite.rhyolite.com > Subject: Re: TCP's handling of IP precedence > > > > If this document proposes to change IP TOS and doesn't address > > how it affects existing standards, it is _they_ who should have > > read, understood, and addressed these problems _before_ going to > > proposed draft. > > There's lots of good discussion going on, and I'm glad that people > are giving this issue the focus it deserves. ... > Without this functionality, QOS w/ native IP is exceedingly > more difficult. ... > I wonder about the actual meaning and interpretation of the RFC > given the rare implementation. But what about the reason behind TCP's spec... The idea behind TCP aborting the connection when the TOS bits change is that a property of the connection has changed after being negotiated. Is it the case that Diffserv: - intends these bits to be used for TCP connections? - intends that they change after a connection is established? or would that constitute the need for a TCP extension to renegotiate? Joe From owner-tcp-impl@lerc.nasa.gov Thu Sep 16 00:26:49 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26346 for ; Thu, 16 Sep 1999 00:26:48 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA08300 for tcp-impl-outgoing; Wed, 15 Sep 1999 21:19:49 -0400 (EDT) Received: from mailcarrier.snv1.gctr.net (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA08296 for ; Wed, 15 Sep 1999 21:19:48 -0400 (EDT) Received: from pobox.snv1.gctr.net (pobox.snv1.gctr.net [204.71.194.242]) by mailcarrier.snv1.gctr.net (8.9.3/8.9.0) with ESMTP id BAA08711; Thu, 16 Sep 1999 01:19:46 GMT Received: from vauxhall.isi.net (vauxhall.isi.net [208.48.114.38]) by pobox.snv1.gctr.net (8.9.3/8.9.1) with ESMTP id BAA13115; Thu, 16 Sep 1999 01:19:46 GMT Received: (from alan@localhost) by vauxhall.isi.net (8.8.8/8.8.8) id SAA13158; Wed, 15 Sep 1999 18:19:50 -0700 (PDT) Date: Wed, 15 Sep 1999 18:19:50 -0700 From: Alan Hannan To: Joe Touch Cc: tcp-impl@grc.nasa.gov, vjs@calcite.rhyolite.com Subject: Re: TCP's handling of IP precedence Message-ID: <19990915181950.E12989@globalcenter.net> References: <199909160106.SAA29807@rum.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199909160106.SAA29807@rum.isi.edu>; from Joe Touch on Wed, Sep 15, 1999 at 06:06:01PM -0700 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > But what about the reason behind TCP's spec... > > The idea behind TCP aborting the connection when > the TOS bits change is that a property of the > connection has changed after being negotiated. I'm not sure that's entirely the case, but it sounds very reasonable and I don't know it NOT to be the case. > Is it the case that Diffserv: > > - intends these bits to be used for TCP connections? No. > - intends that they change after a connection is established? > or would that constitute the need for > a TCP extension to renegotiate? Kind of, but not really. Rather, Diffserv intends that they change while the connection is being established. Remember that what happens is that the initiator tries to setup a tcp session w/ TOS=0; but en route to the receiver, a router changes the DS bits from the original [as specificed by the initiator] to something else. The receiver then 'plays along' because he doesn't know any better, and the initiator doesn't get back what he wants, so he breaks the connection. Ideally, the 'initiator' would negotiate the TOS w/ the receiver, but this doesn't happen. -alan From owner-tcp-impl@lerc.nasa.gov Thu Sep 16 00:31:56 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26436 for ; Thu, 16 Sep 1999 00:31:55 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA08441 for tcp-impl-outgoing; Wed, 15 Sep 1999 21:23:07 -0400 (EDT) Received: from tnt.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA08435 for ; Wed, 15 Sep 1999 21:23:06 -0400 (EDT) Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA00985; Wed, 15 Sep 1999 18:23:03 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id SAA29842; Wed, 15 Sep 1999 18:23:02 -0700 (PDT) Date: Wed, 15 Sep 1999 18:23:02 -0700 (PDT) Message-Id: <199909160123.SAA29842@rum.isi.edu> To: touch@ISI.EDU, alan@globalcenter.net Subject: Re: TCP's handling of IP precedence Cc: tcp-impl@grc.nasa.gov, vjs@calcite.rhyolite.com X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: Alan Hannan > To: Joe Touch > Cc: tcp-impl@grc.nasa.gov, vjs@calcite.rhyolite.com > Subject: Re: TCP's handling of IP precedence > > > Is it the case that Diffserv: > > > > - intends these bits to be used for TCP connections? > > No. > > > - intends that they change after a connection is established? > > or would that constitute the need for > > a TCP extension to renegotiate? > > Kind of, but not really. I don't understand how the first question can be a "No" and the second question is relevant. However... > > Rather, Diffserv intends that they change while the connection is > being established. > > Remember that what happens is that the initiator tries to setup a > tcp session w/ TOS=0; but en route to the receiver, a router > changes the DS bits from the original [as specificed by the > initiator] to something else. The receiver then 'plays along' > because he doesn't know any better, and the initiator doesn't get > back what he wants, so he breaks the connection. > > Ideally, the 'initiator' would negotiate the TOS w/ the receiver, > but this doesn't happen. Why shouldn't this happen like ICMP redirects or PMTU - some sort of NACK at the ICMP level to the source? I.e., "ideally, the initiator would negotiate with the network, then ask the receiver for something known"... ?? Joe From owner-tcp-impl@lerc.nasa.gov Thu Sep 16 01:37:05 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00634 for ; Thu, 16 Sep 1999 01:36:50 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA10606 for tcp-impl-outgoing; Wed, 15 Sep 1999 22:15:41 -0400 (EDT) Received: from mailcarrier.snv1.gctr.net (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA10595 for ; Wed, 15 Sep 1999 22:15:35 -0400 (EDT) Received: from pobox.snv1.gctr.net (pobox.snv1.gctr.net [204.71.194.242]) by mailcarrier.snv1.gctr.net (8.9.3/8.9.0) with ESMTP id CAA13327; Thu, 16 Sep 1999 02:15:29 GMT Received: from vauxhall.isi.net (vauxhall.isi.net [208.48.114.38]) by pobox.snv1.gctr.net (8.9.3/8.9.1) with ESMTP id CAA16074; Thu, 16 Sep 1999 02:15:28 GMT Received: (from alan@localhost) by vauxhall.isi.net (8.8.8/8.8.8) id TAA13351; Wed, 15 Sep 1999 19:15:32 -0700 (PDT) Date: Wed, 15 Sep 1999 19:15:32 -0700 From: Alan Hannan To: Joe Touch Cc: tcp-impl@grc.nasa.gov, vjs@calcite.rhyolite.com Subject: Re: TCP's handling of IP precedence Message-ID: <19990915191531.F12989@globalcenter.net> References: <199909160123.SAA29842@rum.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199909160123.SAA29842@rum.isi.edu>; from Joe Touch on Wed, Sep 15, 1999 at 06:23:02PM -0700 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > > > Is it the case that Diffserv: > > > > > > - intends these bits to be used for TCP connections? > > > > No. > I don't understand how the first question can be > a "No" and the second question is relevant. I think I was focused on the tree instead of the forest. Yes, Diffserv intends for these bits to be used to differentiate service levels of TCP connections, as a non-specific subset of IP traffic. I interpreted your question to mean that Diffserv intended the bits to be a component of the connection setup. > > Rather, Diffserv intends that they change while the connection is > > being established. > > > > Remember that what happens is that the initiator tries to setup a > > tcp session w/ TOS=0; but en route to the receiver, a router > > changes the DS bits from the original [as specificed by the > > initiator] to something else. The receiver then 'plays along' > > because he doesn't know any better, and the initiator doesn't get > > back what he wants, so he breaks the connection. > > > > Ideally, the 'initiator' would negotiate the TOS w/ the receiver, > > but this doesn't happen. > > Why shouldn't this happen like ICMP redirects or PMTU - some sort > of NACK at the ICMP level to the source? One reason is that the quality of the traffic is non-relevant to the connection; ie; IP is connection-less; so failure to be granted a given traffic quality should not inhibit the connection, as a function of the protocol. > I.e., "ideally, the initiator would negotiate with the network, > then ask the receiver for something known"... Yes, this is one approach, but _that_ change to the tcp spec is far more reaching than the one we're proposing :-) -alan From owner-tcp-impl@lerc.nasa.gov Thu Sep 16 01:54:09 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01578 for ; Thu, 16 Sep 1999 01:53:59 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA11522 for tcp-impl-outgoing; Wed, 15 Sep 1999 22:43:06 -0400 (EDT) Received: from berserkly.bsdi.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA11509; Wed, 15 Sep 1999 22:43:00 -0400 (EDT) Received: from berserkly.bsdi.com (localhost.pe1hzg.ampr.org [127.0.0.1]) by berserkly.bsdi.com (8.9.0/8.9.0) with ESMTP id EAA04722; Thu, 16 Sep 1999 04:41:10 +0200 (CEST) Message-Id: <199909160241.EAA04722@berserkly.bsdi.com> To: mallman@grc.nasa.gov cc: tcp-impl@grc.nasa.gov, "Vern Paxson" , kml@novell.com From: Geert Jan de Groot Subject: Re: TCP Problems with Path MTU Discovery In-reply-to: Your message of "Mon, 13 Sep 1999 22:02:28 EDT." <199909140202.WAA01162@tuvok.lerc.nasa.gov> Date: Thu, 16 Sep 1999 04:39:42 +0200 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Mon, 13 Sep 1999 22:02:28 -0400 Mark Allman wrote: > Vern and I believe the pmtud I-D is nearing the point where we can > issue a last call and boot it up to the IESG. I sent a list of comments on May 28 to tcp-impl but didn't see them reflected in the -02 draft (nor responses that they shouldn't be changed). I'm appending my original message below for your convienence. I realise that the draft says 'configuration errors' but really would like to make a case for listing them more explicitely, this is an operational rather than an implementation matter and it just happens too often... Geert Jan ---- Date: Fri, 28 May 1999 00:58:11 +0200 To: tcp-impl@grc.nasa.gov From: Geert Jan de Groot Subject: Comments on draft-ietf-tcpimpl-pmtud-01.txt I would like to make a couple of comments on the Path MTU Discovery Problems draft, and perhaps have a little discussion on it. First, a quicky at the end of the document: >3.3. Determining MSS from PMTU ... > The MSS advertised at the start of a connection should be based on ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the MTU of the interfaces on the system. Some systems use PMTUD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > determined values to determine the MSS to advertise. > This results in an advertised MSS that is smaller than the largest > MTU the system can receive. I would like to change the marked sentence with: The MSS advertised at the start of a connection should be based on the largest MTU of all interfaces on the system. Rationale: assume a TCP connect happens over an ethernet interface. While the TCP session is alive, routing changes and the session is now routed over an FDDI interface. If mss would have been 1460 (ethernet), we would see micrograms on the FDDI interface unneccesary. I just want to make the original text more explicit, that's all. Then the real issue: >3.1. Black Hole Detection ... > Path MTU Discovery (PMTUD) works by sending out as large a packet > as possible, with the Don't Fragment (DF) bit set in the IP header. > If the packet is too large for a router to forward on to a particu- > lar link, the router must send an ICMP Destination Unreachable -- > Fragmentation Needed message to the source address. > > As was pointed out in [RFC1435], routers don't always do this cor- > rectly -- many routers fail to send the ICMP messages, for a vari- > ety of reasons ranging from kernel bugs to configuration problems. > Firewalls are often misconfigured to supress all ICMP messages. > > PMTUD, as documented in [RFC1191], fails when confronted with this > problem. The upper-layer protocol continues to try to send large > packets and, without the ICMP messages, never discovers that it > needs to reduce the size of those packets. Its packets are disap- > pearing into a PMTUD black hole. I would like to make things more explicit by adding another scenario, one that I'm seeing every few weeks, and which IMHO warrants either explicit mentioning in an RFC. This is a typical scenario: - Many ISP's now run with MTU~4470 in their cloud, also on serial lines to their customers; - An uncreasing number of webfarms apperently allow this large an MTU all the way to the web server; - Assume a typical customer of such an ISP, using a Cisco box with Cisco-HDLC framing (which apperently doesn't catch MTU mismatches). Customer has a cache box with ethernet (to the Cisco), and FDDI (to the internal network), and hence MSS = 4352 - 40 = 4312 bytes. - Note that the default MTU on Cisco serial lines is 1500 bytes. If the customer surfs to such a high-MTU site, we see the SYN exchange, the HTTP request gets sent, but data never arrives at the cache. Investigation reveals that large packets are sent on the serial line to the customer router, however because it's configured for smaller MTU, this packet overruns the input buffer, so the packet is dropped (and the giants error counter is bumped up). It is important to note that, since the packet is not received correctly, no ICMP message is sent, and therefore we have a blackhole scenario. In defense I must mention that if the ISP sets up the customer router, the serial line is configured with the correct MTU, however chances are that the customer sets up the router himself, the configuration is lost at an upgrade or otherwise. We see this kind of problem as a support case every few weeks; I have poked a bit around and there are numerous places where this potential problem currently exists (but is masked in practive by a 1500-MTU hop somewhere in the field). >Implications > This failure is especially difficult to debug, as pings and some > interactive TCP connections to the destination host work. Bulk > transfers fail with the first large packet and the connection even- > tually times out. Note however, that it is possible to diagnose this by pinging with large packets: from the customer, try to ping the Cisco, then ping with 32K packets. If this all succeeds, repeat both tests with the ISP end of the serial line. If the large packet ping test fails, you have the problem (though for completeness, the test should be run from both ends) > TCP should notice that the connection is timing out. After several > timeouts, TCP should attempt to send smaller packets, perhaps turn- > ing off the DF flag for each packet. If this succeeds, it should > continue to turn off PMTUD for the connection for some reasonable > period of time, after which it should probe again to try to deter- > mine if the path has changed. I am not sure if I agree with this. First, there is a huge performance impact; second, there is ambiguity between packets dropped because of MTU problems and packets dropped because of congestion. The side effect of the suggestion above is that congestion might lead to sending micrograms unneccesary. Second, this requires changes in the web server config, while it's the _client_ path that's broken. I see no big incentive for webserver maintainers to install this workaround if it becomes available. So, my questions are: - Is it appropiate to document the scenario above explicitely? - Should it be documented in a tcpimpl document (it's not a tcpimpl issue!) - I don't agree with the blackhole workaround, and believe it should not be recommended. Comments? Geert Jan From owner-tcp-impl@lerc.nasa.gov Thu Sep 16 03:19:52 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07576 for ; Thu, 16 Sep 1999 03:19:51 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA14491 for tcp-impl-outgoing; Thu, 16 Sep 1999 00:10:04 -0400 (EDT) Received: from newdev.harvard.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id AAA14487 for ; Thu, 16 Sep 1999 00:10:03 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id AAA10532; Thu, 16 Sep 1999 00:09:59 -0400 (EDT) Date: Thu, 16 Sep 1999 00:09:59 -0400 (EDT) From: Scott Bradner Message-Id: <199909160409.AAA10532@newdev.harvard.edu> To: alan@globalcenter.net, touch@ISI.EDU Subject: Re: TCP's handling of IP precedence Cc: tcp-impl@grc.nasa.gov, vjs@calcite.rhyolite.com Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > - intends that they change after a connection is established? if the packet stream were going through a policing gateway that remarks the field if the trafic load is above a limit the bits could change during the session see draft-heinanen-diffserv-trtcm-01.txt Scott From owner-tcp-impl@lerc.nasa.gov Thu Sep 16 03:19:56 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07574 for ; Thu, 16 Sep 1999 03:19:51 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA14364 for tcp-impl-outgoing; Thu, 16 Sep 1999 00:06:47 -0400 (EDT) Received: from shasta-exch.shastanets.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id AAA14359 for ; Thu, 16 Sep 1999 00:06:46 -0400 (EDT) Received: by mailserver.shastanets.com with Internet Mail Service (5.5.2448.0) id ; Wed, 15 Sep 1999 21:06:44 -0700 Message-ID: <4DEC824F6F1FD3119BEF0000E86CEA010BA7AB@mailserver.shastanets.com> From: Steve Alexander To: "'Joe Touch'" , alan@globalcenter.net Cc: tcp-impl@grc.nasa.gov, vjs@calcite.rhyolite.com Subject: RE: TCP's handling of IP precedence Date: Wed, 15 Sep 1999 21:06:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Changing the 5 TOS bits on the fly may work fine in implementations that are picky about precedence, since precedence is defined as the upper 3 bits; my old sendmail changed the TOS from LOW-DELAY to THROUGHPUT when switching from header mode to data mode. I think that came from Dave Borman's UNICOS /etc/iptos (which I blatantly ripped off after Dave posted the API and file format to the tcpip list). Changing the 3 precedence bits was the big no-no, at least if you're a strict constructionist of RFC 793. -- Steve > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Wednesday, September 15, 1999 6:06 PM > To: touch@ISI.EDU; alan@globalcenter.net > Cc: tcp-impl@grc.nasa.gov; vjs@calcite.rhyolite.com > Subject: Re: TCP's handling of IP precedence > > > The idea behind TCP aborting the connection when > the TOS bits change is that a property of the > connection has changed after being negotiated. From owner-tcp-impl@lerc.nasa.gov Thu Sep 16 06:56:24 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08627 for ; Thu, 16 Sep 1999 06:56:23 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA19161 for tcp-impl-outgoing; Thu, 16 Sep 1999 02:33:51 -0400 (EDT) Received: from nico.telstra.net (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA19157 for ; Thu, 16 Sep 1999 02:33:48 -0400 (EDT) Received: from sao (lon-qbu-bsj-vty7.as.wcom.net [195.232.124.7]) by nico.telstra.net (8.8.8/8.6.10) with ESMTP id QAA23514; Thu, 16 Sep 1999 16:32:22 +1000 (EST) Message-Id: <4.2.0.58.19990916145502.009e3f00@mako1.telstra.net> X-Sender: gih@mako1.telstra.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 16 Sep 1999 14:59:39 +1000 To: Joe Touch From: Geoff Huston Subject: Re: TCP's handling of IP precedence Cc: alan@globalcenter.net, tcp-impl@grc.nasa.gov, vjs@calcite.rhyolite.com In-Reply-To: <199909160123.SAA29842@rum.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > >Why shouldn't this happen like ICMP redirects or PMTU - some sort >of NACK at the ICMP level to the source? > >I.e., "ideally, the initiator would negotiate with the network, >then ask the receiver for something known"... Marshall Rose and I wrote a draft along those very lines about 3 years back - using the PMTU approach to undertake dynamic discovery of path TOS. But I note that this approach is not overly compatible with the current DiffServ architecture, where the DS field can be arbitrarily changed at any point in the network by any marker to any value (*). If you're interested I could dredge the draft up again. Geoff (*) One of a number of significant weakness in the DiffServ architecture as it currently stands - DiffServ still has some ways to go, obviously. From owner-tcp-impl@lerc.nasa.gov Thu Sep 16 17:02:39 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05832 for ; Thu, 16 Sep 1999 17:02:38 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA06317 for tcp-impl-outgoing; Thu, 16 Sep 1999 13:18:51 -0400 (EDT) Received: from tnt.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA06311; Thu, 16 Sep 1999 13:18:49 -0400 (EDT) Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA14172; Thu, 16 Sep 1999 10:18:42 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id KAA00389; Thu, 16 Sep 1999 10:18:42 -0700 (PDT) Date: Thu, 16 Sep 1999 10:18:42 -0700 (PDT) Message-Id: <199909161718.KAA00389@rum.isi.edu> To: mallman@grc.nasa.gov, GeertJan.deGroot@bsdi.com Subject: Re: TCP Problems with Path MTU Discovery Cc: tcp-impl@grc.nasa.gov, vern@aciri.org, kml@novell.com X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: Geert Jan de Groot > Subject: Re: TCP Problems with Path MTU Discovery > Date: Thu, 16 Sep 1999 04:39:42 +0200 ... > First, a quicky at the end of the document: > > >3.3. Determining MSS from PMTU > ... > > The MSS advertised at the start of a connection should be based on > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > the MTU of the interfaces on the system. Some systems use PMTUD > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > determined values to determine the MSS to advertise. > > This results in an advertised MSS that is smaller than the largest > > MTU the system can receive. > > I would like to change the marked sentence with: > The MSS advertised at the start of a connection should be based on > the largest MTU of all interfaces on the system. > > Rationale: assume a TCP connect happens over an ethernet interface. > While the TCP session is alive, routing changes and the session is > now routed over an FDDI interface. If mss would have been 1460 (ethernet), > we would see micrograms on the FDDI interface unneccesary. > I just want to make the original text more explicit, that's all. Advertising the largest of all interfaces at the _start_ of a connection won't help a connection that changes interfaces while it is running. The advertised MSS need only be as large as the MTU of the outgoing interface during connection start. (if there is reason to re-check or re-try larger MTUs later, that needs to be addressed separately). > > TCP should notice that the connection is timing out. After several > > timeouts, TCP should attempt to send smaller packets, perhaps turn- > > ing off the DF flag for each packet. If this succeeds, it should > > continue to turn off PMTUD for the connection for some reasonable > > period of time, after which it should probe again to try to deter- > > mine if the path has changed. > > I am not sure if I agree with this. First, there is a huge performance > impact; second, there is ambiguity between packets dropped because of > MTU problems and packets dropped because of congestion. The side effect > of the suggestion above is that congestion might lead to sending > micrograms unneccesary. > Second, this requires changes in the web server config, while it's > the _client_ path that's broken. I see no big incentive for webserver > maintainers to install this workaround if it becomes available. Interesting idea - that backoff includes packet size, as well as frequency. Whether that is useful depends not on whether there is congestion, but on what is congested. If there is output port contention at a router, smaller packet sizes may be a good way to go here. If the router queue slots grab fixed chunks of memory, or if the problem is per-packet processing (i.e., if the problem is per-packet, not per-byte) then only time-based backoff will help. Very interesting reseach - might be worthwhile to mention as a possibility, but until someone specs it more precisely and implements it, it may be premature to reccommend. Joe From owner-tcp-impl@lerc.nasa.gov Thu Sep 16 19:06:44 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08151 for ; Thu, 16 Sep 1999 19:06:44 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA22099 for tcp-impl-outgoing; Thu, 16 Sep 1999 15:17:10 -0400 (EDT) Received: from frantic.bsdi.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA22050; Thu, 16 Sep 1999 15:16:58 -0400 (EDT) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id OAA20420; Thu, 16 Sep 1999 14:16:44 -0500 (CDT) Date: Thu, 16 Sep 1999 14:16:44 -0500 (CDT) From: David Borman Message-Id: <199909161916.OAA20420@frantic.bsdi.com> To: GeertJan.deGroot@bsdi.com, mallman@grc.nasa.gov, touch@ISI.EDU Subject: Re: TCP Problems with Path MTU Discovery Cc: kml@novell.com, tcp-impl@grc.nasa.gov, vern@aciri.org Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: Joe Touch > Date: Thu, 16 Sep 1999 10:18:42 -0700 (PDT) > Subject: Re: TCP Problems with Path MTU Discovery > > > From: Geert Jan de Groot > > Subject: Re: TCP Problems with Path MTU Discovery > > Date: Thu, 16 Sep 1999 04:39:42 +0200 > ... > > First, a quicky at the end of the document: > > > > >3.3. Determining MSS from PMTU > > ... > > > The MSS advertised at the start of a connection should be based on > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > the MTU of the interfaces on the system. Some systems use PMTUD > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > determined values to determine the MSS to advertise. > > > This results in an advertised MSS that is smaller than the largest > > > MTU the system can receive. > > > > I would like to change the marked sentence with: > > The MSS advertised at the start of a connection should be based on > > the largest MTU of all interfaces on the system. > > > > Rationale: assume a TCP connect happens over an ethernet interface. > > While the TCP session is alive, routing changes and the session is > > now routed over an FDDI interface. If mss would have been 1460 (ethernet), > > we would see micrograms on the FDDI interface unneccesary. > > I just want to make the original text more explicit, that's all. > > Advertising the largest of all interfaces at the _start_ of > a connection won't help a connection that changes interfaces > while it is running. Sure it will. > The advertised MSS need only be as large as the MTU of > the outgoing interface during connection start. You've never heard of asymetric routes? Just because the packets go out an ethernet interface, doesn't mean that the return traffic can't come in the FDDI interface. When you advertise only 1500 bytes in the MSS, then return traffic through the FDDI interface is limited to 1500 bytes. > (if there is reason to re-check or re-try larger MTUs > later, that needs to be addressed separately). PMTUD already does rechecks for larger MTUs. BTW, if you look at RFC 1191, pg. 6, it says: .... The MSS option should be 40 octets less than the size of the largest datagram the host is able to reassemble (MMS_R, as defined in [1]); in many cases, this will be the architectural limit of 65495 (65535 - 40) octets. A host MAY send an MSS value derived from the MTU of its connected network (the maximum MTU over its connected networks, for a multi-homed host); this should not cause problems for PMTU Discovery, and may dissuade a broken peer from sending enormous datagrams. Note: At the moment, we see no reason to send an MSS greater than the maximum MTU of the connected networks, and we recommend that hosts do not use 65495. It is quite possible that some IP implementations have sign-bit bugs that would be tickled by unnecessary use of such a large MSS. Note that it doesn't say anything about using the MTU of the outgoing interface, it says use the "maximum MTU of the connected networks". That sounds to me like using the largest MTU across all interfaces. -David Borman, dab@bsdi.com From owner-tcp-impl@lerc.nasa.gov Thu Sep 16 19:32:11 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08901 for ; Thu, 16 Sep 1999 19:32:11 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA28692 for tcp-impl-outgoing; Thu, 16 Sep 1999 12:09:14 -0400 (EDT) Received: from eamail1-out.unisys.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA28688 for ; Thu, 16 Sep 1999 12:09:13 -0400 (EDT) Received: from ih94.ea.unisys.com (192-61-10194.unisys.com [192.61.101.94] (may be forged)) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id QAA07985; Thu, 16 Sep 1999 16:09:01 GMT Received: from us-slc-exch-2.slc.unisys.com (us-slc-exch-2 [192.60.250.12] (may be forged)) by ih94.ea.unisys.com (8.9.3/8.9.3) with ESMTP id QAA19088; Thu, 16 Sep 1999 16:09:05 GMT Received: by us-slc-exch-2 with Internet Mail Service (5.5.2448.0) id ; Thu, 16 Sep 1999 10:12:46 -0600 Message-ID: <236F133B43F4D211A4B00090273C79DC0E0C9F@rv-ex-2.rsvl.unisys.com> From: "Smith, Allyn D" To: "'Vernon Schryver'" Cc: tcp-impl@grc.nasa.gov Subject: RE: TCP's handling of IP precedence Date: Thu, 16 Sep 1999 10:08:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk My mail delivery has been rather untimely (I also think I may not have received all my messages) so I'm not quite sure where the discussion is, but, here are another couple of comments I hope are relative. >> .... I understand that it's probably too late to change the >> DiffServ spec now, but perhaps we can learn something from this. >> ... >If it is not too late to change RFC 793, then how can it be too late to >change RFC 2474? Does the fact that RFC 793 is about 10 times older >and at least 10,000,000 times more widely implemented really mean that >RFC 2474 is the one that cannot be changed? SHEESH! >Let's agree that there is a problem, and set out to solve it with the >minimum overall pain, but with the onus for bearing most of any unavoidable >pain on DiffServ. Well excuuuuuusssssse me. DiffServ made a potentially catastrophic blunder here and should be changed if it makes sense. What I really meant to say was that I singularly do not have the power to retract the current pre-standard existing DiffServ implementations that are causing problems nor the power to change the existing spec. In the mean time, I have to fight the fires caused by those existing DiffServ implementations and succumb to the redefinition of the TOS byte to ensure that clients TCP connections are not abnormally terminated, thanks to DiffServ. By conforming to the redefinition, I also have to pray that I don't break any of their applications that may be dependent on the precedence bits. Here's what I think should formally happen: - The IETF should retract the current standing of the DiffServ spec. - The proposed ID, "TCP Processing of the Precedence Field", should be bandied about and debated. - The outcome of the debate should determine the standing of the proposed ID and current DiffServ spec. Let's try to "put the horse before the cart". Al Smith From owner-tcp-impl@lerc.nasa.gov Thu Sep 16 19:56:42 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09822 for ; Thu, 16 Sep 1999 19:56:42 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA29705 for tcp-impl-outgoing; Thu, 16 Sep 1999 16:23:04 -0400 (EDT) Received: from tnt.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA29695; Thu, 16 Sep 1999 16:23:01 -0400 (EDT) Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA04918; Thu, 16 Sep 1999 13:22:58 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id NAA00644; Thu, 16 Sep 1999 13:22:58 -0700 (PDT) Date: Thu, 16 Sep 1999 13:22:58 -0700 (PDT) Message-Id: <199909162022.NAA00644@rum.isi.edu> To: GeertJan.deGroot@bsdi.com, mallman@grc.nasa.gov, touch@ISI.EDU, dab@bsdi.com Subject: Re: TCP Problems with Path MTU Discovery Cc: kml@novell.com, tcp-impl@grc.nasa.gov, vern@aciri.org X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From dab@frantic.bsdi.com Thu Sep 16 12:17:38 1999 > Delivery-Date: Thu, 16 Sep 1999 12:17:38 -0700 > Return-Path: dab@frantic.bsdi.com > Date: Thu, 16 Sep 1999 14:16:44 -0500 (CDT) > From: David Borman > To: GeertJan.deGroot@bsdi.com, mallman@grc.nasa.gov, touch@ISI.EDU > Subject: Re: TCP Problems with Path MTU Discovery > Cc: kml@novell.com, tcp-impl@grc.nasa.gov, vern@aciri.org > > > From: Joe Touch > > Date: Thu, 16 Sep 1999 10:18:42 -0700 (PDT) > > Subject: Re: TCP Problems with Path MTU Discovery > > > > > From: Geert Jan de Groot > > > Subject: Re: TCP Problems with Path MTU Discovery > > > Date: Thu, 16 Sep 1999 04:39:42 +0200 > > ... > > > First, a quicky at the end of the document: > > > > > > >3.3. Determining MSS from PMTU > > > ... > > > > The MSS advertised at the start of a connection should be based on > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > the MTU of the interfaces on the system. Some systems use PMTUD > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > determined values to determine the MSS to advertise. > > > > This results in an advertised MSS that is smaller than the largest > > > > MTU the system can receive. > > > > > > I would like to change the marked sentence with: > > > The MSS advertised at the start of a connection should be based on > > > the largest MTU of all interfaces on the system. > > > > > > Rationale: assume a TCP connect happens over an ethernet interface. > > > While the TCP session is alive, routing changes and the session is > > > now routed over an FDDI interface. If mss would have been 1460 (ethernet), > > > we would see micrograms on the FDDI interface unneccesary. > > > I just want to make the original text more explicit, that's all. > > ... > > The advertised MSS need only be as large as the MTU of > > the outgoing interface during connection start. > > You've never heard of asymetric routes? Granted. In that case, then the discussion should read: The MSS advertised for a connection, whether at the start or during PMTU rediscovery, should be the largest incoming MTU of all interfaces on the system. (add the word incoming - not only are routes asymmetric, so may be MTUs). Joe From owner-tcp-impl@lerc.nasa.gov Fri Sep 17 08:13:03 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06882 for ; Fri, 17 Sep 1999 08:13:01 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA08645 for tcp-impl-outgoing; Thu, 16 Sep 1999 18:23:11 -0400 (EDT) Received: from e2.ny.us.ibm.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA08638 for ; Thu, 16 Sep 1999 18:23:10 -0400 (EDT) From: mehra@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA344066 for ; Thu, 16 Sep 1999 18:22:38 -0400 Received: from d54mta08.raleigh.ibm.com (d54mta08.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.05) with SMTP id SAA21164 for ; Thu, 16 Sep 1999 18:23:07 -0400 Received: by d54mta08.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852567EE.007AF481 ; Thu, 16 Sep 1999 18:22:59 -0400 X-Lotus-FromDomain: IBMUS To: tcp-impl@lerc.nasa.gov Message-ID: <852567EE.007AF430.00@d54mta08.raleigh.ibm.com> Date: Thu, 16 Sep 1999 17:22:12 -0500 Subject: I'd like to unsubscribe from this list Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Who do I need to send a note to? thanks, Shashi. Manager, X-Server Development & Graphics Performance, IBM Austin Phone: TL 678-4662 External (512) 838-4662 E-mail: mehra@us.ibm.com "Those who dare, do; those who dare not, do not!" - Patrick Dennis. From owner-tcp-impl@lerc.nasa.gov Fri Sep 17 08:31:19 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10247 for ; Fri, 17 Sep 1999 08:31:18 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA07221 for tcp-impl-outgoing; Thu, 16 Sep 1999 18:03:06 -0400 (EDT) Received: from mail-blue.research.att.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA07217 for ; Thu, 16 Sep 1999 18:03:05 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 41FC74CE43; Thu, 16 Sep 1999 18:03:00 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA23753; Thu, 16 Sep 1999 18:02:59 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id PAA18295; Thu, 16 Sep 1999 15:02:59 -0700 (PDT) Message-Id: <199909162202.PAA18295@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: touch@isi.edu Subject: Re: TCP Problems with Path MTU Discovery Cc: tcp-impl@grc.nasa.gov Date: Thu, 16 Sep 1999 15:02:58 -0700 Versions: dmail (solaris) 2.2e/makemail 2.8u Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk >Advertising the largest of all interfaces at the _start_ of >a connection won't help a connection that changes interfaces >while it is running. Since the MSS can only be advertised at the start of a connection, this is the only time to communicate this information. >(if there is reason to re-check or re-try larger MTUs >later, that needs to be addressed separately). RFC1191 already addresses trying larger MTUs, in sections 6.3 and 7.1 . Section 6.3 explicitly mentions using a different interface on a multi-homed host. Bill From owner-tcp-impl@lerc.nasa.gov Fri Sep 17 15:17:45 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28813 for ; Fri, 17 Sep 1999 15:17:44 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA22133 for tcp-impl-outgoing; Fri, 17 Sep 1999 10:18:20 -0400 (EDT) Received: from ausmail2.austin.ibm.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA22129 for ; Fri, 17 Sep 1999 10:18:19 -0400 (EDT) Received: from netmail.austin.ibm.com (netmail.austin.ibm.com [9.53.250.98]) by ausmail2.austin.ibm.com (8.9.1/8.8.5) with ESMTP id JAA40232 for ; Fri, 17 Sep 1999 09:14:45 -0500 Received: from ambika.austin.ibm.com (ambika.austin.ibm.com [9.53.150.77]) by netmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id JAA24678 for ; Fri, 17 Sep 1999 09:18:17 -0500 Received: from austin.ibm.com (localhost.austin.ibm.com [127.0.0.1]) by ambika.austin.ibm.com (AIX4.3/UCB 8.8.8/8.7-client1.01) with ESMTP id JAA26074 for ; Fri, 17 Sep 1999 09:18:15 -0500 Message-ID: <37E24DA7.318ADAF3@austin.ibm.com> Date: Fri, 17 Sep 1999 09:18:15 -0500 From: venkat venkatsubra Organization: IBM X-Mailer: Mozilla 4.06 [en] (X11; I; AIX 4.3) MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Re: TCP's handling of IP precedence References: <199909151933.NAA25200@calcite.rhyolite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit The following mail seems to indicate that NCR's MP-RAS Unix was having similar problem after they made changes to the Precedence bits handling in tcp input to conform to RFC 793. They did this change to pass one of the Unix'95 Certification test. Now i think they got rid of this change (available in a later patch) - or giving the user an option to turn off/on this behaviour. > Subject: TOS and PRECEDENCE bits > From: Bob Walpole > Date: 1998/12/23 > Newsgroups: comp.protocols.tcp-ip > Here's a specific scenario I have ran into a couple of times. > By default our TOS field is set to 0. > Most applications that set the TOS do not set the PRECEDENCE bits > anyway, at least in my limited experience. > Is IP allowed to tell TCP to reset the connection if the incoming > precedence bits do not match those stored in the inpcb for this > connection? > What should it do, if anything? > Is this specified anywhere? > I have seen precedence bits 110 (when the other interface was X.25) and > 100 (when the other interface was unkown) in packets from routers. This > causes the TCP connection to be reset. > If Iset ip_settos to 0, would it be reasonable to assume I do not wish > to check the value in the incoming packets? Venkat Vernon Schryver wrote: > > From: Vern Paxson > > > ... > > 5. 6 months later it's discvered that the redefinition causes one > > TCP to send resets. The email describing this says > > > > > As it turns out, this is an archaically (sp) known > > > problem, with a pre-existing patch. > > > > and elicits a reply: > > > > > MacTCP is *old*, and has many more problems than > > > this. Please tell your help desks that if they run > > > across users still using MacTCP, that they advise > > > them to upgrade to at least MacOS 7.5.3 (preferably > > > 7.5.5), which is free, and includes Open > > > Transport. > > See also the note this morning from someone reporting about what sounds > like the same problem with some Windows TCP code. > > If only ancient MacTCP had the problem, you might, but only might get away > with declaring old MacTCP non-conformant. That is basically what you > are proposing, to break an unknown number of existing implementations and > installations. > > > 6. The question now is how many significant TCPs are actually > > effected, and, accordingly, how to fix the problem. > > Agreed. > > However, on general grounds the fait accompli argument is completely > inadmissable. 400 people participating in DiffServ meetings are not a > majority of the IETF, even if majorities mattered, which they don't. > Even if you accept the history as you have stated it (which I don't quite), > the onus for bearing fixing the problem lies with DiffServe, *NOT* TCP. > If a painless change can be made to TCP, then that would be great, and > would remove the burden from DiffServ. If there is no painless TCP fix, > then the pain *MUST* be borne by DiffServ. > > ] From: Vern Paxson > > ] That's the point of Last Call - if you care about where the IETF is going, > ] you are supposed to read ietf-announce@ietf.org and see what is being > ] proposed. You don't have to read all the documents, just the ones that > ] appear relevant. The abstract of RFC 2474 is clear that the document is > ] about redefining the TOS byte. > > That is mistaken in several ways. Even if the Last Call had said something > about breaking existing TCP, the onus would still be on DiffServ. However, > given the established IETF culture and expectations, something that talks > about redefining the TOS byte would be assumed by knowledgable people to > upward compatiable and not break existing installations without explicitly > saying so, and not without a lot more main IETF list discussion than > the last call. > > By concidence, I had been trying to understand RFC 2474 before all of this > broke, and had assumed the intent of RFC 2474 was to be upward compatible. > The words in RFC 2474 are not entirely clear, but they do promise > significant upward compatibility. Consider the start of section 4: > > The DS field will have a limited backwards compatibility with current > practice, as described in this section. Backwards compatibility is > addressed in two ways. First, there are per-hop behaviors that are > already in widespread use (e.g., those satisfying the IPv4 Precedence > queueing requirements specified in [RFC1812]), and we wish to permit > their continued use in DS-compliant nodes. ... > > ] > Since getting anything changed during Last Call is at best difficult > ] > ] The WG raised the issue of what depends on the current structure of the TOS > ] byte at length, had considerable discussion, and no one brought up the TCP > ] incompatibility. It's not as though it wasn't high profile - 400+ people > ] attend each diffserv meeting. But even so, it was on the radar as a > ] significant issue, and I think it would have been treated very seriously > ] as a last call comment. > > I am confident of the good intentions of all concerned. Still, when > balancing painful changes, which sub-community (or if you prefer, chunks > of code) must suffer most of the pain? > > ] > Instead of requiring changes to an unknown but apparently significant > ] > number of existing TCP implementations and literally uncountable TCP > ] > installations, why not strengthen the DiffServ words about upward > ] > compatibility? > ] > ] One of the key questions is: is it really a significant number of TCP > ] implementations? That's why this discussion should happen on tcp-impl. > > I agree that is a critical question. The note this morning about > Windows 3.1 was extremely worrisome. > > ] > If the RFC 1349/RFC 1812 values of the IP TOS byte were > ] > required to be get through unchanged (after possibly having been mapped > ] > to other values and back again), would any existing combinations of > ] > applications and host break? > ] > ] How do you know what to map them back to? It's not a one-to-one mapping. > > Which map is not 1:1 and does it matter? Since RFC 2474 defines a lot > more potential behaviors than RFC 1812 and RFCX 1349, you obviously cannot > map DiffServ 1:1 onto RFC 1349. However, in practice there are only about > 3 different RFC 1349 values. It seems to me that requiring that DiffServ > preserve 3 values would completely would be painless for DiffServ, and > far wiser than declaring that an unknowable number of TCP implementations > and installations non-conformant and requiring them to be changed. > > I think the only commonly used RFC 1349 values are 0 (extremely common), > 0x10 (minimize delay), and 0x80 (maximize throughput). See your nearest > BSD source trees. I found all of those in the first 4.4BSD-Lite CDROM, > and I know that 0x10 has been creeping into other widely used applications, > partly because I've helped push it. > > Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Fri Sep 17 15:30:57 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29046 for ; Fri, 17 Sep 1999 15:30:56 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA29041 for tcp-impl-outgoing; Fri, 17 Sep 1999 11:12:26 -0400 (EDT) Received: from mailhost.iprg.nokia.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA29031 for ; Fri, 17 Sep 1999 11:12:24 -0400 (EDT) Received: from vienna.iprg.nokia.com (vienna.iprg.nokia.com [205.226.11.35]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id IAA02918 for ; Fri, 17 Sep 1999 08:12:18 -0700 (PDT) From: Fred Bauer Received: (fred@localhost) by vienna.iprg.nokia.com (8.8.8/8.6.12) id IAA09515 for tcp-impl@lerc.nasa.gov; Fri, 17 Sep 1999 08:12:18 -0700 (PDT) Date: Fri, 17 Sep 1999 08:12:18 -0700 (PDT) Message-Id: <199909171512.IAA09515@vienna.iprg.nokia.com> To: tcp-impl@lerc.nasa.gov Subject: INFOCOM 2000 Call For Papers Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk CALL FOR PARTICIPATION ----------------------------------------------------------- | | | ### # # ####### ####### ##### ####### # # | | # ## # # # # # # # # ## ## | | # # # # # # # # # # # # # # | | # # # # ##### # # # # # # # # | | # # # # # # # # # # # # | | # # ## # # # # # # # # # | | ### # # # ####### ##### ####### # # | | | | | \ ##### ### ### ### / \ # # # # # # # # / \ # # # # # # # / \ ##### # # # # # # / \ # # # # # # # / \ # # # # # # # / \ ####### ### ### ### / \ / ------------------------------------------ IEEE Infocom 2000 (Israel) http://www.comnet.technion.ac.il/infocom2000 (U.S.A.) http://www.cse.ucsc.edu/~rom/infocom2000 (Japan) http://halo.kuamp.kyoto-u.ac.jp/~infocom Dan Panorama Hotel, Tel Aviv, Israel March 26-30, 2000 Sponsored by the IEEE Communications and Computer Societies VENUE ===== For the last 18 years, Infocom has been the major conference on computer communications and networking, bringing together researchers and implementors of every aspect of data communications and networks presenting the most up-to-date results and achievements in the field. The 19th annual conference on Computer Communications, Infocom 2000, will be held at the Dan Panorama Hotel in Tel-Aviv, Israel, during the week of March 26-30, 2000. Overlooking the Mediterranean, the Dan Panorama Tel Aviv is a city hotel in a resort setting. Just a few steps away are fine shops, theaters, restaurants and the corporate world of Tel Aviv, contrasted by the ancient port city of Jaffa with its picturesque corners and flea markets for bargain hunters. The hotel features a large swimming pool, beach access and a fully equipped health & fitness center including dry sauna, jacuzzi, and massage services. IMPORTANT DATES =============== Hotel reservation cut-off date* January 24, 2000 Early registration cut-off date March 1, 2000 Tutorials March 26-27, 2000 Conference March 28-30, 2000 * Israel is expected to be crowded with tourists during the year 2000. Furthermore, the Pope is scheduled to visit Israel the week before the conference. Hence, it is advised to make hotel reservations for the conference as soon as possible. HOTEL RATES =========== Double Occupancy $157.50 Single Occupancy $139.00 Rates are per room per night and include full Israeli buffet breakfast. The rates also include all taxes for non-israelis. For more details consult the web pages. REGISTRATION FEES ================= Registration fees for an IEEE member prior to March 1, 2000 will be $500 and it will include all technical sessions, open receptions, proceedings (CD) and three lunches. For other fees consult the web pages. ------------- SCOPE ===== Original papers and panel discussions describing state-of-the-art research and development in all areas of computer networking and data communications will be presented. Topics of interest include: Active Networks Network Management and Control BISDN and ATM Network Reliability Billing and Pricing Network Restoration Congestion and Admission Control Network Signaling Distributed Network Algorithms Network Standards High-Speed Network Protocols Network and Protocol Performance Integrated Control of Networks Optical Networks Intelligent Networks Personal Communications Systems Internet Photonic Switching Internetworking Protocol Design and Analysis Lightwave Networks Quality of Service Mobility Routing and Routing Protocols Multicast/Broadcast Algorithms Security and Privacy Multimedia Protocols Switch Architectures Multimedia Terminals and Systems Testbeds and Measurements Multiple Access Traffic Management and Control Network Architectures Video Networking Network Design and Planning Wireless Networks and Protocols KEYNOTE SPEAKER =============== Prof. Leonard Kleinrock, Chairman, Nomadix, Inc. TUTORIALS ========= Full Day -------- - Wavelength-routing optical networks (Kumar Sivarajan, Indian Institute of Science) - The evolution of QoS in the Internet standards community (Jon Crowcroft, University College London) - Overview of network security (Radia Perlman, Sun Microsystems) - Traffic management (Khosrow Sohraby, University of Missouri, Kansas City) Half Day -------- - MPLS (Loa Anderson, Nortel Networks) - Advanced Ethernet technology (Donno Van-Mirop, IBM Israel) - Satellite IP networking (Catherine Rosenberg, Purdue University) - IP Multicast: past, present and future (Radia Perlman, Sun Microsystems & Christophe Diot, Sprint) - Mobile IP: adding mobility to the Internet (Charles Perkins, Nokia Research) TRAVEL GRANTS ============= Limited travel assistance to students, post-docs and junior faculty for defraying some of the costs of presenting a paper in the conference will be available. Please refer to the conference web sites for further details later this year. QUESTIONS? =========================== Write to infocom@comnet.technion.ac.il] From owner-tcp-impl@lerc.nasa.gov Fri Sep 17 15:44:15 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29256 for ; Fri, 17 Sep 1999 15:44:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA04406 for tcp-impl-outgoing; Fri, 17 Sep 1999 11:45:20 -0400 (EDT) Received: from eamail1-out.unisys.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA04383 for ; Fri, 17 Sep 1999 11:45:16 -0400 (EDT) Received: from us-ea-gtwy-4.ea.unisys.com ([192.61.146.122]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id PAA21611 for ; Fri, 17 Sep 1999 15:45:04 GMT Received: by us-ea-gtwy-4.ea.unisys.com with Internet Mail Service (5.5.2448.0) id ; Fri, 17 Sep 1999 10:45:14 -0500 Message-ID: <236F133B43F4D211A4B00090273C79DC0E0CA2@rv-ex-2.rsvl.unisys.com> From: "Smith, Allyn D" To: tcp-impl@grc.nasa.gov Subject: RE: TCP's handling of IP precedence Date: Fri, 17 Sep 1999 10:45:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Here's some fuel for the fire. As evidence that DiffServs twiddling of the TOS byte bits may potentially be a big problem, Microsoft has a bug where they fail to initialize the TOS byte causing them to send random TOS byte values. The net effect of this is the same as the DiffServ bit twiddling: reset TCP connections. If you're interested, you may view the Microsoft knowledge base article describing this at: http://support.microsoft.com/support/kb/articles/q217/2/07.asp Regards, Al Smith