From owner-pilc@lerc.nasa.gov Wed Mar 1 09:26:16 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02441 for ; Wed, 1 Mar 2000 09:26:14 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA03806 for pilc-outgoing; Wed, 1 Mar 2000 08:13:24 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA03771 for ; Wed, 1 Mar 2000 08:13:20 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA27490; Wed, 1 Mar 2000 08:13:19 -0500 (EST) Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.0) id xma027430; Wed, 1 Mar 00 08:12:54 -0500 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.10.0.Beta12/8.10.0.Beta12) with ESMTP id e21DHTI15363; Wed, 1 Mar 2000 13:17:30 GMT Message-ID: <38BD08FA.AD0BFCFD@erg.abdn.ac.uk> Date: Wed, 01 Mar 2000 13:30:30 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: touch CC: pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <200002291819.KAA04170@boreas.isi.edu> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit More clarification... Joe Touch wrote: > > From owner-pilc@lerc.nasa.gov Mon Feb 28 08:05:06 2000 > > Date: Mon, 28 Feb 2000 15:06:57 +0100 > > From: Dr G Fairhurst > > CC: "'pilc@grc.nasa.gov'" , > > "Phil Karn (E-mail)" > > Subject: Re: Draft on Advice for Internet Subnetwork Designers > > > > Here are some comments on Link Level Issues: > > > > "Falk, Aaron" wrote: > > > > > Folks-- > > > > > > A very important piece of work for PILC is the LINK draft that Phil Karn is > > > editing. > > > http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-01.txt > > > > PAGE 4: MTU Size > > > > It may be useful to note that using IPSEC in tunnel mode can increase > > the size of a packet as it travels across the network. This can result > > in a smaller MTU. > > Doesn't IPSEC in any mode do this? (tunnel or transport?) > > (provided it's added after the source - and, in the case > of overlay networks, [paradoxically] transport may be > more useful) Sure, you are correct. But, I seem to remember the draft mentioning 1500B MTU. Now, since this is a link designer's draft, what we are presumably interested in is frame payload data size... So, if normal IP is used that is maximum 1500B. If IPSEC is used end-to-end that is still 1500B of frame payload, even though MTU is reduced. But with tunnel mode along part of the path, the rest of the path outside the tunnel now sees a reduced MTU - or the tunneled path needs to support a larger frame size. Just saying 1500B is not a universal MTU anymore. (P.S. GRE encapsulation, etc also have this effect). > > > The IPv4 packet header contains a header checksum that verifies the integrity > > of the header. This checksum was originally design to protect from router > > software errors, however this function is no longer necessary. > > Not so much necessary, as not worth the cost. > Better wording. > > > IPv6 does > > not therefore implement a network level integrity checksum. The role of the > > IP checksum has therefore been subsumed into the TCP and UDP > > checksums. > > More into IPSEC than into TCP and UDP, no? > IPSEC is one way, it is not (I think) mandatory, so TCP/UDP may still get bad packets which they have to reject.... > Joe From owner-pilc@lerc.nasa.gov Wed Mar 1 09:46:49 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03215 for ; Wed, 1 Mar 2000 09:46:47 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA09778 for pilc-outgoing; Wed, 1 Mar 2000 08:54:39 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA09746 for ; Wed, 1 Mar 2000 08:54:36 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA02806; Wed, 1 Mar 2000 08:54:36 -0500 (EST) Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.0) id xma002788; Wed, 1 Mar 00 08:54:23 -0500 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.10.0.Beta12/8.10.0.Beta12) with ESMTP id e21DxkI15804; Wed, 1 Mar 2000 13:59:46 GMT Message-ID: <38BD12E2.60CDF3F3@erg.abdn.ac.uk> Date: Wed, 01 Mar 2000 14:12:53 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "'pilc@grc.nasa.gov'" CC: L.Wood@eim.surrey.ac.uk Subject: Re: Draft on Advice for Internet Subnetwork Designers References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I'm following up the thread on ARQ, sorry for the delay in getting back: Lloyd Wood wrote: > On Mon, 28 Feb 2000, Dr G Fairhurst wrote: > > > "Falk, Aaron" wrote: > > > > > Folks-- > > > > > > A very important piece of work for PILC is the LINK draft that Phil Karn is > > > editing. > > > http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-01.txt > > > > (2) Link layer protocols should provide adequate protection from > > transmission errors. > > It's a tradeoff dependent on the characteristics and use of the link, > since the end-to-end checksum catches a number of errors. If the > reader thinks 'adequate protection' means 100% reliability means ARQ, > you've got problems. Adequate protection form errors, in my thinking, means that PDUs delivered end-to-end should not contain minimal errors. The UDP/TCP validation using the checksum is designed to detect computer manipulation errors (e.g. DMA under-runs, pointer corruption, etc), not to detect random (or burst) channel errors. A more powerful CRC is required in this case. This is a different issue to non-delivery. Point 3 below. > How about: > > Link layer protocols should provide adequate protection from > transmission errors. This is necessary since: > 1. there is as yet no internetwork framework for detecting or > handling link transmission errors effectively > 2. it is desirable from a performance viewpoint to avoid triggering > congestion control algorithms needlessly as result of errored > link-layer frames being discarded. > 3. the TCP and UDP checksums are neither strong nor foolproof. > > > Whereas in previous cases, small CRCs or no CRC > > (in the case of SLIP) have been tolerated. A CRC-32 is desirable for > > each packet (as in Ethernet). > > ...or as in ATM AAL5. The best choice of CRC might be dependent on > advertised MTU and link characteristics; probably need a note on > transparent fragmentation here. I can't think of any references as to > why CRC-32 is considered adequate/sufficient offhand, but some would > be nice. In fact we have two ways (which may be used together). The first is add a CRC per segment (frame) as X.25 did. The second is add a CRC per PDU as ATM did. The reference to CRC evaluation for ATM is "Stone, Jonathon, Greenwood, Michael, and Partridge, Craig, Performance of CRC's over Real Data. IEEE/ACM Transactions on Networking, 1998. 6(5): p. 529-543" A possible reference for the thought behind per-PDU CRC rather than per segment CRC is in: "Wang, Zheng and Crowcroft, Jon, SEAL Detects Cell Misordering. IEEE Network, 1992. 6(4): p. 8-9" On points 1,2, Reliable or Partial Reliable delivery implies the use of ARQ, bit level (physical) FEC, Packet level FEC, or some hybrid of these. > > > I think it may be wise to note that there are two approaches to TCP > > friendly link ARQ. One has been put forward by Balakrishnan: > > > > "H. Balakrishnan, V.N. Padmanabhan, S Seshan, and R H Katz, A > > Comparison of Mechanisms for Improving TCP Performance over > > Wireless Links. IEEE Trans Net, 1997. 5(6): p. 756-759." > > > > In this case, TCP headers are read and the information used to tune > > the link protocol. > > this breaks layering. Ugh. And it's a fat lot of use with e.g. IPSec. > Not my first or recommended choice. I'm not sure I like it, but we should be aware there are many ways of doing it, ranging from "looking" at headers, which is the most benign. To delaying packets, modifying headers and inserting extra packets, which are more pro-active. People do this kind of thing, and given the right technique for the correctly identified problem may get big benefits. There are problems if TCP changes, IPSEC is used (could we need a proxy?), ECN is deployed, etc, etc. I agree there is a warning attached here. I don't like going down this path either :-) > > The other approach is to bound link behaviour to match TCP > > "requirements" i.e. A receiver may calculate the variation > > of the recovery delay and then give up, if the variation > > which will be introduced is more than that can be tolerated > > by the TCP transport layer. > > and this assumes that the link in question is the only link in the > path doing such calculations. ugh again. > To get best performance this is correct. The penalty for doing too much retransmission is poorer link performance. There are far fewer impacts on TCP end-to-end behaviour. > > Really, you should imo be saying that if the variation is any more > than an order of magnitude less than the limit of transparency to TCP, > give up on the resend requests. If it's likely to be regularly more > than an order of magnitude less than the transparency limit, be very > skeptical of ARQ. What do you mean by "limit of transparency"? > > (500ms RTO gives 50ms per-link limit, which is probably a bit on the > high side, given that the draft talks about 10-20ms delay already. > But two orders of magnitude would be 5ms. I have to stop myself > thinking in binary magnitudes too...) > > cheers, > > L. > > PGP Best wishes, Gorry Fairhurst. From owner-pilc@lerc.nasa.gov Wed Mar 1 14:14:27 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10850 for ; Wed, 1 Mar 2000 14:14:25 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA19186 for pilc-outgoing; Wed, 1 Mar 2000 13:12:20 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA19138 for ; Wed, 1 Mar 2000 13:12:15 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA09695; Wed, 1 Mar 2000 13:12:14 -0500 (EST) Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma009646; Wed, 1 Mar 00 13:12:00 -0500 Received: (from touch@localhost) by boreas.isi.edu (8.8.7/8.8.6) id KAA21226; Wed, 1 Mar 2000 10:11:55 -0800 (PST) Date: Wed, 1 Mar 2000 10:11:55 -0800 (PST) From: Joe Touch Message-Id: <200003011811.KAA21226@boreas.isi.edu> To: gorry@erg.abdn.ac.uk Subject: Re: Draft on Advice for Internet Subnetwork Designers Cc: pilc@grc.nasa.gov Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From gorry@erg.abdn.ac.uk Wed Mar 1 05:12:19 2000 > Date: Wed, 01 Mar 2000 13:30:30 +0100 > From: Dr G Fairhurst > To: touch > CC: pilc@grc.nasa.gov > Subject: Re: Draft on Advice for Internet Subnetwork Designers > > More clarification... > > Joe Touch wrote: > > > > "Falk, Aaron" wrote: > > > > > > PAGE 4: MTU Size > > > > > > It may be useful to note that using IPSEC in tunnel mode can increase > > > the size of a packet as it travels across the network. This can result > > > in a smaller MTU. > > > > Doesn't IPSEC in any mode do this? (tunnel or transport?) > > > > (provided it's added after the source - and, in the case > > of overlay networks, [paradoxically] transport may be > > more useful) > > Sure, you are correct. But, I seem to remember the draft mentioning 1500B MTU. > Now, since this is a link designer's draft, what we are presumably interested in > is frame payload data size... So, if normal IP is used that is maximum 1500B. > If IPSEC is used end-to-end that is still 1500B of frame payload, even though > MTU is reduced. But with tunnel mode along part of the path, the rest of the > path outside the tunnel now sees a reduced MTU - or the tunneled path needs > to support a larger frame size. Just saying 1500B is not a > universal MTU anymore. It doesn't matter where IPSEC is used - E2E or tunnel. Either way eats into the MTU. The PILC doc is talking about link MTUs; everything except the link header consumes that. > > > IPv6 does > > > not therefore implement a network level integrity checksum. The role of the > > > IP checksum has therefore been subsumed into the TCP and UDP > > > checksums. > > > > More into IPSEC than into TCP and UDP, no? > > IPSEC is one way, it is not (I think) mandatory, so TCP/UDP may still get > bad packets which they have to reject.... Support for IPSEC is mandatory in IPv6, which is where the IP checksum has been removed. Its _use_ is not mandatory. The role of the IP checksum was to check the IP header. The role of the TCP/UDP checksums is to check the data. If you want to protect/sum the header, you should (and thus, above, can) use IPSEC. Joe From owner-pilc@lerc.nasa.gov Wed Mar 1 14:42:09 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11487 for ; Wed, 1 Mar 2000 14:42:08 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA24445 for pilc-outgoing; Wed, 1 Mar 2000 13:46:46 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA24416 for ; Wed, 1 Mar 2000 13:46:44 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA14346; Wed, 1 Mar 2000 13:46:44 -0500 (EST) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma014320; Wed, 1 Mar 00 13:46:37 -0500 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12QE8m-00025R-00; Wed, 01 Mar 2000 18:46:32 +0000 Date: Wed, 1 Mar 2000 18:46:28 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Joe Touch cc: gorry@erg.abdn.ac.uk, pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers In-Reply-To: <200003011811.KAA21226@boreas.isi.edu> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Wed, 1 Mar 2000, Joe Touch wrote: > Gorry wrote: > > Joe Touch wrote: > > > Gorry wrote: > > > > IPv6 does > > > > not therefore implement a network level integrity checksum. The role of the > > > > IP checksum has therefore been subsumed into the TCP and UDP > > > > checksums. > > > > > > More into IPSEC than into TCP and UDP, no? No. > > IPSEC is one way, it is not (I think) mandatory, so TCP/UDP may still get > > bad packets which they have to reject.... Yes. Of course, since the TCP/UDP checksum is weak, there's a chance that a bad packet may slip through. > Support for IPSEC is mandatory in IPv6 oh, whoopee. This Will Ensure IPSEC's Success. > which is where the IP checksum > has been removed. Its _use_ is not mandatory. > > The role of the IP checksum was to check the IP header. The role of > the TCP/UDP checksums is to check the data. Sorry, no. The TCP/UDP checksums still check the integrity of significant parts of the IP header, even with IPv6. Remember the "pseudo-header"? Read RFC2460 section 8, page 26. It is this check which adequately makes up for the IP header checksum (which would have been a pain in IPv6, what with extension headers). > If you want to protect/sum > the header, you should (and thus, above, can) use IPSEC. Sorry, no. Use of IPSec is not necessary. Useful header integrity checks come with the standard UDP/TCP pseudo-header check in IPv6, and including pseudo-headers in checksums is an expected feature of any IPv6 transport protocol. L. personal doubt is a powerful and accurate weapon. PGP From owner-pilc@lerc.nasa.gov Wed Mar 1 14:59:17 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11848 for ; Wed, 1 Mar 2000 14:59:15 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA28621 for pilc-outgoing; Wed, 1 Mar 2000 14:12:21 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA28597 for ; Wed, 1 Mar 2000 14:12:19 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA18168; Wed, 1 Mar 2000 14:12:18 -0500 (EST) Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018149; Wed, 1 Mar 00 14:12:03 -0500 Received: (from touch@localhost) by boreas.isi.edu (8.8.7/8.8.6) id LAA28774; Wed, 1 Mar 2000 11:11:54 -0800 (PST) Date: Wed, 1 Mar 2000 11:11:54 -0800 (PST) From: Joe Touch Message-Id: <200003011911.LAA28774@boreas.isi.edu> To: L.Wood@eim.surrey.ac.uk Subject: Re: Draft on Advice for Internet Subnetwork Designers Cc: gorry@erg.abdn.ac.uk, pilc@grc.nasa.gov Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From l.wood@eim.surrey.ac.uk Wed Mar 1 10:46:34 2000 > Date: Wed, 1 Mar 2000 18:46:28 +0000 (GMT) > From: Lloyd Wood > To: Joe Touch > cc: gorry@erg.abdn.ac.uk, pilc@grc.nasa.gov > Subject: Re: Draft on Advice for Internet Subnetwork Designers > X-no-archive: yes > > On Wed, 1 Mar 2000, Joe Touch wrote: > > Gorry wrote: > > > Joe Touch wrote: > > > > Gorry wrote: > > > > > IPv6 does > > > > > not therefore implement a network level integrity checksum. The role of the > > > > > IP checksum has therefore been subsumed into the TCP and UDP > > > > > checksums. > > > > > > > > More into IPSEC than into TCP and UDP, no? > > No. > > > > IPSEC is one way, it is not (I think) mandatory, so TCP/UDP may still get > > > bad packets which they have to reject.... > > Yes. Of course, since the TCP/UDP checksum is weak, there's a chance > that a bad packet may slip through. > > ... > > The role of the IP checksum was to check the IP header. The role of > > the TCP/UDP checksums is to check the data. > > Sorry, no. The TCP/UDP checksums still check the integrity of > significant parts of the IP header, even with IPv6. Remember the > "pseudo-header"? It certainly checks the pseudo header. Not the header. There are components of the header not in the pseudoheader (flags, options, etc.) > > If you want to protect/sum > > the header, you should (and thus, above, can) use IPSEC. > > Sorry, no. Use of IPSec is not necessary. Useful header integrity > checks come with the standard UDP/TCP pseudo-header check in IPv6, and > including pseudo-headers in checksums is an expected feature of any > IPv6 transport protocol. Not if you are concerned about the integrity of the IP header - all (or at least the end-to-end part, including flags and E2E options) of it. Joe From owner-pilc@lerc.nasa.gov Wed Mar 1 15:47:08 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12699 for ; Wed, 1 Mar 2000 15:47:06 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA04410 for pilc-outgoing; Wed, 1 Mar 2000 14:49:55 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA04373 for ; Wed, 1 Mar 2000 14:49:51 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA23232; Wed, 1 Mar 2000 14:49:50 -0500 (EST) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma023177; Wed, 1 Mar 00 14:49:06 -0500 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12QF7F-0002tX-00; Wed, 01 Mar 2000 19:49:01 +0000 Date: Wed, 1 Mar 2000 19:48:57 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Joe Touch cc: gorry@erg.abdn.ac.uk, pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers In-Reply-To: <200003011911.LAA28774@boreas.isi.edu> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Wed, 1 Mar 2000, Joe Touch wrote: > > > If you want to protect/sum > > > the header, you should (and thus, above, can) use IPSEC. > > > > Sorry, no. Use of IPSec is not necessary. Useful header integrity > > checks come with the standard UDP/TCP pseudo-header check in IPv6, and > > including pseudo-headers in checksums is an expected feature of any > > IPv6 transport protocol. > > Not if you are concerned about the integrity of the IP header - > all (or at least the end-to-end part, including flags and E2E options) > of it. If you're using AH or ESP in tunnel mode, you'll get all the IP header. Otherwise, yes, AH in transport mode gives a check on everything bar mutable fields, while ESP is useless in this regard. Header checksumming isn't an intended explicit design feature of IPSec, surely? More a side-effect of authentication... [http://www.counterpane.com/ipsec.html questions header verification, AH and transport mode entirely, and points out problems with AH header authentication.] Doesn't the complexity for IPSec-based header protection more than outweigh the incremental value of any gains over the pseudo-header check? L. I'm pretty sure that header checksumming is _not_ what IPSec is _for_. What is IPSec for? PGP From owner-pilc@lerc.nasa.gov Wed Mar 1 18:09:31 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16048 for ; Wed, 1 Mar 2000 18:09:30 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA25755 for pilc-outgoing; Wed, 1 Mar 2000 17:18:32 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA25729 for ; Wed, 1 Mar 2000 17:18:29 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA19295; Wed, 1 Mar 2000 17:18:28 -0500 (EST) Received: from motgate.mot.com(129.188.136.100) by seraph3.lerc.nasa.gov via smap (V5.0) id xma019252; Wed, 1 Mar 00 17:17:45 -0500 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id PAA25586; Wed, 1 Mar 2000 15:17:28 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id PAA26919; Wed, 1 Mar 2000 15:17:27 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id RAA16642; Wed, 1 Mar 2000 17:17:26 -0500 (EST) Message-Id: <200003012217.RAA16642@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: "Falk, Aaron" cc: "'pilc@grc.nasa.gov'" , "Phil Karn (E-mail)" Subject: Re: Draft on Advice for Internet Subnetwork Designers In-reply-to: Your message of "Thu, 24 Feb 2000 12:02:08 EST." <8046A317B5F4D21186610008C7EBB696F055EE@grnexch1.panamsat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Mar 2000 17:17:27 -0500 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Comments: 1) Shortly before the Washington meeting, I sent a suggestion to change the Introduction/Overview section as follows. > ...seminal paper "End-to-End Arguments in System Design" [SRC81]. This paper > argued that many -- if not most -- network functions are best implemented on > an end-to-end basis, i.e., at the higher protocol layers. Duplicating these > functions at the lower levels can be needlessly redundant or harmful. > However, there are also cases where duplication can be justified by > considerations such as performance, availability or security. Examples > might include link layer retransmission on an unusually lossy channel, e.g., > mobile radio, encryption of the entire link layer protocol over a shared > medium, or redundant paths at the link layer for fault recovery. > Duplication of functions should be done only based on an understanding of > system level implications, including any side-effects on the higher layers. I still believe rather strongly that this is more appropriate than the current wording. Since it has been quite a while since the last discussion of the document on the mailing list, a reminder seems appropriate. 2) Some initial thoughts on what we should do with the empty section on buffering, congestion and flow control. Let's discuss on the list, and I'll draft text after the discussion: a) [Following owes a great deal to a side-discussion I had with Mark Allman] TCP needs lots of buffering. An ability to buffer bursts of up to (fixed delay)*(bottleneck rate) per TCP connection in each node is ideal if impractical. Problem is that neither the fixed delay nor the bottleneck rate is necessarily known at any node. A good approximation is fixed delay of the link * link bandwidth. For links that have variable delays, the approximation should be based on the max. Also, the maximum number of TCP connections per node is very difficult to determine a priori, and is not subject to any kind of admission control (except perhaps at a PEP). A SWAG has to suffice. Some kind of mechanism to measure delay on the link can be useful in autotuning buffer sizes. In general, more buffers are better than fewer. For example, TCP performance in very early ATM switch implementations suffered horribly from the small buffer sizes. b) There is a rough consensus (not unanimous) in the research community that active queue management is important to improving fairness, link utilization and throughput. Reference RFC 2309. Followed by a brief introduction to active queue management, with RED as an example. An important part of the concept is that active queue management attempts to keep average queue depths short, while accommodating short term bursts. It may be advisable for subnets that perform queueing and discarding to consider implementing some form of active queue management, especially if large aggregates of TCP connections are likely to share the same queue. It may be less effective in the case, for example, of an ATM switch that implements per-VC queueuing. Note, incidentally, that active queue management algorithms in general are highly sensitive to parameter settings and reference Borden and Fioriu paper. c) If the subnet does fragmentation and reassembly, make sure that if it becomes necessary to discard, then discard entire frames, not just scattered fragments. For ATM, this specifically means using EPD/PPD, and reference ATM Forum TM 4.0 specification. Reference Romanow paper. d) If the subnet includes flow control that shapes the rate at the edge of the subnet to match a share of the bottleneck bandwidth in the subnet (e.g., ATM ABR), this has the effect of pushing congestion to the edge of the subnet. In such a case, adequate buffering is needed at the edge of the subnet (see a above). Whether or not there is benefit in this kind of flow control is controversial, and there have been simulation studies that go both ways. Anecdotally, some large networks have used ABR sucessfully to carry IP traffic, but no published results. e) Flow control mechanisms that mark but do not shape frames in excess of fair share of the bottleneck rate (e.g., frame relay FECN and BECN) are at best useful only in the context of IP ECN (RFC 2481). New subnets would do well to have flow control mechanisms that have that semantics (i.e., feedback signal based on EWMA buffer size, feedback set probabilistically proportional to difference between two thresholds, or always set when second threshold exceeded) so that feedback could be 'bubbled up' from the subnet layer to the IP header. 3) I have some ideas on QoS, which I'll try to organize and send out over the next few days. From owner-pilc@lerc.nasa.gov Wed Mar 1 19:48:15 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19266 for ; Wed, 1 Mar 2000 19:48:14 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA03296 for pilc-outgoing; Wed, 1 Mar 2000 18:41:05 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA03284 for ; Wed, 1 Mar 2000 18:41:03 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA29733; Wed, 1 Mar 2000 18:41:02 -0500 (EST) Received: from breeze.lcs.mit.edu(18.31.0.83) by seraph3.lerc.nasa.gov via smap (V5.0) id xma029704; Wed, 1 Mar 00 18:40:44 -0500 Received: from breeze.lcs.mit.edu (hari@localhost [127.0.0.1]) by breeze.lcs.mit.edu (8.8.7/8.8.7) with ESMTP id SAA02095; Wed, 1 Mar 2000 18:42:48 -0500 Message-Id: <200003012342.SAA02095@breeze.lcs.mit.edu> X-Mailer: exmh version 2.0.2 X-url: http://wind.lcs.mit.edu/~hari/ From: Hari Balakrishnan Reply-to: Hari Balakrishnan To: pilc@grc.nasa.gov, van@cisco.com cc: padmanab@microsoft.com, vern@ee.lbl.gov, hari@lcs.mit.edu Subject: PILC ASYM document Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Mar 2000 18:42:48 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Reviving an old, old thread about draft-ietf-pilc-asym-00.txt (Balakrishnan & Padmanabhan): On Mon, 22 Nov 1999 10:23:46 -0600, Spencer Dawkins wrote: > Van Jacobson: RFC 1144 header compression, in one-byte mode (as opposed to > five-six-byte mode), handles 3000:1 asymmetry. Are we seeing connection > paths that are more asymmetric than this? What's the point? This comment was from the PILC minutes of the Washington DC IETF (11/10/99). It has come to our attention from Aaron and Spencer (chairs of the working group) that we had perhaps not clarified what we meant by asymmetry, and that Van's comment above implied that a push-back was needed on this document. Venkat and I don't believe that this assessment is necessarily correct for the following reasons: 1. The document draft-ietf-pilc-asym-00.txt isn't about bandwidth asymmetry alone; it defines (perhaps inelegantly) "asymmetry" to be all cases when the characteristics of one direction "significantly" impact performance in the other. It goes on to describe several kinds of interactions, including bandwidth asymmetry (exacerbated in the presence of bi-directional traffic), media-access asymmetry that causes latency variability, error/loss rate asymmetry. All of these are _real_ and not just of academic interest. 2. If you have a bandwidth-asymmetric network and ACKs aren't going across a loss-prone path, VJ header compression solves the problem. Completely. The draft says as much. 3. But there are important, real cases when things aren't quite so simple: (i) Media-access. Many MAC protocols are RTS/CTS based, requiring a synchronization handshake before communication, with each failed RTS triggering an exponential backoff followed by retry. This avoids unnecessary data collisions that may otherwise result. Examples include many packet radio networks and the 802.11 spec. In such networks, it has been observed that latency can be highly variable, and as a result data and ACKs interact badly. The consequence is that the RTO becomes very large because rttvar is large. When a timeout occurs, the idle times are prohibitively large. In such situations, performance would improve a lot more from *infrequent* acks (and of course you need methods to deal with this at the sender, as described in the draft) than from *smaller* (header-compressed) ACKs. (Infrequent ACKs need to be dealt with without increasing burstiness, and the draft talks about this at length.) (ii) Bi-directional traffic. I didn't think this was such a common occurrence, but I recently received this message from a DSL customer, which I repeat verbatim below. (The customer recently graduated from MIT.) -------------------------------------------------------------------- Date: Mon, 31 Jan 2000 11:47:05 -0800 (PST) From: nelson@monkey.org (Nelson Minar) To: 6.892-students@MIT.EDU Subject: assymetry and TCP performance? I thought I was so smart after taking Hari's class last semester, but I'm having a hard time diagnosing a simple problem. I'm on PacBell DSL here in California. It's pretty good, 1.5 Mbits/sec downstream and 128 kbits/sec upstream or so. Reliable. Except one problem - when someone is downloading a file off of my web server, saturating the 128kbits/sec upstream link, then all my performance goes to hell. Pinging the gateway takes 2 seconds round trip, and things like DNS or web page fetches are either terrible performance or just don't work. I'd expect things to be a bit sluggish, but not anywhere near this bad. Is there anything simple written about assymetry and TCP performance? I have some guesses about what's going on, but I'd like to understand this problem better. Thanks! Nelson -------------------------------------------------------------------- One might think that this is an uncommon situation, but if you look at the way the Internet is evolving, nodes serving information from people's homes are becoming increasingly commonplace and are likely to dramatically increase in the next few years. I predict that situations like Nelson's above will not be rare in the near future, when we start putting all our computers and myriad other devices in our homes on the Internet. (iii) Loss rate asymmetry: Some of the techniques (e.g., sender adaptation) described in the draft handle this case as well, which is observed in many real systems including mobile ones where end stations transmit at much lower power and contend for reverse slots whereas the forward channel is from a high-powered base station and is therefore relatively loss-free. Given these situations, we believe that they are worth clearly documenting in a draft. I don't believe that these are of purely academic interest. We are very interested in your reactions to this. Thank you! Hari From owner-pilc@lerc.nasa.gov Wed Mar 1 19:55:57 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19337 for ; Wed, 1 Mar 2000 19:55:56 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA04575 for pilc-outgoing; Wed, 1 Mar 2000 19:01:20 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA04563 for ; Wed, 1 Mar 2000 19:01:18 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA01911; Wed, 1 Mar 2000 19:01:17 -0500 (EST) Received: from mgate-01.teledesic.com(216.190.22.41) by seraph3.lerc.nasa.gov via smap (V5.0) id xma001901; Wed, 1 Mar 00 19:01:09 -0500 Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2448.0) id <1MHV4GY1>; Wed, 1 Mar 2000 15:57:47 -0800 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE07B8100@tdmail2.teledesic.com> From: Marie-Jose Montpetit To: "'Dan Grossman'" Cc: "'pilc@grc.nasa.gov'" , "Phil Karn (E-mail)" , "Falk, Aaron" Subject: RE: Draft on Advice for Internet Subnetwork Designers Date: Wed, 1 Mar 2000 15:50:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk My own comments below. -----Original Message----- From: Dan Grossman [mailto:dan@dma.isg.mot.com] Sent: Wednesday, March 01, 2000 2:17 PM To: Falk, Aaron Cc: 'pilc@grc.nasa.gov'; Phil Karn (E-mail) Subject: Re: Draft on Advice for Internet Subnetwork Designers Comments: 1) Shortly before the Washington meeting, I sent a suggestion to change the Introduction/Overview section as follows. > ...seminal paper "End-to-End Arguments in System Design" [SRC81]. This paper > argued that many -- if not most -- network functions are best implemented on > an end-to-end basis, i.e., at the higher protocol layers. Duplicating these > functions at the lower levels can be needlessly redundant or harmful. > However, there are also cases where duplication can be justified by > considerations such as performance, availability or security. Examples > might include link layer retransmission on an unusually lossy channel, e.g., > mobile radio, encryption of the entire link layer protocol over a shared > medium, or redundant paths at the link layer for fault recovery. > Duplication of functions should be done only based on an understanding of > system level implications, including any side-effects on the higher layers. I still believe rather strongly that this is more appropriate than the current wording. Since it has been quite a while since the last discussion of the document on the mailing list, a reminder seems appropriate. I agree. Strangely enough I was also trying to come up with words for the introduction as it was apparent from the disucssions in Washington that the purpose of the LINK draft was not fully understood. While the actual wording is probably variable from one person to another I think the message should be clear that the LINK draft is there to help to have a system view hence to help sub-network designers get a flavor for the end to end aspects of deploying IP subnets and make sure these subnets integrate in the IP Network of Networks. 2) Some initial thoughts on what we should do with the empty section on buffering, congestion and flow control. Let's discuss on the list, and I'll draft text after the discussion: a) [Following owes a great deal to a side-discussion I had with Mark Allman] TCP needs lots of buffering. An ability to buffer bursts of up to (fixed delay)*(bottleneck rate) per TCP connection in each node is ideal if impractical. Problem is that neither the fixed delay nor the bottleneck rate is necessarily known at any node. A good approximation is fixed delay of the link * link bandwidth. For links that have variable delays, the approximation should be based on the max. Also, the maximum number of TCP connections per node is very difficult to determine a priori, and is not subject to any kind of admission control (except perhaps at a PEP). A SWAG has to suffice. Some kind of mechanism to measure delay on the link can be useful in autotuning buffer sizes. In general, more buffers are better than fewer. For example, TCP performance in very early ATM switch implementations suffered horribly from the small buffer sizes. Yes but if I remember this is also when the traffic statistics were basically ill undestood. While I do agree that more buffering is better than less, I would also raise the issue of buffering delays especially if a path goes through more than one subnet. Then do you have to implement some queue management at each point? b) There is a rough consensus (not unanimous) in the research community that active queue management is important to improving fairness, link utilization and throughput. Reference RFC 2309. Followed by a brief introduction to active queue management, with RED as an example. An important part of the concept is that active queue management attempts to keep average queue depths short, while accommodating short term bursts. It may be advisable for subnets that perform queueing and discarding to consider implementing some form of active queue management, especially if large aggregates of TCP connections are likely to share the same queue. It may be less effective in the case, for example, of an ATM switch that implements per-VC queueuing. Note, incidentally, that active queue management algorithms in general are highly sensitive to parameter settings and reference Borden and Fioriu paper. Again I agree. But do my question qould be to which level of detail we want to go? And is active queue management a link issue? c) If the subnet does fragmentation and reassembly, make sure that if it becomes necessary to discard, then discard entire frames, not just scattered fragments. For ATM, this specifically means using EPD/PPD, and reference ATM Forum TM 4.0 specification. Reference Romanow paper. Yes and I think we could even suggest that the subnet data unit (SDU?) have some markings for this. d) If the subnet includes flow control that shapes the rate at the edge of the subnet to match a share of the bottleneck bandwidth in the subnet (e.g., ATM ABR), this has the effect of pushing congestion to the edge of the subnet. In such a case, adequate buffering is needed at the edge of the subnet (see a above). Whether or not there is benefit in this kind of flow control is controversial, and there have been simulation studies that go both ways. Anecdotally, some large networks have used ABR sucessfully to carry IP traffic, but no published results. This also has links into the subnets that use bandwidth on demand and yes the buffering is an issue again. I have seen BTW RSVP to ATM results (S. Giordano) but not ABR. e) Flow control mechanisms that mark but do not shape frames in excess of fair share of the bottleneck rate (e.g., frame relay FECN and BECN) are at best useful only in the context of IP ECN (RFC 2481). New subnets would do well to have flow control mechanisms that have that semantics (i.e., feedback signal based on EWMA buffer size, feedback set probabilistically proportional to difference between two thresholds, or always set when second threshold exceeded) so that feedback could be 'bubbled up' from the subnet layer to the IP header. Yes. How about some bubbling up of air interface conditions into control messages or cost functions? 3) I have some ideas on QoS, which I'll try to organize and send out over the next few days. Any link will have to address the resource negociations/reservations and some of the diffserv issues; the active queue management you addressed already. Marie-Jose From owner-pilc@lerc.nasa.gov Wed Mar 1 21:46:06 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21209 for ; Wed, 1 Mar 2000 21:46:05 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA11072 for pilc-outgoing; Wed, 1 Mar 2000 20:56:04 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAA11055 for ; Wed, 1 Mar 2000 20:56:02 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id UAA12158; Wed, 1 Mar 2000 20:56:02 -0500 (EST) Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma012063; Wed, 1 Mar 00 20:55:17 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id SAA12044 for pilc@grc.nasa.gov env-from ; Wed, 1 Mar 2000 18:55:15 -0700 (MST) Date: Wed, 1 Mar 2000 18:55:15 -0700 (MST) From: Vernon Schryver Message-Id: <200003020155.SAA12044@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: PILC ASYM document Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Hari Balakrishnan > ... > 3. But there are important, real cases when things aren't quite so simple: > > (i) Media-access. Many MAC protocols are RTS/CTS based, > requiring a synchronization handshake before communication, with > each failed RTS triggering an exponential backoff followed by retry. > ... I don't understand the a priori relevance of such considerations. TCP is not a MAC protocol, and in general is supposed to be blithely ignorant of oddities in the link layer. > ... > (ii) Bi-directional traffic. I didn't think this was such a > common occurrence, but I recently received this message from a DSL > customer, which I repeat verbatim below. (The customer recently > graduated from MIT.) > ... > Except one problem - when someone is downloading a file off of > my web server, saturating the 128kbits/sec upstream link, then all > my performance goes to hell. Pinging the gateway takes 2 seconds > round trip, ... The problems there are irrelevant to the draft. First, no matter what you do, you can't get more than 128 kbit/sec from a 128 kbit/sec link. Second, such experiences show that saturating a link with mixtures of interactive and bulk traffic through with routers that no any notion of priority queues is a bad idea, which is not exactly a new discovery. > One might think that this is an uncommon situation, but if you > look at the way the Internet is evolving, nodes serving information from > people's homes are becoming increasingly commonplace and are likely to > dramatically increase in the next few years. I predict that situations > like Nelson's above will not be rare in the near future, when we start > putting all our computers and myriad other devices in our homes on the > Internet. Those problems are not new. In the good old days, many of us suffered exactly such situations as Nelson's, except that our links were 10 or 50 times slower. Please consider ancient asymmetric dial-up modems including those from (I think) Courier and modems that were sort-of assymetric like Telebits. > (iii) Loss rate asymmetry: Some of the techniques (e.g., sender > adaptation) described in the draft handle this case as well, which > is observed in many real systems including mobile ones where end > stations transmit at much lower power and contend for reverse slots > whereas the forward channel is from a high-powered base station > and is therefore relatively loss-free. That sounds like the old argument that the upper layers must be modified for every new link layer that comes along, regardless of whether how different it really is (think about Telebits). Some people reflexively resist that argument. > Given these situations, we believe that they are worth clearly > documenting in a draft. ... Anyone can write about almost anything in an offishal fur shure Internet Draft, as demonstrated by draft-terrell-ip-spec-ipv7-ipv8-addr-cls-*.txt. Besides, that draft-ietf-pilc-asym-00.txt exists is not controversial. The interesting question is what happens to a draft after it has been published. How people are supposed to respond to this draft? Is it intended to become a Proposed Standard or a BCP? Or would it become just another Informational RFC? Or is it a call to start some experiments? It seems that draft-ietf-pilc-asym-00.txt has two parts. One is a discussion of various problems, and the other advocates several significant de facto changes to TCP. It's hard to argue with a discussion of problems, but I'm not convinced of the wisdom of the advocated changes. For example, the document is not convincing about obvious worries about consequences of reconstructing ACK's, such as distorting the RTT measurement. (Yes, I've read the end of section 5.2.2.) For another example, I'm not convinced by section 5.1.5 that Acks-first scheduling does not require the gateway to explicitly identify or maintain state for individual TCP connections, if it wants to avoid re-ordering TCP segments in a single stream that contain data and those that don't. Please also note that the draft fails to mention by now ancient experience with some of its advocated changes to TCP, changes that have not been enthusiastically adopted. (Yes, I'm once again for the umpteenth time pointing at the ACK compression mechanisms used on a bunch of well known cable modem systems with 10 Mbit/sec downstream rates and 10-30 Kbit/sec upstream rates.) Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Wed Mar 1 23:27:06 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23440 for ; Wed, 1 Mar 2000 23:27:05 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA14125 for pilc-outgoing; Wed, 1 Mar 2000 21:59:08 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA14110 for ; Wed, 1 Mar 2000 21:59:04 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id VAA17368; Wed, 1 Mar 2000 21:59:04 -0500 (EST) Received: from out1.prserv.net(32.97.166.31) by seraph3.lerc.nasa.gov via smap (V5.0) id xma017334; Wed, 1 Mar 00 21:58:50 -0500 Received: from attglobal.net ([32.100.71.151]) by prserv.net (out1) with SMTP id <2000030202584425202ab4tme>; Thu, 2 Mar 2000 02:58:45 +0000 Message-ID: <38BDD8B7.D56083EA@attglobal.net> Date: Wed, 01 Mar 2000 18:57:59 -0800 From: Cannara Reply-To: cannara@attglobal.net X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Marie-Jose Montpetit CC: "'Dan Grossman'" , "'pilc@grc.nasa.gov'" , "Phil Karn (E-mail)" , "Falk, Aaron" Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <25D0C66E6D25D311B2AC0008C7913EE07B8100@tdmail2.teledesic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Another comment -- one point that was raised quite a while ago, but remains overlooked in IP6 is that dependence on TCP/UDP checksums is irrelevant to routers. The IP checksum, now absent in default IP6 pkts raises the possibility of bad router memory creating downstream problems for routers that cache route paths via address analysis. Any one router or level 3 switch with some bad buffer/register mem can wreak havoc in later router decision making. This seems to be one of a few curious steps backward taken in IP6. Alex Marie-Jose Montpetit wrote: > > My own comments below. > > -----Original Message----- > From: Dan Grossman [mailto:dan@dma.isg.mot.com] > Sent: Wednesday, March 01, 2000 2:17 PM > To: Falk, Aaron > Cc: 'pilc@grc.nasa.gov'; Phil Karn (E-mail) > Subject: Re: Draft on Advice for Internet Subnetwork Designers > > Comments: > > 1) Shortly before the Washington meeting, I sent a suggestion to change the > Introduction/Overview section as follows. > > > ...seminal paper "End-to-End Arguments in System Design" [SRC81]. This > paper > > argued that many -- if not most -- network functions are best implemented > on > > an end-to-end basis, i.e., at the higher protocol layers. Duplicating > these > > functions at the lower levels can be needlessly redundant or harmful. > > However, there are also cases where duplication can be justified by > > considerations such as performance, availability or security. Examples > > might include link layer retransmission on an unusually lossy channel, > e.g., > > mobile radio, encryption of the entire link layer protocol over a shared > > medium, or redundant paths at the link layer for fault recovery. > > Duplication of functions should be done only based on an understanding of > > system level implications, including any side-effects on the higher > layers. > > I still believe rather strongly that this is more appropriate than the > current > wording. Since it has been quite a while since the last discussion of the > document on the mailing list, a reminder seems appropriate. > > I agree. Strangely enough I was also trying to come up with words for the > introduction as it was apparent from the disucssions in Washington that the > purpose of the LINK draft was not fully understood. While the actual wording > is probably variable from one person to another I think the message should > be clear that the LINK draft is there to help to have a system view hence to > help sub-network designers get a flavor for the end to end aspects of > deploying IP subnets and make sure these subnets integrate in the IP Network > of Networks. > > 2) Some initial thoughts on what we should do with the empty section on > buffering, congestion and flow control. Let's discuss on the list, and I'll > > draft text after the discussion: > a) [Following owes a great deal to a side-discussion I had with Mark Allman] > > TCP needs lots of buffering. An ability to buffer bursts of up to (fixed > delay)*(bottleneck rate) per TCP connection in each node is ideal if > impractical. Problem is that neither the fixed delay nor the bottleneck > rate > is necessarily known at any node. A good approximation is fixed delay of > the > link * link bandwidth. For links that have variable delays, the > approximation > should be based on the max. Also, the maximum number of TCP connections per > > node is very difficult to determine a priori, and is not subject to any kind > > of admission control (except perhaps at a PEP). A SWAG has to suffice. > Some > kind of mechanism to measure delay on the link can be useful in autotuning > buffer sizes. In general, more buffers are better than fewer. For example, > > TCP performance in very early ATM switch implementations suffered horribly > from the small buffer sizes. > > Yes but if I remember this is also when the traffic statistics were > basically ill undestood. While I do agree that more buffering is better than > less, I would also raise the issue of buffering delays especially if a path > goes through more than one subnet. Then do you have to implement some queue > management at each point? > > b) There is a rough consensus (not unanimous) in the research community that > > active queue management is important to improving fairness, link utilization > > and throughput. Reference RFC 2309. Followed by a brief introduction to > active queue management, with RED as an example. An important part of the > concept is that active queue management attempts to keep average queue > depths > short, while accommodating short term bursts. It may be advisable for > subnets > that perform queueing and discarding to consider implementing some form of > active queue management, especially if large aggregates of TCP connections > are > likely to share the same queue. It may be less effective in the case, for > example, of an ATM switch that implements per-VC queueuing. Note, > incidentally, that active queue management algorithms in general are highly > sensitive to parameter settings and reference Borden and Fioriu paper. > > Again I agree. But do my question qould be to which level of detail we want > to go? And is active queue management a link issue? > > c) If the subnet does fragmentation and reassembly, make sure that if it > becomes necessary to discard, then discard entire frames, not just scattered > > fragments. For ATM, this specifically means using EPD/PPD, and reference ATM > > Forum TM 4.0 specification. Reference Romanow paper. > > Yes and I think we could even suggest that the subnet data unit (SDU?) have > some markings for this. > > d) If the subnet includes flow control that shapes the rate at the edge of > the > subnet to match a share of the bottleneck bandwidth in the subnet (e.g., ATM > > ABR), this has the effect of pushing congestion to the edge of the subnet. > In > such a case, adequate buffering is needed at the edge of the subnet (see a > above). Whether or not there is benefit in this kind of flow control is > controversial, and there have been simulation studies that go both ways. > Anecdotally, some large networks have used ABR sucessfully to carry IP > traffic, but no published results. > > This also has links into the subnets that use bandwidth on demand and yes > the buffering is an issue again. I have seen BTW RSVP to ATM results (S. > Giordano) but not ABR. > > e) Flow control mechanisms that mark but do not shape frames in excess of > fair > share of the bottleneck rate (e.g., frame relay FECN and BECN) are at best > useful only in the context of IP ECN (RFC 2481). New subnets would do well > to > have flow control mechanisms that have that semantics (i.e., feedback signal > > based on EWMA buffer size, feedback set probabilistically proportional to > difference between two thresholds, or always set when second threshold > exceeded) so that feedback could be 'bubbled up' from the subnet layer to > the > IP header. > > Yes. How about some bubbling up of air interface conditions into control > messages or cost functions? > > 3) I have some ideas on QoS, which I'll try to organize and send out over > the > next few days. > > Any link will have to address the resource negociations/reservations and > some of the diffserv issues; the active queue management you addressed > already. > > Marie-Jose > From owner-pilc@lerc.nasa.gov Wed Mar 1 23:38:58 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23998 for ; Wed, 1 Mar 2000 23:38:58 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA14517 for pilc-outgoing; Wed, 1 Mar 2000 22:06:37 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA14505 for ; Wed, 1 Mar 2000 22:06:35 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id WAA17999; Wed, 1 Mar 2000 22:06:34 -0500 (EST) Received: from breeze.lcs.mit.edu(18.31.0.83) by seraph3.lerc.nasa.gov via smap (V5.0) id xma017900; Wed, 1 Mar 00 22:06:06 -0500 Received: from breeze.lcs.mit.edu (hari@localhost [127.0.0.1]) by breeze.lcs.mit.edu (8.8.7/8.8.7) with ESMTP id WAA02582; Wed, 1 Mar 2000 22:07:59 -0500 Message-Id: <200003020307.WAA02582@breeze.lcs.mit.edu> X-Mailer: exmh version 2.0.2 Reply-To: Hari Balakrishnan X-url: http://wind.lcs.mit.edu/~hari/ To: Vernon Schryver cc: pilc@grc.nasa.gov Subject: Re: PILC ASYM document In-reply-to: Your message of "Wed, 01 Mar 2000 18:55:15 MST" <200003020155.SAA12044@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Mar 2000 22:07:58 -0500 From: Hari Balakrishnan Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Dear Vernon, On Wed, 01 Mar 2000 18:55:15 MST, you wrote: > > From: Hari Balakrishnan > > > ... > > 3. But there are important, real cases when things aren't quite so simple: > > > > (i) Media-access. Many MAC protocols are RTS/CTS based, > > requiring a synchronization handshake before communication, with > > each failed RTS triggering an exponential backoff followed by retry. > > ... > > I don't understand the a priori relevance of such considerations. > TCP is not a MAC protocol, and in general is supposed to be blithely > ignorant of oddities in the link layer. And indeed it is. Making it robust to infrequent ACKs is an all-round win. No one is suggesting any link-specific modification to TCP. > > (ii) Bi-directional traffic. I didn't think this was such a > > common occurrence, but I recently received this message from a DSL > > customer, which I repeat verbatim below. (The customer recently > > graduated from MIT.) > > > ... > > Except one problem - when someone is downloading a file off of > > my web server, saturating the 128kbits/sec upstream link, then all > > my performance goes to hell. Pinging the gateway takes 2 seconds > > round trip, ... > > The problems there are irrelevant to the draft. First, no matter what > you do, you can't get more than 128 kbit/sec from a 128 kbit/sec link. > Second, such experiences show that saturating a link with mixtures of > interactive and bulk traffic through with routers that no any notion of > priority queues is a bad idea, which is not exactly a new discovery. Gosh, who said anything about interactive traffic! This happens when you're doing bulk traffic in both directions. The problems are quite relevant to the draft. > > One might think that this is an uncommon situation, but if you > > look at the way the Internet is evolving, nodes serving information from > > people's homes are becoming increasingly commonplace and are likely to > > dramatically increase in the next few years. I predict that situations > > like Nelson's above will not be rare in the near future, when we start > > putting all our computers and myriad other devices in our homes on the > > Internet. > > Those problems are not new. In the good old days, many of us suffered > exactly such situations as Nelson's, except that our links were 10 or 50 > times slower. Please consider ancient asymmetric dial-up modems including > those from (I think) Courier and modems that were sort-of assymetric like > Telebits. Evidently you decided to do nothing about the problem then, same as now. :) (Sorry, couldn't resist, given your general tone.) > > (iii) Loss rate asymmetry: Some of the techniques (e.g., sender > > adaptation) described in the draft handle this case as well, which > > is observed in many real systems including mobile ones where end > > stations transmit at much lower power and contend for reverse slots > > whereas the forward channel is from a high-powered base station > > and is therefore relatively loss-free. > > That sounds like the old argument that the upper layers must be > modified for every new link layer that comes along, regardless of > whether how different it really is (think about Telebits). > Some people reflexively resist that argument. In general, reflexive reactions aren't well-advised in a scientific discipline. Furthermore, many of the solutions advocated in the draft are link-layer ones. The changes proposed to TCP itself are all ones that DO NOT degrade TCP behavior or performance over any other paths, and often, they improve them. Ergo, I believe they are a good idea; the solutions are not of the form where they improve performance in one situation and degrade it in several other places. > > Given these situations, we believe that they are worth clearly > > documenting in a draft. ... > > Anyone can write about almost anything in an offishal fur shure Internet > Draft, as demonstrated by draft-terrell-ip-spec-ipv7-ipv8-addr-cls-*.txt. > Besides, that draft-ietf-pilc-asym-00.txt exists is not controversial. > The interesting question is what happens to a draft after it has been > published. How people are supposed to respond to this draft? Is it > intended to become a Proposed Standard or a BCP? Or would it become > just another Informational RFC? Or is it a call to start some experiments? Frankly, whether or not the draft exists makes no difference to me personally. However, I think that not being aware of some important issues (not merely academic ones) that affect TCP performance over some classes of real networks is not a good situation. It isn't a call for more experiments necessarily, although that would be welcome. I assumed it would be informational. I don't know for sure though, I suppose it also depends on the WG chairs. Hari Balakrishnan http://wind.lcs.mit.edu/~hari/ From owner-pilc@lerc.nasa.gov Thu Mar 2 03:16:03 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08553 for ; Thu, 2 Mar 2000 03:16:03 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA26210 for pilc-outgoing; Thu, 2 Mar 2000 02:09:51 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA26200 for ; Thu, 2 Mar 2000 02:09:46 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA08135; Thu, 2 Mar 2000 02:09:44 -0500 (EST) Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma008125; Thu, 2 Mar 00 02:09:29 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id AAA16766 for pilc@grc.nasa.gov env-from ; Thu, 2 Mar 2000 00:09:28 -0700 (MST) Date: Thu, 2 Mar 2000 00:09:28 -0700 (MST) From: Vernon Schryver Message-Id: <200003020709.AAA16766@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: PILC ASYM document Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Hari Balakrishnan > ... > > I don't understand the a priori relevance of such considerations. > > TCP is not a MAC protocol, and in general is supposed to be blithely > > ignorant of oddities in the link layer. > > And indeed it is. Making it robust to infrequent ACKs is an all-round win. No > one is suggesting any link-specific modification to TCP. I don't understand that. Where do you have infrequent ACKs in an active TCP connection except where a strange link layer is being either very smart or too smart by half, and eating ACKs? What happened to the notion of "ACK pacing"? Making TCP robust to infrequent ACKs is a special change particularly for links that like to preferentially eat some special kinds of upper layer frames. It might well be a good idea, but with no offense intended, more than academic assurances would be nice before we rush out and modify all current TCP implementations. > > > ... > > > Except one problem - when someone is downloading a file off of > > > my web server, saturating the 128kbits/sec upstream link, then all > > > my performance goes to hell. Pinging the gateway takes 2 seconds > > > round trip, ... > > > > The problems there are irrelevant to the draft. First, no matter what > > you do, you can't get more than 128 kbit/sec from a 128 kbit/sec link. > > Second, such experiences show that saturating a link with mixtures of > > interactive and bulk traffic through with routers that no any notion of > > priority queues is a bad idea, which is not exactly a new discovery. > > Gosh, who said anything about interactive traffic! This happens when you're > doing bulk traffic in both directions. Nelson's only quantitative performance measurement (that I recall) involved interactive stuff, his 2 second pings. He didn't say anything (as I recall) in terms of bits/sec that showed the downstream pipe was not full. It might not have been full, and one would hope an MIT alumni would do a complete set of measurements. However, the left coast does affect people. I've even known people on the right coast within a rifle shot of MIT to blow off a little private steam in wildly overstated complaints about lame ISP services. > ... > > Those problems are not new. In the good old days, many of us suffered > > exactly such situations as Nelson's, except that our links were 10 or 50 > > times slower. Please consider ancient asymmetric dial-up modems including > > those from (I think) Courier and modems that were sort-of assymetric like > > Telebits. > > Evidently you decided to do nothing about the problem then, same as now. :) > (Sorry, couldn't resist, given your general tone.) Actually, that's wrong. We have various link layer things including data compression, VJ header compression, and various priority queueing at least partly because of the old problems. Note that the things we do have received a lot of real life testing and serious measuring before they were documented in RFC's. Besides, one of my favorite sayings goes something like "anyone can always find something to add to anything." Some of what you propose might be very good things. One or two meet my personal prejudices for what's right and needed dead on. However, as far as I can tell, you've offered only academic or qualitative and anecdotal support for them. In other words, what kind of RFC should your draft should become? > > > (iii) Loss rate asymmetry: Some of the techniques (e.g., sender > > > adaptation) described in the draft handle this case as well, which > > > is observed in many real systems including mobile ones where end > > > stations transmit at much lower power and contend for reverse slots > > > whereas the forward channel is from a high-powered base station > > > and is therefore relatively loss-free. > > > > That sounds like the old argument that the upper layers must be > > modified for every new link layer that comes along, regardless of > > whether how different it really is (think about Telebits). > > Some people reflexively resist that argument. > > In general, reflexive reactions aren't well-advised in a scientific discipline In general, that is false. This isn't a scientific discipline, but if it were, Occam's Razor would be a reputable reflexive reaction. In an engineering discipline like our's, Occam's Razor as well as the rule of thumb that says you don't change things without good, quantitative reasons are wise reflexes. >Furthermore, many of the solutions advocated in the draft are link-layer ones The whole point of your proposals is to affect TCP. Most of your proposals ("solutions"?--sheesh!) might large effects on TCP, assume TCP has certain behaviors (e.g. RTT measurement won't be trashed by ACK compression or performance won't be zapped by re-ordered TCP segments), or assume TCP will be changed at least slightly (e.g. made "robust to infrequent ACKs"). > The changes proposed to TCP itself are all ones that DO NOT degrade TCP > behavior or performance over any other paths, and often, they improve them. > > Ergo, I believe they are a good idea; the solutions are not of the form where > they improve performance in one situation and degrade it in several other > places. I'm sure you think so. Over the years I too have had wonderful ideas that I was sure would have lots of wonderful results and no bad effects. I was even right on the second half about one or two of them. In other words, if you're proposing a BCP or STD, it's far too early. Still, the ideas would be interesting to test seriously, and I don't mean a couple of master's thesis simulations suitable for IEEE publication. (I hope no one has done any of those for these ideas since I don't intend any particular offense by that point.) And characterizing your proposals as "solutions" again? I'd go for "proposed solutions", "possible solutions," or even "likely solutions", but you're a *long* way from bald "solutions". You haven't even offered convincing evidence for all of your characterizations of the problems! > .. > > The interesting question is what happens to a draft after it has been > > published. How people are supposed to respond to this draft? Is it > > intended to become a Proposed Standard or a BCP? Or would it become > > just another Informational RFC? Or is it a call to start some experiments? > > Frankly, whether or not the draft exists makes no difference to me personally > However, I think that not being aware of some important issues (not merely > academic ones) that affect TCP performance over some classes of real networks > is not a good situation. > > It isn't a call for more experiments necessarily, although that would be > welcome. I assumed it would be informational. I don't know for sure though > I suppose it also depends on the WG chairs. Urging serious experiments of the ideas is a good idea. However, you keep talking about "solutions," which would be strong for an official working group Informational RFC. Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Thu Mar 2 04:37:31 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09154 for ; Thu, 2 Mar 2000 04:37:30 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA00147 for pilc-outgoing; Thu, 2 Mar 2000 03:20:17 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id DAA00138 for ; Thu, 2 Mar 2000 03:20:16 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA13494; Thu, 2 Mar 2000 03:20:15 -0500 (EST) Received: from ra5399b-port38.qualcomm.com(129.46.55.165) by seraph3.lerc.nasa.gov via smap (V5.0) id xma013489; Thu, 2 Mar 00 03:20:10 -0500 Received: (from karn@localhost) by laptop.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id AAA00479; Thu, 2 Mar 2000 00:20:05 -0800 Date: Thu, 2 Mar 2000 00:20:05 -0800 Message-Id: <200003020820.AAA00479@laptop.ka9q.ampr.org> From: Phil Karn To: marie@teledesic.com CC: dan@dma.isg.mot.com, pilc@grc.nasa.gov, afalk@PanAmSat.com In-reply-to: <25D0C66E6D25D311B2AC0008C7913EE07B8100@tdmail2.teledesic.com> (message from Marie-Jose Montpetit on Wed, 1 Mar 2000 15:50:38 -0800) Subject: Re: Draft on Advice for Internet Subnetwork Designers Reply-to: karn@qualcomm.com References: <25D0C66E6D25D311B2AC0008C7913EE07B8100@tdmail2.teledesic.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Thanks for all the comments. I'll work on incorporating them into the draft this weekend after I get back from the IAB workshop. Phil From owner-pilc@lerc.nasa.gov Thu Mar 2 12:49:58 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20825 for ; Thu, 2 Mar 2000 12:49:56 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA10810 for pilc-outgoing; Thu, 2 Mar 2000 10:41:27 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA10754 for ; Thu, 2 Mar 2000 10:41:21 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA23122; Thu, 2 Mar 2000 10:41:20 -0500 (EST) Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.0) id xma023050; Thu, 2 Mar 00 10:40:39 -0500 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.10.0.Beta12/8.10.0.Beta12) with ESMTP id e22FjoI02806; Thu, 2 Mar 2000 15:45:50 GMT Message-ID: <38BE7D3E.71079764@erg.abdn.ac.uk> Date: Thu, 02 Mar 2000 15:43:15 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Joe Touch , pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <200003011811.KAA21226@boreas.isi.edu> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I know this is in danger of getting really side-tracked, and what you say is interesting, but the subnet link designer is interested in subnet payload size, not just MTU. What I meant to say was there are conditions under which the payload size is reduced, because a PMTU smaller than the link MTU was selected by PMTU discovery. Gorry Joe Touch wrote: > > From gorry@erg.abdn.ac.uk Wed Mar 1 05:12:19 2000 > > Date: Wed, 01 Mar 2000 13:30:30 +0100 > > From: Dr G Fairhurst > > To: touch > > CC: pilc@grc.nasa.gov > > Subject: Re: Draft on Advice for Internet Subnetwork Designers > > > > More clarification... > > > > Joe Touch wrote: > > > > > > "Falk, Aaron" wrote: > > > > > > > > PAGE 4: MTU Size > > > > > > > > It may be useful to note that using IPSEC in tunnel mode can increase > > > > the size of a packet as it travels across the network. This can result > > > > in a smaller MTU. > > > > > > Doesn't IPSEC in any mode do this? (tunnel or transport?) > > > > > > (provided it's added after the source - and, in the case > > > of overlay networks, [paradoxically] transport may be > > > more useful) > > > > Sure, you are correct. But, I seem to remember the draft mentioning 1500B MTU. > > Now, since this is a link designer's draft, what we are presumably interested in > > is frame payload data size... So, if normal IP is used that is maximum 1500B. > > If IPSEC is used end-to-end that is still 1500B of frame payload, even though > > MTU is reduced. But with tunnel mode along part of the path, the rest of the > > path outside the tunnel now sees a reduced MTU - or the tunneled path needs > > to support a larger frame size. Just saying 1500B is not a > > universal MTU anymore. > > It doesn't matter where IPSEC is used - E2E or tunnel. Either > way eats into the MTU. The PILC doc is talking about link MTUs; > everything except the link header consumes that. > > > > > IPv6 does > > > > not therefore implement a network level integrity checksum. The role of the > > > > IP checksum has therefore been subsumed into the TCP and UDP > > > > checksums. > > > > > > More into IPSEC than into TCP and UDP, no? > > > > IPSEC is one way, it is not (I think) mandatory, so TCP/UDP may still get > > bad packets which they have to reject.... > > Support for IPSEC is mandatory in IPv6, which is where the IP checksum > has been removed. Its _use_ is not mandatory. > > The role of the IP checksum was to check the IP header. The role of > the TCP/UDP checksums is to check the data. If you want to protect/sum > the header, you should (and thus, above, can) use IPSEC. > > Joe From owner-pilc@lerc.nasa.gov Thu Mar 2 15:45:25 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26354 for ; Thu, 2 Mar 2000 15:45:25 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA15069 for pilc-outgoing; Thu, 2 Mar 2000 14:31:11 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA15050 for ; Thu, 2 Mar 2000 14:31:10 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA23514; Thu, 2 Mar 2000 14:31:08 -0500 (EST) Received: from bunny.panamsat.com(208.217.183.130) by seraph3.lerc.nasa.gov via smap (V5.0) id xma023472; Thu, 2 Mar 00 14:30:56 -0500 Received: by atlconn1.panamsat.com with Internet Mail Service (5.5.2448.0) id ; Thu, 2 Mar 2000 14:30:54 -0500 Message-ID: <8046A317B5F4D21186610008C7EBB696F05644@grnexch1.panamsat.com> From: "Falk, Aaron" To: "'Vernon Schryver'" Cc: pilc@grc.nasa.gov Subject: RE: PILC ASYM document Date: Thu, 2 Mar 2000 14:26:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Vernon wrote: > ... > The interesting question is what happens to a draft after it has been > published. How people are supposed to respond to this draft? Is it > intended to become a Proposed Standard or a BCP? Or would it become > just another Informational RFC? Or is it a call to start > some experiments? Vernon- The ASYM document is in our charter to be published as a BCP. This choice was made before a document was written and the assumption was that it would contain a) a description of the problems, b) proposed well-understood mitigations (implemented at the layer of your choice), and possibly, well-caveated proposals for future protocol development. The PILC charter does not include developing any new protocols. However, if we find something that we believe should be developed, we can approach the IESG about rechartering the working group. The working group has several options: - the topic can be discarded as not relevant and the draft allowed to expire (or submitted as a non-wg draft by the authors), - the draft can be submitted by the working group as an Informational or BCP RFC, - and/or we can seek to develop some protocol changes and an STD. A key to determining what will happen will be how large the consituency is and deep the need is. Hence this discussion... Before the working group could take on developing a new protocol, a compelling argument needs to be made for the need of such an activity. Hari and Venkat have made their case that this is a real problem and I'm looking to the mail list for validation that the problem merits further definition and the proposals merit further development by this working group. I appreciate your comments and invite more. --aaron From owner-pilc@lerc.nasa.gov Thu Mar 2 18:35:20 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01532 for ; Thu, 2 Mar 2000 18:35:20 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA06843 for pilc-outgoing; Thu, 2 Mar 2000 17:07:20 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA06805 for ; Thu, 2 Mar 2000 17:07:17 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA14884; Thu, 2 Mar 2000 17:07:16 -0500 (EST) Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma014856; Thu, 2 Mar 00 17:07:05 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id PAA01125 for pilc@grc.nasa.gov env-from ; Thu, 2 Mar 2000 15:07:01 -0700 (MST) Date: Thu, 2 Mar 2000 15:07:01 -0700 (MST) From: Vernon Schryver Message-Id: <200003022207.PAA01125@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: RE: PILC ASYM document Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: "Falk, Aaron" > ... > The ASYM document is in our charter to be published as a BCP. This choice > was made before a document was written and the assumption was that it would > contain a) a description of the problems, b) proposed well-understood > mitigations (implemented at the layer of your choice), and possibly, > well-caveated proposals for future protocol development. The PILC charter > does not include developing any new protocols. However, if we find something > that we believe should be developed, we can approach the IESG about > rechartering the working group. It is clear Hari's document cannot conceivably be (part of) a Best Current Practices in the immediate future. I think Hari agrees with that, despite his unqualified uses of "problem" and "solution." Before ACK regenerating, ACK-only scheduling, or the other ideas could be listed in a BCP, we need real testing to see what they break. (Claims that nothing would break are obvious nonsense; every worthwhile change in a system as big as the Internet breaks something that someone somewhere values. Worse, no one knows enough about the system to predict accurately what will break.) The many ADSL networks provide many test beds for some hacks on free UNIX and Linux kernels. Some artificial throttling and random filtering might ADLS links similar to wireless links. If the ideas are safe enough, users of modified systems would not notice the change. > The working group has several options: > > - the topic can be discarded as not relevant and the draft allowed to expire > (or submitted as a non-wg draft by the authors), > > - the draft can be submitted by the working group as an Informational or BCP > RFC, > > - and/or we can seek to develop some protocol changes and an STD. > > A key to determining what will happen will be how large the consituency is > and deep the need is. Hence this discussion... The issues (note I didn't say "problems") listed in Hari's document have long had a significant consituency outside the IETF. (Yes, I'm yet again refering in part to cable modem games with ACKs.) I think the issues are more worthy than many other IETF activities, such as the zillions of MIB's. > Before the working group could take on developing a new protocol, a > compelling argument needs to be made for the need of such an activity. Hari > and Venkat have made their case that this is a real problem and I'm looking > to the mail list for validation that the problem merits further definition > and the proposals merit further development by this working group. > > I appreciate your comments and invite more. The practice followed by Van Jacobson, Sally Floyd, and others has worked pretty well over the years. They do lots of simulating, testing, and more than prototype implementing before publishing anything, or at least before announcing solutions or proposing IETF sanctioned changes in widely deployed implementations. A recent example is the change in the initial TCP window, which was done at least partly under the auspices of the TCP Implementors working group. (I don't mean to say anything about which WG should own which territory, but only offer a relevant mailinglist archive.) Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Thu Mar 2 19:27:38 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02182 for ; Thu, 2 Mar 2000 19:27:37 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA11273 for pilc-outgoing; Thu, 2 Mar 2000 17:55:19 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA11255 for ; Thu, 2 Mar 2000 17:55:17 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA20631; Thu, 2 Mar 2000 17:55:17 -0500 (EST) Received: from motgate.mot.com(129.188.136.100) by seraph3.lerc.nasa.gov via smap (V5.0) id xma020615; Thu, 2 Mar 00 17:55:05 -0500 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id PAA28918; Thu, 2 Mar 2000 15:53:42 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA21298; Thu, 2 Mar 2000 15:53:37 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id RAA23882; Thu, 2 Mar 2000 17:53:33 -0500 (EST) Message-Id: <200003022253.RAA23882@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Marie-Jose Montpetit cc: "'pilc@grc.nasa.gov'" , "Phil Karn (E-mail)" , "Falk, Aaron" Subject: Re: Draft on Advice for Internet Subnetwork Designers In-reply-to: Your message of "Wed, 01 Mar 2000 15:50:38 EST." <25D0C66E6D25D311B2AC0008C7913EE07B8100@tdmail2.teledesic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Mar 2000 17:53:32 -0500 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > a) [Following owes a great deal to a side-discussion I had with Mark Allman] > > TCP needs lots of buffering. An ability to buffer bursts of up to (fixed > delay)*(bottleneck rate) per TCP connection in each node is ideal if > impractical. Problem is that neither the fixed delay nor the bottleneck > rate > is necessarily known at any node. A good approximation is fixed delay of > the > link * link bandwidth. For links that have variable delays, the > approximation > should be based on the max. Also, the maximum number of TCP connections per > > node is very difficult to determine a priori, and is not subject to any kind > > of admission control (except perhaps at a PEP). A SWAG has to suffice. > Some > kind of mechanism to measure delay on the link can be useful in autotuning > buffer sizes. In general, more buffers are better than fewer. For example, > > TCP performance in very early ATM switch implementations suffered horribly > from the small buffer sizes. > > Yes but if I remember this is also when the traffic statistics were > basically ill undestood. While I do agree that more buffering is better than > less, I would also raise the issue of buffering delays especially if a path > goes through more than one subnet. Then do you have to implement some queue > management at each point? > The model I've been working with (especially since that side discussion) is that if the subnet does queueing (buffering, scheduling, discarding), then the queueing systems in the subnet has exactly the same effect as queues in routers. This may be worth stating. Thus, recommendations about having a window size worth of buffers per TCP connection, using active queue management, etc. in the subnet would follow from similar recommendations at the IP layer. As with IP layer forwarding, the objective is not to have large buffers that are always full, but rather the capability to absorb large bursts. Since many of the kinds of subnets we're talking about will be (or will contain) the bottleneck link, one might expect that an entire window's worth of data might easily wind up at a single node in the subnet. > b) There is a rough consensus (not unanimous) in the research community that > > active queue management is important to improving fairness, link utilization > > and throughput. Reference RFC 2309. Followed by a brief introduction to > active queue management, with RED as an example. An important part of the > concept is that active queue management attempts to keep average queue > depths > short, while accommodating short term bursts. It may be advisable for > subnets > that perform queueing and discarding to consider implementing some form of > active queue management, especially if large aggregates of TCP connections > are > likely to share the same queue. It may be less effective in the case, for > example, of an ATM switch that implements per-VC queueuing. Note, > incidentally, that active queue management algorithms in general are highly > sensitive to parameter settings and reference Borden and Fioriu paper. > > Again I agree. But do my question qould be to which level of detail we want > to go? And is active queue management a link issue? Probably not much more detail than the sketch. Details could be by reference. > > c) If the subnet does fragmentation and reassembly, make sure that if it > becomes necessary to discard, then discard entire frames, not just scattered > > fragments. For ATM, this specifically means using EPD/PPD, and reference ATM > > Forum TM 4.0 specification. Reference Romanow paper. > > Yes and I think we could even suggest that the subnet data unit (SDU?) have > some markings for this. Can you explain? > > d) If the subnet includes flow control that shapes the rate at the edge of > the > subnet to match a share of the bottleneck bandwidth in the subnet (e.g., ATM > > ABR), this has the effect of pushing congestion to the edge of the subnet. > In > such a case, adequate buffering is needed at the edge of the subnet (see a > above). Whether or not there is benefit in this kind of flow control is > controversial, and there have been simulation studies that go both ways. > Anecdotally, some large networks have used ABR sucessfully to carry IP > traffic, but no published results. > > This also has links into the subnets that use bandwidth on demand and yes > the buffering is an issue again. I have seen BTW RSVP to ATM results (S. > Giordano) but not ABR. RSVP to ATM is an unrelated issue. Raj Jain and some of his students did a lot of simulation papers on this a few years ago. So did Marty Borden and Nanying Yin (I think). And there were some advocacy papers in the ATM Forum. I think it's fair to say that there was no consensus among the researchers in this area. In the meantime, I have heard that there have been some sucessful deployments, but the network operators involved have not published their results. > e) Flow control mechanisms that mark but do not shape frames in excess of > fair > share of the bottleneck rate (e.g., frame relay FECN and BECN) are at best > useful only in the context of IP ECN (RFC 2481). New subnets would do well > to > have flow control mechanisms that have that semantics (i.e., feedback signal > > based on EWMA buffer size, feedback set probabilistically proportional to > difference between two thresholds, or always set when second threshold > exceeded) so that feedback could be 'bubbled up' from the subnet layer to > the > IP header. > > Yes. How about some bubbling up of air interface conditions into control > messages or cost functions? I'm not sure what you're suggesting. The semantics that I wanted to 'bubble up' is identical to that of the ECN in RFC 2481 (see my observation above). Thus, a queue in the subnet could provide a filtered indication to the TCP layer that it was congested just as if were a queue in a router. What semantics in an air interface could map to any existing or potential semantics in IP? > Marie-Jose Dan From owner-pilc@lerc.nasa.gov Thu Mar 2 20:59:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02986 for ; Thu, 2 Mar 2000 20:59:02 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA17432 for pilc-outgoing; Thu, 2 Mar 2000 19:31:20 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA17413 for ; Thu, 2 Mar 2000 19:31:19 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA29883; Thu, 2 Mar 2000 19:31:17 -0500 (EST) Received: from mail2.microsoft.com(131.107.3.124) by seraph3.lerc.nasa.gov via smap (V5.0) id xma029843; Thu, 2 Mar 00 19:30:37 -0500 Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 Mar 2000 16:29:59 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Thu, 2 Mar 2000 16:29:59 -0800 Message-ID: <3924E6A6E200D211BAC900805F6FC9E1082E6BF2@RED-MSG-11> From: Venkat Padmanabhan To: "'Vernon Schryver'" , pilc@grc.nasa.gov Subject: RE: PILC ASYM document Date: Thu, 2 Mar 2000 16:29:55 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > > (i) Media-access. Many MAC protocols are RTS/CTS based, > > requiring a synchronization handshake before communication, with > > each failed RTS triggering an exponential backoff followed by retry. > > ... > > I don't understand the a priori relevance of such considerations. > TCP is not a MAC protocol, and in general is supposed to be blithely > ignorant of oddities in the link layer. Unless there are aspects of TCP that interact poorly with the link's characteristics. Media access asymmetry is often a fundamental artifact of the hub-and-spokes configuration of the network. It is often a lot less expensive for the hub (e.g., a wireless base station or cable modem head-end equipment) to transmit packets to the (distributed) end-stations than it is for the latter to transmit to the hub (due to contention). In the context of a downstream TCP data transfer (i.e., in the direction from the hub to an end-station), this characteristic of the link would make the transmission of ack packets by the end-station expensive, regardless of the size of those packets. Hari and I have observed this problem via simulations and actual measurements of a packet radio network. (See sections 5 and 7.2 of http://www.research.microsoft.com/~padmanab/papers/monet99-tcpasym.ps.gz). We also have anecdotal evidence of similar problems in cable modem systems. We were hoping to hear experiences of other people confirming or refuting this. Barbed emails heavy in sarcasm unfortunately drown out whatever technical point was sought to be conveyed. Regarding your implication that TCP should be ignorant of the oddities of the link layer, an analogy might illustrate why this argument isn't necessarily right. HTTP/1.0 (an application-level protocol) ignored artifacts of the underlying TCP transport protocol (e.g., slow start) and opened a new TCP connection for each request. Consequently, performance suffered. > The problems there are irrelevant to the draft. First, no matter what > you do, you can't get more than 128 kbit/sec from a 128 kbit/sec link. I would second your remark about the 128 Kbps link, but I don't see why it is relevant. No one is claiming that a 128 Kbps link could/should be driven faster than 128 Kbps. The point is that congestion on the 128 Kbps uplink resulted in poor utilization of the 1.5 Mbps downlink. > Second, such experiences show that saturating a link with mixtures of > interactive and bulk traffic through with routers that no any > notion of > priority queues is a bad idea, which is not exactly a new discovery. What we are talking about of here is not "mixtures of interactive and bulk traffic". Rather it is the interference between the acks of a downstream bulk transfer with data packets of an upstream bulk transfer. > That sounds like the old argument that the upper layers must be > modified for every new link layer that comes along, regardless of > whether how different it really is (think about Telebits). > Some people reflexively resist that argument. I have no idea what Telebits is, but regardless we are not arguing that the upper layers must be modified for every new link layer. Rather we have attempted to document a set of problems related to asymmetry and an approach to addressing these that has a common thread: reducing the frequency of acks -- a generalization of delayed acks, if you will -- and making the sender robust against disruptions in the ack stream. These have been derived from our experience/experiments with a few network technologies. Whether to turn any of this into a proposed standard would depend on whether there is a consensus on their relevance in a wider setting > Is it intended to become a Proposed Standard or a BCP? Or would it become > just another Informational RFC? Or is it a call to start > some experiments? > Good question. As Aaron states, the PILC WG's current charter precludes turning this into a proposed standard (of course, I realize that this technicality is not the only hurdle in the way!). If there is sufficient consensus and supplementary/supporting evidence (e.g., experiences with other network technologies), then (parts of) the document can be turned into a BCP. If not, I guess it will be an Informational RFC. Venkat Padmanabhan Microsoft Research padmanab@microsoft.com http://www.research.microsoft.com/~padmanab From owner-pilc@lerc.nasa.gov Fri Mar 3 06:32:07 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22831 for ; Fri, 3 Mar 2000 06:32:07 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA18140 for pilc-outgoing; Fri, 3 Mar 2000 04:56:11 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA18136 for ; Fri, 3 Mar 2000 04:56:10 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA16614; Fri, 3 Mar 2000 04:56:09 -0500 (EST) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma016528; Fri, 3 Mar 00 04:56:09 -0500 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12QooR-0007Em-00; Fri, 03 Mar 2000 09:55:59 +0000 Date: Fri, 3 Mar 2000 09:55:55 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Venkat Padmanabhan cc: "'Vernon Schryver'" , pilc@grc.nasa.gov Subject: RE: PILC ASYM document In-Reply-To: <3924E6A6E200D211BAC900805F6FC9E1082E6BF2@RED-MSG-11> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Thu, 2 Mar 2000, Venkat Padmanabhan wrote: > Regarding your implication that TCP should be ignorant of the oddities > of the link layer, an analogy might illustrate why this argument isn't > necessarily right. HTTP/1.0 (an application-level protocol) ignored > artifacts of the underlying TCP transport protocol (e.g., slow start) > and opened a new TCP connection for each request. Consequently, performance > suffered. That analogy is misleading. HTTP _always_ runs over TCP, so there are widespread gains from optimising interaction between the two. It's a global (a World-Wide, even) optimisation with few tradeoffs. TCP does not always run over e.g. some braindead ARQ-to-infinity link layer. Optimising TCP for such a special case would prove detrimental to interactions with other, different, link layers. It's a local optimisation with many tradeoffs. Making TCP independent of link layer oddities strives for the general case of global optimisation. Vernon is correct. L. the Internet: increasingly a bunch of isolated local optimisations with undesirable global interactions. PGP From owner-pilc@lerc.nasa.gov Fri Mar 3 06:47:56 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22996 for ; Fri, 3 Mar 2000 06:47:55 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA19367 for pilc-outgoing; Fri, 3 Mar 2000 05:29:57 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id FAA19360 for ; Fri, 3 Mar 2000 05:29:56 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id FAA18915; Fri, 3 Mar 2000 05:29:56 -0500 (EST) Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018911; Fri, 3 Mar 00 05:29:39 -0500 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.10.0.Beta12/8.10.0.Beta12) with ESMTP id e23AZ7I10502 for ; Fri, 3 Mar 2000 10:35:08 GMT Message-ID: <38BF85EC.32E65E95@erg.abdn.ac.uk> Date: Fri, 03 Mar 2000 10:31:40 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 CC: pilc@grc.nasa.gov Subject: Re: PILC ASYM document References: <3924E6A6E200D211BAC900805F6FC9E1082E6BF2@RED-MSG-11> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit The well proven approach taken by Sally Floyd, et al (just using the name quoted on the list, no offence to Sally) is a good one for some problems. But it does not always work. The problem with PILC as a whole is that the issues being discussed are (as Phil Karn put it) from two different communities. The two need to talk to each other in moderate tones of voice, so that we understand what TCP is actually asking for. I disagree that TCP "works well" over all links. If you define "well" as meaning doesn't fail to delivery (eventually) then that's OK, but normally that's not my thinking. TCP is end-to-end, but link designers need to take on board what is really happening. Once the subnet designers document is clear, I suggest we will probably see the need for the ASYM document. I'd like to see the ASYM draft opened up a little in terms of discussing different approaches... and getting a clearer problem statement, then input from the cable people, radio people, the DVB people, and anyone else. My concern is, until we get the first ID into some shape, we attract a lot of confusing comments every time something is mentioned (this isn't new/ this isn't needed/etc). I recommend we keep the document as an ID and wait for the SUBNET DESIGNERS draft to reach stability first (next draft?), then look discuss the approaches in detail at Pittsburgh.... Gorry Fairhurst. From owner-pilc@lerc.nasa.gov Fri Mar 3 10:46:03 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01004 for ; Fri, 3 Mar 2000 10:45:57 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA07898 for pilc-outgoing; Fri, 3 Mar 2000 09:07:37 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA07863 for ; Fri, 3 Mar 2000 09:07:32 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA09422; Fri, 3 Mar 2000 09:07:28 -0500 (EST) Received: from unknown(208.217.183.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma009396; Fri, 3 Mar 00 09:07:21 -0500 Received: by atlconn1.panamsat.com with Internet Mail Service (5.5.2448.0) id ; Fri, 3 Mar 2000 09:07:21 -0500 Message-ID: <8046A317B5F4D21186610008C7EBB696F0564C@grnexch1.panamsat.com> From: "Falk, Aaron" To: "'Vernon Schryver'" Cc: pilc@grc.nasa.gov Subject: RE: PILC ASYM document Date: Fri, 3 Mar 2000 09:03:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Vernon wrote: > > The practice followed by Van Jacobson, Sally Floyd, and > others has worked > pretty well over the years. They do lots of simulating, > testing, and more > than prototype implementing before publishing anything, or at > least before > announcing solutions or proposing IETF sanctioned changes in widely > deployed implementations. A recent example is the change in > the initial > TCP window, which was done at least partly under the auspices > of the TCP > Implementors working group. Vernon- You've made an excellent point. Actually, getting researchers of the caliber you mention is part of the goals of this group. (Sally, Van: are you listening?) However, to get networking researchers engaged in a problem there needs to be a clear articulation of exactly what the problem is. Part of that discussion would be to propose some candidate solutions. This is why PILC isn't developing any protocols -- we are supposed to be bringing together user/developer communities _who_may_not_be_experienced_in_Internet_protocol_R_&_D_ to document the problems they see on links of interest. One possible outcome is that an Informational RFC is published. Getting to that point will require a rough consensus on the issues. The dialog will likely be of greater value than the document. These dialogs can have profound influence decisions on IETF activities in the future. Some might say (& I heard it about TCPSAT), that this isn't relevant work for the IETF, since the IETF develops protocols for the Internet. My understanding is that the IETF's charter is not quite that narrow. PILC is doing the advance work to identify whether a new protocol(s) needs to be developed. Part of that process is requirements definition (such as is going on in ECM). But before you can define requirements you need agreement on what the issues are and whether they require fixing. *That* is what we are doing now. (I might add that TCPSAT was very effective in giving the satellite community a clue on issues surrounding TCP performance. This was/is a community where most designers didn't have a background in Internet protocols and didn't understand the performance/design tradeoffs. To a certain extent, PILC is a generalization of the TCPSAT goals to a wider community of interest.) --aaron From owner-pilc@lerc.nasa.gov Fri Mar 3 11:20:18 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02197 for ; Fri, 3 Mar 2000 11:20:18 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA15977 for pilc-outgoing; Fri, 3 Mar 2000 09:57:54 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA15960 for ; Fri, 3 Mar 2000 09:57:52 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA16499; Fri, 3 Mar 2000 09:57:50 -0500 (EST) Received: from mail.cis.ohio-state.edu(164.107.115.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma016483; Fri, 3 Mar 00 09:57:33 -0500 Received: from eta.cis.ohio-state.edu (mukul@eta.cis.ohio-state.edu [164.107.112.62]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id JAA29798; Fri, 3 Mar 2000 09:57:32 -0500 (EST) Received: from localhost (mukul@localhost) by eta.cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id JAA22258; Fri, 3 Mar 2000 09:57:31 -0500 (EST) X-Authentication-Warning: eta.cis.ohio-state.edu: mukul owned process doing -bs Date: Fri, 3 Mar 2000 09:57:31 -0500 (EST) From: mukul goyal To: Lloyd Wood cc: Venkat Padmanabhan , "'Vernon Schryver'" , pilc@grc.nasa.gov Subject: RE: PILC ASYM document In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > TCP does not always run over e.g. some braindead ARQ-to-infinity link > layer. Optimising TCP for such a special case would prove detrimental > to interactions with other, different, link layers. It's a local > optimisation with many tradeoffs. > Lloyd, could you clarify this further? I think that draft talks about ideas like restricting the number of packets sent in a burst and making sure that window increase is independent of number of ACKs received. I think it will be a _global_ optimization and not a _local_ one. I might be missing something but can you provide some example scenarios where such a thing will not be good. > Making TCP independent of link layer oddities strives for the general > case of global optimisation. Vernon is correct. I thought that's what draft talking about: making TCP independent of link layer oddities. Mukul From owner-pilc@lerc.nasa.gov Fri Mar 3 11:33:37 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02637 for ; Fri, 3 Mar 2000 11:33:37 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA19709 for pilc-outgoing; Fri, 3 Mar 2000 10:21:07 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA19693 for ; Fri, 3 Mar 2000 10:21:05 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA19661; Fri, 3 Mar 2000 10:21:04 -0500 (EST) Received: from mail.cis.ohio-state.edu(164.107.115.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma019628; Fri, 3 Mar 00 10:20:45 -0500 Received: from eta.cis.ohio-state.edu (mukul@eta.cis.ohio-state.edu [164.107.112.62]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id KAA01240 for ; Fri, 3 Mar 2000 10:20:44 -0500 (EST) Received: from localhost (mukul@localhost) by eta.cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id KAA23771 for ; Fri, 3 Mar 2000 10:20:44 -0500 (EST) X-Authentication-Warning: eta.cis.ohio-state.edu: mukul owned process doing -bs Date: Fri, 3 Mar 2000 10:20:44 -0500 (EST) From: mukul goyal cc: pilc@grc.nasa.gov Subject: Self-Clocking (RE: PILC ASYM document) In-Reply-To: <8046A317B5F4D21186610008C7EBB696F0564C@grnexch1.panamsat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Hi All, THis is a diversion from the topic on hand but I am confused about the meaning of the term "self-clocking". Recently, I posted this query on tcpsat list and Dr. Partridge sent a reply which I am pasting below: Date: Sat, 26 Feb 2000 16:01:55 -0500 From: Craig Partridge To: mukul goyal Cc: tcpsat@grc.nasa.gov Subject: Re: Lack of TCP self-clocking in practical networks I feel that TCP's self-clocking as illustrated in Van Jacobson's 1988 paper exists only if bottleneck link is a link of lower capacity (i.e. bandwidth) than other links. However, if bottleneck link has higher capacity than other links (i.e. the link is bottlenecked because a large number of flows are using it simulateneously), there is no self-clocking any more. I don't think it is that simple Self clocking always occurs -- you inject a packet in response to an ack and the ack is telling you when the network has capacity for your new packet. The issue raised in your note is whether the spacing of the acks reflects the available bandwidth at the bottleneck. In most cases the answer is that it reflects bandwidth only imperfectly. Ack compression, queueing disciplines, etc., all conspire to muddy the spacing. Craig **************************************************** This gives me an impression that self-clocking refers to the property that a new packet will be injected into the network when an old one has left it and ACK basically conveyes this information to the sender. Another interpretation of self-clocking that I have seen in many places including PILC ASYM draft is that temporal spacing of ACKS reflect the _bottleneck_ bandwidth in forward (or reverse) direction. FInally, self-clocking might be interpreted as TCP's property that temporal spacing of ACKs reflect _available_ bandwidth at bottleneck for a flow. (I know that this is not true.) I would like to know what is the accepted definition of Self-Clocking and if some IETF document talks about it. It might be a good idea to have a document that lists accepted definition of concepts like this. Thanks, Mukul From owner-pilc@lerc.nasa.gov Fri Mar 3 14:13:24 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06823 for ; Fri, 3 Mar 2000 14:13:22 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA13697 for pilc-outgoing; Fri, 3 Mar 2000 13:04:02 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA13678 for ; Fri, 3 Mar 2000 13:04:00 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA12253; Fri, 3 Mar 2000 13:03:59 -0500 (EST) Received: from out5.prserv.net(32.97.166.35) by seraph3.lerc.nasa.gov via smap (V5.0) id xma012242; Fri, 3 Mar 00 13:03:58 -0500 Received: from attglobal.net ([32.100.70.66]) by prserv.net (out5) with SMTP id <200003031803502430233a0se>; Fri, 3 Mar 2000 18:03:51 +0000 Message-ID: <38BFFE59.B95ADE4A@attglobal.net> Date: Fri, 03 Mar 2000 10:03:05 -0800 From: Cannara Reply-To: cannara@attglobal.net X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk CC: pilc@grc.nasa.gov Subject: Re: PILC ASYM document References: <3924E6A6E200D211BAC900805F6FC9E1082E6BF2@RED-MSG-11> <38BF85EC.32E65E95@erg.abdn.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Good points Gorry. We need to enter this millennium with a little less bureaucratic defensiveness about the "existence proof" that is the current Internet protocol/infrastructure. Passing over its security pit, if we look at TCP, in particular and in the light of day, we see a 'transport' that is incapable of distinguishing important, performance-degrading effects. For instance, its response to packet loss being identical whether the packet was errored or congested out of existence causes real, costly delays. These events increase as it is run more often over media for which it was never designed. The increasing dependence of real business, rather than subsidized research, on the Internet is already revealing how influential the $ side of the equation is becoming. Engineering should follow this lead. Alex Dr G Fairhurst wrote: > > The well proven approach taken by Sally Floyd, et al (just using the name > quoted > on the list, no offence to Sally) is a good one for some problems. But it > does not > always work. The problem with PILC as a whole is that the issues being > discussed > are (as Phil Karn put it) from two different communities. The two need to talk > to > each other in moderate tones of voice, so that we understand what TCP is > actually > asking for. I disagree that TCP "works well" over all links. If you define > "well" as > meaning doesn't fail to delivery (eventually) then that's OK, but normally > that's > not my thinking. TCP is end-to-end, but link designers need to take on board > what is really happening. Once the subnet designers document is clear, I > suggest > we will probably see the need for the ASYM document. > > I'd like to see the ASYM draft opened up a little in terms of discussing > different > approaches... and getting a clearer problem statement, then input from the > cable > people, radio people, the DVB people, and anyone else. My concern is, until > we get the first ID into some shape, we attract a lot of confusing comments > every > time something is mentioned (this isn't new/ this isn't needed/etc). > > I recommend we keep the document as an ID and wait for the SUBNET DESIGNERS > draft to reach stability first (next draft?), then look discuss the approaches > in detail at Pittsburgh.... > > Gorry Fairhurst. From owner-pilc@lerc.nasa.gov Fri Mar 3 15:00:58 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07769 for ; Fri, 3 Mar 2000 15:00:57 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA21973 for pilc-outgoing; Fri, 3 Mar 2000 13:58:05 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA21935 for ; Fri, 3 Mar 2000 13:58:01 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA19729; Fri, 3 Mar 2000 13:58:01 -0500 (EST) Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma019681; Fri, 3 Mar 00 13:57:33 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id LAA20759 for pilc@grc.nasa.gov env-from ; Fri, 3 Mar 2000 11:57:30 -0700 (MST) Date: Fri, 3 Mar 2000 11:57:30 -0700 (MST) From: Vernon Schryver Message-Id: <200003031857.LAA20759@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: RE: PILC ASYM document Sender: owner-pilc@lerc.nasa.gov Precedence: bulk } From: mukul goyal } THis is a diversion from the topic on hand ... it seems relevant to me. } It might be a good idea to have a document that lists accepted definition } of concepts like this. More of a definition of ACK clock, pacing, etc. would be good, especially in a document that mandates or at least encourage practices that, as Craig Partridge said, "muddy the spacing". .... From: Dr G Fairhurst ] The well proven approach taken by Sally Floyd, et al (just using ] the name quoted on the list, no offence to Sally) is a good one ] for some problems. But it does not always work. Yes, doing "lots of simulating, testing and more than prototype implementing before publishing anything, or at least before announcing solutions or proposing IETF sanctioned changes in widely deployed implementations" does not always work. Failure is part of inventing. However, defining protocols (e.g. ACK regeneration) without doing all of that other stuff is almost certain to fail. Examining relevant history (e.g. asymmetric dial-up modems carrying TCP/IP/SLIP and TCP/IP/PPP) and long standing, current industry practice (e.g. ACK compression in the metropolitan cable TV modem systems of Hybrid Systems installed for the last 6-10 years) is as good in an academic paper as in an official WG RFC, even if only Informational. .... > From: Venkat Padmanabhan > ... > We also have anecdotal evidence of similar problems in cable modem > systems. We were hoping to hear experiences of other people confirming > or refuting this. How would such experiences be other than still more anectotal evidence that could neither confirm nor refute the draft? Don't we need some prototype implementing and serious testing before advocating ACK regeneration or compression? (Not to mention re-ordering the TCP segment stream by moving pure ACKs ahead of data) > Barbed emails heavy in sarcasm unfortunately drown > out whatever technical point was sought to be conveyed. I haven't intend as much barbed sarcasm as seems to have been read. But if you keep twisting my tail by talking about a BCP openly based on a few tests, some thinking, a few anecdotes, and not even a nod at historical or current industry practice, I'll start meaning it. > Regarding your implication that TCP should be ignorant of the oddities > of the link layer, an analogy might illustrate why this argument isn't > necessarily right. HTTP/1.0 (an application-level protocol) ignored > artifacts of the underlying TCP transport protocol (e.g., slow start) > and opened a new TCP connection for each request. Consequently, performance > suffered. That's a very good example. Would it have been better to modify TCP/IP to fit HTTP/1.0 or to modify HTTP/1.0 to fit TCP/IP? Do you think a BCP recommending that slow start be turned off for HTTP traffic should have been written instead of the work on HTTP/1.1? Do you think that the tests that supported increasing the intial TCP window were not needed, that it would have been wise to mandate that change without what passes for due consideration in the IETF, running code? > ... > What we are talking about of here is not "mixtures of interactive > and bulk traffic". Rather it is the interference between the acks of > a downstream bulk transfer with data packets of an upstream bulk transfer. Did I fail to see the numbers in Hari's message from measurements that supported the hypothesis that the downstream pipe was not full? I didn't keep a copy of the original message, and I remember only a mention of ping as support for the hypothesis. Do you agree that the 2 second ping measurement contradicts or at best shows nothing about the hypothesis? > ... > I have no idea what Telebits is, but regardless we are not arguing > that the upper layers must be modified for every new link layer. You really should look at Telebit and Courier modems. You might find that many of the problems listed in the document are 10 or 15 years old. That's not to say that they have already been solved or shouldn't finally be solved, but that you might then have more than anecdotes. > Rather we have attempted to document a set of problems related to > asymmetry and an approach to addressing these that has a common > thread: reducing the frequency of acks -- a generalization of > delayed acks, if you will -- and making the sender robust against > disruptions in the ack stream. These have been derived from our > experience/experiments with a few network technologies. Whether to > turn any of this into a proposed standard would depend on whether > there is a consensus on their relevance in a wider setting If "disruptions in the ack stream" did not mean intentional, consistent filtering mandated by the same BCP, who could disagree with that? > > Is it intended to become a Proposed Standard or a BCP? Or would it > become > > just another Informational RFC? Or is it a call to start > > some experiments? > > Good question. As Aaron states, the PILC WG's current charter precludes > turning this into a proposed standard (of course, I realize that this > technicality is not the only hurdle in the way!). I don't see why that should be a hurdle. The IETF is not yet the IEEE where very heavy duty politicing happens before a committee gets to own its turf, or the ANSI where the most weighty deliberations in any committee concern defending its turf from other committees. The IETF is supposed to be about "running code" even before "rough concensus." Let's have some running code, and then worry about the official documents. > If there is sufficient > consensus and supplementary/supporting evidence (e.g., experiences with > other network technologies), then (parts of) the document can > be turned into a BCP. ... How could the WG publish a Best Current Practice about things that are not Current Practice and are not known to be harmless, not to mention Best? As far as I can tell, no one has even started to demonstrate that the various ideas for modifying the ACK stream do more good than harm. For example, if ACK compression as great an idea as you think and my prejudices agree, then why is it as if the large scale commercial installations that use ACK compression do not exist? Why do so many knowledgable people only grimace when you mention ACK compression? It's early and unnecessary to write a BCP that might be turn out to say the equivalent of "disable slow start on all hosts because otherwise HTTP/1.0 works poorly." > If not, I guess it will be an Informational RFC. What's wrong with doing some prototype implementing and serious testing before worrying about publishing an official document or whether it should be Informational, STD, or BCP? The point of the IETF is not merely publishing documents about ideas for protocol changes, but "running code." Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Fri Mar 3 15:11:15 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08146 for ; Fri, 3 Mar 2000 15:11:14 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA23773 for pilc-outgoing; Fri, 3 Mar 2000 14:09:21 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA23740 for ; Fri, 3 Mar 2000 14:09:19 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA21537; Fri, 3 Mar 2000 14:09:17 -0500 (EST) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma021487; Fri, 3 Mar 00 14:08:57 -0500 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12QxRQ-00062v-00; Fri, 03 Mar 2000 19:08:48 +0000 Date: Fri, 3 Mar 2000 19:08:44 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: mukul goyal cc: Venkat Padmanabhan , "'Vernon Schryver'" , pilc@grc.nasa.gov Subject: RE: PILC ASYM document In-Reply-To: Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Restoring cut text here. Venkat wrote: | Regarding your implication that TCP should be ignorant of the oddities | of the link layer, an analogy might illustrate why this argument isn't | necessarily right. HTTP/1.0 (an application-level protocol) ignored | artifacts of the underlying TCP transport protocol (e.g., slow start) | and opened a new TCP connection for each request. Consequently, performance | suffered. I responded: $ That analogy is misleading. $ $ HTTP _always_ runs over TCP, so there are widespread gains from $ optimising interaction between the two. It's a global (a World-Wide, $ even) optimisation with few tradeoffs. On Fri, 3 Mar 2000, mukul goyal wrote: > > TCP does not always run over e.g. some braindead ARQ-to-infinity link > > layer. Optimising TCP for such a special case would prove detrimental > > to interactions with other, different, link layers. It's a local > > optimisation with many tradeoffs. > > Lloyd, could you clarify this further? My comments are purely a response to Venkat's comments, and should not be construed as comments on the contents of the draft. > I thought that's what draft talking about: making TCP independent of link > layer oddities. what the draft and the list talk about can be very separate things. L. PGP From owner-pilc@lerc.nasa.gov Fri Mar 3 20:03:55 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12867 for ; Fri, 3 Mar 2000 20:03:55 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA25730 for pilc-outgoing; Fri, 3 Mar 2000 18:57:26 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA25719 for ; Fri, 3 Mar 2000 18:57:25 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA26386; Fri, 3 Mar 2000 18:57:25 -0500 (EST) Received: from mgate-01.teledesic.com(216.190.22.41) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026376; Fri, 3 Mar 00 18:57:04 -0500 Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2448.0) id <1MHV4N8S>; Fri, 3 Mar 2000 15:53:55 -0800 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE07BC85F@tdmail2.teledesic.com> From: Marie-Jose Montpetit To: "Falk, Aaron" , "'Vernon Schryver'" Cc: pilc@grc.nasa.gov Subject: RE: PILC ASYM document Date: Fri, 3 Mar 2000 15:46:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk I would also stress that while I never believed we should change the Internet protocols to support new links with asymmetry or delay or noise (in fact all pieces of the bigger pie), I think it is important to have the different communities at least sharing the issues and have the people designing the links (the subnets) be aware of what is running end to end over them. Marie-Jose -----Original Message----- From: Falk, Aaron [mailto:afalk@PanAmSat.com] Sent: Friday, March 03, 2000 6:03 AM To: 'Vernon Schryver' Cc: pilc@grc.nasa.gov Subject: RE: PILC ASYM document Vernon wrote: > > The practice followed by Van Jacobson, Sally Floyd, and > others has worked > pretty well over the years. They do lots of simulating, > testing, and more > than prototype implementing before publishing anything, or at > least before > announcing solutions or proposing IETF sanctioned changes in widely > deployed implementations. A recent example is the change in > the initial > TCP window, which was done at least partly under the auspices > of the TCP > Implementors working group. Vernon- You've made an excellent point. Actually, getting researchers of the caliber you mention is part of the goals of this group. (Sally, Van: are you listening?) However, to get networking researchers engaged in a problem there needs to be a clear articulation of exactly what the problem is. Part of that discussion would be to propose some candidate solutions. This is why PILC isn't developing any protocols -- we are supposed to be bringing together user/developer communities _who_may_not_be_experienced_in_Internet_protocol_R_&_D_ to document the problems they see on links of interest. One possible outcome is that an Informational RFC is published. Getting to that point will require a rough consensus on the issues. The dialog will likely be of greater value than the document. These dialogs can have profound influence decisions on IETF activities in the future. Some might say (& I heard it about TCPSAT), that this isn't relevant work for the IETF, since the IETF develops protocols for the Internet. My understanding is that the IETF's charter is not quite that narrow. PILC is doing the advance work to identify whether a new protocol(s) needs to be developed. Part of that process is requirements definition (such as is going on in ECM). But before you can define requirements you need agreement on what the issues are and whether they require fixing. *That* is what we are doing now. (I might add that TCPSAT was very effective in giving the satellite community a clue on issues surrounding TCP performance. This was/is a community where most designers didn't have a background in Internet protocols and didn't understand the performance/design tradeoffs. To a certain extent, PILC is a generalization of the TCPSAT goals to a wider community of interest.) --aaron From owner-pilc@lerc.nasa.gov Sun Mar 5 16:03:55 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11379 for ; Sun, 5 Mar 2000 16:03:55 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA29262 for pilc-outgoing; Sun, 5 Mar 2000 14:53:55 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA29254 for ; Sun, 5 Mar 2000 14:53:50 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA12375; Sun, 5 Mar 2000 14:53:49 -0500 (EST) Received: from taurus.cs.albany.edu(169.226.2.109) by seraph3.lerc.nasa.gov via smap (V5.0) id xma012288; Sun, 5 Mar 00 14:53:24 -0500 Received: from karp.cs.albany.edu (karp.cs.albany.edu [169.226.2.52]) by taurus.cs.albany.edu (8.9.3+Sun/8.9.1) with ESMTP id OAA03418; Sun, 5 Mar 2000 14:52:30 -0500 (EST) From: "S.S.Ravi" Received: (from ravi@localhost) by karp.cs.albany.edu (SMI-8.6/CLI2) id OAA19809; Sun, 5 Mar 2000 14:52:54 -0500 Date: Sun, 5 Mar 2000 14:52:54 -0500 Message-Id: <200003051952.OAA19809@karp.cs.albany.edu> To: alg@comm.toronto.edu, cabernet-events@ncl.ac.uk, cellular@comnets.rwth-aachen.de, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, commsoft@ieee.org, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, dbworld@cs.wisc.edu, end2end-interest@ISI.EDU, enternet@bbn.com, hipparch@sophia.inria.fr, ieeetcpc@ccvm.sunysb.edu, itc@attrh1.attrh.att.com, kuvs-elg@fokus.gmd.de, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, performance@haven.epm.ornl.gov, pilc@grc.nasa.gov, reres@laas.fr, sig-dsm@doc.ic.ac.uk, tcgn@ieee.org, tcos-announce@dartmouth.edu, testnet@canarie.ca, xtp-relay@cs.concordia.ca Subject: DIAL M for Mobility (Second Call for Papers) Sender: owner-pilc@lerc.nasa.gov Precedence: bulk (Please accept our apologies if you receive multiple copies.) SECOND CALL FOR PAPERS 4th International Workshop on Discrete Algorithms and Methods for Mobile Computing & Communications (DIALM for Mobility) August 11, 2000 Boston, Massachusetts, USA In conjunction with ACM MobiCom 2000 Sponsored by ACM SIGMOBILE Submission Deadline: April 25, 2000 Workshop URL : http://www.eecis.udel.edu/~elloyd/dialm.d/home.html SCOPE: Mobile computing and communications devices such as portable phones, laptops and palmtops will have an enormous impact on our lifestyle over the next several decades. The introduction of mobility raises a number of new research issues. This workshop is devoted to discrete algorithms and methods in the context of mobile and wireless computing and communications. The workshop is intended to serve as a forum for open discussions and lively debate, and to foster cooperation among practitioners and theoreticians. The workshop encourages submission of papers based on work-in-progress. Proposals for panels designed to generate lively discussions are also invited. Contributions are solicited in all areas related to mobile computing and communications where discrete algorithms and methods are utilized, including, but not limited to: distributed algorithms frequency allocation scheduling location tracking site allocation multihop packet radio networks wireless networks synchronization cryptography and security error correcting codes handover (handoff) telecommunications modeling optimization routing satellite communication PROGRAM CHAIR: Errol L. Lloyd Department of Computer and Information Sciences University of Delaware Newark, DE, USA Email: elloyd@udel.edu PROGRAM COMMITTEE Amotz Bar-Noy, AT&T Labs and Tel Aviv University, Israel Anthony Ephremides, University of Maryland, USA Aura Ganz, University of Massachusetts, USA Juraj Hromkovic, RWTH Aachen, Germany Bo Li, Hong Kong University of Science and Technology, Hong Kong Jason Yi-Bing Lin, National Chiao-Tung University, ROC Errol Lloyd, University of Delaware,USA -- Program Chair Madhav Marathe, Los Alamos National Lab Marina Papatriantafilou, Chalmers Univ. of Technology, Sweden Stephane Perennes, INRIA, France Cynthia Phillips, Sandia National Laboratories, USA Balaji Raghavachari, University of Texas at Dallas, USA S.S. Ravi, SUNY Albany, USA -- Publicity Chair Andrea Richa, Arizona State University, USA Aravind Srinivasan, Bell Labs, USA Martha Steenstrup, BBN, USA Subhash Suri, Washington University, USA Eli Upfal, Brown University, USA Peter Widmayer, ETH Zurich, Switzerland STEERING COMMITTEE Ian Akyildiz, Georgia Tech, USA Maurizio Bonuccelli, University of Pisa, Italy (Chair) Afonso Ferreira, CNRS - I3S - INRIA - Sophia Antipolis, France Arunabha Sen, Arizona State University, USA. SUBMISSION GUIDELINES: All paper submissions and panel proposals will be handled electronically. Authors should e-mail a PostScript version of their full paper to elloyd@udel.edu. The font size should be at least 10 pt. The paper should not be longer than 10 single spaced pages using a standard 10point font. Panel proposals may be submitted in ASCII or PostScript format. A panel proposal should include panel topic, sample questions the panel would address, and proposed panel members and moderator. Since deadlines overlap, dual submission of papers to MobiCom and DIALM is encouraged. Any paper accepted for MobiCom will automatically be removed from consideration for DIALM. To ensure that the PostScript versions of the papers can be printed, use PostScript version 2 or later. Also ensure that the paper fits on "US Letter" size paper (8.5X11 inches). Reference only standard Adobe printer fonts (i.e., Courier, Times, Roman, or Helvetica); other fonts may be used but must be included in the PostScript file. Authors will receive a short email ack of their submission within two days of submission. If this is not received, the authors should contact the Program Chair immediately. Authors should separately email the title, authors, mailing address, and abstract to elloyd@udel.edu. All accepted papers will appear (7 to 10 pages per paper) in the workshop proceedings, which will be published by ACM. IMPORTANT DATES: Submissions due : April 25, 2000 Acceptance notification: May 15, 2000 Final paper due : June 1, 2000 Workshop : August 11, 2000 From owner-pilc@lerc.nasa.gov Mon Mar 6 05:43:06 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01780 for ; Mon, 6 Mar 2000 05:43:06 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA02376 for pilc-outgoing; Mon, 6 Mar 2000 04:39:39 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA02372 for ; Mon, 6 Mar 2000 04:39:38 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA07685; Mon, 6 Mar 2000 04:39:36 -0500 (EST) Received: from smtp2.cluster.oleane.net(195.25.12.17) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007681; Mon, 6 Mar 00 04:39:08 -0500 Received: from oleane (dyn-1-1-215.Vin.dialup.oleane.fr [195.25.4.215]) by smtp2.cluster.oleane.net with SMTP id KAA76974; Mon, 6 Mar 2000 10:38:08 +0100 (CET) Message-ID: <00e101bf874f$1e26f920$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: SIP 2000 International Conference Date: Mon, 6 Mar 2000 10:33:45 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DE_01BF8757.73594D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00DE_01BF8757.73594D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Unknown and even rejected by many vendors and operators only a few = months ago, SIP is on the brink of making a definitive name for itself.=20 Visit the SIP 2000 International Conference programme: http://www.upperside.fr/basip.htm ------=_NextPart_000_00DE_01BF8757.73594D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Unknown and even rejected by many vendors and operators only a few = months=20 ago, SIP is on the brink of making a definitive name for itself.
Visit the SIP 2000 International Conference programme:
http://www.upperside.fr/basip.= htm
 
------=_NextPart_000_00DE_01BF8757.73594D00-- From owner-pilc@lerc.nasa.gov Mon Mar 6 16:27:59 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03952 for ; Mon, 6 Mar 2000 16:27:59 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA05712 for pilc-outgoing; Mon, 6 Mar 2000 15:09:24 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA05678 for ; Mon, 6 Mar 2000 15:09:20 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA21131; Mon, 6 Mar 2000 15:09:20 -0500 (EST) Received: from mail5.microsoft.com(131.107.3.121) by seraph3.lerc.nasa.gov via smap (V5.0) id xma021020; Mon, 6 Mar 00 15:08:34 -0500 Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 06 Mar 2000 10:30:55 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id ; Mon, 6 Mar 2000 10:30:55 -0800 Message-ID: <3924E6A6E200D211BAC900805F6FC9E1082E6BFA@RED-MSG-11> From: Venkat Padmanabhan To: "'L.Wood@eim.surrey.ac.uk'" Cc: pilc@grc.nasa.gov Subject: RE: PILC ASYM document Date: Mon, 6 Mar 2000 10:30:45 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > That analogy is misleading. > > HTTP _always_ runs over TCP, so there are widespread gains from > optimising interaction between the two. It's a global (a World-Wide, > even) optimisation with few tradeoffs. > Good point. A more appropriate analogy may be TCP header compression over slow speed links wherein transport-layer specific knowledge is exploited in the link layer of a particular class of links. I would place techniques such as ack filtering/reconstruction (discussed in the draft) in the same category -- link layer algorithms that utilize TCP-specific knowledge without necessarily modifying TCP itself. In that sense, I believe these are bang on target for PILC; basically, designers of such links may need to spinkle some TCP-specific magic dust to have their links perform well with unmodified end-to-end TCP. (N.B.: The draft surveys a whole range of alternatives, some of which do involve mods to the e2e TCP.) > TCP does not always run over e.g. some braindead ARQ-to-infinity link > layer. Optimising TCP for such a special case would prove detrimental > to interactions with other, different, link layers. It's a local > optimisation with many tradeoffs. Yes, it's a local optimization. But it may well be possible to confine it to just the problematic link (for instance, by using an ack reconstructor to undo the effects of ack filtering) thereby minimizing/eliminating adverse interactions with e2e TCP. By the way, as I mentioned in my previous message (as also during my presentation at the DC IETF), the problem of upstream packets (acks in the case of a downstream transfer) being expensive to send may be a fundamental consequence of hub-and-spokes network architectures rather than an artifact of braindead link layers. -Venkat Venkat Padmanabhan Microsoft Research padmanab@microsoft.com http://www.research.microsoft.com/~padmanab From owner-pilc@lerc.nasa.gov Mon Mar 6 16:38:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05182 for ; Mon, 6 Mar 2000 16:37:59 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA12469 for pilc-outgoing; Mon, 6 Mar 2000 15:41:56 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA12396 for ; Mon, 6 Mar 2000 15:41:51 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA26221; Mon, 6 Mar 2000 15:41:50 -0500 (EST) Received: from clavin.cs.tamu.edu(128.194.130.106) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026061; Mon, 6 Mar 00 15:40:37 -0500 Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id OAA26292; Mon, 6 Mar 2000 14:40:36 -0600 (CST) From: Nitin H Vaidya Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.9.3/8.9.3) id OAA13742; Mon, 6 Mar 2000 14:40:13 -0600 (CST) Date: Mon, 6 Mar 2000 14:40:13 -0600 (CST) Message-Id: <200003062040.OAA13742@sun.cs.tamu.edu> To: padmanab@microsoft.com Subject: RE: PILC ASYM document Cc: pilc@grc.nasa.gov Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >> From: Venkat Padmanabhan ... >> in the same category -- link layer algorithms that utilize TCP-specific >> knowledge without necessarily modifying TCP itself. In that sense, >> I believe these are bang on target for PILC; basically, designers >> of such links may need to spinkle some TCP-specific magic dust to >> have their links perform well with unmodified end-to-end TCP. >> (N.B.: The draft surveys a whole range of alternatives, some of which >> do involve mods to the e2e TCP.) Have we exhausted alternatives that do NOT require the link layer to understand TCP? IMHO it is a great idea to have layers communicate information to each other, but it does not seem a good idea to require the link layer to understand the transport protocol. I hope we can agree on this. For instance, it seems reasonable to design a link layer with, say, 2 service classes (such as, never retransmit, versus retransmit X times) -- then each packet sent to the link layer could be tagged with the appropriate service class to be used for that packet The above alternative would be preferable over requiring the link layer to take different actions depending on whether a packet belongs to, say, TCP or UDP. In my opinion, before this group endorses alternatives that require link layer to understand transport protocol, a case needs to be made to show that more reasonable/palatable alternatives do not exist. Cheerio. - nitin From owner-pilc@lerc.nasa.gov Mon Mar 6 18:02:23 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22298 for ; Mon, 6 Mar 2000 18:02:23 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA28940 for pilc-outgoing; Mon, 6 Mar 2000 17:11:24 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA28913 for ; Mon, 6 Mar 2000 17:11:21 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA08803; Mon, 6 Mar 2000 17:11:21 -0500 (EST) Received: from ftpbox.mot.com(129.188.136.101) by seraph3.lerc.nasa.gov via smap (V5.0) id xma008761; Mon, 6 Mar 00 17:10:39 -0500 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA11502; Mon, 6 Mar 2000 14:59:03 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA10021; Mon, 6 Mar 2000 14:58:28 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id QAA18917; Mon, 6 Mar 2000 16:58:09 -0500 (EST) Message-Id: <200003062158.QAA18917@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 cc: "Falk, Aaron" , "'pilc@grc.nasa.gov'" , "Phil Karn (E-mail)" Subject: Re: Draft on Advice for Internet Subnetwork Designers In-reply-to: Your message of "Wed, 01 Mar 2000 17:17:27 EST." <200003012217.RAA16642@noah.dma.isg.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Mar 2000 16:58:11 -0500 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk My thoughts on buffers and queueing didn't seem to generate much as much discussion as I'd hoped. However, since the deadline is upon us, here is some text that Phil can insert into the draft. ----------------------------------------- Buffering, flow control and congestion control Many kinds of subnets have points at which there is contention for link transmission resources. At some of these points, the rate of the link may vary. At such points, there must be a queueing system, including buffering, scheduling and a capability to discard excess subnet packets. These queueing points may also be part of a subnet flow control or congestion control scheme. For the purpose of this discussion, a layered model of the interaction between the IP layer and the subnet layer is not helpful. Instead, we adopt the frame of reference of a packet. At each queueing point -- whether that point is at the IP layer or at the subnet layer -- the packet experiences delay for a period of time (which depends on competing traffic and the scheduling discipline), and is subjected to a local discarding policy. If there are flow control or congestion control mechanisms in the subnet that do not rely on TCP, these must operate on the scheduling discipline and/or the discarding policy in the subnet or in the routers at the edges of the subnet, since TCP has no way to operate on their semantics and IP has no way to be able to pass their semantics to TCP; however, see below for one exception. TCP traffic, and especially aggregated TCP traffic, is bursty. As a result, instantanious queue depth at a queueing point can vary dramatically, even in nominally stable networks. For optimal performance, it is desirable that packets be dropped in a controlled fashion, rather than due to running out of buffers. As a rule of thumb, nodes should be engineered to have buffering available for each TCP connection equal to the product of the maximum instantanious rate at which packets can be transmitted on the link (which is usually the link rate, but may be further limited by a shaper) and the propagation delay of the link. For links that have variable propagation delays (such as having diverse paths, or variable depth interleavers), the longest likely propagation delay should be used. Unfortunately, since the maximum number of TCP connections at a queueing point can neither be known with certainty a priori, nor limited by an admission control policy (except, perhaps, at a PEP), buffer sizes in subnet devices can at best be engineered based on crude estimates. In general, it is wise to err in favor of too much buffering rather than too little. It may also be useful for subnets to incorporate mechanisms for measuring propagation delay, to assist in buffer sizing calculations. There is a rough consensus in the research community that active queue management is important to improving fairness, link utilization and throughput [RFC2309]. Although there are questions and concerns about the efficacy of active queue management (e.g., see [MBDL99]), it is widely considered an improvement over tail-drop discard policies. One well known example of an active queue management the Random Early Detection (RED) algorithm [RED93]. RED maintains an exponential weighted moving average of the queue depth. When this average queue depth is between a maximum threshold max_th, and a minimum threshold min_th, packets are dropped with a probability which is proportional to the amount by which the average queue depth exceeds min_th. When this average queue depth is equal to max_th, the drop probability is equal to a configurable parameter max_p. When this average queue depth is greater than max_th, packets are always dropped. Numerous variants on RED appear in the literature, and there are other active queue management algorithms which claim advantages over RED in various dimensions. Active queue management algorithms forms a control regime wherein dropped packets are treated as a feedback signal. Randomization of dropping tends to break up the observed tendency of TCP windows belonging to different TCP connections to become synchronized by correlated drops, and also imposes a degree of fairness on those connections which properly implement TCP congestion avoidance. Another property of active queue management algorithms which is particularly important to subnet designers is that they attempt to keep average queue depths short, while accommodating large short term bursts. Since TCP neither knows nor cares whether packet loss due to congestive discard is due to congestion at the IP layer or in a subnet, it may be advisable for subnets that perform queueing and discarding to consider implementing some form of active queue management. This especially holds if large aggregates of TCP connections are likely to share the same queue. However, active queue management may be less effective in the case of many queues carrying smaller aggregates of TCP connections, as for example, in an ATM switch that implements per-VC queueuing. Note, incidentally, that the performance of active queue management algorithms is highly sensitive to settings of configurable parameters, and also to factors such as RTT [MBB00][FB00]. Some subnets, most notably ATM, perform segmentation and reassembly at the edge of the subnet, so as to be able to forward subnet packets of size less than an MTU. There are advantages and disadvantages to doing this. However, if this is done, care should be taken in designing discard policies. Subnet packets with missing fragments must be destroyed by the subnet, as they are of no use to TCP. Thus, if the subnet discards random and uncorrelated fragments of IP packets, then the balance of these packets constitute an unproductive load on the subnet and can markedly degrade end-to-end performance. [RF95] Therefore, subnets should attempt to discard entire IP packets. If a portion of an IP packet has been forwarded and discarding of subnet packets which are fragments of the IP packet becomes unavoidable, then either all remaining fragments or all but the fragment marking the end of the packet should be discarded. For ATM subnets, this specifically means using Early Packet Discard and Partial Packet Discard [ATMFTM]. Some subnets might includes flow control mechanisms that effectively require that the rate of traffic flows be shaped as they enter the subnet. One example of such a subnet mechanism is in the ATM Available Bitrate (ABR) service category [ATMFTM]. Such flow control mechanisms have the effect of making the subnet nearly lossless by pushing congestion into the IP routers edges of the subnet. In such a case, adequate buffering and discard policies are needed in these routers to deal with a subnet which appears to have dynamically varying bandwidth. Whether or not there is benefit in this kind of flow control is controversial, and there have been numerous simulation and analytical studies that go both ways. It appears that some of the issues that lead to such different results include sensitivity to ABR parameters, use of binary rather than explicit rate feedback, use (or not) of per-VC queueing, and the specific ATM switch algorithms selected for the study. Anecdotally, some large networks have used IP over ABR to carry TCP traffic, and have claimed it to be sucessful, but have published no results. Another possible approach to flow control in the subnet would be to work with TCP Explicit Congestion Notification (ECN) semantics [RFC2481]. Routers at the edges of the subnet, rather than shaping, would set the ECN bit in those IP packets that are received in subnet packets that have an ECN indication. Nodes in the subnet would need to implement an active queue management protocol which marks subnet packets rather than dropping. However, RFC2481 is presently experimental, and TCPs which can use ECN are not widely deployed. ------------ References [ATMFTM] The ATM Forum, "Traffic Management Specification, Version 4.0", April 1996, document af-tm-0056.000 (www.atmforum.com). [FB00] Firoiu V., and Borden M., "A Study of Active Queue Management for Congestion Control" to appear in Infocom 2000 [MBB00] May, M., Bonald, T., and Bolot, J-C., "Analytic Evaluation of RED Performance" to appear INFOCOM 2000 [MBDL99] May, M., Bolot, J., Diot, C., and Lyles, B., Reasons not to deploy RED, technical report, June 1999. [RF95] Romanow, A., and Floyd, S., Dynamics of TCP Traffic over ATM Networks. IEEE JSAC, V. 13 N. 4, May 1995, p. 633-641. [RFC2481] Ramakrishan, K. and Floyd S., "A Proposal to add Explicit Congestion Notification (ECN) to IP" RFC2481 January 1999 From owner-pilc@lerc.nasa.gov Mon Mar 6 18:13:56 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24702 for ; Mon, 6 Mar 2000 18:13:55 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA00632 for pilc-outgoing; Mon, 6 Mar 2000 17:22:38 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA00607 for ; Mon, 6 Mar 2000 17:22:36 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA10193; Mon, 6 Mar 2000 17:22:36 -0500 (EST) Received: from crufty.research.bell-labs.com(204.178.16.49) by seraph3.lerc.nasa.gov via smap (V5.0) id xma010172; Mon, 6 Mar 00 17:22:04 -0500 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Mon Mar 6 17:21:30 EST 2000 Received: from lucent.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA02876; Mon, 6 Mar 2000 17:21:25 -0500 (EST) Message-ID: <38C43018.3FEDE22D@lucent.com> Date: Mon, 06 Mar 2000 14:24:24 -0800 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: "'pilc@grc.nasa.gov'" Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <200003062158.QAA18917@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dan Grossman wrote: > > My thoughts on buffers and queueing didn't seem to generate much as much > discussion as I'd hoped. However, since the deadline is upon us, here is some > text that Phil can insert into the draft. Nice text. cheers, gja ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs Research Silicon Valley From owner-pilc@lerc.nasa.gov Tue Mar 7 03:28:15 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23499 for ; Tue, 7 Mar 2000 03:28:14 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA24467 for pilc-outgoing; Tue, 7 Mar 2000 02:28:00 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA24458 for ; Tue, 7 Mar 2000 02:27:58 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA28165; Tue, 7 Mar 2000 02:27:57 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma028149; Tue, 7 Mar 00 02:27:27 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id XAA19511; Mon, 6 Mar 2000 23:27:26 -0800 Date: Mon, 6 Mar 2000 23:27:26 -0800 Message-Id: <200003070727.XAA19511@homer.ka9q.ampr.org> From: Phil Karn To: pilc@grc.nasa.gov Subject: Kicking TCP Reply-to: karn@qualcomm.com Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Last week I attended an IAB workshop on wireless IP issues. One of the topics of relevance to this group was making TCP work better over links that can experience long outages. Way back in the mid-to-late 1980s, when I was writing code to run TCP/IP over amateur (ham) packet radio, I created something called a "TCP kick" packet -- a UDP packet that would cause the recipient to force a retransmission on all of its TCP connections to the sender. I hooked it into a hot key so you could "kick" a connection by hitting the key. Given TCP's exponential backoff mechanism and the flakiness of our radio links, this was a real godsend. I've been occasionally floating this idea in the IETF (usually repackaged as an ICMP message), so at the workshop I was asked to write it up as an Internet Draft. Allison Mankin suggested the term "Source Encourage" (ICMP SE). This scheme is designed to improve TCP performance by deliberately short-circuiting TCP's congestion control in situations where it is not needed. But in today's Internet, the potential for abuse of such a scheme for denial of service mischief has to be taken seriously. So instead of allowing the ICMP SE message to "kick" any arbitrary set of TCP connections, I included in it the header of the last packet to be dropped by the router before the link came back up. The recipient of the ICMP SE would check the fields to see that they corresponded to a real TCP connection before forcing a retransmission. This blocks the "blind" 3rd party denial of service attacks that are so easy to mount today. But then I realized that if the router is to hold onto a packet so it can generate an ICMP SE when the link comes back up, it might as well just forward that same packet onto its destination. This will get TCP going again just as surely as the ICMP SE mechanism would. So I'm thinking of inserting some text into the PILC LINK document that would recommend that routers driving subnetworks subject to lengthy outages (e.g., mobile radio) try to hold onto the last IP packet of each flow when a link goes down and forward it to its destination when the link comes back up. A lot of storage would not be needed. One for each TCP connection is all that's needed, with each packet overwriting the previous one. (Obviously things are more complicated if IPSEC is in use, so the router could store just the last packet seen between a given pair of IP addresses). Simplifying things is the fact that most mobile radio links carry only a small number of flows, often just one. Note that this gives nearly all of the benefits claimed for totally reliable link layer protocols with much less effort. The router would not have to promise absolute reliability; if it dropped the stored packet (e.g., due to insufficient memory), TCP would still recover after the link comes back up, just not as quickly. Like all link layer reliability mechanisms below TCP, this one is intended merely as a performance enhancement, not as a reliability guarantee. Comments? Phil From owner-pilc@lerc.nasa.gov Tue Mar 7 03:54:24 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28824 for ; Tue, 7 Mar 2000 03:54:24 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA26203 for pilc-outgoing; Tue, 7 Mar 2000 02:49:00 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA26183 for ; Tue, 7 Mar 2000 02:48:58 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA29843; Tue, 7 Mar 2000 02:48:57 -0500 (EST) Received: from deliverator.sgi.com(204.94.214.10) by seraph3.lerc.nasa.gov via smap (V5.0) id xma029737; Tue, 7 Mar 00 02:48:15 -0500 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id XAA10399; Mon, 6 Mar 2000 23:43:39 -0800 (PST) mail_from (zamsden@clock.engr.sgi.com) Received: from clock.engr.sgi.com (clock.engr.sgi.com [163.154.34.45]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id XAA11157; Mon, 6 Mar 2000 23:48:13 -0800 (PST) mail_from (zamsden@clock.engr.sgi.com) Received: from clock.engr.sgi.com (localhost [127.0.0.1]) by clock.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id XAA21225; Mon, 6 Mar 2000 23:53:42 -0800 (PST) Message-Id: <200003070753.XAA21225@clock.engr.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: karn@qualcomm.com Cc: pilc@grc.nasa.gov Subject: Re: Kicking TCP From: Zachary Amsden In-Reply-To: Your message of "Mon, 06 Mar 2000 23:27:26 PST." <200003070727.XAA19511@homer.ka9q.ampr.org> Date: Mon, 06 Mar 2000 23:53:41 -0800 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Yes, kicking TCP is useful in limited situations, but you needn't go to much trouble at all to do it - you can easily add a kernel hack to reset the retransmission timer on the transmitting socket. This will trigger retranmissions without losing any TCP state, and avoids any protocol modifications. This serves a useful purpose on what I call "blackout" lines - lines of communication that temporarily go dead for several seconds and require complicated renegotiation (like some wireless links). On public connections with interactive users, having a kick command is a very bad idea from a congestion point of view. A neat solution to this problem would be to cache link characteristics with routes, and to tweak TCP strategy routines based on link types - i.e. a kick_timeout that limits the maximum retransmission backoff allowed, after which the retransmit timer starts it's cycle over again, or stays at the maximum. (Modifying cwnd is also possible, but I wouldn't recommend it without analysis). One would really need to do some serious simulation runs to analyze the effects of kicking connections under these circumstances. If you still can't complete the transmission with this strategy, I can't think of any other strategy that would help - if you don't get any ACKs in return, kicking is useless. -- Zachary Amsden zamsden@engr.sgi.com 3-6919 31-2-510 Core Protocols From owner-pilc@lerc.nasa.gov Tue Mar 7 07:56:23 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17815 for ; Tue, 7 Mar 2000 07:56:23 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA20528 for pilc-outgoing; Tue, 7 Mar 2000 07:05:32 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id HAA20502 for ; Tue, 7 Mar 2000 07:05:30 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id HAA19079; Tue, 7 Mar 2000 07:05:29 -0500 (EST) Received: from mgate-01.teledesic.com(216.190.22.41) by seraph3.lerc.nasa.gov via smap (V5.0) id xma019021; Tue, 7 Mar 00 07:04:57 -0500 Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2448.0) id <1MHV44AV>; Tue, 7 Mar 2000 04:01:10 -0800 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE07B810E@tdmail2.teledesic.com> From: Marie-Jose Montpetit To: "'Dan Grossman'" Cc: "Falk, Aaron" , "'pilc@grc.nasa.gov'" , "Phil Karn (E-mail)" Subject: RE: Draft on Advice for Internet Subnetwork Designers Date: Tue, 7 Mar 2000 03:54:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On the topic of packet discard especially on those subnet where capacity is expensive or limited I would add that when possible packets marked form another subnet should be discarded before transmission on the link. Actually this discussion raises also the whole issue of reservations. Some sessions may be reserved so that packet are not randomly discarded but discarded according to some priority scheme. Do we want to add RSVP or diffserv issues to the LINK draft? Maybe in a future version? Marie-Jose -----Original Message----- From: Dan Grossman [mailto:dan@dma.isg.mot.com] Sent: Monday, March 06, 2000 1:58 PM Cc: Falk, Aaron; 'pilc@grc.nasa.gov'; Phil Karn (E-mail) Subject: Re: Draft on Advice for Internet Subnetwork Designers My thoughts on buffers and queueing didn't seem to generate much as much discussion as I'd hoped. However, since the deadline is upon us, here is some text that Phil can insert into the draft. ----------------------------------------- Buffering, flow control and congestion control Many kinds of subnets have points at which there is contention for link transmission resources. At some of these points, the rate of the link may vary. At such points, there must be a queueing system, including buffering, scheduling and a capability to discard excess subnet packets. These queueing points may also be part of a subnet flow control or congestion control scheme. For the purpose of this discussion, a layered model of the interaction between the IP layer and the subnet layer is not helpful. Instead, we adopt the frame of reference of a packet. At each queueing point -- whether that point is at the IP layer or at the subnet layer -- the packet experiences delay for a period of time (which depends on competing traffic and the scheduling discipline), and is subjected to a local discarding policy. If there are flow control or congestion control mechanisms in the subnet that do not rely on TCP, these must operate on the scheduling discipline and/or the discarding policy in the subnet or in the routers at the edges of the subnet, since TCP has no way to operate on their semantics and IP has no way to be able to pass their semantics to TCP; however, see below for one exception. TCP traffic, and especially aggregated TCP traffic, is bursty. As a result, instantanious queue depth at a queueing point can vary dramatically, even in nominally stable networks. For optimal performance, it is desirable that packets be dropped in a controlled fashion, rather than due to running out of buffers. As a rule of thumb, nodes should be engineered to have buffering available for each TCP connection equal to the product of the maximum instantanious rate at which packets can be transmitted on the link (which is usually the link rate, but may be further limited by a shaper) and the propagation delay of the link. For links that have variable propagation delays (such as having diverse paths, or variable depth interleavers), the longest likely propagation delay should be used. Unfortunately, since the maximum number of TCP connections at a queueing point can neither be known with certainty a priori, nor limited by an admission control policy (except, perhaps, at a PEP), buffer sizes in subnet devices can at best be engineered based on crude estimates. In general, it is wise to err in favor of too much buffering rather than too little. It may also be useful for subnets to incorporate mechanisms for measuring propagation delay, to assist in buffer sizing calculations. There is a rough consensus in the research community that active queue management is important to improving fairness, link utilization and throughput [RFC2309]. Although there are questions and concerns about the efficacy of active queue management (e.g., see [MBDL99]), it is widely considered an improvement over tail-drop discard policies. One well known example of an active queue management the Random Early Detection (RED) algorithm [RED93]. RED maintains an exponential weighted moving average of the queue depth. When this average queue depth is between a maximum threshold max_th, and a minimum threshold min_th, packets are dropped with a probability which is proportional to the amount by which the average queue depth exceeds min_th. When this average queue depth is equal to max_th, the drop probability is equal to a configurable parameter max_p. When this average queue depth is greater than max_th, packets are always dropped. Numerous variants on RED appear in the literature, and there are other active queue management algorithms which claim advantages over RED in various dimensions. Active queue management algorithms forms a control regime wherein dropped packets are treated as a feedback signal. Randomization of dropping tends to break up the observed tendency of TCP windows belonging to different TCP connections to become synchronized by correlated drops, and also imposes a degree of fairness on those connections which properly implement TCP congestion avoidance. Another property of active queue management algorithms which is particularly important to subnet designers is that they attempt to keep average queue depths short, while accommodating large short term bursts. Since TCP neither knows nor cares whether packet loss due to congestive discard is due to congestion at the IP layer or in a subnet, it may be advisable for subnets that perform queueing and discarding to consider implementing some form of active queue management. This especially holds if large aggregates of TCP connections are likely to share the same queue. However, active queue management may be less effective in the case of many queues carrying smaller aggregates of TCP connections, as for example, in an ATM switch that implements per-VC queueuing. Note, incidentally, that the performance of active queue management algorithms is highly sensitive to settings of configurable parameters, and also to factors such as RTT [MBB00][FB00]. Some subnets, most notably ATM, perform segmentation and reassembly at the edge of the subnet, so as to be able to forward subnet packets of size less than an MTU. There are advantages and disadvantages to doing this. However, if this is done, care should be taken in designing discard policies. Subnet packets with missing fragments must be destroyed by the subnet, as they are of no use to TCP. Thus, if the subnet discards random and uncorrelated fragments of IP packets, then the balance of these packets constitute an unproductive load on the subnet and can markedly degrade end-to-end performance. [RF95] Therefore, subnets should attempt to discard entire IP packets. If a portion of an IP packet has been forwarded and discarding of subnet packets which are fragments of the IP packet becomes unavoidable, then either all remaining fragments or all but the fragment marking the end of the packet should be discarded. For ATM subnets, this specifically means using Early Packet Discard and Partial Packet Discard [ATMFTM]. Some subnets might includes flow control mechanisms that effectively require that the rate of traffic flows be shaped as they enter the subnet. One example of such a subnet mechanism is in the ATM Available Bitrate (ABR) service category [ATMFTM]. Such flow control mechanisms have the effect of making the subnet nearly lossless by pushing congestion into the IP routers edges of the subnet. In such a case, adequate buffering and discard policies are needed in these routers to deal with a subnet which appears to have dynamically varying bandwidth. Whether or not there is benefit in this kind of flow control is controversial, and there have been numerous simulation and analytical studies that go both ways. It appears that some of the issues that lead to such different results include sensitivity to ABR parameters, use of binary rather than explicit rate feedback, use (or not) of per-VC queueing, and the specific ATM switch algorithms selected for the study. Anecdotally, some large networks have used IP over ABR to carry TCP traffic, and have claimed it to be sucessful, but have published no results. Another possible approach to flow control in the subnet would be to work with TCP Explicit Congestion Notification (ECN) semantics [RFC2481]. Routers at the edges of the subnet, rather than shaping, would set the ECN bit in those IP packets that are received in subnet packets that have an ECN indication. Nodes in the subnet would need to implement an active queue management protocol which marks subnet packets rather than dropping. However, RFC2481 is presently experimental, and TCPs which can use ECN are not widely deployed. ------------ References [ATMFTM] The ATM Forum, "Traffic Management Specification, Version 4.0", April 1996, document af-tm-0056.000 (www.atmforum.com). [FB00] Firoiu V., and Borden M., "A Study of Active Queue Management for Congestion Control" to appear in Infocom 2000 [MBB00] May, M., Bonald, T., and Bolot, J-C., "Analytic Evaluation of RED Performance" to appear INFOCOM 2000 [MBDL99] May, M., Bolot, J., Diot, C., and Lyles, B., Reasons not to deploy RED, technical report, June 1999. [RF95] Romanow, A., and Floyd, S., Dynamics of TCP Traffic over ATM Networks. IEEE JSAC, V. 13 N. 4, May 1995, p. 633-641. [RFC2481] Ramakrishan, K. and Floyd S., "A Proposal to add Explicit Congestion Notification (ECN) to IP" RFC2481 January 1999 From owner-pilc@lerc.nasa.gov Tue Mar 7 07:56:26 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17833 for ; Tue, 7 Mar 2000 07:56:25 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA21543 for pilc-outgoing; Tue, 7 Mar 2000 07:13:46 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id HAA21526 for ; Tue, 7 Mar 2000 07:13:44 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id HAA19671; Tue, 7 Mar 2000 07:13:44 -0500 (EST) Received: from mgate-01.teledesic.com(216.190.22.41) by seraph3.lerc.nasa.gov via smap (V5.0) id xma019660; Tue, 7 Mar 00 07:13:07 -0500 Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2448.0) id <1MHV44AY>; Tue, 7 Mar 2000 04:09:21 -0800 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE07B810F@tdmail2.teledesic.com> From: Marie-Jose Montpetit To: "'Zachary Amsden'" , karn@qualcomm.com Cc: pilc@grc.nasa.gov Subject: RE: Kicking TCP Date: Tue, 7 Mar 2000 04:02:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk I would tend to agree that some simulations maybe needed. However the kicking strategy is closely related to something I have been thinking for a while on how to "advertise" that a link is down or degraded. ICMP extensions were also our first idea or raising the "cost" of a route when the link is down (when multiple routes are available). Maybe what is needed in LINK is a section on suggested mechanisms to survive capacity degradation? Marie-Jose -----Original Message----- From: Zachary Amsden [mailto:zamsden@cthulhu.engr.sgi.com] Sent: Monday, March 06, 2000 11:54 PM To: karn@qualcomm.com Cc: pilc@grc.nasa.gov Subject: Re: Kicking TCP Yes, kicking TCP is useful in limited situations, but you needn't go to much trouble at all to do it - you can easily add a kernel hack to reset the retransmission timer on the transmitting socket. This will trigger retranmissions without losing any TCP state, and avoids any protocol modifications. This serves a useful purpose on what I call "blackout" lines - lines of communication that temporarily go dead for several seconds and require complicated renegotiation (like some wireless links). On public connections with interactive users, having a kick command is a very bad idea from a congestion point of view. A neat solution to this problem would be to cache link characteristics with routes, and to tweak TCP strategy routines based on link types - i.e. a kick_timeout that limits the maximum retransmission backoff allowed, after which the retransmit timer starts it's cycle over again, or stays at the maximum. (Modifying cwnd is also possible, but I wouldn't recommend it without analysis). One would really need to do some serious simulation runs to analyze the effects of kicking connections under these circumstances. If you still can't complete the transmission with this strategy, I can't think of any other strategy that would help - if you don't get any ACKs in return, kicking is useless. -- Zachary Amsden zamsden@engr.sgi.com 3-6919 31-2-510 Core Protocols From owner-pilc@lerc.nasa.gov Tue Mar 7 13:14:13 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23269 for ; Tue, 7 Mar 2000 13:14:12 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA09560 for pilc-outgoing; Tue, 7 Mar 2000 12:15:30 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA09551 for ; Tue, 7 Mar 2000 12:15:28 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA00298; Tue, 7 Mar 2000 12:15:27 -0500 (EST) Received: from out1.prserv.net(32.97.166.31) by seraph3.lerc.nasa.gov via smap (V5.0) id xma000241; Tue, 7 Mar 00 12:14:45 -0500 Received: from attglobal.net ([129.37.22.197]) by prserv.net (out1) with SMTP id <20000307171439252020jauue>; Tue, 7 Mar 2000 17:14:39 +0000 Message-ID: <38C538D6.ACF6B771@attglobal.net> Date: Tue, 07 Mar 2000 09:13:58 -0800 From: Cannara Reply-To: cannara@attglobal.net X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: pilc@grc.nasa.gov Subject: Re: PILC ASYM document References: <200003062040.OAA13742@sun.cs.tamu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Nitin, If the link handles reasonable MTUs and only understands that TCP performs poorly when packets disappear due to errors, rather than router congestion, then that should be enough, since that's a TCP and network-layer failing to manage paths and inform ends well. Alex Nitin H Vaidya wrote: > > >> From: Venkat Padmanabhan > ... > >> in the same category -- link layer algorithms that utilize TCP-specific > >> knowledge without necessarily modifying TCP itself. In that sense, > >> I believe these are bang on target for PILC; basically, designers > >> of such links may need to spinkle some TCP-specific magic dust to > >> have their links perform well with unmodified end-to-end TCP. > >> (N.B.: The draft surveys a whole range of alternatives, some of which > >> do involve mods to the e2e TCP.) > > Have we exhausted alternatives that do NOT require the link > layer to understand TCP? > > IMHO it is a great idea to have layers communicate information > to each other, but it does not seem a good idea to require the > link layer to understand the transport protocol. > > I hope we can agree on this. > > For instance, it seems reasonable to design a link layer with, > say, 2 service classes (such as, never retransmit, versus > retransmit X times) -- then each packet sent to the link layer > could be tagged with the appropriate service class to be used > for that packet > > The above alternative would be preferable over requiring the > link layer to take different actions depending on whether > a packet belongs to, say, TCP or UDP. > > In my opinion, before this group endorses alternatives that > require link layer to understand transport protocol, a case > needs to be made to show that more reasonable/palatable > alternatives do not exist. > > Cheerio. > > - nitin From owner-pilc@lerc.nasa.gov Tue Mar 7 15:42:28 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06999 for ; Tue, 7 Mar 2000 15:42:27 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA28552 for pilc-outgoing; Tue, 7 Mar 2000 14:17:59 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA28508 for ; Tue, 7 Mar 2000 14:17:56 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA17721; Tue, 7 Mar 2000 14:17:53 -0500 (EST) Received: from mbunix.mitre.org(129.83.20.100) by seraph3.lerc.nasa.gov via smap (V5.0) id xma017682; Tue, 7 Mar 00 14:17:42 -0500 Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id OAA03668; Tue, 7 Mar 2000 14:17:29 -0500 (EST) Received: from FUZZY (fuzzy.mitre.org [129.83.20.83]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id OAA24009; Tue, 7 Mar 2000 14:17:05 -0500 (EST) Received: from kscott-pc.mitre.org (128.29.105.134) by fuzzy.mitre.org with SMTP id 19095; Tue, 07 Mar 2000 14:17:22 EST Message-Id: <4.3.2.20000307132541.00b0e5d0@mailsrv2.mitre.org> X-Sender: kscott@mailsrv2.mitre.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 07 Mar 2000 14:17:18 -0500 To: marie@teledesic.com (Marie-Jose Montpetit) From: kscott@mitre.org (Keith Scott) Subject: RE: Kicking TCP cc: pilc@grc.nasa.gov In-Reply-To: <25D0C66E6D25D311B2AC0008C7913EE07B810F@tdmail2.teledesic.c om> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_84782300==_.ALT" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --=====================_84782300==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed We in fact have something akin to this in the Space Communications Protocol Standard (SCPS, http://www.scps.org) protocol definition. We haven't tested it on any large scale yet, but the idea was to allow the link layer, either through inter-layer signalling or by setting an entry in a MIB, to inform the transport layer about the status of an outbound link. When a link goes down, the network layer might reroute, but the transport layer could also essentially suspend the retransmission timer and probe (akin to persist) to determine when the link becomes available again. Using an LRU queue and something like an ICMP message would allow a router serving many flows to inform several (hopefully all) users of a link of that link's status. From the SCPS-TP Specification (http://www.ccsds.org/blue_books.html). The reference [10] mentioned is the specification for the SCPS network layer. 3.4.3 LINK OUTAGES When the sending TCP receives an indication of a link outage, either from inter-layer signaling or from a MIB-query, the sending TCP a) shall suspend transmission; b) shall suspend the retransmission timer; c) may continue to queue user data for transmission, to the extent that retransmission buffer space permits (this is a local implementation option); d) shall periodically, at a locally determined rate (recommended to be some small multiple of the previous retransmission timeout), send a link-probe segment, consisting of the first octet of unacknowledged data: 1) if no unacknowledged data exist, no link probe shall be sent; 2) if data are submitted for transmission during a link outage, the sending of link probes shall resume; e) shall not interpret link probe segments as retransmissions for the purposes of modification of the retransmission timeout or for invocation of slow start or congestion avoidance; f) may resume normal communication when the sending TCP 1) receives a 'link restored' or 'link redirect' control message (refer to reference [10]); 2) determines that the link is available from a MIB-query (refer to 5.2.2.8 of this document); 3) receives an acknowledgment that arrives at least one RTT after the commencement of the link outage. --keith At 04:02 AM 03/07/2000 -0800, Marie-Jose Montpetit wrote: >I would tend to agree that some simulations may be needed. > >However the kicking strategy is closely related to something I have been >thinking for a while on how to "advertise" that a link is down or degraded. >ICMP extensions were also our first idea or raising the "cost" of a route >when the link is down (when multiple routes are available). > >Maybe what is needed in LINK is a section on suggested mechanisms to survive >capacity degradation? > >Marie-Jose --=====================_84782300==_.ALT Content-Type: text/html; charset="us-ascii" X-MIME-Autoconverted: from 8bit to quoted-printable by smtpproxy1.mitre.org id OAA03668 Content-Transfer-Encoding: quoted-printable
We in fact have something akin to this in the Space Communications Protocol Standard (SCPS, http://www.scps.org) protocol definition.  We haven't tested it on any large scale yet, but the idea was to allow the link layer, either through inter-layer signalling or by setting an entry in a MIB, to inform the transport layer about the status of an outbound link.  When a link goes down, the network layer might reroute, but the transport layer could also essentially suspend the retransmission timer and probe (akin to persist) to determine when the link becomes available again.  Using an LRU queue and something like an ICMP message would allow a router serving many flows to inform several (hopefully all) users of a link of that link's status.

From the SCPS-TP Specification (http= ://www.ccsds.org/blue_books.html).  The reference [10] mentioned is the specification for the SCPS network layer.

3.4.3 LINK OUTAGES
When the sending TCP receives an indication of a link outage, either from inter-layer
signaling or from a MIB-query, the sending TCP
  a) shall suspend transmission;
  b) shall suspend the retransmission timer;
  c) may continue to queue user data for transmission, to the extent that retransmission
        buffer space permits (this is a local implementation option);
  d) shall periodically, at a locally determined rate (recommended to be some small
        multiple of the previous retransmission timeout), send a link-probe segment,
        consisting of the first octet of unacknowledged data:
    &= nbsp; 1) if no unacknowledged data exist, no link probe shall be sent;
      2) if data are submitted for transmission during a link outage, the sending of link
        probes shall resume;
  e) shall not interpret link probe segments as retransmissions for the purposes of
        modificati= on of the retransmission timeout or for invocation of slow start or
        congestion avoidance;
  f) may resume normal communication when the sending TCP
      1) receives a =91link restored=92 or =91li= nk redirect=92 control message (refer to reference [10]);
      2) determines that the link is available from a MIB-query (refer to 5.2.2.8 of this document);
      3) receives an acknowledgment that arrives at least one RTT after the commencement
        of the link outage.


                --keith

At 04:02 AM 03/07/2000 -0800, Marie-Jose Montpetit wrote:
I would tend to agree that some simulations may be needed.

However the kicking strategy is closely related to something I have been
thinking for a while on how to "advertise" that a link is down or degraded.
ICMP extensions were also our first idea or raising the "cost" of a route
when the link is down (when multiple routes are available).

Maybe what is needed in LINK is a section on suggested mechanisms to survive
capacity degradation?

Marie-Jose
--=====================_84782300==_.ALT-- From owner-pilc@lerc.nasa.gov Tue Mar 7 16:07:11 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13572 for ; Tue, 7 Mar 2000 16:07:08 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA04156 for pilc-outgoing; Tue, 7 Mar 2000 14:51:06 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA04114 for ; Tue, 7 Mar 2000 14:51:03 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA23401; Tue, 7 Mar 2000 14:51:00 -0500 (EST) Received: from pneumatic-tube.sgi.com(204.94.214.22) by seraph3.lerc.nasa.gov via smap (V5.0) id xma023351; Tue, 7 Mar 00 14:50:38 -0500 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA03116; Tue, 7 Mar 2000 11:53:50 -0800 (PST) mail_from (zamsden@clock.engr.sgi.com) Received: from clock.engr.sgi.com (clock.engr.sgi.com [163.154.34.45]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA45537; Tue, 7 Mar 2000 11:50:34 -0800 (PST) mail_from (zamsden@clock.engr.sgi.com) Received: from clock.engr.sgi.com (localhost [127.0.0.1]) by clock.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA16193; Tue, 7 Mar 2000 11:56:07 -0800 (PST) Message-Id: <200003071956.LAA16193@clock.engr.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: kscott@mitre.org (Keith Scott) Cc: pilc@grc.nasa.gov Subject: Re: Kicking TCP From: Zachary Amsden In-Reply-To: Your message of "Tue, 07 Mar 2000 14:17:18 EST." <4.3.2.20000307132541.00b0e5d0@mailsrv2.mitre.org> Date: Tue, 07 Mar 2000 11:56:06 -0800 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk There is a mechanism for sending redirects within the protocol framework itself - ICMP source quench can be used to indicate the loss of a flow, and ICMP redirect may be sent as an indicator that the flow has been restored. -- Zachary Amsden zamsden@engr.sgi.com 3-6919 31-2-510 Core Protocols From owner-pilc@lerc.nasa.gov Tue Mar 7 16:31:59 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20012 for ; Tue, 7 Mar 2000 16:31:55 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA07129 for pilc-outgoing; Tue, 7 Mar 2000 15:09:09 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA07087 for ; Tue, 7 Mar 2000 15:09:04 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA26397; Tue, 7 Mar 2000 15:09:03 -0500 (EST) Received: from mbunix.mitre.org(129.83.20.100) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026329; Tue, 7 Mar 00 15:08:27 -0500 Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id PAA12959; Tue, 7 Mar 2000 15:08:00 -0500 (EST) Received: from FUZZY (fuzzy.mitre.org [129.83.20.83]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id PAA02906; Tue, 7 Mar 2000 15:07:38 -0500 (EST) Received: from kscott-pc.mitre.org (128.29.105.134) by fuzzy.mitre.org with SMTP id 19163; Tue, 07 Mar 2000 15:07:56 EST Message-Id: <4.3.2.20000307145906.00c53cb0@mailsrv2.mitre.org> X-Sender: kscott@mailsrv2.mitre.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 07 Mar 2000 15:07:54 -0500 To: zamsden@cthulhu.engr.sgi.com (Zachary Amsden) From: kscott@mitre.org (Keith Scott) Subject: Re: Kicking TCP cc: pilc@grc.nasa.gov In-Reply-To: <200003071956.LAA16193@clock.engr.sgi.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_87817148==_.ALT" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --=====================_87817148==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Yes, but if you do this you have to take the hit from the source quench and go through slow-start again. Using our method (the ICMP-style one, say), a source gets notified that a link it was using has gone dead and immediately suspends its timers and begins probing. When the link comes up again, transmission resumes with no cut in cwnd. A selective negative acknowledgement (SNACK) scheme helps us recover from packets in transit when the link went down. Using SACK to complement SNACK would probably do even better. --keith` At 11:56 AM 03/07/2000 -0800, Zachary Amsden wrote: >There is a mechanism for sending redirects within the protocol framework >itself - ICMP source quench can be used to indicate the loss of a flow, and >ICMP redirect may be sent as an indicator that the flow has been restored. > >-- >Zachary Amsden zamsden@engr.sgi.com 3-6919 31-2-510 Core Protocols > --=====================_87817148==_.ALT Content-Type: text/html; charset="us-ascii" Yes, but if you do this you have to take the hit from the source quench and go through slow-start again.  Using our method (the ICMP-style one, say), a source gets notified that a link it was using has gone dead and immediately suspends its timers and begins probing.  When the link comes up again, transmission resumes with no cut in cwnd.  A selective negative acknowledgement (SNACK) scheme helps us recover from packets in transit when the link went down.  Using SACK to complement SNACK would probably do even better.

                --keith`

At 11:56 AM 03/07/2000 -0800, Zachary Amsden wrote:
There is a mechanism for sending redirects within the protocol framework
itself - ICMP source quench can be used to indicate the loss of a flow, and
ICMP redirect may be sent as an indicator that the flow has been restored.

--
Zachary Amsden  zamsden@engr.sgi.com  3-6919  31-2-510  Core Protocols

--=====================_87817148==_.ALT-- From owner-pilc@lerc.nasa.gov Tue Mar 7 16:37:24 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21159 for ; Tue, 7 Mar 2000 16:37:20 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA08014 for pilc-outgoing; Tue, 7 Mar 2000 15:13:40 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA07968 for ; Tue, 7 Mar 2000 15:13:34 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA27326; Tue, 7 Mar 2000 15:13:34 -0500 (EST) Received: from ns0.utdallas.edu(129.110.10.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma027283; Tue, 7 Mar 00 15:13:00 -0500 Received: from apache.utdallas.edu (apache.utdallas.edu [129.110.16.9]) by ns0.utdallas.edu (Postfix) with ESMTP id 15E7619FFC5; Tue, 7 Mar 2000 14:12:59 -0600 (CST) Received: from localhost (ravip@localhost) by apache.utdallas.edu (8.9.1/8.9.1) with ESMTP id OAA10248; Tue, 7 Mar 2000 14:12:58 -0600 (CST) X-Authentication-Warning: apache.utdallas.edu: ravip owned process doing -bs Date: Tue, 7 Mar 2000 14:12:58 -0600 (CST) From: Ravi Prakash To: Zachary Amsden Cc: Keith Scott , pilc@grc.nasa.gov Subject: Re: Kicking TCP In-Reply-To: <200003071956.LAA16193@clock.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Yes, I agree with this. We proposed a similar approach in our WCNC'99 paper (co-authored with Meghana Sahasrabudhe) for mobile ad hoc networks. There, we also observed that if a path is disrupted for an extended period of time, the routing protocol will discover this fact and set the distance metric to infinity. In ad hoc networks as each node also serves as a router such an ICMP message can be generated locally. Of course, Phil's idea preceded our similar observation by several years. Thanks, ----Ravi. On Tue, 7 Mar 2000, Zachary Amsden wrote: > There is a mechanism for sending redirects within the protocol framework > itself - ICMP source quench can be used to indicate the loss of a flow, and > ICMP redirect may be sent as an indicator that the flow has been restored. > > -- > Zachary Amsden zamsden@engr.sgi.com 3-6919 31-2-510 Core Protocols > > > ======================================================================== Ravi Prakash (ravip@utdallas.edu) www.utdallas.edu/~ravip Department of Computer Science The University of Texas at Dallas Richardson, TX 75083-0688. Phone: (972) 883-2289, Fax: (972) 883-2349 From owner-pilc@lerc.nasa.gov Tue Mar 7 16:48:19 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24249 for ; Tue, 7 Mar 2000 16:48:18 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA11663 for pilc-outgoing; Tue, 7 Mar 2000 15:36:14 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA11640 for ; Tue, 7 Mar 2000 15:36:12 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA01235; Tue, 7 Mar 2000 15:36:10 -0500 (EST) Received: from deliverator.sgi.com(204.94.214.10) by seraph3.lerc.nasa.gov via smap (V5.0) id xma001222; Tue, 7 Mar 00 15:36:03 -0500 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA22879; Tue, 7 Mar 2000 12:31:26 -0800 (PST) mail_from (zamsden@clock.engr.sgi.com) Received: from clock.engr.sgi.com (clock.engr.sgi.com [163.154.34.45]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA70674; Tue, 7 Mar 2000 12:36:00 -0800 (PST) mail_from (zamsden@clock.engr.sgi.com) Received: from clock.engr.sgi.com (localhost [127.0.0.1]) by clock.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA16815; Tue, 7 Mar 2000 12:41:33 -0800 (PST) Message-Id: <200003072041.MAA16815@clock.engr.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: kscott@mitre.org (Keith Scott) Cc: pilc@grc.nasa.gov Subject: Re: Kicking TCP From: Zachary Amsden In-Reply-To: Your message of "Tue, 07 Mar 2000 15:07:54 EST." <4.3.2.20000307145906.00c53cb0@mailsrv2.mitre.org> Date: Tue, 07 Mar 2000 12:41:33 -0800 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > Yes, but if you do this you have to take the hit from the source quench and > go through slow-start again. Using our method (the ICMP-style one, say), a > source gets notified that a link it was using has gone dead and immediately > suspends its timers and begins probing. When the link comes up again, > transmission resumes with no cut in cwnd. A selective negative > acknowledgement (SNACK) scheme helps us recover from packets in transit > when the link went down. Using SACK to complement SNACK would probably do > even better. > > --keith how about using ICMP unreachable with a new code for Network Temporarily unavailable - if this is received, TCP should save it's current window, temporarily cut the window to zero, and begin sending ACK probes at a regular rate. When it receives an ACK in return (see note below), it restores it's old window and resumes transmission. *Note - you could send some type of message Network Available Again, but if the transmitting hosts resends in response to that, it may act too eagerly - it may take some time for routes to be renegotiated on the other end of the connection, causing the data to be misrouted and lost. That will result in a slow start for TCP, which is what we were trying to avoid. Getting an ACK in response to a probe ensures the network is stable again. The real question is what to use for the probe timeout value - perhaps a function of the computed RTT for the connection? -- Zachary Amsden zamsden@engr.sgi.com 3-6919 31-2-510 Core Protocols From owner-pilc@lerc.nasa.gov Tue Mar 7 17:39:59 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10007 for ; Tue, 7 Mar 2000 17:39:59 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA22354 for pilc-outgoing; Tue, 7 Mar 2000 16:51:19 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA22318 for ; Tue, 7 Mar 2000 16:51:16 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA12063; Tue, 7 Mar 2000 16:51:15 -0500 (EST) Received: from motgate2.mot.com(136.182.1.10) by seraph3.lerc.nasa.gov via smap (V5.0) id xma012016; Tue, 7 Mar 00 16:50:43 -0500 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA16618; Tue, 7 Mar 2000 14:50:26 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA27281; Tue, 7 Mar 2000 14:50:24 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id QAA10572; Tue, 7 Mar 2000 16:50:22 -0500 (EST) Message-Id: <200003072150.QAA10572@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: kscott@mitre.org (Keith Scott) cc: zamsden@cthulhu.engr.sgi.com (Zachary Amsden), pilc@grc.nasa.gov Subject: Re: Kicking TCP In-reply-to: Your message of "Tue, 07 Mar 2000 15:07:54 EST." <4.3.2.20000307145906.00c53cb0@mailsrv2.mitre.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Mar 2000 16:50:23 -0500 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Seems to me that resuming without changing cwnd assumes that the congestion state hasn't changed during the outage. That seems unlikely. Wouldn't it be better to reduce cwnd to ssthresh? From owner-pilc@lerc.nasa.gov Tue Mar 7 19:17:07 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08401 for ; Tue, 7 Mar 2000 19:17:05 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA00807 for pilc-outgoing; Tue, 7 Mar 2000 18:26:12 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA00793 for ; Tue, 7 Mar 2000 18:26:11 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA23391; Tue, 7 Mar 2000 18:26:11 -0500 (EST) Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma023381; Tue, 7 Mar 00 18:26:07 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id QAA26350 for pilc@grc.nasa.gov env-from ; Tue, 7 Mar 2000 16:26:05 -0700 (MST) Date: Tue, 7 Mar 2000 16:26:05 -0700 (MST) From: Vernon Schryver Message-Id: <200003072326.QAA26350@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: Kicking TCP Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Dan Grossman > > Seems to me that resuming without changing cwnd assumes that the congestion >state hasn't changed during the outage. That seems unlikely. Wouldn't it be > better to reduce cwnd to ssthresh? There is a draft that will soon advance (if it has not already) on the standards track concerning what to do when the congestion window gets stale for any of many reasons, including some that cover this situation. Kicking TCP with a repeated TCP segment to trigger a delayed ACK when a link comes back sounds plausible. I bet I could name that tune in 30 lines in a couple of PPP implementations. I'm not sure why it's useful, since I would have hoped that reasonable implementations would queue TCP packets on the far side of the link when it went down, and since the wireless people seem so interested in monitoring the link state. Isn't this repeating of TCP segments a very limited form of ARQ? Are you sure it wouldn't be better to admit as much and then ask if partial ARQ wouldn't be just as simple and more generally effective? Generating an ICMP packet would also be straightforward, if I could figure out where to send it. Would you record the last IP address seen in the router and just send to there in the hope that all TCP connections are to that host? Using an ICMP Redirect to kick TCP sounds unlikely to work. There is too much deployed code that either sends ICMP Redirects in completely unrelated situations or that expects to have to deal with them in unrelated situations. Then there are the many firewalls and other filters that discard all ICMP Redirects on (mostly bogus) security grounds before they could get to the TCP peer. What with firewall, filters, and NAT boxes, I don't see how you can hope to get anything to the TCP remote peer often enough to do much good, except an IP packet that looks very much like other recent IP (i.e. TCP) packets. Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Wed Mar 8 03:22:26 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08106 for ; Wed, 8 Mar 2000 03:22:25 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA02482 for pilc-outgoing; Wed, 8 Mar 2000 02:22:35 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA02464 for ; Wed, 8 Mar 2000 02:22:33 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA07228; Wed, 8 Mar 2000 02:22:32 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007218; Wed, 8 Mar 00 02:22:29 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id XAA27413; Tue, 7 Mar 2000 23:22:26 -0800 Date: Tue, 7 Mar 2000 23:22:26 -0800 Message-Id: <200003080722.XAA27413@homer.ka9q.ampr.org> From: Phil Karn To: marie@teledesic.com CC: zamsden@cthulhu.engr.sgi.com, pilc@grc.nasa.gov In-reply-to: <25D0C66E6D25D311B2AC0008C7913EE07B810F@tdmail2.teledesic.com> (message from Marie-Jose Montpetit on Tue, 7 Mar 2000 04:02:22 -0800) Subject: Re: Kicking TCP Reply-to: karn@qualcomm.com References: <25D0C66E6D25D311B2AC0008C7913EE07B810F@tdmail2.teledesic.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >However the kicking strategy is closely related to something I have been >thinking for a while on how to "advertise" that a link is down or degraded. You can already do that with the ICMP Destination Unreachable (down) or Source Quench (degraded) messages. But some would claim that no explicit notification is really needed; packet drops will tell TCP all it needs to know. Phil From owner-pilc@lerc.nasa.gov Wed Mar 8 03:22:27 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08116 for ; Wed, 8 Mar 2000 03:22:27 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA01975 for pilc-outgoing; Wed, 8 Mar 2000 02:11:25 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA01966 for ; Wed, 8 Mar 2000 02:11:19 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA06257; Wed, 8 Mar 2000 02:11:17 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma006251; Wed, 8 Mar 00 02:11:16 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id XAA27384; Tue, 7 Mar 2000 23:11:11 -0800 Date: Tue, 7 Mar 2000 23:11:11 -0800 Message-Id: <200003080711.XAA27384@homer.ka9q.ampr.org> From: Phil Karn To: dan@dma.isg.mot.com CC: marie@teledesic.com, pilc@grc.nasa.gov, afalk@PanAmSat.com In-reply-to: <200003022253.RAA23882@noah.dma.isg.mot.com> (message from Dan Grossman on Thu, 02 Mar 2000 17:53:32 -0500) Subject: Re: Draft on Advice for Internet Subnetwork Designers Reply-to: karn@qualcomm.com References: <200003022253.RAA23882@noah.dma.isg.mot.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >The model I've been working with (especially since that side discussion) is >that if the subnet does queueing (buffering, scheduling, discarding), then the >queueing systems in the subnet has exactly the same effect as queues in >routers. This may be worth stating. Thus, recommendations about having a Yes. In addition, a subnet that provides lots of buffering must also provide QoS hooks that the IP layer can use. Otherwise, meaningful IP-level QoS will be difficult or impossible to provide. Consider a subnet that can buffer, say, 1 sec of traffic but only provides FIFO service. Then 1 second becomes the minimum delay that the router driving the link can provide to any IP packet regardless of how important its TOS bits say it is. I ran into this problem in the early 1990s when dialup modems began to incorporate error control with internal buffers holding several seconds of data. Once the router sent something to the modem, it could not say "hey, take this new packet and put it ahead of the ones I just sent you". Even though my router gave telnet traffic priority to ftp traffic, telnet sessions performed poorly because each telnet packet had to wait for all the FTP data in the modem's internal queue to drain first. I'm not sure what to say about this in the draft except that subnets that implement more than a minimal amount of internal queuing should probably provide some sort of QoS hook that IP can use to implement its own QoS mechanisms. Phil From owner-pilc@lerc.nasa.gov Wed Mar 8 03:28:18 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09483 for ; Wed, 8 Mar 2000 03:28:17 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA02507 for pilc-outgoing; Wed, 8 Mar 2000 02:24:04 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA02503 for ; Wed, 8 Mar 2000 02:24:03 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA07299; Wed, 8 Mar 2000 02:24:02 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007276; Wed, 8 Mar 00 02:23:51 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id XAA27406; Tue, 7 Mar 2000 23:20:15 -0800 Date: Tue, 7 Mar 2000 23:20:15 -0800 Message-Id: <200003080720.XAA27406@homer.ka9q.ampr.org> From: Phil Karn To: zamsden@cthulhu.engr.sgi.com CC: pilc@grc.nasa.gov In-reply-to: <200003070753.XAA21225@clock.engr.sgi.com> (message from Zachary Amsden on Mon, 06 Mar 2000 23:53:41 -0800) Subject: Re: Kicking TCP Reply-to: karn@qualcomm.com References: <200003070753.XAA21225@clock.engr.sgi.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >Yes, kicking TCP is useful in limited situations, but you needn't go to much >trouble at all to do it - you can easily add a kernel hack to reset the >retransmission timer on the transmitting socket. This will trigger >retranmissions without losing any TCP state, and avoids any protocol >modifications. Yes, I know it's easy to reset the TCP retransmission timer, but what would cause that to happen? That was the intent of my ICMP Source Encourage message. What I'm really looking for comment on is whether the same goal of getting TCP going again quickly can be achieved more transparently by having the subnet hold the last packet of a stream through a link outage, and forward it normally when the link comes back up. PHil From owner-pilc@lerc.nasa.gov Wed Mar 8 03:32:49 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10442 for ; Wed, 8 Mar 2000 03:32:49 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA02689 for pilc-outgoing; Wed, 8 Mar 2000 02:29:19 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA02680 for ; Wed, 8 Mar 2000 02:29:17 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA07625; Wed, 8 Mar 2000 02:29:17 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007601; Wed, 8 Mar 00 02:28:58 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id XAA27461; Tue, 7 Mar 2000 23:28:56 -0800 Date: Tue, 7 Mar 2000 23:28:56 -0800 Message-Id: <200003080728.XAA27461@homer.ka9q.ampr.org> From: Phil Karn To: zamsden@cthulhu.engr.sgi.com CC: kscott@mitre.org, pilc@grc.nasa.gov In-reply-to: <200003071956.LAA16193@clock.engr.sgi.com> (message from Zachary Amsden on Tue, 07 Mar 2000 11:56:06 -0800) Subject: Re: Kicking TCP Reply-to: karn@qualcomm.com References: <200003071956.LAA16193@clock.engr.sgi.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >ICMP redirect may be sent as an indicator that the flow has been restored. I don't think this is the intended use of ICMP redirect. According to RFC1122, a redirect will modify a routing table, but it is not one of the ICMP messages passed upstairs to the transport layer. Are you proposing that it taken on a new meaning? I'm not necessarily opposed to such a proposal, but the LINK document is supposed to concentrate on telling subnet designers what they should do, complementing the other work in PILC on possible changes to the Internet protocols to better support unconventional subnetwork layers. Perhaps your suggestion should be directed to one of the other documents? Phil From owner-pilc@lerc.nasa.gov Wed Mar 8 03:39:01 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11146 for ; Wed, 8 Mar 2000 03:39:00 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA03063 for pilc-outgoing; Wed, 8 Mar 2000 02:36:50 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA03056 for ; Wed, 8 Mar 2000 02:36:48 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA08162; Wed, 8 Mar 2000 02:36:47 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma008141; Wed, 8 Mar 00 02:36:15 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id XAA27464; Tue, 7 Mar 2000 23:36:13 -0800 Date: Tue, 7 Mar 2000 23:36:13 -0800 Message-Id: <200003080736.XAA27464@homer.ka9q.ampr.org> From: Phil Karn To: zamsden@cthulhu.engr.sgi.com CC: kscott@mitre.org, pilc@grc.nasa.gov In-reply-to: <200003072041.MAA16815@clock.engr.sgi.com> (message from Zachary Amsden on Tue, 07 Mar 2000 12:41:33 -0800) Subject: Re: Kicking TCP Reply-to: karn@qualcomm.com References: <200003072041.MAA16815@clock.engr.sgi.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >how about using ICMP unreachable with a new code for Network Temporarily >unavailable - if this is received, TCP should save it's current window, >temporarily cut the window to zero, and begin sending ACK probes at a regular >rate. When it receives an ACK in return (see note below), it restores it's >old window and resumes transmission. I agree with Dan Grossman; I'm not sure you want to save and restore the old TCP state, as opposed to letting it restart slow-start. During the outage state, there is probably little harm in letting the sending TCP probe the link with normal retransmissions. Because each retransmission will be backed off exponentially, the load will be limited even if full packets are used in the probes. Phil From owner-pilc@lerc.nasa.gov Wed Mar 8 03:44:32 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12302 for ; Wed, 8 Mar 2000 03:44:32 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA03443 for pilc-outgoing; Wed, 8 Mar 2000 02:44:19 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA03435 for ; Wed, 8 Mar 2000 02:44:18 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA08905; Wed, 8 Mar 2000 02:44:18 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma008879; Wed, 8 Mar 00 02:43:53 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id XAA27472; Tue, 7 Mar 2000 23:43:49 -0800 Date: Tue, 7 Mar 2000 23:43:49 -0800 Message-Id: <200003080743.XAA27472@homer.ka9q.ampr.org> From: Phil Karn To: vjs@calcite.rhyolite.com CC: pilc@grc.nasa.gov In-reply-to: <200003072326.QAA26350@calcite.rhyolite.com> (message from Vernon Schryver on Tue, 7 Mar 2000 16:26:05 -0700 (MST)) Subject: Re: Kicking TCP Reply-to: karn@qualcomm.com References: <200003072326.QAA26350@calcite.rhyolite.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >Isn't this repeating of TCP segments a very limited form of ARQ? >Are you sure it wouldn't be better to admit as much and then ask if >partial ARQ wouldn't be just as simple and more generally effective? It's not quite the same as partial ARQ. I'm assuming that the node with an interface on the downed link would have an out-of-band indication from the link level driver whether the link is up or down. And when it's down, it wouldn't even try to pass a queued packet to the link driver. It would just hold onto the most recent queued packet on each flow (e.g., TCP connection), overwriting it with any subsequent retransmission and wait for the link to come back up. When it does, it would forward the packet normally. Whether the packet is just a TCP ack or it also contains data, it should stimulate the sending TCP into resuming normal operation. Phil From owner-pilc@lerc.nasa.gov Wed Mar 8 03:56:46 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16686 for ; Wed, 8 Mar 2000 03:56:45 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA04178 for pilc-outgoing; Wed, 8 Mar 2000 03:00:50 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id DAA04160 for ; Wed, 8 Mar 2000 03:00:48 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA10161; Wed, 8 Mar 2000 03:00:48 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma010145; Wed, 8 Mar 00 03:00:21 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id AAA27815; Wed, 8 Mar 2000 00:00:18 -0800 Date: Wed, 8 Mar 2000 00:00:18 -0800 Message-Id: <200003080800.AAA27815@homer.ka9q.ampr.org> From: Phil Karn To: dan@dma.isg.mot.com CC: afalk@PanAmSat.com, pilc@grc.nasa.gov In-reply-to: <200003012217.RAA16642@noah.dma.isg.mot.com> (message from Dan Grossman on Wed, 01 Mar 2000 17:17:27 -0500) Subject: Re: Draft on Advice for Internet Subnetwork Designers Reply-to: karn@qualcomm.com References: <200003012217.RAA16642@noah.dma.isg.mot.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >1) Shortly before the Washington meeting, I sent a suggestion to change the >Introduction/Overview section as follows. >> ...seminal paper "End-to-End Arguments in System Design" [SRC81]. This paper >> argued that many -- if not most -- network functions are best implemented on >> an end-to-end basis, i.e., at the higher protocol layers. Duplicating these >> functions at the lower levels can be needlessly redundant or harmful. >> However, there are also cases where duplication can be justified by >> considerations such as performance, availability or security. Examples >> might include link layer retransmission on an unusually lossy channel, e.g., >> mobile radio, encryption of the entire link layer protocol over a shared >> medium, or redundant paths at the link layer for fault recovery. >> Duplication of functions should be done only based on an understanding of >> system level implications, including any side-effects on the higher layers. >I still believe rather strongly that this is more appropriate than the current >wording. Since it has been quite a while since the last discussion of the >document on the mailing list, a reminder seems appropriate. Okay, here's my current proposed version of this paragraph. I've adopted your language with a few minor changes. What do you think? A major consideration in the efficient design of any layered communication network are the appropriate layer(s) in which to implement a given feature. This issue was first addressed in the seminal paper "End-to-End Arguments in System Design" [SRC81]. This paper argued that many -- if not most -- network functions are best implemented on an end-to-end basis, i.e., at the higher protocol layers. Duplicating these functions at the lower levels can be needlessly redundant or harmful. However, there are cases where duplication can be justified by performance, availability or security considerations. Examples include link layer retransmission on an unusually lossy channel, e.g., mobile radio; link level encryption intended to thwart traffic analysis; and redundant transmission links to improve availability. Duplication of functions should be done only with an understanding of system level implications, including possible interactions with higher layer mechanisms. --Phil From owner-pilc@lerc.nasa.gov Wed Mar 8 04:51:10 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03241 for ; Wed, 8 Mar 2000 04:51:09 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA06896 for pilc-outgoing; Wed, 8 Mar 2000 03:29:23 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id DAA06872 for ; Wed, 8 Mar 2000 03:29:18 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA12783; Wed, 8 Mar 2000 03:29:18 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma012745; Wed, 8 Mar 00 03:28:35 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id AAA27974; Wed, 8 Mar 2000 00:28:33 -0800 Date: Wed, 8 Mar 2000 00:28:33 -0800 Message-Id: <200003080828.AAA27974@homer.ka9q.ampr.org> From: Phil Karn To: dan@dma.isg.mot.com CC: afalk@PanAmSat.com, pilc@grc.nasa.gov In-reply-to: <200003062158.QAA18917@noah.dma.isg.mot.com> (message from Dan Grossman on Mon, 06 Mar 2000 16:58:11 -0500) Subject: Re: Draft on Advice for Internet Subnetwork Designers Reply-to: karn@qualcomm.com References: <200003062158.QAA18917@noah.dma.isg.mot.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >If there are >flow control or congestion control mechanisms in the subnet that do not rely >on TCP, these must operate on the scheduling discipline and/or the discarding >policy in the subnet or in the routers at the edges of the subnet, since TCP >has no way to operate on their semantics and IP has no way to be able to pass >their semantics to TCP; however, see below for one exception. I am editing your text into the Buffering, Flow Control and Congestion Control section, but I am having trouble parsing the above paragraph. Can you explain and/or clarify it? Phil From owner-pilc@lerc.nasa.gov Wed Mar 8 05:00:52 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06167 for ; Wed, 8 Mar 2000 05:00:51 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA08899 for pilc-outgoing; Wed, 8 Mar 2000 03:54:52 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id DAA08889 for ; Wed, 8 Mar 2000 03:54:50 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA15112; Wed, 8 Mar 2000 03:54:49 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma015104; Wed, 8 Mar 00 03:54:32 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id AAA28414; Wed, 8 Mar 2000 00:54:31 -0800 Date: Wed, 8 Mar 2000 00:54:31 -0800 Message-Id: <200003080854.AAA28414@homer.ka9q.ampr.org> From: Phil Karn To: pilc@grc.nasa.gov Subject: Updated LINK draft Reply-to: karn@ka9q.ampr.org Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Okay gang, I've updated the current version of the LINK document on my web page. It incorporates Dan Grossman's recommended new language on the end-to-end principle, and it incorporates (in slightly edited form) Dan Grossman's section on subnetwork buffering, flow control and congestion control. I'm still actively digesting the other comments and incorporating them into the text, but I wanted to update the rather stale version of the document that's been on my web page since the DC IETF. The URL is http://people.qualcomm.com/karn/pilc.txt --Phil From owner-pilc@lerc.nasa.gov Wed Mar 8 05:20:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11565 for ; Wed, 8 Mar 2000 05:20:01 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA09377 for pilc-outgoing; Wed, 8 Mar 2000 04:01:36 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA09360 for ; Wed, 8 Mar 2000 04:01:34 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA15541; Wed, 8 Mar 2000 04:01:34 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma015530; Wed, 8 Mar 00 04:01:11 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id BAA28435; Wed, 8 Mar 2000 01:00:55 -0800 Date: Wed, 8 Mar 2000 01:00:55 -0800 Message-Id: <200003080900.BAA28435@homer.ka9q.ampr.org> From: Phil Karn To: gorry@erg.abdn.ac.uk CC: pilc@grc.nasa.gov In-reply-to: <38BA7E19.CB9D89B1@erg.abdn.ac.uk> (message from Dr G Fairhurst on Mon, 28 Feb 2000 15:06:57 +0100) Subject: Re: Draft on Advice for Internet Subnetwork Designers Reply-to: karn@qualcomm.com References: <8046A317B5F4D21186610008C7EBB696F055EE@grnexch1.panamsat.com> <38BA7E19.CB9D89B1@erg.abdn.ac.uk> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >PAGE 4: MTU Size >It may be useful to note that using IPSEC in tunnel mode can increase >the size of a packet as it travels across the network. This can result >in a smaller MTU. I'm not sure what to do about this one. I'm inclined to agree with the comments that say this is not unique to IPSEC but is a consideration with any IP-in-IP encapsulation scheme -- all of which are at higher layers than the subnet. Perhaps some text would be appropriate that says that while 1500 bytes is an important MTU in the Internet because of the prevalence of Ethernet, it would be useful to support a somewhat larger size to avoid IP fragmentation when tunneling (which would include IPSEC) is used. Problem is, this still doesn't avoid the fragmentation that would occur when the path between the tunnel endpoints includes one or more Ethernets. So the benefits of a larger MTU are apt to be limited anyway. Phil From owner-pilc@lerc.nasa.gov Wed Mar 8 08:37:45 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09238 for ; Wed, 8 Mar 2000 08:37:44 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA20329 for pilc-outgoing; Wed, 8 Mar 2000 07:40:36 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id HAA20310 for ; Wed, 8 Mar 2000 07:40:34 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id HAA02175; Wed, 8 Mar 2000 07:40:34 -0500 (EST) Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma002163; Wed, 8 Mar 00 07:40:12 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id FAA14424 for pilc@grc.nasa.gov env-from ; Wed, 8 Mar 2000 05:40:10 -0700 (MST) Date: Wed, 8 Mar 2000 05:40:10 -0700 (MST) From: Vernon Schryver Message-Id: <200003081240.FAA14424@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: Kicking TCP Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Phil Karn > >Isn't this repeating of TCP segments a very limited form of ARQ? > >Are you sure it wouldn't be better to admit as much and then ask if > >partial ARQ wouldn't be just as simple and more generally effective? > > It's not quite the same as partial ARQ. ok, call it "sort of an imitation of a start of ARQ". > I'm assuming that the node > with an interface on the downed link would have an out-of-band > indication from the link level driver whether the link is up or down. > And when it's down, it wouldn't even try to pass a queued packet to > the link driver. It would just hold onto the most recent queued packet > on each flow (e.g., TCP connection), overwriting it with any > subsequent retransmission and wait for the link to come back up. When > it does, it would forward the packet normally. Whether the packet is > just a TCP ack or it also contains data, it should stimulate the > sending TCP into resuming normal operation. How does that differ from what a reasonable demand dialing PPP implementation does the link goes down unexpected, whether because the peer took it down or the modems (or ISDN line etc.) hiccuped? A reasonable PPP implementation queues the most recent N (for some reasonable N>0, but N>typical window/negotiated MTU is good) and sends them when it can (the link comes up or back up). A PPP implementation that does not do this queuing is a pain to use (or so I think), because it loses the traffic that caused it to demand dial. Unfortunately, many demand dialing PPP implementations are unreasonable by this criterion. Besides, why would there be any worry about memory space or queuing mechanisms? A slow-speed link router would need reasonable queuing memory and mechanisms to handle at least one TCP window's worth of TCP/IP packets. Even Microsoft and Sun think a TCP window should be at least 4 or 16K. Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Wed Mar 8 09:36:57 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00209 for ; Wed, 8 Mar 2000 09:36:55 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA26298 for pilc-outgoing; Wed, 8 Mar 2000 08:30:09 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA26265 for ; Wed, 8 Mar 2000 08:30:05 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA07307; Wed, 8 Mar 2000 08:30:05 -0500 (EST) Received: from mbunix.mitre.org(129.83.20.100) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007231; Wed, 8 Mar 00 08:29:29 -0500 Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id IAA04833; Wed, 8 Mar 2000 08:29:24 -0500 (EST) Received: from FUZZY (fuzzy.mitre.org [129.83.20.83]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id IAA05582; Wed, 8 Mar 2000 08:29:02 -0500 (EST) Received: from kscott-pc.mitre.org (128.29.105.134) by fuzzy.mitre.org with SMTP id 19608; Wed, 08 Mar 2000 08:29:21 EST Message-Id: <4.3.2.20000308082812.00c51390@mailsrv2.mitre.org> X-Sender: kscott@mailsrv2.mitre.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 08 Mar 2000 08:29:24 -0500 To: vjs@calcite.rhyolite.com (Vernon Schryver), pilc@grc.nasa.gov From: kscott@mitre.org (Keith Scott) Subject: Re: Kicking TCP In-Reply-To: <200003072326.QAA26350@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_150315963==_.ALT" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --=====================_150315963==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:26 PM 03/07/2000 -0700, Vernon Schryver wrote: [snip] >Generating an ICMP packet would also be straightforward, if I could >figure out where to send it. Would you record the last IP address >seen in the router and just send to there in the hope that all TCP >connections are to that host? [snip] Our notion was to keep an LRU queue of flows that use that link, and to send "Link Outage" messages to each of the sources. --keith --=====================_150315963==_.ALT Content-Type: text/html; charset="us-ascii" At 04:26 PM 03/07/2000 -0700, Vernon Schryver wrote:

[snip]
Generating an ICMP packet would also be straightforward, if I could
figure out where to send it.  Would you record the last IP address
seen in the router and just send to there in the hope that all TCP
connections are to that host?
[snip]

Our notion was to keep an LRU queue of flows that use that link, and to send "Link Outage" messages to each of the sources.

                --keith
 --=====================_150315963==_.ALT-- From owner-pilc@lerc.nasa.gov Wed Mar 8 09:42:28 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02259 for ; Wed, 8 Mar 2000 09:42:27 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA27092 for pilc-outgoing; Wed, 8 Mar 2000 08:36:11 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA27064 for ; Wed, 8 Mar 2000 08:36:08 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA07920; Wed, 8 Mar 2000 08:36:05 -0500 (EST) Received: from mbunix.mitre.org(129.83.20.100) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007867; Wed, 8 Mar 00 08:35:30 -0500 Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id IAA05892; Wed, 8 Mar 2000 08:35:25 -0500 (EST) Received: from FUZZY (fuzzy.mitre.org [129.83.20.83]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id IAA06669; Wed, 8 Mar 2000 08:35:04 -0500 (EST) Received: from kscott-pc.mitre.org (128.29.105.134) by fuzzy.mitre.org with SMTP id 19616; Wed, 08 Mar 2000 08:35:23 EST Message-Id: <4.3.2.20000308081409.00b2ddd0@mailsrv2.mitre.org> X-Sender: kscott@mailsrv2.mitre.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 08 Mar 2000 08:35:01 -0500 To: zamsden@cthulhu.engr.sgi.com (Zachary Amsden), dan@dma.isg.mot.com (Dan Grossman) From: kscott@mitre.org (Keith Scott) Subject: Re: Kicking TCP cc: pilc@grc.nasa.gov In-Reply-To: <200003072041.MAA16815@clock.engr.sgi.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_150678607==_.ALT" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --=====================_150678607==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Responding to multiple messages: Zachary: Your new ICMP message type is very similar to the "Link Outage" in the SCPS draft, but using a received ACK instead of a "Link Restored" ICMP/MIB Query to notify TCP that the link is back? OK. Although if you simply 'resotre your old window and resume transmission' you'll have the same problem of being too aggressive, no? The points about being too aggressive on a "Link Restored" are quite valid. In some special cases it's justified (e.g. the link that goes out does so for a short period of time then comes back up; routes don't change and there aren't too many other flows/enough time that they can eat up the bandwidth from suspended flows). For specific environments like some spacecraft comms, this is valid. Could also be valid for some last-hop wireless scenarios (Phil?). If the link is out for too long, there are a lot of flows sharing routers used by suspended flows, etc., then resuming at full speed is probably too aggressive (and is bursty regardless), and you would definitely want to reduce cwnd or take some other intelligent action. --keith At 12:41 PM 03/07/2000 -0800, Zachary Amsden wrote: >how about using ICMP unreachable with a new code for Network Temporarily >unavailable - if this is received, TCP should save it's current window, >temporarily cut the window to zero, and begin sending ACK probes at a regular >rate. When it receives an ACK in return (see note below), it restores it's >old window and resumes transmission. > >*Note - you could send some type of message Network Available Again, but if >the transmitting hosts resends in response to that, it may act too eagerly - >it may take some time for routes to be renegotiated on the other end of the >connection, causing the data to be misrouted and lost. That will result in a >slow start for TCP, which is what we were trying to avoid. Getting an ACK in >response to a probe ensures the network is stable again. > >The real question is what to use for the probe timeout value - perhaps a >function of the computed RTT for the connection? > >-- >Zachary Amsden zamsden@engr.sgi.com 3-6919 31-2-510 Core Protocols At 04:50 PM 03/07/2000 -0500, Dan Grossman wrote: >Seems to me that resuming without changing cwnd assumes that the congestion >state hasn't changed during the outage. That seems unlikely. Wouldn't >it be >better to reduce cwnd to ssthresh? --=====================_150678607==_.ALT Content-Type: text/html; charset="us-ascii" Responding to multiple messages:

Zachary: Your new ICMP message type is very similar to the "Link Outage" in the SCPS draft, but using a received ACK instead of a "Link Restored" ICMP/MIB Query to notify TCP that the link is back?  OK.  Although if you simply 'resotre your old window and resume transmission' you'll have the same problem of being too aggressive, no?

The points about being too aggressive on a "Link Restored" are quite valid.  In some special cases it's justified (e.g. the link that goes out does so for a short period of time then comes back up; routes don't change and there aren't too many other flows/enough time that they can eat up the bandwidth from suspended flows).  For specific environments like some spacecraft comms, this is valid.  Could also be valid for some last-hop wireless scenarios (Phil?).

If the link is out for too long, there are a lot of flows sharing routers used by suspended flows, etc., then resuming at full speed is probably too aggressive (and is bursty regardless), and you would definitely want to reduce cwnd or take some other intelligent action.


                --keith

At 12:41 PM 03/07/2000 -0800, Zachary Amsden wrote:
how about using ICMP unreachable with a new code for Network Temporarily
unavailable - if this is received, TCP should save it's current window,
temporarily cut the window to zero, and begin sending ACK probes at a regular
rate.  When it receives an ACK in return (see note below), it restores it's
old window and resumes transmission.

*Note - you could send some type of message Network Available Again, but if
the transmitting hosts resends in response to that, it may act too eagerly -
it may take some time for routes to be renegotiated on the other end of the
connection, causing the data to be misrouted and lost.  That will result in a
slow start for TCP, which is what we were trying to avoid.  Getting an ACK in
response to a probe ensures the network is stable again.

The real question is what to use for the probe timeout value - perhaps a
function of the computed RTT for the connection?

--
Zachary Amsden  zamsden@engr.sgi.com  3-6919  31-2-510  Core Protocols


At 04:50 PM 03/07/2000 -0500, Dan Grossman wrote:
Seems to me that resuming without changing cwnd assumes that the congestion
state hasn't changed during the outage.   That seems unlikely.  Wouldn't it be
better to reduce cwnd to ssthresh?
--=====================_150678607==_.ALT-- From owner-pilc@lerc.nasa.gov Wed Mar 8 09:45:12 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03288 for ; Wed, 8 Mar 2000 09:45:11 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA28041 for pilc-outgoing; Wed, 8 Mar 2000 08:41:27 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA27983 for ; Wed, 8 Mar 2000 08:41:22 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA08591; Wed, 8 Mar 2000 08:41:20 -0500 (EST) Received: from ftpbox.mot.com(129.188.136.101) by seraph3.lerc.nasa.gov via smap (V5.0) id xma008568; Wed, 8 Mar 00 08:41:02 -0500 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id GAA27930; Wed, 8 Mar 2000 06:40:56 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id GAA02040; Wed, 8 Mar 2000 06:40:55 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id IAA15226; Wed, 8 Mar 2000 08:40:53 -0500 (EST) Message-Id: <200003081340.IAA15226@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: karn@qualcomm.com cc: afalk@PanAmSat.com, pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers In-reply-to: Your message of "Wed, 08 Mar 2000 00:00:18 EST." <200003080800.AAA27815@homer.ka9q.ampr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Mar 2000 08:40:54 -0500 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Phil, Looks good. Thanks. Dan > >1) Shortly before the Washington meeting, I sent a suggestion to change the > >Introduction/Overview section as follows. > > >> ...seminal paper "End-to-End Arguments in System Design" [SRC81]. This paper > >> argued that many -- if not most -- network functions are best implemented on > >> an end-to-end basis, i.e., at the higher protocol layers. Duplicating these > >> functions at the lower levels can be needlessly redundant or harmful. > >> However, there are also cases where duplication can be justified by > >> considerations such as performance, availability or security. Examples > >> might include link layer retransmission on an unusually lossy channel, e.g., > >> mobile radio, encryption of the entire link layer protocol over a shared > >> medium, or redundant paths at the link layer for fault recovery. > >> Duplication of functions should be done only based on an understanding of > >> system level implications, including any side-effects on the higher layers. > > >I still believe rather strongly that this is more appropriate than the current > >wording. Since it has been quite a while since the last discussion of the > >document on the mailing list, a reminder seems appropriate. > > Okay, here's my current proposed version of this paragraph. I've > adopted your language with a few minor changes. What do you think? > > A major consideration in the efficient design of any layered > communication network are the appropriate layer(s) in which to > implement a given feature. This issue was first addressed in the > seminal paper "End-to-End Arguments in System Design" [SRC81]. This > paper argued that many -- if not most -- network functions are best > implemented on an end-to-end basis, i.e., at the higher protocol > layers. Duplicating these functions at the lower levels can be > needlessly redundant or harmful. However, there are cases where > duplication can be justified by performance, availability or security > considerations. Examples include link layer retransmission on an > unusually lossy channel, e.g., mobile radio; link level encryption > intended to thwart traffic analysis; and redundant transmission > links to improve availability. Duplication of functions should be > done only with an understanding of system level implications, including > possible interactions with higher layer mechanisms. > > --Phil From owner-pilc@lerc.nasa.gov Wed Mar 8 10:39:56 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22951 for ; Wed, 8 Mar 2000 10:39:54 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA05948 for pilc-outgoing; Wed, 8 Mar 2000 09:35:25 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA05916 for ; Wed, 8 Mar 2000 09:35:22 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA15448; Wed, 8 Mar 2000 09:35:22 -0500 (EST) Received: from motgate.mot.com(129.188.136.100) by seraph3.lerc.nasa.gov via smap (V5.0) id xma015394; Wed, 8 Mar 00 09:34:53 -0500 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA29251; Wed, 8 Mar 2000 07:34:41 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA22965; Wed, 8 Mar 2000 07:34:40 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id JAA18285; Wed, 8 Mar 2000 09:34:39 -0500 (EST) Message-Id: <200003081434.JAA18285@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: karn@qualcomm.com cc: afalk@PanAmSat.com, pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers In-reply-to: Your message of "Wed, 08 Mar 2000 00:28:33 EST." <200003080828.AAA27974@homer.ka9q.ampr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Mar 2000 09:34:40 -0500 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > >If there are > >flow control or congestion control mechanisms in the subnet that do not rely > >on TCP, these must operate on the scheduling discipline and/or the discarding > >policy in the subnet or in the routers at the edges of the subnet, since TCP > >has no way to operate on their semantics and IP has no way to be able to pass > >their semantics to TCP; however, see below for one exception. > > I am editing your text into the Buffering, Flow Control and Congestion Control > section, but I am having trouble parsing the above paragraph. Can you explain > and/or clarify it? > > Phil Yeah, that is a little awkward, and run-on. Try: In addition, some subnets may have flow control or congestion control mechanisms in addition to packet dropping and reliance on TCP behavior. Such mechanisms can operate on components in the subnet layer, such as schedulers, shapers or discarders, and can affect the operation of IP forwarders at the edges of the subnet. However, with the exception of RFC2481 explicit congestion notification (which will be discussed below), IP has no way to pass explicit congestion or flow control signals to TCP, and TCP would not react to such signals if they were available. Dan From owner-pilc@lerc.nasa.gov Wed Mar 8 11:48:10 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17848 for ; Wed, 8 Mar 2000 11:48:09 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA17669 for pilc-outgoing; Wed, 8 Mar 2000 10:49:41 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA17639 for ; Wed, 8 Mar 2000 10:49:39 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA25426; Wed, 8 Mar 2000 10:49:39 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.0) id xma025291; Wed, 8 Mar 00 10:48:58 -0500 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.194.130]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id QAA01541; Wed, 8 Mar 2000 16:48:49 +0100 (MET) Received: from eifel.eed.ericsson.se (eifel [164.48.194.242]) by chapelle.eed.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA23396; Wed, 8 Mar 2000 16:48:46 +0100 (MET) Message-Id: <4.2.0.58.20000308155004.00c34220@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 08 Mar 2000 16:48:37 +0100 To: karn@qualcomm.com From: Reiner Ludwig Subject: Why we don't need ICMP SE? (was Re: Kicking TCP) Cc: pilc@grc.nasa.gov In-Reply-To: <200003070727.XAA19511@homer.ka9q.ampr.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 08:27 3/7/00 , Phil Karn wrote: >[...] >But then I realized that if the router is to hold onto a packet so it >can generate an ICMP SE when the link comes back up, it might as well >just forward that same packet onto its destination. This will get TCP >going again just as surely as the ICMP SE mechanism would. So why not do exactly that? We have proposed a "link layer version" of that idea in http://iceberg.cs.berkeley.edu/papers/Ludwig-WINET99/ (the server is currently not accessible - that will be fixed soon), and discuss the link outage issue in section 5 of that paper. I have additional TCP trace plots that show how nicely this appoach works in case of link outages. I can make those traces available if people are interested. If you do this at the link layer instead of the network layer you are free to queue more than just a single packet, e.g., you can queue the entire flight of packets belonging to a TCP flow if resources allow for that. In situations where the link outage was not long enough to trigger a timeout, no packets need to retransmitted at all! And remember, with TCP's super-conservative retransmission timer you can afford quite some link outages without triggering a timeout. >So I'm thinking of inserting some text into the PILC LINK document >that would recommend that routers driving subnetworks subject to >lengthy outages (e.g., mobile radio) try to hold onto the last IP >packet of each flow when a link goes down and forward it to its >destination when the link comes back up. Agree. However, I would leave it open whether this approach is implemented at the router level (only buffering a single packet) or the link layer. It should also be mentioned that no packet should be buffered longer than the Maximum Segment Lifetime (MSL), i.e., 240 seconds, at most. >Note that this gives nearly all of the benefits claimed for totally >reliable link layer protocols with much less effort. Don't agree. With the router level approach you need to change router implementation (deployment concern!). The link layer approach can be designed into upcoming wireless systems. >The router would >not have to promise absolute reliability; if it dropped the stored >packet (e.g., due to insufficient memory), TCP would still recover >after the link comes back up, just not as quickly. Like all link layer >reliability mechanisms below TCP, this one is intended merely as >a performance enhancement, not as a reliability guarantee. With Dan's section referencing the e2e argument paper, we know that a reliability guarantee can only be provided by an end point, not a link layer. I.e., highly persistent link layer error recovery (limited to the class of reliable flows to avoid head-of-line blocking for delay-sensitive flows) does not provide a reliability guarantee but is also merely a performance enhancement. ///Reiner From owner-pilc@lerc.nasa.gov Wed Mar 8 11:48:18 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17905 for ; Wed, 8 Mar 2000 11:48:17 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA15649 for pilc-outgoing; Wed, 8 Mar 2000 10:37:42 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA15614 for ; Wed, 8 Mar 2000 10:37:39 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA23629; Wed, 8 Mar 2000 10:37:39 -0500 (EST) Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma023608; Wed, 8 Mar 00 10:37:22 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id IAA18001 for pilc@grc.nasa.gov env-from ; Wed, 8 Mar 2000 08:37:17 -0700 (MST) Date: Wed, 8 Mar 2000 08:37:17 -0700 (MST) From: Vernon Schryver Message-Id: <200003081537.IAA18001@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: Kicking TCP Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: kscott@mitre.org (Keith Scott) > ... > Our notion was to keep an LRU queue of flows that use that link, and to > send "Link Outage" messages to each of the sources. Which router would send the messages, the near or far side of the link from the point of view of the kick packet? If it is the far side, then wouldn't it be a lot simpler and more effective to either 1. have the link layer tell the TCP state machines to retransmit any unacknowledged TCP bytes by forcing their retransmission timers to zero? This is a layering violation, but I trust most of us are Sunday-only worshipers in that religion. If you want to get fancy, you could fail to reduce the congestion window. 2. do what is common (albeit not common enough) and reasonable in in PPP implementations, which is to have a reasonable sized transmit queue ( > typical window/MTU), and only send packets when the link seems healthy? Don't you need such a queue to deal with bursts, so that the only modification would be to not drop IP packets when the link is broken, as is typical in link layer drivers, including Ethernet, FDDI, and 802.5? Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Wed Mar 8 11:59:22 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21873 for ; Wed, 8 Mar 2000 11:59:22 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA16772 for pilc-outgoing; Wed, 8 Mar 2000 10:43:47 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA16708 for ; Wed, 8 Mar 2000 10:43:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA24698; Wed, 8 Mar 2000 10:43:39 -0500 (EST) Received: from clavin.cs.tamu.edu(128.194.130.106) by seraph3.lerc.nasa.gov via smap (V5.0) id xma024669; Wed, 8 Mar 00 10:43:35 -0500 Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id JAA05166; Wed, 8 Mar 2000 09:43:32 -0600 (CST) From: Nitin H Vaidya Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.9.3/8.9.3) id JAA20566; Wed, 8 Mar 2000 09:43:07 -0600 (CST) Date: Wed, 8 Mar 2000 09:43:07 -0600 (CST) Message-Id: <200003081543.JAA20566@sun.cs.tamu.edu> To: karn@qualcomm.com, zamsden@cthulhu.engr.sgi.com Subject: Re: Kicking TCP Cc: kscott@mitre.org, pilc@grc.nasa.gov Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >> >how about using ICMP unreachable with a new code for Network Temporarily >> >unavailable - if this is received, TCP should save it's current window, >> >temporarily cut the window to zero, and begin sending ACK probes at a regular >> >rate. When it receives an ACK in return (see note below), it restores it's >> >old window and resumes transmission. You might be interested in a paper we wrote on TCP for mobile ad hoc networks in Mobicom'99, which bahaves similar to what you suggest. Regards. - nitin From owner-pilc@lerc.nasa.gov Wed Mar 8 12:13:04 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26276 for ; Wed, 8 Mar 2000 12:13:04 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA21956 for pilc-outgoing; Wed, 8 Mar 2000 11:14:28 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA21921 for ; Wed, 8 Mar 2000 11:14:25 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA29208; Wed, 8 Mar 2000 11:14:25 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma029159; Wed, 8 Mar 00 11:13:51 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id IAA29427; Wed, 8 Mar 2000 08:13:48 -0800 Date: Wed, 8 Mar 2000 08:13:48 -0800 Message-Id: <200003081613.IAA29427@homer.ka9q.ampr.org> From: Phil Karn To: dan@dma.isg.mot.com CC: afalk@PanAmSat.com, pilc@grc.nasa.gov In-reply-to: <200003081434.JAA18285@noah.dma.isg.mot.com> (message from Dan Grossman on Wed, 08 Mar 2000 09:34:40 -0500) Subject: Re: Draft on Advice for Internet Subnetwork Designers Reply-to: karn@qualcomm.com References: <200003081434.JAA18285@noah.dma.isg.mot.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >In addition, some subnets may have flow control or congestion control >mechanisms in addition to packet dropping and reliance on TCP behavior. Such >mechanisms can operate on components in the subnet layer, such as schedulers, >shapers or discarders, and can affect the operation of IP forwarders at the >edges of the subnet. However, with the exception of RFC2481 explicit >congestion notification (which will be discussed below), IP has no way to pass >explicit congestion or flow control signals to TCP, and TCP would not react to >such signals if they were available. Ah, much better! I'll stick it in. Phil From owner-pilc@lerc.nasa.gov Wed Mar 8 12:46:39 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08998 for ; Wed, 8 Mar 2000 12:46:38 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA28000 for pilc-outgoing; Wed, 8 Mar 2000 11:52:04 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA27962 for ; Wed, 8 Mar 2000 11:52:02 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA05302; Wed, 8 Mar 2000 11:52:02 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma005249; Wed, 8 Mar 00 11:51:28 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id IAA01772; Wed, 8 Mar 2000 08:51:23 -0800 Date: Wed, 8 Mar 2000 08:51:23 -0800 Message-Id: <200003081651.IAA01772@homer.ka9q.ampr.org> From: Phil Karn To: gorry@erg.abdn.ac.uk CC: pilc@grc.nasa.gov In-reply-to: <38BA7E19.CB9D89B1@erg.abdn.ac.uk> (message from Dr G Fairhurst on Mon, 28 Feb 2000 15:06:57 +0100) Subject: Re: Draft on Advice for Internet Subnetwork Designers Reply-to: karn@qualcomm.com References: <8046A317B5F4D21186610008C7EBB696F055EE@grnexch1.panamsat.com> <38BA7E19.CB9D89B1@erg.abdn.ac.uk> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Gorry, >Reference: MPEG-2 or DVB reference. I'm editing in your text. Can you provide cites to these reference(s)? Phil From owner-pilc@lerc.nasa.gov Wed Mar 8 12:49:49 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10316 for ; Wed, 8 Mar 2000 12:49:49 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA27501 for pilc-outgoing; Wed, 8 Mar 2000 11:49:05 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA27482 for ; Wed, 8 Mar 2000 11:49:03 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA04887; Wed, 8 Mar 2000 11:49:02 -0500 (EST) Received: from host60d9.alcatel.com(128.251.96.217) by seraph3.lerc.nasa.gov via smap (V5.0) id xma004765; Wed, 8 Mar 00 11:48:20 -0500 Received: from usa.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id KAA08874; Wed, 8 Mar 2000 10:48:05 -0600 (CST) Message-ID: <38C683AB.60123AFB@usa.alcatel.com> Date: Wed, 08 Mar 2000 10:45:31 -0600 From: Vincent Magret Organization: Alcatel USA, Inc. X-Sender: "Vincent Magret" X-Mailer: Mozilla 4.5 [en]C-CCK-MCD ANS2.00 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: PILC Subject: Re: Kicking TCP References: <200003072041.MAA16815@clock.engr.sgi.com> Content-Type: multipart/mixed; boundary="------------F025A5A6BB7FC1BD3821D88B" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. --------------F025A5A6BB7FC1BD3821D88B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Why sending a probe when the information could be sent for the node in the network that monitors the broken link. Just put the TCP sender connection in idle state for a certain time, after which the connection will be broke down. The question is then How long? Vincent Zachary Amsden wrote: > > Yes, but if you do this you have to take the hit from the source quench and > > go through slow-start again. Using our method (the ICMP-style one, say), a > > source gets notified that a link it was using has gone dead and immediately > > suspends its timers and begins probing. When the link comes up again, > > transmission resumes with no cut in cwnd. A selective negative > > acknowledgement (SNACK) scheme helps us recover from packets in transit > > when the link went down. Using SACK to complement SNACK would probably do > > even better. > > > > --keith > > how about using ICMP unreachable with a new code for Network Temporarily > unavailable - if this is received, TCP should save it's current window, > temporarily cut the window to zero, and begin sending ACK probes at a regular > rate. When it receives an ACK in return (see note below), it restores it's > old window and resumes transmission. > > *Note - you could send some type of message Network Available Again, but if > the transmitting hosts resends in response to that, it may act too eagerly - > it may take some time for routes to be renegotiated on the other end of the > connection, causing the data to be misrouted and lost. That will result in a > slow start for TCP, which is what we were trying to avoid. Getting an ACK in > response to a probe ensures the network is stable again. > > The real question is what to use for the probe timeout value - perhaps a > function of the computed RTT for the connection? > > -- > Zachary Amsden zamsden@engr.sgi.com 3-6919 31-2-510 Core Protocols --------------F025A5A6BB7FC1BD3821D88B Content-Type: text/x-vcard; charset=us-ascii; name="vincent.magret.vcf" Content-Description: Card for Vincent Magret Content-Disposition: attachment; filename="vincent.magret.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Magret;Vincent tel;fax:+1 972 996 5902 tel;work:+1 972 996 2625 x-mozilla-html:FALSE org:;Network Strategy Group version:2.1 email;internet:vincent.magret@usa.alcatel.com adr;quoted-printable:;;1201 E. Campbell rd=0D=0AM-S 446-310;Ricahrdson;Texas;75081;USA fn:Vincent Magret end:vcard --------------F025A5A6BB7FC1BD3821D88B-- From owner-pilc@lerc.nasa.gov Wed Mar 8 13:47:37 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26052 for ; Wed, 8 Mar 2000 13:47:36 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA05705 for pilc-outgoing; Wed, 8 Mar 2000 12:50:35 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA05666 for ; Wed, 8 Mar 2000 12:50:32 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA12825; Wed, 8 Mar 2000 12:50:32 -0500 (EST) Received: from out4.prserv.net(32.97.166.34) by seraph3.lerc.nasa.gov via smap (V5.0) id xma012743; Wed, 8 Mar 00 12:49:54 -0500 Received: from attglobal.net ([32.100.71.87]) by prserv.net (out4) with SMTP id <2000030817495123901tigcqe>; Wed, 8 Mar 2000 17:49:52 +0000 Message-ID: <38C6928D.21BFC9C6@attglobal.net> Date: Wed, 08 Mar 2000 09:49:01 -0800 From: Cannara Reply-To: cannara@attglobal.net X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <8046A317B5F4D21186610008C7EBB696F055EE@grnexch1.panamsat.com> <38BA7E19.CB9D89B1@erg.abdn.ac.uk> <200003080900.BAA28435@homer.ka9q.ampr.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Perhaps we should be considering at least the FDDI MTU of 4500B as a basis for future statements? This would cover all Ethernet-sourced pkts that get tunnelled. Routers from the major manuf. have interface specs for which this is no problem. Of course, the Ethernet folks are talking of larger pkts as well. Alex Phil Karn wrote: > > >PAGE 4: MTU Size > > >It may be useful to note that using IPSEC in tunnel mode can increase > >the size of a packet as it travels across the network. This can result > >in a smaller MTU. > > I'm not sure what to do about this one. I'm inclined to agree with the > comments that say this is not unique to IPSEC but is a consideration with any > IP-in-IP encapsulation scheme -- all of which are at higher layers than the subnet. > > Perhaps some text would be appropriate that says that while 1500 bytes > is an important MTU in the Internet because of the prevalence of > Ethernet, it would be useful to support a somewhat larger size to avoid IP fragmentation > when tunneling (which would include IPSEC) is used. Problem is, this still doesn't > avoid the fragmentation that would occur when the path between the tunnel endpoints > includes one or more Ethernets. So the benefits of a larger MTU are apt to be limited anyway. > > Phil From owner-pilc@lerc.nasa.gov Wed Mar 8 13:51:52 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27366 for ; Wed, 8 Mar 2000 13:51:51 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA06750 for pilc-outgoing; Wed, 8 Mar 2000 12:57:25 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA06710 for ; Wed, 8 Mar 2000 12:57:22 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA13773; Wed, 8 Mar 2000 12:57:19 -0500 (EST) Received: from out4.prserv.net(32.97.166.34) by seraph3.lerc.nasa.gov via smap (V5.0) id xma013693; Wed, 8 Mar 00 12:56:43 -0500 Received: from attglobal.net ([32.100.71.87]) by prserv.net (out4) with SMTP id <2000030817564023901o9guoe>; Wed, 8 Mar 2000 17:56:41 +0000 Message-ID: <38C69427.927B0842@attglobal.net> Date: Wed, 08 Mar 2000 09:55:51 -0800 From: Cannara Reply-To: cannara@attglobal.net X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <200003062158.QAA18917@noah.dma.isg.mot.com> <200003080828.AAA27974@homer.ka9q.ampr.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit FYI, a related suggestion was for IP to communicate info TCP could use by passing up the IP ID (v4) via TCP's Urgent Pointer (with URG bit off) and the receiving TCP would so get the ID of the packet sent, then return that ID when it Acked that pkt. The sender keeps a list of IDs vs TCP pkts and then knows exactly what TCP packet was acked, even if there is a false retransmission (due to a short timer, etc.) and can avoid going into backoffs simply because of misjudgments of RTT, etc. IPv6, of course, has messed this up (no ID). Alex Phil Karn wrote: > > >If there are > >flow control or congestion control mechanisms in the subnet that do not rely > >on TCP, these must operate on the scheduling discipline and/or the discarding > >policy in the subnet or in the routers at the edges of the subnet, since TCP > >has no way to operate on their semantics and IP has no way to be able to pass > >their semantics to TCP; however, see below for one exception. > > I am editing your text into the Buffering, Flow Control and Congestion Control > section, but I am having trouble parsing the above paragraph. Can you explain > and/or clarify it? > > Phil From owner-pilc@lerc.nasa.gov Wed Mar 8 14:05:03 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01323 for ; Wed, 8 Mar 2000 14:05:02 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA08874 for pilc-outgoing; Wed, 8 Mar 2000 13:11:38 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA08853 for ; Wed, 8 Mar 2000 13:11:36 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA15814; Wed, 8 Mar 2000 13:11:35 -0500 (EST) Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma015764; Wed, 8 Mar 00 13:10:58 -0500 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id KAA13540; Wed, 8 Mar 2000 10:10:25 -0800 (PST) Message-ID: <38C6977F.35048669@isi.edu> Date: Wed, 08 Mar 2000 10:10:07 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Dan Grossman CC: karn@qualcomm.com, afalk@PanAmSat.com, pilc@grc.nasa.gov, touch@ISI.EDU Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <200003081340.IAA15226@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dan Grossman wrote: > > Phil, > Looks good. Thanks. > Dan > > >1) Shortly before the Washington meeting, I sent a suggestion to change the > > >Introduction/Overview section as follows. > > > > >> ...seminal paper "End-to-End Arguments in System Design" [SRC81]. This paper > > >> argued that many -- if not most -- network functions are best implemented on > > >> an end-to-end basis, i.e., at the higher protocol layers. Duplicating these > > >> functions at the lower levels can be needlessly redundant or harmful. > > >> However, there are also cases where duplication can be justified by > > >> considerations such as performance, availability or security. Examples > > >> might include link layer retransmission on an unusually lossy channel, e.g., > > >> mobile radio, encryption of the entire link layer protocol over a shared > > >> medium, or redundant paths at the link layer for fault recovery. > > >> Duplication of functions should be done only based on an understanding of > > >> system level implications, including any side-effects on the higher layers. The paper does not exactly argue that these fns are best implemented E2E; it argues that: (I call this the E2E Principle:) End-to-end services cannot be provided solely by the composition of hop-by-hop services. (I call this the E2E Corrolary:) Hop-by-hop services may be required for performance, but they enhance, rather than replace, the corresponding end-to-end service. The issue of whether they are needlessly redundent or harmful stems only from these. A HBH implementation is harmful only where it is used to incorrectly replace an E2E one (violating E2E Princ.) or where it fails to enhance the concurrent E2E version (violating E2E Corrol.) "best implemented as E2E" isn't exactly the point; the point is that HBH is insufficient, not 'relatively worse'. Duplication at lower layers is strictly a performance issue, by my read. Is there a way of morphing that into the above?? Joe From owner-pilc@lerc.nasa.gov Wed Mar 8 14:08:52 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02484 for ; Wed, 8 Mar 2000 14:08:51 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA10093 for pilc-outgoing; Wed, 8 Mar 2000 13:19:08 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA10072 for ; Wed, 8 Mar 2000 13:19:06 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA16860; Wed, 8 Mar 2000 13:19:05 -0500 (EST) Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma016731; Wed, 8 Mar 00 13:18:27 -0500 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id KAA14791; Wed, 8 Mar 2000 10:18:04 -0800 (PST) Message-ID: <38C6994A.2216D26D@isi.edu> Date: Wed, 08 Mar 2000 10:17:46 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: karn@qualcomm.com CC: gorry@erg.abdn.ac.uk, pilc@grc.nasa.gov, touch@ISI.EDU Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <8046A317B5F4D21186610008C7EBB696F055EE@grnexch1.panamsat.com> <38BA7E19.CB9D89B1@erg.abdn.ac.uk> <200003080900.BAA28435@homer.ka9q.ampr.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Phil Karn wrote: > > >PAGE 4: MTU Size > > >It may be useful to note that using IPSEC in tunnel mode can increase > >the size of a packet as it travels across the network. This can result > >in a smaller MTU. Many protocols other than IPSEC can reduce the E2E MTU. IPSEC is one, IPIP tunneling is another (it need not include or refer to IPSEC), as are any protocols that augment the IP header with options. > I'm not sure what to do about this one. I'm inclined to agree with the > comments that say this is not unique to IPSEC but is a consideration with any > IP-in-IP encapsulation scheme -- all of which are at higher layers than the subnet. Any protocol that augments the IP header can cause this, whether by encapsulation, option augmentation, etc. > Perhaps some text would be appropriate that says that while 1500 bytes > is an important MTU in the Internet because of the prevalence of > Ethernet, it would be useful to support a somewhat larger size to avoid IP fragmentation > when tunneling (which would include IPSEC) is used. Problem is, this still doesn't > avoid the fragmentation that would occur when the path between the tunnel endpoints > includes one or more Ethernets. So the benefits of a larger MTU are apt to be limited anyway. A useful point may be "don't assume the MTU at all anymore," i.e., it might be worthwhile to have designers of links _and_ upper protocols both drop such preconceptions they have about the link. Joe From owner-pilc@lerc.nasa.gov Wed Mar 8 14:35:06 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09720 for ; Wed, 8 Mar 2000 14:35:06 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA12962 for pilc-outgoing; Wed, 8 Mar 2000 13:37:12 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA12870 for ; Wed, 8 Mar 2000 13:37:08 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA19374; Wed, 8 Mar 2000 13:37:06 -0500 (EST) Received: from pneumatic-tube.sgi.com(204.94.214.22) by seraph3.lerc.nasa.gov via smap (V5.0) id xma019307; Wed, 8 Mar 00 13:36:24 -0500 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA02271; Wed, 8 Mar 2000 10:39:16 -0800 (PST) mail_from (zamsden@clock.engr.sgi.com) Received: from clock.engr.sgi.com (clock.engr.sgi.com [163.154.34.45]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA73388; Wed, 8 Mar 2000 10:35:54 -0800 (PST) mail_from (zamsden@clock.engr.sgi.com) Received: from clock.engr.sgi.com (localhost [127.0.0.1]) by clock.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA20340; Wed, 8 Mar 2000 10:41:34 -0800 (PST) Message-Id: <200003081841.KAA20340@clock.engr.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: karn@qualcomm.com Cc: kscott@mitre.org, pilc@grc.nasa.gov Subject: Re: Kicking TCP From: Zachary Amsden In-Reply-To: Your message of "Tue, 07 Mar 2000 23:36:13 PST." <200003080736.XAA27464@homer.ka9q.ampr.org> Date: Wed, 08 Mar 2000 10:41:34 -0800 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > >how about using ICMP unreachable with a new code for Network Temporarily > >unavailable - if this is received, TCP should save it's current window, > >temporarily cut the window to zero, and begin sending ACK probes at a regular > >rate. When it receives an ACK in return (see note below), it restores it's > >old window and resumes transmission. > > I agree with Dan Grossman; I'm not sure you want to save and restore > the old TCP state, as opposed to letting it restart slow-start. That was the intention of my original idea - to reduce cwnd and send periodic (rather than backed-off) probes, and do a slow-restart upon receipt of an ACK. > During the outage state, there is probably little harm in letting the > sending TCP probe the link with normal retransmissions. Because each > retransmission will be backed off exponentially, the load will be > limited even if full packets are used in the probes. During the outage state, if the router is queuing the data as suggested, upon restoration, any queued data will be sent as a burst to the other side, and the resulting ACKs will cause the window to re-inflate. So if you have a buffering router, no protocol modifications are really necessary to get you going again. So yes, restoring cwnd to the pre-outage value with a buffering router would cause the window to possibly double what the window was before congestion, which would be a bad thing. With no buffering in the router, saving/restoring cwnd via link down/up notifications seems like a good idea. At most only hosts that recognize the notification scheme will start retransmitting with prior windows, so hosts that don't will just backoff and slow-start. So there shouldn't be any problem with congestion after link up notification if there wasn't any congestion when the link went down. The notification scheme is really just an implementation detail, and I'm just wondering whether it can be done within the current framework by being creative without breaking too many semantics. -- Zachary Amsden zamsden@engr.sgi.com 3-6919 31-2-510 Core Protocols From owner-pilc@lerc.nasa.gov Wed Mar 8 14:53:58 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16123 for ; Wed, 8 Mar 2000 14:53:57 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA17619 for pilc-outgoing; Wed, 8 Mar 2000 14:06:30 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA17573 for ; Wed, 8 Mar 2000 14:06:28 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA23981; Wed, 8 Mar 2000 14:06:26 -0500 (EST) Received: from ftpbox.mot.com(129.188.136.101) by seraph3.lerc.nasa.gov via smap (V5.0) id xma023962; Wed, 8 Mar 00 14:06:20 -0500 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA25857; Wed, 8 Mar 2000 12:05:53 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id MAA10055; Wed, 8 Mar 2000 12:05:51 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id OAA00375; Wed, 8 Mar 2000 14:05:45 -0500 (EST) Message-Id: <200003081905.OAA00375@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Joe Touch cc: karn@qualcomm.com, afalk@PanAmSat.com, pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers In-reply-to: Your message of "Wed, 08 Mar 2000 10:10:07 EST." <38C6977F.35048669@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Mar 2000 14:05:44 -0500 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > > > Dan Grossman wrote: > > > > Phil, > > Looks good. Thanks. > > Dan > > > >1) Shortly before the Washington meeting, I sent a suggestion to change the > > > >Introduction/Overview section as follows. > > > > > > >> ...seminal paper "End-to-End Arguments in System Design" [SRC81]. This paper > > > >> argued that many -- if not most -- network functions are best implemented on > > > >> an end-to-end basis, i.e., at the higher protocol layers. Duplicating these > > > >> functions at the lower levels can be needlessly redundant or harmful. > > > >> However, there are also cases where duplication can be justified by > > > >> considerations such as performance, availability or security. Examples > > > >> might include link layer retransmission on an unusually lossy channel, e.g., > > > >> mobile radio, encryption of the entire link layer protocol over a shared > > > >> medium, or redundant paths at the link layer for fault recovery. > > > >> Duplication of functions should be done only based on an understanding of > > > >> system level implications, including any side-effects on the higher layers. > > The paper does not exactly argue that these fns are best implemented > E2E; > it argues that: > > (I call this the E2E Principle:) > End-to-end services cannot be provided solely by the composition > of hop-by-hop services. > > (I call this the E2E Corrolary:) > Hop-by-hop services may be required for performance, but they enhance, > rather than replace, the corresponding end-to-end service. > Not just for performance, but otherwise agree thus far. > The issue of whether they are needlessly redundent or harmful stems only > from these. > A HBH implementation is harmful only where it is used to incorrectly > replace an E2E one > (violating E2E Princ.) or where it fails to enhance the concurrent E2E > version (violating > E2E Corrol.) > > "best implemented as E2E" isn't exactly the point; the point is that HBH > is insufficient, > not 'relatively worse'. I agree up to this point. The old text was a bit of an oversimplification of the end-to-end paper. The underlying issue in end-to-end was the historical battle between X.25 with Class 0 transport protocol and IP with TCP (or CLNP and Class 4 transport protocol). X.25 attempted to provide an end-to-end reliable service using network layer (hop-by-hop) mechanisms, so that no retransmission mechanisms were required in the end systems. The point was that although those kinds of mechanisms could produce an _almost_ reliable service at the cost of expensive mechanisms in the network, a _truly_ reliable end-to-end service could never be supported using only hop-by-hop mechanisms. The end-to-end paper then extends its exposition of this flaw to further argue for statelessness as a way of providing end-to-end availability despite network failures ("fate sharing"), and in general to call for extremely lightweight networks. >Duplication at lower layers is strictly a > performance > issue, by my read. Here's where I disagree. There are hop-by-hop (or, rather) subnet functions which are in some sense redundant with end-to-end functions, but which are still needed for security and availability, as well as performance. The examples in the new text are fairly generic examples. Consider the case of availability: various kinds of subnets -- SONET/SDH, ATM, MPLS, optical -- provide some kind of failover protection switching. These are stateful and redundant with IP layer re-routing, and could if improperly used result in harmful interactions with the IP layer. On the other hand, they can accomplish a failover in 50 ms, rather than the 30 seconds or more that it takes for OSPF to reconverge; if Five-9s availability is a network objective, then these additional mechanisms are needed. > Is there a way of morphing that into the above?? > ...[SRC81]. This paper argued that certain kinds of end-to-end services cannot be provided solely by the composition of hop-by-hop mechanisms, and instead require mechanisms that operate end-to-end. Duplicative presence of hop-by-hop mechanisms in the network can be needlessly redundant or even cause harmful interactions with end-to-end mechanisms. However... From owner-pilc@lerc.nasa.gov Wed Mar 8 15:19:56 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22827 for ; Wed, 8 Mar 2000 15:19:55 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA21027 for pilc-outgoing; Wed, 8 Mar 2000 14:28:59 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA20998 for ; Wed, 8 Mar 2000 14:28:55 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA27211; Wed, 8 Mar 2000 14:28:55 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma027104; Wed, 8 Mar 00 14:28:41 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id LAA01883; Wed, 8 Mar 2000 11:28:30 -0800 Date: Wed, 8 Mar 2000 11:28:30 -0800 Message-Id: <200003081928.LAA01883@homer.ka9q.ampr.org> From: Phil Karn To: zamsden@cthulhu.engr.sgi.com CC: kscott@mitre.org, pilc@grc.nasa.gov In-reply-to: <200003081841.KAA20340@clock.engr.sgi.com> (message from Zachary Amsden on Wed, 08 Mar 2000 10:41:34 -0800) Subject: Re: Kicking TCP Reply-to: karn@qualcomm.com References: <200003081841.KAA20340@clock.engr.sgi.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >During the outage state, if the router is queuing the data as suggested, upon >restoration, any queued data will be sent as a burst to the other side, and >the resulting ACKs will cause the window to re-inflate. So if you have a Only if all the data is queued during the outages. I propose having the subnet queue only the last packet on each flow, or alternatively some small number of packets N, with the older packets discarded as new ones arrive. Phil From owner-pilc@lerc.nasa.gov Wed Mar 8 15:20:12 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22928 for ; Wed, 8 Mar 2000 15:20:11 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA21173 for pilc-outgoing; Wed, 8 Mar 2000 14:29:45 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA21139 for ; Wed, 8 Mar 2000 14:29:42 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA27295; Wed, 8 Mar 2000 14:29:41 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma027269; Wed, 8 Mar 00 14:29:12 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id LAA01886; Wed, 8 Mar 2000 11:29:10 -0800 Date: Wed, 8 Mar 2000 11:29:10 -0800 Message-Id: <200003081929.LAA01886@homer.ka9q.ampr.org> From: Phil Karn To: touch@ISI.EDU CC: dan@dma.isg.mot.com, afalk@PanAmSat.com, pilc@grc.nasa.gov, touch@ISI.EDU In-reply-to: <38C6977F.35048669@isi.edu> (message from Joe Touch on Wed, 08 Mar 2000 10:10:07 -0800) Subject: Re: Draft on Advice for Internet Subnetwork Designers Reply-to: karn@ka9q.ampr.org References: <200003081340.IAA15226@noah.dma.isg.mot.com> <38C6977F.35048669@isi.edu> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >Is there a way of morphing that into the above?? I agree with your presentation. I'll try to come up with the appropriate language. Phil From owner-pilc@lerc.nasa.gov Wed Mar 8 16:45:59 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17931 for ; Wed, 8 Mar 2000 16:45:59 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA01205 for pilc-outgoing; Wed, 8 Mar 2000 15:38:50 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA01196 for ; Wed, 8 Mar 2000 15:38:48 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA07021; Wed, 8 Mar 2000 15:38:47 -0500 (EST) Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007006; Wed, 8 Mar 00 15:38:34 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id NAA25072 for pilc@grc.nasa.gov env-from ; Wed, 8 Mar 2000 13:38:33 -0700 (MST) Date: Wed, 8 Mar 2000 13:38:33 -0700 (MST) From: Vernon Schryver Message-Id: <200003082038.NAA25072@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: Kicking TCP Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Phil Karn >>During the outage state, if the router is queuing the data as suggested, upon > >restoration, any queued data will be sent as a burst to the other side, and > >the resulting ACKs will cause the window to re-inflate. So if you have a > > Only if all the data is queued during the outages. I propose having the subnet > queue only the last packet on each flow, or alternatively some small number > of packets N, with the older packets discarded as new ones arrive. Again, doesn't any reasonable router queue at least the last N packets that arrive while its flakey link is down but expected to be restored? Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Thu Mar 9 00:55:01 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10547 for ; Thu, 9 Mar 2000 00:55:01 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id XAA05247 for pilc-outgoing; Wed, 8 Mar 2000 23:47:51 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id XAA04453; Wed, 8 Mar 2000 23:29:13 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id XAA24251; Wed, 8 Mar 2000 23:29:13 -0500 (EST) Received: from leonis.nus.edu.sg(137.132.1.18) by seraph3.lerc.nasa.gov via smap (V5.0) id xma024225; Wed, 8 Mar 00 23:28:37 -0500 Received: from engtanlk.nus.edu.sg ([137.132.204.243]) by leonis.nus.edu.sg (8.9.3/8.9.3) with SMTP id KAA29894; Thu, 9 Mar 2000 10:39:58 +0800 (SST) Message-ID: <003a01bf8971$4bd19780$f3cc8489@engtanlk.nus.edu.sg> From: "ICON'2000 Secretariat" To: Subject: 7 days to go ! Have you submitted your paper. Date: Thu, 9 Mar 2000 10:39:57 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01BF89B4.59ED3660" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0037_01BF89B4.59ED3660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All=20 =20 * Kindly ignore this email if you have received this before.=20 Thanks you for your kind attention. =20 The 8th IEEE International Conference On Networks will be held from=20 September 5- 8, 2000 in Singapore. The aim of the conference is to = provide=20 an international forum for experts to promote, share and discuss various = issues and developments in the broad field of computer and communication = networks. We thus seek and solicit your contributions in the form of original/unpublished papers, tutorials, and topics for=20 special sessions/panel discussions. More information on the scope of the = conference and the guidelines for the submission of contributions can be obtained at this web site :http://www.comp.nus.edu.sg/~icon/ We look forward to your participation. Thank you. Icon 2000 organizing Committee ------=_NextPart_000_0037_01BF89B4.59ED3660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All
 
*=20 Kindly ignore this email if you have received this before.=20
Thanks you for your kind = attention.
 

The 8th IEEE International Conference On Networks will be held from =

September 5- 8, 2000 in Singapore. The aim of the conference is to = provide=20

an international forum for experts to promote, share and discuss = various

issues and developments in the broad field of computer and = communication

networks. We thus seek and solicit your contributions

in the form of original/unpublished papers, tutorials, and topics for =

special sessions/panel discussions. More information on the scope of = the

conference and the guidelines for the submission of contributions = can

be obtained at this web site :http://www.comp.nus.edu.sg/~icon/

 

We look forward to your participation. Thank you.

Icon 2000 organizing=20 Committee

= ------=_NextPart_000_0037_01BF89B4.59ED3660-- From owner-pilc@lerc.nasa.gov Thu Mar 9 04:20:35 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21109 for ; Thu, 9 Mar 2000 04:20:30 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA16434 for pilc-outgoing; Thu, 9 Mar 2000 03:18:09 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id DAA16425 for ; Thu, 9 Mar 2000 03:18:07 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA13135; Thu, 9 Mar 2000 03:18:07 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma013109; Thu, 9 Mar 00 03:17:40 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id AAA04398; Thu, 9 Mar 2000 00:17:36 -0800 Date: Thu, 9 Mar 2000 00:17:36 -0800 Message-Id: <200003090817.AAA04398@homer.ka9q.ampr.org> From: Phil Karn To: marie@teledesic.com CC: dan@dma.isg.mot.com, afalk@PanAmSat.com, pilc@grc.nasa.gov In-reply-to: <25D0C66E6D25D311B2AC0008C7913EE07B810E@tdmail2.teledesic.com> (message from Marie-Jose Montpetit on Tue, 7 Mar 2000 03:54:12 -0800) Subject: Re: Draft on Advice for Internet Subnetwork Designers Reply-to: karn@qualcomm.com References: <25D0C66E6D25D311B2AC0008C7913EE07B810E@tdmail2.teledesic.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >On the topic of packet discard especially on those subnet where capacity is >expensive or limited I would add that when possible packets marked form >another subnet should be discarded before transmission on the link. Is this an issue for the subnetwork designer, or for the router that drives the subnetwork? Phil From owner-pilc@lerc.nasa.gov Thu Mar 9 09:35:06 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20854 for ; Thu, 9 Mar 2000 09:35:04 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA05611 for pilc-outgoing; Thu, 9 Mar 2000 08:29:06 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA05607 for ; Thu, 9 Mar 2000 08:29:04 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA07758; Thu, 9 Mar 2000 08:29:04 -0500 (EST) Received: from unknown(192.116.146.9) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007204; Thu, 9 Mar 00 08:27:30 -0500 Received: by NEPTUNE with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Mar 2000 15:12:49 +0200 Message-ID: <973F816F4D85D311A48300A0C9D346660A34E9@NEPTUNE> From: Michael Orr To: pilc@grc.nasa.gov Subject: RE: PILC ASYM document Date: Thu, 9 Mar 2000 15:12:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > Before the working group could take on developing a new protocol, a > compelling argument needs to be made for the need of such an activity. Hari > and Venkat have made their case that this is a real problem and I'm looking > to the mail list for validation that the problem merits further definition > and the proposals merit further development by this working group. > --aaron Put me down for "yes, it is a real problem, and worth discussing/solving". I am not quite sure if a new protocol is required, but if we don't thoroughly discuss, how will we decide? we need to see the trade-offs. -- Michael Orr orr@iname.com From owner-pilc@lerc.nasa.gov Thu Mar 9 10:01:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29200 for ; Thu, 9 Mar 2000 10:01:00 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA10252 for pilc-outgoing; Thu, 9 Mar 2000 08:59:33 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA10222 for ; Thu, 9 Mar 2000 08:59:30 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA12003; Thu, 9 Mar 2000 08:59:28 -0500 (EST) Received: from mgate-01.teledesic.com(216.190.22.41) by seraph3.lerc.nasa.gov via smap (V5.0) id xma011894; Thu, 9 Mar 00 08:59:25 -0500 Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2448.0) id <1MHV45RM>; Thu, 9 Mar 2000 05:55:50 -0800 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE07B8134@tdmail2.teledesic.com> From: Marie-Jose Montpetit To: "'karn@qualcomm.com'" Cc: dan@dma.isg.mot.com, afalk@PanAmSat.com, pilc@grc.nasa.gov Subject: RE: Draft on Advice for Internet Subnetwork Designers Date: Thu, 9 Mar 2000 05:48:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-pilc@lerc.nasa.gov Precedence: bulk If we start from the premise that the equipment that is connected to the subnetwork is unaware of the particularities of the subnetwork, which I think is usually the case, then it is an issue for the designer. Marie-Jose > -----Original Message----- > From: Phil Karn [SMTP:karn@ka9q.ampr.org] > Sent: Thursday, March 09, 2000 12:18 AM > To: marie@teledesic.com > Cc: dan@dma.isg.mot.com; afalk@PanAmSat.com; pilc@grc.nasa.gov > Subject: Re: Draft on Advice for Internet Subnetwork Designers > > >On the topic of packet discard especially on those subnet where capacity > is > >expensive or limited I would add that when possible packets marked form > >another subnet should be discarded before transmission on the link. > > Is this an issue for the subnetwork designer, or for the router that > drives the subnetwork? > > Phil From owner-pilc@lerc.nasa.gov Thu Mar 9 13:58:45 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16342 for ; Thu, 9 Mar 2000 13:58:43 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA14786 for pilc-outgoing; Thu, 9 Mar 2000 12:40:22 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA14761 for ; Thu, 9 Mar 2000 12:40:17 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA13580; Thu, 9 Mar 2000 12:40:16 -0500 (EST) Received: from dirty.research.bell-labs.com(204.178.16.6) by seraph3.lerc.nasa.gov via smap (V5.0) id xma013565; Thu, 9 Mar 00 12:40:03 -0500 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Mar 9 12:38:55 EST 2000 Received: from lucent.com (ex-vpn66.pa.bell-labs.com [135.250.1.66]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA03203; Thu, 9 Mar 2000 12:38:45 -0500 (EST) Message-ID: <38C7E240.F06A0126@lucent.com> Date: Thu, 09 Mar 2000 09:41:20 -0800 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Marie-Jose Montpetit CC: "'karn@qualcomm.com'" , pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <25D0C66E6D25D311B2AC0008C7913EE07B8134@tdmail2.teledesic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit marie-jose, not in this case. it is a design decision for the router, not the link. think ISSLL, IP-ATM, etc, etc.... the IP to link layer driver is where we implement particular rules for mapping certain types of (marked) IP packets onto links, subsets of links, or /dev/null. cheers, gja Marie-Jose Montpetit wrote: > > If we start from the premise that the equipment that is connected to the > subnetwork is unaware of the particularities of the subnetwork, which I > think is usually the case, then it is an issue for the designer. > > Marie-Jose > > > -----Original Message----- > > From: Phil Karn [SMTP:karn@ka9q.ampr.org] > > Sent: Thursday, March 09, 2000 12:18 AM > > To: marie@teledesic.com > > Cc: dan@dma.isg.mot.com; afalk@PanAmSat.com; pilc@grc.nasa.gov > > Subject: Re: Draft on Advice for Internet Subnetwork Designers > > > > >On the topic of packet discard especially on those subnet where capacity > > is > > >expensive or limited I would add that when possible packets marked form > > >another subnet should be discarded before transmission on the link. > > > > Is this an issue for the subnetwork designer, or for the router that > > drives the subnetwork? > > > > Phil -- ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs Research Silicon Valley From owner-pilc@lerc.nasa.gov Thu Mar 9 13:58:49 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16382 for ; Thu, 9 Mar 2000 13:58:47 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA16223 for pilc-outgoing; Thu, 9 Mar 2000 12:50:51 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA16201 for ; Thu, 9 Mar 2000 12:50:48 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA14888; Thu, 9 Mar 2000 12:50:47 -0500 (EST) Received: from crufty.research.bell-labs.com(204.178.16.49) by seraph3.lerc.nasa.gov via smap (V5.0) id xma014852; Thu, 9 Mar 00 12:50:04 -0500 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Mar 9 12:48:31 EST 2000 Received: from lucent.com (ex-vpn66.pa.bell-labs.com [135.250.1.66]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA03394; Thu, 9 Mar 2000 12:48:26 -0500 (EST) Message-ID: <38C7E485.108379DD@lucent.com> Date: Thu, 09 Mar 2000 09:51:01 -0800 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Marie-Jose Montpetit CC: "'karn@qualcomm.com'" , pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <25D0C66E6D25D311B2AC0008C7913EE07B813F@tdmail2.teledesic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit okay. i see the adaptation as part of the router, so perhaps we're in agreement. gja Marie-Jose Montpetit wrote: > > Agreed it is not the "link" as we could understand it in the case of > wireless for example but surely the "transport" in the subnet. What I meant > is the router should not (minimally?) be impacted. The adaptation should. > > Marie-Jose > > -----Original Message----- > From: Grenville Armitage [mailto:gja@lucent.com] > Sent: Thursday, March 09, 2000 9:41 AM > To: Marie-Jose Montpetit > Cc: 'karn@qualcomm.com'; pilc@grc.nasa.gov > Subject: Re: Draft on Advice for Internet Subnetwork Designers > > marie-jose, > > not in this case. it is a design decision for the router, not > the link. think ISSLL, IP-ATM, etc, etc.... the IP to link layer > driver is where we implement particular rules for mapping certain > types of (marked) IP packets onto links, subsets of links, or > /dev/null. > > cheers, > gja > > Marie-Jose Montpetit wrote: > > > > If we start from the premise that the equipment that is connected to the > > subnetwork is unaware of the particularities of the subnetwork, which I > > think is usually the case, then it is an issue for the designer. > > > > Marie-Jose > > > > > -----Original Message----- > > > From: Phil Karn [SMTP:karn@ka9q.ampr.org] > > > Sent: Thursday, March 09, 2000 12:18 AM > > > To: marie@teledesic.com > > > Cc: dan@dma.isg.mot.com; afalk@PanAmSat.com; pilc@grc.nasa.gov > > > Subject: Re: Draft on Advice for Internet Subnetwork Designers > > > > > > >On the topic of packet discard especially on those subnet where > capacity > > > is > > > >expensive or limited I would add that when possible packets marked form > > > >another subnet should be discarded before transmission on the link. > > > > > > Is this an issue for the subnetwork designer, or for the router that > > > drives the subnetwork? > > > > > > Phil > > -- > ________________________________________________________________________ > Grenville Armitage http://mh005.infi.net/~gja > Bell Labs Research Silicon Valley -- ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs Research Silicon Valley From owner-pilc@lerc.nasa.gov Thu Mar 9 14:33:09 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16341 for ; Thu, 9 Mar 2000 13:58:43 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA15629 for pilc-outgoing; Thu, 9 Mar 2000 12:46:17 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA15613 for ; Thu, 9 Mar 2000 12:46:16 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA14315; Thu, 9 Mar 2000 12:46:16 -0500 (EST) Received: from mgate-01.teledesic.com(216.190.22.41) by seraph3.lerc.nasa.gov via smap (V5.0) id xma014266; Thu, 9 Mar 00 12:45:51 -0500 Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2448.0) id <1MHV46FW>; Thu, 9 Mar 2000 09:42:18 -0800 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE07B813F@tdmail2.teledesic.com> From: Marie-Jose Montpetit To: "'Grenville Armitage'" Cc: "'karn@qualcomm.com'" , pilc@grc.nasa.gov Subject: RE: Draft on Advice for Internet Subnetwork Designers Date: Thu, 9 Mar 2000 09:35:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Agreed it is not the "link" as we could understand it in the case of wireless for example but surely the "transport" in the subnet. What I meant is the router should not (minimally?) be impacted. The adaptation should. Marie-Jose -----Original Message----- From: Grenville Armitage [mailto:gja@lucent.com] Sent: Thursday, March 09, 2000 9:41 AM To: Marie-Jose Montpetit Cc: 'karn@qualcomm.com'; pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers marie-jose, not in this case. it is a design decision for the router, not the link. think ISSLL, IP-ATM, etc, etc.... the IP to link layer driver is where we implement particular rules for mapping certain types of (marked) IP packets onto links, subsets of links, or /dev/null. cheers, gja Marie-Jose Montpetit wrote: > > If we start from the premise that the equipment that is connected to the > subnetwork is unaware of the particularities of the subnetwork, which I > think is usually the case, then it is an issue for the designer. > > Marie-Jose > > > -----Original Message----- > > From: Phil Karn [SMTP:karn@ka9q.ampr.org] > > Sent: Thursday, March 09, 2000 12:18 AM > > To: marie@teledesic.com > > Cc: dan@dma.isg.mot.com; afalk@PanAmSat.com; pilc@grc.nasa.gov > > Subject: Re: Draft on Advice for Internet Subnetwork Designers > > > > >On the topic of packet discard especially on those subnet where capacity > > is > > >expensive or limited I would add that when possible packets marked form > > >another subnet should be discarded before transmission on the link. > > > > Is this an issue for the subnetwork designer, or for the router that > > drives the subnetwork? > > > > Phil -- ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs Research Silicon Valley From owner-pilc@lerc.nasa.gov Thu Mar 9 19:18:11 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17667 for ; Thu, 9 Mar 2000 19:18:10 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA01135 for pilc-outgoing; Thu, 9 Mar 2000 18:08:25 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA01124 for ; Thu, 9 Mar 2000 18:08:23 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA29849; Thu, 9 Mar 2000 18:08:22 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma029809; Thu, 9 Mar 00 18:07:55 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id PAA09751; Thu, 9 Mar 2000 15:07:40 -0800 Date: Thu, 9 Mar 2000 15:07:40 -0800 Message-Id: <200003092307.PAA09751@homer.ka9q.ampr.org> From: Phil Karn To: vjs@calcite.rhyolite.com CC: pilc@grc.nasa.gov In-reply-to: <200003081240.FAA14424@calcite.rhyolite.com> (message from Vernon Schryver on Wed, 8 Mar 2000 05:40:10 -0700 (MST)) Subject: Re: Kicking TCP Reply-to: karn@qualcomm.com References: <200003081240.FAA14424@calcite.rhyolite.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >How does that differ from what a reasonable demand dialing PPP >implementation does the link goes down unexpected, whether because the >peer took it down or the modems (or ISDN line etc.) hiccuped? A reasonable >PPP implementation queues the most recent N (for some reasonable N>0, but >N>typical window/negotiated MTU is good) and sends them when it can (the >link comes up or back up). A PPP implementation that does not do this >queuing is a pain to use (or so I think), because it loses the traffic >that caused it to demand dial. Unfortunately, many demand dialing PPP >implementations are unreasonable by this criterion. My suggestion really doesn't differ, so perhaps all I need to do is to insert language into the LINK draft that says essentially this. Phil From owner-pilc@lerc.nasa.gov Thu Mar 9 19:20:16 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18288 for ; Thu, 9 Mar 2000 19:20:15 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA02087 for pilc-outgoing; Thu, 9 Mar 2000 18:22:39 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA02081 for ; Thu, 9 Mar 2000 18:22:38 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA01525; Thu, 9 Mar 2000 18:22:37 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma001514; Thu, 9 Mar 00 18:22:06 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id PAA09774; Thu, 9 Mar 2000 15:22:02 -0800 Date: Thu, 9 Mar 2000 15:22:02 -0800 Message-Id: <200003092322.PAA09774@homer.ka9q.ampr.org> From: Phil Karn To: Reiner.Ludwig@eed.ericsson.se CC: pilc@grc.nasa.gov In-reply-to: <4.2.0.58.20000308155004.00c34220@chapelle.ericsson.se> (message from Reiner Ludwig on Wed, 08 Mar 2000 16:48:37 +0100) Subject: Re: Why we don't need ICMP SE? (was Re: Kicking TCP) Reply-to: karn@qualcomm.com References: <4.2.0.58.20000308155004.00c34220@chapelle.ericsson.se> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >If you do this at the link layer instead of the network layer you are free >to queue more than just a single packet, e.g., you can queue the entire >flight of packets belonging to a TCP flow if resources allow for that. In Well, I guess you could but I wouldn't want a short outage to result in a lot of duplicate packets spewing out over the link after the link comes back up. Seems to me you're better off holding onto just the last packet or two per flow. >Agree. However, I would leave it open whether this approach is implemented >at the router level (only buffering a single packet) or the link layer. It I agree with this too. >should also be mentioned that no packet should be buffered longer than the >Maximum Segment Lifetime (MSL), i.e., 240 seconds, at most. Is the MSL a real thing, or is it just a fiction? In either case, I see no need to hold onto any packet for longer than the sending TCP's likely retransmission interval -- except for the very last packet whose purpose is more to notify TCP that the channel is back up than to avoid a retransmission. But since the subnet doesn't have any way to know what TCP's retransmission timeout is, you have to make a guess. >>Note that this gives nearly all of the benefits claimed for totally >>reliable link layer protocols with much less effort. >Don't agree. With the router level approach you need to change router >implementation (deployment concern!). The link layer approach can be >designed into upcoming wireless systems. Okay, I didn't mean to distinguish between a router implementation and a link implementation of the "hold the last packet" technique, and I'll try to explain in the draft that either is OK. >layer. I.e., highly persistent link layer error recovery (limited to the >class of reliable flows to avoid head-of-line blocking for delay-sensitive >flows) does not provide a reliability guarantee but is also merely a >performance enhancement. Exactly. In this case, the performance enhancement is to get TCP going again more quickly after the link recovers. Phil From owner-pilc@lerc.nasa.gov Thu Mar 9 19:24:49 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19643 for ; Thu, 9 Mar 2000 19:24:47 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA02558 for pilc-outgoing; Thu, 9 Mar 2000 18:29:25 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA02524 for ; Thu, 9 Mar 2000 18:29:23 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA02293; Thu, 9 Mar 2000 18:29:22 -0500 (EST) Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma002272; Thu, 9 Mar 00 18:29:05 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id QAA22998 for pilc@grc.nasa.gov env-from ; Thu, 9 Mar 2000 16:29:03 -0700 (MST) Date: Thu, 9 Mar 2000 16:29:03 -0700 (MST) From: Vernon Schryver Message-Id: <200003092329.QAA22998@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: Kicking TCP Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Phil Karn > >How does that differ from what a reasonable demand dialing PPP > >implementation does the link goes down unexpected, whether because the > >peer took it down or the modems (or ISDN line etc.) hiccuped? A reasonable > >PPP implementation queues the most recent N (for some reasonable N>0, but > >N>typical window/negotiated MTU is good) ... > My suggestion really doesn't differ, so perhaps all I need to do is > to insert language into the LINK draft that says essentially this. Regardless of whether there might be a new ICMP kick TCP type, I think the LINK draft should say something like that. PPP implementations that don't queue traffic when they know the link is sick are even more common than they are lame, and they're awfully lame. Another way they're lame that I haven't mentioned lately is what happens when you try to start a TCP connection that requires DNS answers. The initial UDP packet will wake up your demand dialed link, but if your PPP code is stupid and discards instead of queuing it, you'll be sitting waiting a long time after a PPP/ISDN link is up for your DNS resolver to time out and retry. Isn't the DNS timeout 30 seconds? An ISDN link comes up in 2-5 seconds and a slow v.32bis modem needs only ~28 seconds. However, someone privately pointed out that there is a difference between reasonable queuing and something like an ICMP kick TCP message when the queuing drops the newest instead of oldest traffic and when the queue is smaller than the traffic while the link is ill. If the queue overflows and new traffic is discarded, TCP will suffer a time out. The old queued traffic should kick TCP enough to shorten the timeout, but the result won't be as quick the result of dropping the newest packets. Worse, if there are lots of streams and a tiny queue, some TCP connections might not be kicked at all. Still, I think reasonable queuing is close enough and needed regardless. There is no need for a new ICMP kick TCP type, not to mention novel interpretations of Redirects, new UDP messages, or other things. Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Thu Mar 9 19:28:13 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20662 for ; Thu, 9 Mar 2000 19:28:11 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA02276 for pilc-outgoing; Thu, 9 Mar 2000 18:25:40 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA02258 for ; Thu, 9 Mar 2000 18:25:38 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA01912; Thu, 9 Mar 2000 18:25:37 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma001893; Thu, 9 Mar 00 18:25:04 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id PAA09777; Thu, 9 Mar 2000 15:25:00 -0800 Date: Thu, 9 Mar 2000 15:25:00 -0800 Message-Id: <200003092325.PAA09777@homer.ka9q.ampr.org> From: Phil Karn To: vjs@calcite.rhyolite.com CC: pilc@grc.nasa.gov In-reply-to: <200003081537.IAA18001@calcite.rhyolite.com> (message from Vernon Schryver on Wed, 8 Mar 2000 08:37:17 -0700 (MST)) Subject: Re: Kicking TCP Reply-to: karn@qualcomm.com References: <200003081537.IAA18001@calcite.rhyolite.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > 1. have the link layer tell the TCP state machines to retransmit any > unacknowledged TCP bytes by forcing their retransmission timers > to zero? This is a layering violation, but I trust most of us > are Sunday-only worshipers in that religion. It's more than a technical layering violation, because how would you do it if the TCP and the link layer are on separate machines? You'd need to define some communication mechanism, which was the intent of my ICMP SE message. > 2. do what is common (albeit not common enough) and reasonable in in PPP > implementations, which is to have a reasonable sized transmit queue > ( > typical window/MTU), and only send packets when the link seems > healthy? Don't you need such a queue to deal with bursts, so that the > only modification would be to not drop IP packets when the link is > broken, as is typical in link layer drivers, including Ethernet, FDDI, > and 802.5? Again, I agree. I will add text that encourages the subnetwork designer to use any internal information it may have about the state of the link or subnetwork to block the acceptance of IP packets if it is clear that those packets would be dropped, and to hold onto the most recent packets that it may have accepted before the link/subnet went down and to try to deliver them after the link/subnet comes back up. Phil From owner-pilc@lerc.nasa.gov Thu Mar 9 19:45:18 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26647 for ; Thu, 9 Mar 2000 19:45:17 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA03742 for pilc-outgoing; Thu, 9 Mar 2000 18:48:10 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA03718 for ; Thu, 9 Mar 2000 18:48:08 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA04157; Thu, 9 Mar 2000 18:48:07 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma004120; Thu, 9 Mar 00 18:47:24 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id PAA09789; Thu, 9 Mar 2000 15:47:12 -0800 Date: Thu, 9 Mar 2000 15:47:12 -0800 Message-Id: <200003092347.PAA09789@homer.ka9q.ampr.org> From: Phil Karn To: cannara@attglobal.net CC: pilc@grc.nasa.gov In-reply-to: <38C69427.927B0842@attglobal.net> (message from Cannara on Wed, 08 Mar 2000 09:55:51 -0800) Subject: Re: Draft on Advice for Internet Subnetwork Designers Reply-to: karn@qualcomm.com References: <200003062158.QAA18917@noah.dma.isg.mot.com> <200003080828.AAA27974@homer.ka9q.ampr.org> <38C69427.927B0842@attglobal.net> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >FYI, a related suggestion was for IP to communicate info TCP could use by >passing up the IP ID (v4) via TCP's Urgent Pointer (with URG bit off) and the >receiving TCP would so get the ID of the packet sent, then return that ID when >it Acked that pkt. The sender keeps a list of IDs vs TCP pkts and then knows Ugh, what a layer-violating hack! I think a better way already exists to deal with the false retransmission problem: TCP header timestamps. Phil From owner-pilc@lerc.nasa.gov Thu Mar 9 19:45:48 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26805 for ; Thu, 9 Mar 2000 19:45:46 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA03756 for pilc-outgoing; Thu, 9 Mar 2000 18:48:53 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA03745 for ; Thu, 9 Mar 2000 18:48:52 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA04190; Thu, 9 Mar 2000 18:48:52 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma004184; Thu, 9 Mar 00 18:48:47 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id PAA09794; Thu, 9 Mar 2000 15:48:46 -0800 Date: Thu, 9 Mar 2000 15:48:46 -0800 Message-Id: <200003092348.PAA09794@homer.ka9q.ampr.org> From: Phil Karn To: touch@ISI.EDU CC: pilc@grc.nasa.gov In-reply-to: <38C6994A.2216D26D@isi.edu> (message from Joe Touch on Wed, 08 Mar 2000 10:17:46 -0800) Subject: Re: Draft on Advice for Internet Subnetwork Designers Reply-to: karn@qualcomm.com References: <8046A317B5F4D21186610008C7EBB696F055EE@grnexch1.panamsat.com> <38BA7E19.CB9D89B1@erg.abdn.ac.uk> <200003080900.BAA28435@homer.ka9q.ampr.org> <38C6994A.2216D26D@isi.edu> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >A useful point may be "don't assume the MTU at all anymore," i.e., it >might be worthwhile to have designers of links _and_ upper protocols >both drop such preconceptions they have about the link. That's a good idea. Not only does tunneling mess up assumptions about MTUs and the distribution of packet sizes, but so do the newer TCP header options (timestamps, etc). phil From owner-pilc@lerc.nasa.gov Thu Mar 9 19:47:40 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27400 for ; Thu, 9 Mar 2000 19:47:39 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA04296 for pilc-outgoing; Thu, 9 Mar 2000 18:56:26 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA04265 for ; Thu, 9 Mar 2000 18:56:24 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA05108; Thu, 9 Mar 2000 18:56:23 -0500 (EST) Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma005048; Thu, 9 Mar 00 18:55:48 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id QAA23348 for pilc@grc.nasa.gov env-from ; Thu, 9 Mar 2000 16:55:44 -0700 (MST) Date: Thu, 9 Mar 2000 16:55:44 -0700 (MST) From: Vernon Schryver Message-Id: <200003092355.QAA23348@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: Kicking TCP Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Phil Karn > ... > > 1. have the link layer tell the TCP state machines to retransmit any > > unacknowledged TCP bytes by forcing their retransmission timers > > to zero? ... > It's more than a technical layering violation, because how would > you do it if the TCP and the link layer are on separate machines? > You'd need to define some communication mechanism, which was the > intent of my ICMP SE message. Yes, but in many cases (e.g. mobile phones) the host and the router are pretty close to each other. But I agree that reasonable queuing next to the link is far better. > ... > Again, I agree. I will add text that encourages the subnetwork designer > to use any internal information it may have about the state of the > link or subnetwork to block the acceptance of IP packets if it is clear > that those packets would be dropped, and to hold onto the most recent > packets that it may have accepted before the link/subnet went down > and to try to deliver them after the link/subnet comes back up. That sound great. Something I forget to mention in my previous note is that private cooresondent pointed out that RED and other fancy queuing disciplines tend to encourage dropping the most recent instead oldest packets. Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Thu Mar 9 19:49:05 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27871 for ; Thu, 9 Mar 2000 19:49:03 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA03566 for pilc-outgoing; Thu, 9 Mar 2000 18:45:55 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA03556 for ; Thu, 9 Mar 2000 18:45:53 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA03965; Thu, 9 Mar 2000 18:45:52 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma003945; Thu, 9 Mar 00 18:45:19 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id PAA09786; Thu, 9 Mar 2000 15:45:17 -0800 Date: Thu, 9 Mar 2000 15:45:17 -0800 Message-Id: <200003092345.PAA09786@homer.ka9q.ampr.org> From: Phil Karn To: touch@ISI.EDU CC: pilc@grc.nasa.gov In-reply-to: <38C6977F.35048669@isi.edu> (message from Joe Touch on Wed, 08 Mar 2000 10:10:07 -0800) Subject: Re: Draft on Advice for Internet Subnetwork Designers Reply-to: karn@qualcomm.com References: <200003081340.IAA15226@noah.dma.isg.mot.com> <38C6977F.35048669@isi.edu> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Okay, here's the current wording of the end-to-end principle section. Any more comments? --Phil A major consideration in the efficient design of any layered communication network are the appropriate layer(s) in which to implement a given feature. This issue was first addressed in the seminal paper "End-to-End Arguments in System Design" [SRC81]. This paper argued that many functions can be implemented properly *only* on an end-to-end basis, i.e., at the higher protocol layers, outside the subnetwork. These functions include ensuring the reliable delivery of data and the protection of information through cryptography. Duplicating these functions at the lower protocol layers (i.e., within the subnetwork) can be needlessly redundant or even harmful to cost and performance. However, partial duplication of functionality in a lower layer can *sometimes* be justified by performance, security or availability considerations. Examples include link layer retransmission on an unusually lossy channel, e.g., mobile radio; link level encryption intended to thwart traffic analysis; and redundant transmission links to improve availability. Duplication of protocol function should be done only with an understanding of system level implications, including possible interactions with higher layer mechanisms. From owner-pilc@lerc.nasa.gov Thu Mar 9 21:30:44 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27542 for ; Thu, 9 Mar 2000 21:30:44 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA10189 for pilc-outgoing; Thu, 9 Mar 2000 20:39:55 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAA10181 for ; Thu, 9 Mar 2000 20:39:54 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id UAA15306; Thu, 9 Mar 2000 20:39:53 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma015295; Thu, 9 Mar 00 20:39:26 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id RAA09976; Thu, 9 Mar 2000 17:39:23 -0800 Date: Thu, 9 Mar 2000 17:39:23 -0800 Message-Id: <200003100139.RAA09976@homer.ka9q.ampr.org> From: Phil Karn To: pilc@grc.nasa.gov, iab-wireless-workshop@ietf.org Subject: Wording for "Recovery from Subnetwork Outages" Reply-to: karn@ka9q.ampr.org Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Here's the text I just wrote for the PILC LINK document that discusses subnetwork mechanisms that could speed up TCP's recovery from a temporary subnetwork outage. I put it in a new section titled "Recovery from Subnetwork Outages". This is the "implicit" alternative to the ICMP Source Encourage message that I discussed earlier. --Phil Some types of subnetworks, particularly mobile radio, are subject to frequent temporary outages. For example, an active cellular data user may drive or walk into an area (such as a tunnel) that is out of range of any base station. No packets will be successfully delivered until the user returns to an area with coverage. The Internet protocols currently provide no way for a subnetwork to explicitly notify an upper layer protocol (e.g., TCP) that it is experiencing an outage, as distinguished from severe congestion. Under these circumstances TCP will, after each unsuccessful retransmission, wait even longer before trying again; this is its "exponential backoff" algorithm. And since there is also currently no way for a subnetwork to explicitly notify TCP when it is again operational, TCP will not discover this until its next retransmission attempt. If TCP has backed off, this may take some time. This can lead to extremely poor TCP performance over such subnetworks. It is therefore highly desirable that a subnetwork subject to outages not silently discard packets during an outage. Ideally, it should define an interface to the next higher layer (i.e., IP) that allows it to refuse packets during an outage, and to automatically ask IP for new packets when it is again able to deliver them. If it cannot do this, then the subnetwork should hold onto at least some of the packets it accepts during an outage and attempt to deliver them when the subnetwork comes back up. Note that it is *not* necessary to avoid any and all packet drops during an outage. The purpose of holding onto a packet during an outage, either in the subnetwork or at the IP layer, is so that its eventual delivery can implicitly notify TCP that the subnetwork is again operational. This is to enhance performance, not to ensure reliability -- a task that as discussed earlier can only be done properly on an end-to-end basis. Only a single packet per TCP connection need be held in this way; subsequent packets can either replace the existing packet, or they can be discarded. Either way, TCP will quickly recover from these additional losses once the flow resumes. Because it would be a layering violation for IP or a subnetwork to look at the TCP headers of the packets it carries (which would in any event be impossible if IPSEC encryption is in use), it would be reasonable for the IP or subnetwork layers to choose, as a design parameter, some small number of packets that it will retain during an outage. From owner-pilc@lerc.nasa.gov Thu Mar 9 23:43:09 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13662 for ; Thu, 9 Mar 2000 23:43:09 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA16637 for pilc-outgoing; Thu, 9 Mar 2000 22:42:11 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA16610 for ; Thu, 9 Mar 2000 22:42:08 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id WAA25763; Thu, 9 Mar 2000 22:42:08 -0500 (EST) Received: from out5.prserv.net(32.97.166.35) by seraph3.lerc.nasa.gov via smap (V5.0) id xma025727; Thu, 9 Mar 00 22:41:24 -0500 Received: from attglobal.net ([129.37.21.172]) by prserv.net (out5) with SMTP id <200003100341122430327ak6e>; Fri, 10 Mar 2000 03:41:13 +0000 Message-ID: <38C86EAD.4F961B9F@attglobal.net> Date: Thu, 09 Mar 2000 19:40:29 -0800 From: Cannara Reply-To: cannara@attglobal.net X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <200003062158.QAA18917@noah.dma.isg.mot.com> <200003080828.AAA27974@homer.ka9q.ampr.org> <38C69427.927B0842@attglobal.net> <200003092347.PAA09789@homer.ka9q.ampr.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Phil, this wasn't suggested as a "thing to do", but an illustration of what could be done, even just experimentally or by simulation, to demonstrate the utility of addressing TCP's blind side. If timestamps can be trusted, then maybe that's a way. In any case, considerable performance in real situations is sacrificed because we've gone years without taking significant action to help TCP avoid making costly mistakes. "Ugh" is indeed the right word for those behaviors. Alex Phil Karn wrote: > > >FYI, a related suggestion was for IP to communicate info TCP could use by > >passing up the IP ID (v4) via TCP's Urgent Pointer (with URG bit off) and the > >receiving TCP would so get the ID of the packet sent, then return that ID when > >it Acked that pkt. The sender keeps a list of IDs vs TCP pkts and then knows > > Ugh, what a layer-violating hack! I think a better way already exists > to deal with the false retransmission problem: TCP header timestamps. > > Phil From owner-pilc@lerc.nasa.gov Thu Mar 9 23:43:14 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13686 for ; Thu, 9 Mar 2000 23:43:13 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA16849 for pilc-outgoing; Thu, 9 Mar 2000 22:45:55 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA16843 for ; Thu, 9 Mar 2000 22:45:54 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id WAA26052; Thu, 9 Mar 2000 22:45:53 -0500 (EST) Received: from out5.prserv.net(32.97.166.35) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026044; Thu, 9 Mar 00 22:45:31 -0500 Received: from attglobal.net ([129.37.21.172]) by prserv.net (out5) with SMTP id <2000031003451924301msqafe>; Fri, 10 Mar 2000 03:45:19 +0000 Message-ID: <38C86F9E.3F8BD601@attglobal.net> Date: Thu, 09 Mar 2000 19:44:30 -0800 From: Cannara Reply-To: cannara@attglobal.net X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <200003081340.IAA15226@noah.dma.isg.mot.com> <38C6977F.35048669@isi.edu> <200003092345.PAA09786@homer.ka9q.ampr.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Sounds good Phil, and I'd add something a bit stronger in relation to higher-layers that, in fact, are not fully capable of offering reliability and performance under circumstances that the lower layers can do better on. This relates to the problems TCP has with noncongestive loss, etc. Alex Phil Karn wrote: > > Okay, here's the current wording of the end-to-end principle section. > Any more comments? --Phil > > A major consideration in the efficient design of any layered > communication network are the appropriate layer(s) in which to > implement a given feature. This issue was first addressed in the > seminal paper "End-to-End Arguments in System Design" [SRC81]. This > paper argued that many functions can be implemented properly *only* on > an end-to-end basis, i.e., at the higher protocol layers, outside the > subnetwork. These functions include ensuring the reliable delivery of > data and the protection of information through cryptography. > Duplicating these functions at the lower protocol layers (i.e., within > the subnetwork) can be needlessly redundant or even harmful to cost > and performance. > > However, partial duplication of functionality in a lower layer > can *sometimes* be justified by performance, security or availability > considerations. Examples include link layer retransmission on an > unusually lossy channel, e.g., mobile radio; link level encryption > intended to thwart traffic analysis; and redundant transmission links > to improve availability. Duplication of protocol function should be done only > with an understanding of system level implications, including possible > interactions with higher layer mechanisms. From owner-pilc@lerc.nasa.gov Fri Mar 10 02:36:27 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17416 for ; Fri, 10 Mar 2000 02:36:26 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA23946 for pilc-outgoing; Fri, 10 Mar 2000 01:21:12 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA23937 for ; Fri, 10 Mar 2000 01:21:10 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id BAA08682; Fri, 10 Mar 2000 01:21:09 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma008654; Fri, 10 Mar 00 01:20:59 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id WAA10795; Thu, 9 Mar 2000 22:20:55 -0800 Date: Thu, 9 Mar 2000 22:20:55 -0800 Message-Id: <200003100620.WAA10795@homer.ka9q.ampr.org> From: Phil Karn To: vjs@calcite.rhyolite.com CC: pilc@grc.nasa.gov In-reply-to: <200003092355.QAA23348@calcite.rhyolite.com> (message from Vernon Schryver on Thu, 9 Mar 2000 16:55:44 -0700 (MST)) Subject: Re: Kicking TCP Reply-to: karn@qualcomm.com References: <200003092355.QAA23348@calcite.rhyolite.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >Something I forget to mention in my previous note is that private >cooresondent pointed out that RED and other fancy queuing disciplines >tend to encourage dropping the most recent instead oldest packets. Did you mean to say that? Before RED, the usual scheme was to drop all new packets when the queue filled up. With RED, you pick a packet at random from the queue, so the older packets can get dropped too. It seems to me that simply implementing RED in the IP router that drives a link subject to outages will pretty much implement my suggestion as long as the subnet doesn't take anything out of the IP send queue as long as its down. During the outage, RED will continue to manage the IP queue as new packets arrive. When the outage is over, the survivors on the queue will be sent. Hopefully that will include at least one packet per pending TCP connection. Fortunately, most "flaky links" rarely carry more than one active TCP connection at a time, so this should usually be the case. Phil From owner-pilc@lerc.nasa.gov Fri Mar 10 02:53:42 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17415 for ; Fri, 10 Mar 2000 02:36:26 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA25309 for pilc-outgoing; Fri, 10 Mar 2000 01:40:40 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA25304 for ; Fri, 10 Mar 2000 01:40:39 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id BAA10165; Fri, 10 Mar 2000 01:40:39 -0500 (EST) Received: from dirty.research.bell-labs.com(204.178.16.6) by seraph3.lerc.nasa.gov via smap (V5.0) id xma010160; Fri, 10 Mar 00 01:40:22 -0500 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Mar 10 01:39:00 EST 2000 Received: from lucent.com (ex-vpn66.pa.bell-labs.com [135.250.1.66]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id BAA20318; Fri, 10 Mar 2000 01:38:51 -0500 (EST) Message-ID: <38C89917.5809496E@lucent.com> Date: Thu, 09 Mar 2000 22:41:27 -0800 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: karn@qualcomm.com CC: vjs@calcite.rhyolite.com, pilc@grc.nasa.gov Subject: Re: Kicking TCP References: <200003092355.QAA23348@calcite.rhyolite.com> <200003100620.WAA10795@homer.ka9q.ampr.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Phil Karn wrote: > > >Something I forget to mention in my previous note is that private > >cooresondent pointed out that RED and other fancy queuing disciplines > >tend to encourage dropping the most recent instead oldest packets. > > Did you mean to say that? Before RED, the usual scheme was to drop all > new packets when the queue filled up. With RED, you pick a packet at > random from the queue, so the older packets can get dropped too. Not exactly - RED just randomizes the drop/insert decision made by the queue manager for a newly arrived packet. To the best of my knowledge, there's nothing inherent in the RED scheme that requires randomly choosing a packet currently *in* the queue for dropping. (A minor optimization is to use the arrival of a new packet to trigger a random decision to drop from front...) But that's an aside - the observation that queues have enough space to hold a windows worth of packets from the active flows (either because the queue is big, or the number of flows is small) makes the issue moot wrt kicking TCP. cheers, the-private-correspondent :) From owner-pilc@lerc.nasa.gov Fri Mar 10 03:24:55 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02598 for ; Fri, 10 Mar 2000 03:24:48 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA27299 for pilc-outgoing; Fri, 10 Mar 2000 02:29:28 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA27292 for ; Fri, 10 Mar 2000 02:29:27 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA14088; Fri, 10 Mar 2000 02:29:27 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma014063; Fri, 10 Mar 00 02:29:00 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id XAA11823; Thu, 9 Mar 2000 23:28:59 -0800 Date: Thu, 9 Mar 2000 23:28:59 -0800 Message-Id: <200003100728.XAA11823@homer.ka9q.ampr.org> From: Phil Karn To: pilc@grc.nasa.gov Subject: CRCs, Checksums and Error Detection Reply-to: karn@qualcomm.com Sender: owner-pilc@lerc.nasa.gov Precedence: bulk I just added this section in the "Reliability and Error Control" section. I will keep editing the LINK document, adding new text and comments as I get them, until tomorrow when I will send a snapshot to the ID editor with enough time to make the deadline... --Phil The TCP, UDP and IP protocols all use a simple 16-bit 1's complement checksum algorithm to detect corrupted packets. The IP checksum protects only the IP header, while the TCP and UDP checksums protect both the TCP/UDP header and any user data. In TCP the checksum is mandatory while it is optional in UDP. These checksums are not very strong from a coding theory standpoint. But they are easy to compute in software, and various proposals to replace them with stronger checksums have failed. Experience has shown that nearly all subnetworks that carry the Internet protocols have a very low undetected error rate, so the existing Internet checksums are rarely called upon to catch an error. Most of the errors caught by the Internet checksum are generally the result of hardware or software failure than of a subnetwork transmission error. This lowers the motivation to overcome the performance and especially the backward compatibility problems of a new, stronger Internet checksum. The typical IP subnetwork implements an internal error detection code that discards packets failing this check instead of delivering them to the IP layer. A 16-bit cyclic redundancy check (CRC) is usually the minimum, and this is known to be considerably stronger than the 16-bit standard Internet checksum. The Point-to-Point Protocol (PPP) uses a 16-bit CRC, often in conjunction with the V.42bis error control provided in a typical dialup modem. 802.3/Ethernet uses a 32-bit CRC that is considerably stronger, and many subnetworks (notably dialup modem, mobile radio and satellite) also incorporate forward error correction, often in hardware. Any new subnetwork designed to carry IP should therefore provide error detection at least as strong as a 16-bit CRC and preferably stronger. Note that while this will achieve a very low undetected packet error rate, this will not (and need not) achieve a very low packet loss rate as the Internet protocols are better suited to dealing with lost packets than with corrupted packets. From owner-pilc@lerc.nasa.gov Fri Mar 10 07:54:57 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28973 for ; Fri, 10 Mar 2000 07:54:56 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA09049 for pilc-outgoing; Fri, 10 Mar 2000 06:50:29 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id GAA09037 for ; Fri, 10 Mar 2000 06:50:27 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA02367; Fri, 10 Mar 2000 06:50:27 -0500 (EST) Received: from clavin.cs.tamu.edu(128.194.130.106) by seraph3.lerc.nasa.gov via smap (V5.0) id xma002300; Fri, 10 Mar 00 06:49:47 -0500 Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id FAA22503; Fri, 10 Mar 2000 05:49:41 -0600 (CST) From: Nitin H Vaidya Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.9.3/8.9.3) id FAA26889; Fri, 10 Mar 2000 05:49:14 -0600 (CST) Date: Fri, 10 Mar 2000 05:49:14 -0600 (CST) Message-Id: <200003101149.FAA26889@sun.cs.tamu.edu> To: karn@ka9q.ampr.org, pilc@grc.nasa.gov Subject: Re: Wording for "Recovery from Subnetwork Outages" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Phil: >> Only a single packet per TCP connection need be held in this way; >> subsequent packets can either replace the existing packet, or they can >> be discarded. Either way, TCP will quickly recover from these >> additional losses once the flow resumes. One implication of the above statement -- in the case when a single packet is held -- would be that it can be *any* single packet, not necessarily the earliest one. Why is that enough to kickstart TCP? One out-of-order (data) packet will trigger one dupack. Not enough to result in a fast retransmit. Unless something else is modified, if only packet is going to be held, it should be the earliest data packet. On reverse path, it is OK to hold any one TCP ACK due to the cummulative nature. On the forward path, if the earliest data packet is dropped, then need to hold at least three other data packets, not just one, to result in fast retransmit, instead of a (long) wait for timeout. Am I missing something? ... it is rather early Friday morning for me, and hopefully, I can be forgiven in that case -:) Assuming I am sufficiently awake ... Preferential drop-from-front is better for * TCP ACKs in all cases (errors or congstion) * TCP Data when packets must be dropped due to congestion, (but not necessarily in case of errors). Of course, if TCP sender was earlier informed that the channel is dead, then even one dupack would be enough to kickstart the sender. Cheerio. - nitin From owner-pilc@lerc.nasa.gov Fri Mar 10 09:41:22 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05471 for ; Fri, 10 Mar 2000 09:41:21 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA21143 for pilc-outgoing; Fri, 10 Mar 2000 08:49:05 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA21104 for ; Fri, 10 Mar 2000 08:49:01 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA13497; Fri, 10 Mar 2000 08:49:00 -0500 (EST) Received: from porsta.cs.helsinki.fi(128.214.48.124) by seraph3.lerc.nasa.gov via smap (V5.0) id xma013467; Fri, 10 Mar 00 08:48:38 -0500 Received: from kaloure.cs.Helsinki.FI (kojo@kaloure.cs.Helsinki.FI [128.214.9.79]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id PAA01995; Fri, 10 Mar 2000 15:48:22 +0200 Date: Fri, 10 Mar 2000 15:48:27 +0200 (EET) From: Markku Kojo To: karn@qualcomm.com cc: vjs@calcite.rhyolite.com, pilc@grc.nasa.gov Subject: Re: Kicking TCP In-Reply-To: <200003092307.PAA09751@homer.ka9q.ampr.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Thu, 9 Mar 2000, Phil Karn wrote: > >How does that differ from what a reasonable demand dialing PPP > >implementation does the link goes down unexpected, whether because the > >peer took it down or the modems (or ISDN line etc.) hiccuped? A reasonable > >PPP implementation queues the most recent N (for some reasonable N>0, but > >N>typical window/negotiated MTU is good) and sends them when it can (the > >link comes up or back up). A PPP implementation that does not do this > >queuing is a pain to use (or so I think), because it loses the traffic > >that caused it to demand dial. Unfortunately, many demand dialing PPP > >implementations are unreasonable by this criterion. > > My suggestion really doesn't differ, so perhaps all I need to do is > to insert language into the LINK draft that says essentially this. Agreed. But just in case someone may interpret the statement above differently: PPP is not used on all links/subnetworks which have this problem; there are/will be number of (wireless) links having the link outage problem but which are not employing PPP. PPP is link layer to me. And, if the actual link is of "serial type" on which PPP is needed, then this is obviously best implemented in PPP, otherwise this should be addressed in the link design. Maybe this was already clear to everyone ... /Markku From owner-pilc@lerc.nasa.gov Fri Mar 10 09:49:08 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07977 for ; Fri, 10 Mar 2000 09:48:58 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA21757 for pilc-outgoing; Fri, 10 Mar 2000 08:52:51 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA21711 for ; Fri, 10 Mar 2000 08:52:47 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA14011; Fri, 10 Mar 2000 08:52:46 -0500 (EST) Received: from mgate-01.teledesic.com(216.190.22.41) by seraph3.lerc.nasa.gov via smap (V5.0) id xma013969; Fri, 10 Mar 00 08:52:16 -0500 Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2448.0) id <1MHV48XM>; Fri, 10 Mar 2000 05:48:44 -0800 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE07B815C@tdmail2.teledesic.com> From: Marie-Jose Montpetit To: "'karn@qualcomm.com'" , pilc@grc.nasa.gov Subject: RE: CRCs, Checksums and Error Detection Date: Fri, 10 Mar 2000 05:41:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-pilc@lerc.nasa.gov Precedence: bulk After the "stronger" in the last sentence maybe you want to add: "...stronger to survive cluster of errors that can happen in many subnetworks." > -----Original Message----- > From: Phil Karn [SMTP:karn@ka9q.ampr.org] > Sent: Thursday, March 09, 2000 11:29 PM > To: pilc@grc.nasa.gov > Subject: CRCs, Checksums and Error Detection > > > I just added this section in the "Reliability and Error Control" section. > I will keep editing the LINK document, adding new text and comments as > I get them, until tomorrow when I will send a snapshot to the ID editor > with enough time to make the deadline... --Phil > > The TCP, UDP and IP protocols all use a simple 16-bit 1's complement > checksum algorithm to detect corrupted packets. The IP checksum > protects only the IP header, while the TCP and UDP checksums protect > both the TCP/UDP header and any user data. In TCP the checksum is > mandatory while it is optional in UDP. > > These checksums are not very strong from a coding theory standpoint. > But they are easy to compute in software, and various proposals to > replace them with stronger checksums have failed. Experience has shown > that nearly all subnetworks that carry the Internet protocols have a > very low undetected error rate, so the existing Internet checksums are > rarely called upon to catch an error. Most of the errors caught by the > Internet checksum are generally the result of hardware or software > failure than of a subnetwork transmission error. This lowers the > motivation to overcome the performance and especially the backward > compatibility problems of a new, stronger Internet checksum. > > The typical IP subnetwork implements an internal error detection code that > discards packets failing this check instead of delivering them to > the IP layer. A 16-bit cyclic redundancy check (CRC) is usually the > minimum, and this is known to be considerably stronger than the 16-bit > standard Internet checksum. The Point-to-Point Protocol (PPP) uses a > 16-bit CRC, often in conjunction with the V.42bis error control > provided in a typical dialup modem. 802.3/Ethernet uses a 32-bit CRC > that is considerably stronger, and many subnetworks (notably dialup > modem, mobile radio and satellite) also incorporate forward error > correction, often in hardware. > > Any new subnetwork designed to carry IP should therefore provide error > detection at least as strong as a 16-bit CRC and preferably stronger. > Note that while this will achieve a very low undetected packet error > rate, this will not (and need not) achieve a very low packet loss rate > as the Internet protocols are better suited to dealing with lost > packets than with corrupted packets. From owner-pilc@lerc.nasa.gov Fri Mar 10 10:11:57 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14142 for ; Fri, 10 Mar 2000 10:11:53 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA26617 for pilc-outgoing; Fri, 10 Mar 2000 09:20:35 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA26588 for ; Fri, 10 Mar 2000 09:20:32 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA17357; Fri, 10 Mar 2000 09:20:30 -0500 (EST) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma017330; Fri, 10 Mar 00 09:20:18 -0500 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12TQGz-0002Nb-00; Fri, 10 Mar 2000 14:20:13 +0000 Date: Fri, 10 Mar 2000 14:20:04 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: karn@qualcomm.com cc: pilc@grc.nasa.gov Subject: Re: CRCs, Checksums and Error Detection In-Reply-To: <200003100728.XAA11823@homer.ka9q.ampr.org> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Thu, 9 Mar 2000, Phil Karn wrote: > The TCP, UDP and IP protocols all use a simple 16-bit 1's complement > checksum algorithm to detect corrupted packets. The IP checksum > protects only the IP header, while the TCP and UDP checksums protect > both the TCP/UDP header and any user data. In TCP the checksum is > mandatory while it is optional in UDP. Fine for v4, but needs something about IPv6's different behaviour - no IP checksum, and the UDP checksum is no longer optional (UDP Lite proposals aside). L. PGP From owner-pilc@lerc.nasa.gov Fri Mar 10 12:27:52 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29483 for ; Fri, 10 Mar 2000 12:27:51 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA16254 for pilc-outgoing; Fri, 10 Mar 2000 11:25:54 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA16221 for ; Fri, 10 Mar 2000 11:25:52 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA04163; Fri, 10 Mar 2000 11:25:50 -0500 (EST) Received: from ftpbox.mot.com(129.188.136.101) by seraph3.lerc.nasa.gov via smap (V5.0) id xma004136; Fri, 10 Mar 00 11:25:44 -0500 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA23625; Fri, 10 Mar 2000 09:25:33 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA10372; Fri, 10 Mar 2000 09:25:32 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA06058; Fri, 10 Mar 2000 11:25:31 -0500 (EST) Message-Id: <200003101625.LAA06058@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: karn@qualcomm.com cc: touch@ISI.EDU, pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers In-reply-to: Your message of "Thu, 09 Mar 2000 15:45:17 EST." <200003092345.PAA09786@homer.ka9q.ampr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Mar 2000 11:25:33 -0500 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > Okay, here's the current wording of the end-to-end principle section. > Any more comments? --Phil > > A major consideration in the efficient design of any layered > communication network are the appropriate layer(s) in which to > implement a given feature. This issue was first addressed in the Suggest changing 'feature' to 'function'. I don't believe that it was first addressed in the Saltzer, Reed and Clark paper. If I remember, this was an ongoing debate, and Saltzer, Reed and Clark captured one set of views. > seminal paper "End-to-End Arguments in System Design" [SRC81]. This > paper argued that many functions can be implemented properly *only* on > an end-to-end basis, i.e., at the higher protocol layers, outside the > subnetwork. These functions include ensuring the reliable delivery of I think Joe's point was that certain end-to-end services such as reliable delivery and confidentiality cannot be provided solely by composition of hop-by hop services. > data and the protection of information through cryptography. try... confidentiality and message integrity > Duplicating these functions at the lower protocol layers (i.e., within > the subnetwork) can be needlessly redundant or even harmful to cost > and performance. > > However, partial duplication of functionality in a lower layer > can *sometimes* be justified by performance, security or availability why the extra emphasis? > considerations. Examples include link layer retransmission on an > unusually lossy channel, e.g., mobile radio; link level encryption > intended to thwart traffic analysis; and redundant transmission links > to improve availability. Duplication of protocol function should be done only > with an understanding of system level implications, including possible > interactions with higher layer mechanisms. From owner-pilc@lerc.nasa.gov Fri Mar 10 12:57:57 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09036 for ; Fri, 10 Mar 2000 12:57:56 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA20224 for pilc-outgoing; Fri, 10 Mar 2000 11:52:12 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA20196 for ; Fri, 10 Mar 2000 11:52:09 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA08088; Fri, 10 Mar 2000 11:52:06 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007955; Fri, 10 Mar 00 11:51:29 -0500 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.194.130]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id RAA06768; Fri, 10 Mar 2000 17:51:22 +0100 (MET) Received: from eifel.eed.ericsson.se (eifel [164.48.194.242]) by chapelle.eed.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA05339; Fri, 10 Mar 2000 17:51:20 +0100 (MET) Message-Id: <4.2.0.58.20000310173701.00bc6d70@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 10 Mar 2000 17:51:11 +0100 To: karn@qualcomm.com From: Reiner Ludwig Subject: Re: Why we don't need ICMP SE? (was Re: Kicking TCP) Cc: Reiner.Ludwig@eed.ericsson.se, pilc@grc.nasa.gov In-Reply-To: <200003092322.PAA09774@homer.ka9q.ampr.org> References: <4.2.0.58.20000308155004.00c34220@chapelle.ericsson.se> <4.2.0.58.20000308155004.00c34220@chapelle.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 00:22 3/10/00 , Phil Karn wrote: > >If you do this at the link layer instead of the network layer you are free > >to queue more than just a single packet, e.g., you can queue the entire > >flight of packets belonging to a TCP flow if resources allow for that. In > >Well, I guess you could but I wouldn't want a short outage to result >in a lot of duplicate packets spewing out over the link after the link >comes back up. Seems to me you're better off holding onto just the >last packet or two per flow. You are right in the case where "standard" TCP gets a spurious timeout because the sender basically does a go-back-N. However, short link outages will often _not_ trigger a (spurious) timeout. In those cases it would be better to buffer all packets that arrive at the link during the outage. So I guess it's hard to say what is best to do given that the link layer has little knowledge of the sender's RTO. You're right for "standard" TCP, we have to do some guessing. > >should also be mentioned that no packet should be buffered longer than the > >Maximum Segment Lifetime (MSL), i.e., 240 seconds, at most. > >Is the MSL a real thing, or is it just a fiction? For example, RFC1122 uses the MSL as an upper limit for the reassembly timeout value in the case of IP fragmentation. >In either case, I see >no need to hold onto any packet for longer than the sending TCP's likely >retransmission interval -- except for the very last packet >whose purpose is more to notify TCP that the channel is back up >than to avoid a retransmission. But since the subnet doesn't have any >way to know what TCP's retransmission timeout is, you >have to make a guess. Basically agree. See above. Note though that with a TCP that is a bit more robust (http://iceberg.cs.berkeley.edu/papers/Ludwig-Eifel-Alg/index.html), i.e., that does not do a go-back-N after a spurious timeout, it is always better to buffer all packets. ///Reiner From owner-pilc@lerc.nasa.gov Fri Mar 10 13:01:50 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10305 for ; Fri, 10 Mar 2000 13:01:49 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA21680 for pilc-outgoing; Fri, 10 Mar 2000 12:04:08 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA21655 for ; Fri, 10 Mar 2000 12:04:06 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA09582; Fri, 10 Mar 2000 12:04:06 -0500 (EST) Received: from motgate2.mot.com(136.182.1.10) by seraph3.lerc.nasa.gov via smap (V5.0) id xma009537; Fri, 10 Mar 00 12:03:32 -0500 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id KAA06728; Fri, 10 Mar 2000 10:03:24 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id KAA14155; Fri, 10 Mar 2000 10:03:21 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id MAA07417; Fri, 10 Mar 2000 12:03:07 -0500 (EST) Message-Id: <200003101703.MAA07417@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: karn@qualcomm.com cc: pilc@grc.nasa.gov Subject: Re: CRCs, Checksums and Error Detection In-reply-to: Your message of "Thu, 09 Mar 2000 23:28:59 EST." <200003100728.XAA11823@homer.ka9q.ampr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Mar 2000 12:03:09 -0500 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > > The TCP, UDP and IP protocols all use a simple 16-bit 1's complement > checksum algorithm to detect corrupted packets. The IP checksum > protects only the IP header, while the TCP and UDP checksums protect > both the TCP/UDP header and any user data. In TCP the checksum is > mandatory while it is optional in UDP. > > These checksums are not very strong from a coding theory standpoint. > But they are easy to compute in software, and various proposals to > replace them with stronger checksums have failed. Experience has shown > that nearly all subnetworks that carry the Internet protocols have a > very low undetected error rate, so the existing Internet checksums are > rarely called upon to catch an error. Most of the errors caught by the > Internet checksum are generally the result of hardware or software > failure than of a subnetwork transmission error. This lowers the > motivation to overcome the performance and especially the backward > compatibility problems of a new, stronger Internet checksum. > Aside: wouldn't strict application of the end-to-end principle indicate that strong end-to-end mechanisms are needed to provide assurance of accurate data transfer? (Don't bother to answer this until after the deadline :-) > The typical IP subnetwork implements an internal error detection code that > discards packets failing this check instead of delivering them to > the IP layer. A 16-bit cyclic redundancy check (CRC) is usually the > minimum, and this is known to be considerably stronger than the 16-bit > standard Internet checksum. The Point-to-Point Protocol (PPP) uses a > 16-bit CRC, often in conjunction with the V.42bis error control The correct reference is to PPP over HDLC Framing, RFC 1622. The 16 bit CRC is the default, and a 32 bit CRC is an LCP option. > provided in a typical dialup modem. 802.3/Ethernet uses a 32-bit CRC Ethernet is but one example. Others that come to mind include AAL5/ATM, FDDI, Token Ring, PPP over SONET/SDH. > that is considerably stronger, and many subnetworks (notably dialup > modem, mobile radio and satellite) also incorporate forward error > correction, often in hardware. > > Any new subnetwork designed to carry IP should therefore provide error > detection at least as strong as a 16-bit CRC and preferably stronger. I think we should make a stronger statement, and say 'at least as strong as as the CRC-32 specified in ISO/IEC 3309:1991(E), "Information Technology - Telecommunications and information exchange between systems - High-level data link control (HDLC) procedures - Frame structure", International Organization For Standardization, Fourth edition 1991-06-01. The reason for being specific is that other 32-bit CRCs exist (but are not widely implemented) which do not have as good error detection properties. You might also want to mention something to the effect that if the subnet designer chooses to invent their own error detecting codes, they need to be very careful about their coding theory, and it's probably wiser to just reuse the CRC-32 defined for HDLC. You can also mention that CRCs do not have very good error detection properties in the presence of error bursts or deletions longer than the generator polynomial (or is it the generator polynomial - 1?). Use a CRC to match and/or include other ways (such as a length field) to detect deletions if they are possible in the subnet. > Note that while this will achieve a very low undetected packet error > rate, this will not (and need not) achieve a very low packet loss rate > as the Internet protocols are better suited to dealing with lost > packets than with corrupted packets. From owner-pilc@lerc.nasa.gov Fri Mar 10 13:06:47 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12118 for ; Fri, 10 Mar 2000 13:06:47 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA22654 for pilc-outgoing; Fri, 10 Mar 2000 12:10:54 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA22632 for ; Fri, 10 Mar 2000 12:10:52 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA10482; Fri, 10 Mar 2000 12:10:52 -0500 (EST) Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma010469; Fri, 10 Mar 00 12:10:18 -0500 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id JAA25270; Fri, 10 Mar 2000 09:10:14 -0800 (PST) Message-ID: <38C92C5F.798967C@isi.edu> Date: Fri, 10 Mar 2000 09:09:51 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: cannara@attglobal.net CC: pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <200003081340.IAA15226@noah.dma.isg.mot.com> <38C6977F.35048669@isi.edu> <200003092345.PAA09786@homer.ka9q.ampr.org> <38C86F9E.3F8BD601@attglobal.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Cannara wrote: > > Sounds good Phil, and I'd add something a bit stronger in relation to > higher-layers that, in fact, are not fully capable of offering reliability and > performance under circumstances that the lower layers can do better on. This > relates to the problems TCP has with noncongestive loss, etc. Is this saying that the lower layer is required to help the higher, or that the lower layer replaces the higher? WRT the latter, E2E asserts that HBH may be required for performance, but not correctness. Is there a counterexample? Joe From owner-pilc@lerc.nasa.gov Fri Mar 10 13:09:49 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13121 for ; Fri, 10 Mar 2000 13:09:44 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA22159 for pilc-outgoing; Fri, 10 Mar 2000 12:07:09 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA22120 for ; Fri, 10 Mar 2000 12:07:06 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA09977; Fri, 10 Mar 2000 12:07:06 -0500 (EST) Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma009840; Fri, 10 Mar 00 12:06:27 -0500 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id JAA24791; Fri, 10 Mar 2000 09:06:24 -0800 (PST) Message-ID: <38C92B79.E8842596@isi.edu> Date: Fri, 10 Mar 2000 09:06:01 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Dan Grossman CC: karn@qualcomm.com, pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <200003101625.LAA06058@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dan Grossman wrote: > > > Okay, here's the current wording of the end-to-end principle section. > > Any more comments? --Phil > > > > A major consideration in the efficient design of any layered > > communication network are the appropriate layer(s) in which to > > implement a given feature. This issue was first addressed in the > Suggest changing 'feature' to 'function'. > I don't believe that it was first addressed in the Saltzer, Reed and Clark > paper. If I remember, this was an ongoing debate, and Saltzer, Reed and Clark > captured one set of views. IMO, "captured" == "addressed" (or close enough). > > seminal paper "End-to-End Arguments in System Design" [SRC81]. This > > paper argued that many functions can be implemented properly *only* on > > an end-to-end basis, i.e., at the higher protocol layers, outside the > > subnetwork. These functions include ensuring the reliable delivery of > I think Joe's point was that certain end-to-end services such as reliable > delivery and > confidentiality cannot be provided solely by composition of hop-by hop > services. The *only* above appears to suffice; it might be more clear to include the caveat. Further, SRC81 didn't say 'some functions' so much as 'many _end-to-end_ functions'. > > data and the protection of information through cryptography. > try... confidentiality and message integrity > > Duplicating these functions at the lower protocol layers (i.e., within > > the subnetwork) can be needlessly redundant or even harmful to cost > > and performance. > > > > However, partial duplication of functionality in a lower layer > > can *sometimes* be justified by performance, security or availability > why the extra emphasis? These two paragraphs appear to contradict each other. It may be useful to unify them into a single statement that: Where HBH is implemented without consideration of E2E, it can be needlessly redundent or even harmful to cost and performance. However, HBH services can be designed to assist, rather than replace or ignore, their E2E counterparts. In this latter case, they can improve the performance of the E2E function. Joe From owner-pilc@lerc.nasa.gov Fri Mar 10 13:21:23 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17527 for ; Fri, 10 Mar 2000 13:21:22 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA23410 for pilc-outgoing; Fri, 10 Mar 2000 12:16:56 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA23390 for ; Fri, 10 Mar 2000 12:16:53 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA11393; Fri, 10 Mar 2000 12:16:52 -0500 (EST) Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma011283; Fri, 10 Mar 00 12:16:08 -0500 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id JAA25909; Fri, 10 Mar 2000 09:16:07 -0800 (PST) Message-ID: <38C92DC0.362EC628@isi.edu> Date: Fri, 10 Mar 2000 09:15:44 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: karn@qualcomm.com CC: pilc@grc.nasa.gov Subject: Re: CRCs, Checksums and Error Detection References: <200003100728.XAA11823@homer.ka9q.ampr.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Phil Karn wrote: > > I just added this section in the "Reliability and Error Control" section. > I will keep editing the LINK document, adding new text and comments as > I get them, until tomorrow when I will send a snapshot to the ID editor > with enough time to make the deadline... --Phil > > The TCP, UDP and IP protocols all use a simple 16-bit 1's complement > checksum algorithm to detect corrupted packets. The IP checksum > protects only the IP header, while the TCP and UDP checksums protect > both the TCP/UDP header and any user data. In TCP the checksum is > mandatory while it is optional in UDP. > > These checksums are not very strong from a coding theory standpoint. > But they are easy to compute in software, and various proposals to > replace them with stronger checksums have failed. Experience has shown > that nearly all subnetworks that carry the Internet protocols have a > very low undetected error rate, so the existing Internet checksums are > rarely called upon to catch an error. Most of the errors caught by the > Internet checksum are generally the result of hardware or software > failure than of a subnetwork transmission error. This lowers the > motivation to overcome the performance and especially the backward > compatibility problems of a new, stronger Internet checksum. My understanding is that these checksums either "are intended to" or "in practice usually catch only" software errors, not link errors. On the original nodes, they were for memory corruption, etc. Does anyone recall whether they were ever intended to find link errors too? (if not, the wording in paragraph 1 might be softened) > Any new subnetwork designed to carry IP should therefore provide error > detection at least as strong as a 16-bit CRC and preferably stronger. > Note that while this will achieve a very low undetected packet error > rate, this will not (and need not) achieve a very low packet loss rate > as the Internet protocols are better suited to dealing with lost > packets than with corrupted packets. This appears to assert false positives are better than false negatives, e.g., that turning the "drop" knob lower is bad when it lets through bad packets. If so, it may be useful to state it directly. Joe From owner-pilc@lerc.nasa.gov Fri Mar 10 13:22:59 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18082 for ; Fri, 10 Mar 2000 13:22:58 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA24101 for pilc-outgoing; Fri, 10 Mar 2000 12:22:55 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA24073 for ; Fri, 10 Mar 2000 12:22:53 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA12149; Fri, 10 Mar 2000 12:22:52 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma012117; Fri, 10 Mar 00 12:22:38 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id JAA17753; Fri, 10 Mar 2000 09:22:34 -0800 Date: Fri, 10 Mar 2000 09:22:34 -0800 Message-Id: <200003101722.JAA17753@homer.ka9q.ampr.org> From: Phil Karn To: vaidya@cs.tamu.edu CC: pilc@grc.nasa.gov In-reply-to: <200003101149.FAA26889@sun.cs.tamu.edu> (message from Nitin H Vaidya on Fri, 10 Mar 2000 05:49:14 -0600 (CST)) Subject: Re: Wording for "Recovery from Subnetwork Outages" Reply-to: karn@qualcomm.com References: <200003101149.FAA26889@sun.cs.tamu.edu> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >One implication of the above statement -- in the case when >a single packet is held -- would be that it can >be *any* single packet, not necessarily the earliest one. >Why is that enough to kickstart TCP? >One out-of-order (data) packet will trigger one dupack. >Not enough to result in a fast retransmit. Uh...yes. Let me mull over this. Phil From owner-pilc@lerc.nasa.gov Fri Mar 10 13:28:54 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20577 for ; Fri, 10 Mar 2000 13:28:54 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA24953 for pilc-outgoing; Fri, 10 Mar 2000 12:30:26 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA24919 for ; Fri, 10 Mar 2000 12:30:23 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA13040; Fri, 10 Mar 2000 12:30:23 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma012956; Fri, 10 Mar 00 12:29:44 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id JAA17782; Fri, 10 Mar 2000 09:29:42 -0800 Date: Fri, 10 Mar 2000 09:29:42 -0800 Message-Id: <200003101729.JAA17782@homer.ka9q.ampr.org> From: Phil Karn To: touch@ISI.EDU CC: dan@dma.isg.mot.com, pilc@grc.nasa.gov In-reply-to: <38C92B79.E8842596@isi.edu> (message from Joe Touch on Fri, 10 Mar 2000 09:06:01 -0800) Subject: Re: Draft on Advice for Internet Subnetwork Designers Reply-to: karn@qualcomm.com References: <200003101625.LAA06058@noah.dma.isg.mot.com> <38C92B79.E8842596@isi.edu> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Wow, I never thought the wording of a section on the end-to-end principle would generate so much discussion! I worded the current sections the way I did because of my observation that many subnetwork designers do not understand that services such as reliable delivery can only be properly implemented on an end-to-end basis, so they go ahead and put reliability into the subnet without any regard to whether it hurts or helps overall performance -- because they're thinking about reliability, not performance. With the ID deadline coming up in a few hours, I can't spend much more time on this point. I'll maybe make one more pass to try to handle your comments, but I have to move on. Now if we want to pick it up again after the deadline, I suppose we could... Phil From owner-pilc@lerc.nasa.gov Fri Mar 10 13:35:36 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22885 for ; Fri, 10 Mar 2000 13:35:35 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA24727 for pilc-outgoing; Fri, 10 Mar 2000 12:28:57 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA24702 for ; Fri, 10 Mar 2000 12:28:54 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA12843; Fri, 10 Mar 2000 12:28:53 -0500 (EST) Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma012826; Fri, 10 Mar 00 12:28:46 -0500 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id JAA27581 for ; Fri, 10 Mar 2000 09:28:45 -0800 (PST) Message-ID: <38C930B6.2F06A0AE@isi.edu> Date: Fri, 10 Mar 2000 09:28:22 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "'pilc@grc.nasa.gov'" Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <200003011811.KAA21226@boreas.isi.edu> <38BE7D3E.71079764@erg.abdn.ac.uk> <38BEB03F.4B7D352A@isi.edu> <38BF7021.D1246081@erg.abdn.ac.uk> <38BFED49.4929A6AB@isi.edu> <38C00C62.AF841B3E@isi.edu> <38C8FC80.6C3BC7BB@erg.abdn.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Regarding MTU assumptions... Gorry Fairhurst and I went a round on this off-line; here are our thoughts. Joe -------- Issue: The concept of link MTU becomes fuzzy or nonexistent in today's Internet. The use of security, tunneling, and other header augmentation over subpaths can substantially affect the size of link MTU, even while a connection is in progress. As a result, references to specific link MTU sizes, e.g., 1500B, may not be appropriate. A designer attempting to achieve that size on a single link will certainly have their efforts thwarted by IPSEC or IPIP tunneling, among others. In other words - even IP is a link layer, in IPSEC and in IPIP. The best thing a link designer can do about MTU is _assume it can change_. From owner-pilc@lerc.nasa.gov Fri Mar 10 13:49:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28163 for ; Fri, 10 Mar 2000 13:49:01 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA27484 for pilc-outgoing; Fri, 10 Mar 2000 12:52:12 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA27462 for ; Fri, 10 Mar 2000 12:52:09 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA15778; Fri, 10 Mar 2000 12:52:07 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma015643; Fri, 10 Mar 00 12:51:43 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id JAA17938; Fri, 10 Mar 2000 09:51:41 -0800 Date: Fri, 10 Mar 2000 09:51:41 -0800 Message-Id: <200003101751.JAA17938@homer.ka9q.ampr.org> From: Phil Karn To: dan@dma.isg.mot.com CC: pilc@grc.nasa.gov In-reply-to: <200003101703.MAA07417@noah.dma.isg.mot.com> (message from Dan Grossman on Fri, 10 Mar 2000 12:03:09 -0500) Subject: Re: CRCs, Checksums and Error Detection Reply-to: karn@qualcomm.com References: <200003101703.MAA07417@noah.dma.isg.mot.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >The correct reference is to PPP over HDLC Framing, RFC 1622. The 16 bit CRC That's 1662, not 1622. Phil From owner-pilc@lerc.nasa.gov Fri Mar 10 13:51:45 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29105 for ; Fri, 10 Mar 2000 13:51:43 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA26702 for pilc-outgoing; Fri, 10 Mar 2000 12:46:10 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA26666 for ; Fri, 10 Mar 2000 12:46:08 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA14928; Fri, 10 Mar 2000 12:46:07 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma014881; Fri, 10 Mar 00 12:45:24 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id JAA17813; Fri, 10 Mar 2000 09:45:22 -0800 Date: Fri, 10 Mar 2000 09:45:22 -0800 Message-Id: <200003101745.JAA17813@homer.ka9q.ampr.org> From: Phil Karn To: dan@dma.isg.mot.com CC: pilc@grc.nasa.gov In-reply-to: <200003101703.MAA07417@noah.dma.isg.mot.com> (message from Dan Grossman on Fri, 10 Mar 2000 12:03:09 -0500) Subject: Re: CRCs, Checksums and Error Detection Reply-to: karn@qualcomm.com References: <200003101703.MAA07417@noah.dma.isg.mot.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >Aside: wouldn't strict application of the end-to-end principle indicate that >strong end-to-end mechanisms are needed to provide assurance of accurate data >transfer? (Don't bother to answer this until after the deadline :-) I'll answer it anyway. Yes, they do. But this doesn't really argue for changing TCP. For some time I've thought it would be a good idea for application layer protocols like FTP, SMTP and HTTP to exchange MD5 (or similar) hashes of their transferred files as a final end-to-end integrity check. (I implemented a XMD5 command in my own FTP server many years ago). TCP is often not implemented in a sufficiently end-to-end fashion, as in some OSes you can have truncated files that aren't indicated as such to the user. Phil From owner-pilc@lerc.nasa.gov Fri Mar 10 14:12:20 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07728 for ; Fri, 10 Mar 2000 14:12:19 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA28994 for pilc-outgoing; Fri, 10 Mar 2000 13:04:56 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA28968 for ; Fri, 10 Mar 2000 13:04:53 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA17335; Fri, 10 Mar 2000 13:04:53 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma017316; Fri, 10 Mar 00 13:04:26 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id KAA18173; Fri, 10 Mar 2000 10:04:19 -0800 Date: Fri, 10 Mar 2000 10:04:19 -0800 Message-Id: <200003101804.KAA18173@homer.ka9q.ampr.org> From: Phil Karn To: dan@dma.isg.mot.com CC: pilc@grc.nasa.gov In-reply-to: <200003101703.MAA07417@noah.dma.isg.mot.com> (message from Dan Grossman on Fri, 10 Mar 2000 12:03:09 -0500) Subject: Re: CRCs, Checksums and Error Detection Reply-to: karn@qualcomm.com References: <200003101703.MAA07417@noah.dma.isg.mot.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >You might also want to mention something to the effect that if the subnet >designer chooses to invent their own error detecting codes, they need to be >very careful about their coding theory, and it's probably wiser to just reuse >the CRC-32 defined for HDLC. There are even stronger alternatives, so I don't want to specifically mandate the 32-bit CRC. E.g., in concatenated coding systems with a Reed-Solomon outer code, the usual number of parity bytes chosen for the RS code will provide an extremely low undetected error rate, much lower than for a 32-bit CRC. These codes are frequently used on satellite channels. >You can also mention that CRCs do not have very good error detection >properties in the presence of error bursts or deletions longer than the >generator polynomial (or is it the generator polynomial - 1?). Use a CRC to Well, the worst-case failure rate of a CRC is generally on the order of 1/2^N, where N is the number of bits in the remainder. As I recall, they do better when the number of errors is less than N, i.e., they detect them all. So yeah, CRCs don't do as well on long error bursts, but that's relative to the short bursts where they're 100% effective. I think 1/2^32 (worst case) is small enough to suit us, don't you think? Phil From owner-pilc@lerc.nasa.gov Fri Mar 10 14:29:10 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13812 for ; Fri, 10 Mar 2000 14:29:09 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA01908 for pilc-outgoing; Fri, 10 Mar 2000 13:23:41 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA01845 for ; Fri, 10 Mar 2000 13:23:38 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA20415; Fri, 10 Mar 2000 13:23:37 -0500 (EST) Received: from ftpbox.mot.com(129.188.136.101) by seraph3.lerc.nasa.gov via smap (V5.0) id xma020365; Fri, 10 Mar 00 13:23:06 -0500 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA19878; Fri, 10 Mar 2000 11:23:04 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id LAA13263; Fri, 10 Mar 2000 11:23:03 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id NAA09967; Fri, 10 Mar 2000 13:23:00 -0500 (EST) Message-Id: <200003101823.NAA09967@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: karn@qualcomm.com cc: pilc@grc.nasa.gov Subject: Re: CRCs, Checksums and Error Detection In-reply-to: Your message of "Fri, 10 Mar 2000 10:04:19 EST." <200003101804.KAA18173@homer.ka9q.ampr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Mar 2000 13:23:01 -0500 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > >You might also want to mention something to the effect that if the subnet > >designer chooses to invent their own error detecting codes, they need to be > >very careful about their coding theory, and it's probably wiser to just reuse > >the CRC-32 defined for HDLC. > > There are even stronger alternatives, so I don't want to specifically > mandate the 32-bit CRC. E.g., in concatenated coding systems with a > Reed-Solomon outer code, the usual number of parity bytes chosen for > the RS code will provide an extremely low undetected error rate, much > lower than for a 32-bit CRC. These codes are frequently used on > satellite channels. Point taken. On the other hand, I vividly recollect an ancient war where the CRC in question was so poorly designed that it could not detect any odd-length error burst. So, yeah, wiser to just reuse an existing error detecting code. > > >You can also mention that CRCs do not have very good error detection > >properties in the presence of error bursts or deletions longer than the > >generator polynomial (or is it the generator polynomial - 1?). Use a CRC to > > Well, the worst-case failure rate of a CRC is generally on the order > of 1/2^N, where N is the number of bits in the remainder. As I recall, > they do better when the number of errors is less than N, i.e., they > detect them all. So yeah, CRCs don't do as well on long error bursts, > but that's relative to the short bursts where they're 100% effective. I didn't intend to get to that level of detail, but now that you've written it down, maybe it would be better to put it in the draft. > I think 1/2^32 (worst case) is small enough to suit us, don't you > think? Sure. 1/2^16 probably isn't, though. At least if it's my financial data that's being protected. Dan > Phil > > > From owner-pilc@lerc.nasa.gov Fri Mar 10 15:17:06 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00138 for ; Fri, 10 Mar 2000 15:17:05 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA11538 for pilc-outgoing; Fri, 10 Mar 2000 14:23:53 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA11499 for ; Fri, 10 Mar 2000 14:23:50 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA00193; Fri, 10 Mar 2000 14:23:50 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma000164; Fri, 10 Mar 00 14:23:19 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id LAA18584; Fri, 10 Mar 2000 11:22:59 -0800 Date: Fri, 10 Mar 2000 11:22:59 -0800 Message-Id: <200003101922.LAA18584@homer.ka9q.ampr.org> From: Phil Karn To: gja@lucent.com CC: vjs@calcite.rhyolite.com, pilc@grc.nasa.gov In-reply-to: <38C89917.5809496E@lucent.com> (message from Grenville Armitage on Thu, 09 Mar 2000 22:41:27 -0800) Subject: Re: Kicking TCP Reply-to: karn@qualcomm.com References: <200003092355.QAA23348@calcite.rhyolite.com> <200003100620.WAA10795@homer.ka9q.ampr.org> <38C89917.5809496E@lucent.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >of my knowledge, there's nothing inherent in the RED scheme that >requires randomly choosing a packet currently *in* the queue for >dropping. (A minor optimization is to use the arrival of a new I thought it did, but it's been a while since I read up on it. Phil From owner-pilc@lerc.nasa.gov Fri Mar 10 15:29:25 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03976 for ; Fri, 10 Mar 2000 15:29:24 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA12891 for pilc-outgoing; Fri, 10 Mar 2000 14:32:52 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA12857 for ; Fri, 10 Mar 2000 14:32:49 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA01536; Fri, 10 Mar 2000 14:32:49 -0500 (EST) Received: from out2.prserv.net(32.97.166.32) by seraph3.lerc.nasa.gov via smap (V5.0) id xma001493; Fri, 10 Mar 00 14:32:47 -0500 Received: from attglobal.net ([166.72.80.122]) by prserv.net (out2) with SMTP id <2000031019324022901fckuue>; Fri, 10 Mar 2000 19:32:40 +0000 Message-ID: <38C94DAB.28AF9669@attglobal.net> Date: Fri, 10 Mar 2000 11:31:55 -0800 From: Cannara Reply-To: cannara@attglobal.net X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: "'pilc@grc.nasa.gov'" Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <200003011811.KAA21226@boreas.isi.edu> <38BE7D3E.71079764@erg.abdn.ac.uk> <38BEB03F.4B7D352A@isi.edu> <38BF7021.D1246081@erg.abdn.ac.uk> <38BFED49.4929A6AB@isi.edu> <38C00C62.AF841B3E@isi.edu> <38C8FC80.6C3BC7BB@erg.abdn.ac.uk> <38C930B6.2F06A0AE@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Good. Why not add that the MTU at the lowest layer should be large enough to handle all known tunnellings of all other bottom layers. Otherwise, fragmentation must be handled there, as it has been for FDDI/Enet or Token/Enet bridging? Phil's comment about MD5, etc. completion checks is a good recommendation, and the session layer has that as a logical responsibility, to be done often enough that it fits users' timescales of activity. Alex Joe Touch wrote: > > Regarding MTU assumptions... > Gorry Fairhurst and I went a round on this off-line; > here are our thoughts. > > Joe > > -------- > > Issue: > > The concept of link MTU becomes fuzzy or nonexistent in today's > Internet. > The use of security, tunneling, and other header augmentation > over subpaths can substantially affect > the size of link MTU, even while a connection is in progress. > > As a result, references to specific link MTU sizes, e.g., 1500B, may > not be appropriate. A designer attempting to achieve that size on > a single link will certainly have their efforts thwarted by IPSEC or > IPIP tunneling, among others. > > In other words - even IP is a link layer, in IPSEC and in IPIP. > The best thing a link designer can do about MTU is _assume it can > change_. From owner-pilc@lerc.nasa.gov Fri Mar 10 15:59:27 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14879 for ; Fri, 10 Mar 2000 15:59:27 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA16386 for pilc-outgoing; Fri, 10 Mar 2000 14:59:09 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA16362 for ; Fri, 10 Mar 2000 14:59:06 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA04658; Fri, 10 Mar 2000 14:59:04 -0500 (EST) Received: from out2.prserv.net(32.97.166.32) by seraph3.lerc.nasa.gov via smap (V5.0) id xma004613; Fri, 10 Mar 00 14:58:25 -0500 Received: from attglobal.net ([166.72.80.122]) by prserv.net (out2) with SMTP id <2000031019581822902mk6dae>; Fri, 10 Mar 2000 19:58:18 +0000 Message-ID: <38C953AD.734E99D7@attglobal.net> Date: Fri, 10 Mar 2000 11:57:33 -0800 From: Cannara Reply-To: cannara@attglobal.net X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <200003081340.IAA15226@noah.dma.isg.mot.com> <38C6977F.35048669@isi.edu> <200003092345.PAA09786@homer.ka9q.ampr.org> <38C86F9E.3F8BD601@attglobal.net> <38C92C5F.798967C@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Since there've long been many experiences in networking outside the Internet protocols, even before them, it's often been assumed, in my engineering experience, that each layer does its every best to assure delivery to the next node, without sacrificing available performance (note lack of saying: "bandwidth", which is erroneously used these days). So, Enet for example, makes better use of a shared medium than does Token, at most common usage levels, but it guarantees (within 32-bits of CRC) that received data are right. Its CSMA/CD is faster at resolving contention without loss delays than Token and Token is better than any transport, including TCP. Token Ring even had "assured delivery" in the IBM spec, but not implemented. Imagine TCP on Enet -- if a collision were to go unsensed, then we'd be back to Aloha Net, waiting 100s of milliseconds for TCP (NCP, SPP...) to recover the loss that Enet recovers in a millisecond. This obviously makes no sense, which is what Abramson and Metcalfe determined decades ago and solved by adding swift, effective contention handling for layer 1. The e-to-e principles are interesting, but in a real sense, bureaucratic: "work with TCP, it's our old buddy and we worked on it for all these years..." No layer is fully independent of those below, and those below have the purpose of delivering services to layers above that are useful to these upper layers. There's no 3rd tablet from the mount that says "Thou shalt not communicate between protocol layers", especially when things can be made to perform better and more reliably by doing so. Service to Mankind is engineering's purpose, right? So, since TCP counts and tracks individual packets (ok, segments), and has algorithms pasted on over the years to help router (ok, gateway) queues avoid embarassment, why should anyone balk at giving it more help from any layer below -- its backoff algorithm is there to help the network-layer queues, not just the end-station's slowness. We've already seen a good deal of mucking about among TCP/IP layers and even removal of useful services, such as the IP ID in v6, apparently because no one really understood all the implications. We don't need many np simulations to understand that TCP needs help to perform reasonably in a busy, lossy network. Oh, what's "HBH" -- should we buy or sell? Thanks, Alex Joe Touch wrote: > > Cannara wrote: > > > > Sounds good Phil, and I'd add something a bit stronger in relation to > > higher-layers that, in fact, are not fully capable of offering reliability and > > performance under circumstances that the lower layers can do better on. This > > relates to the problems TCP has with noncongestive loss, etc. > > Is this saying that the lower layer is required to help the higher, > or that the lower layer replaces the higher? > > WRT the latter, E2E asserts that HBH may be required for performance, > but not correctness. Is there a counterexample? > > Joe From owner-pilc@lerc.nasa.gov Fri Mar 10 15:59:28 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14890 for ; Fri, 10 Mar 2000 15:59:28 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA15568 for pilc-outgoing; Fri, 10 Mar 2000 14:53:09 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA15542 for ; Fri, 10 Mar 2000 14:53:06 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA03926; Fri, 10 Mar 2000 14:53:05 -0500 (EST) Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma003889; Fri, 10 Mar 00 14:52:43 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id MAA22403 env-from ; Fri, 10 Mar 2000 12:52:27 -0700 (MST) Date: Fri, 10 Mar 2000 12:52:27 -0700 (MST) From: Vernon Schryver Message-Id: <200003101952.MAA22403@calcite.rhyolite.com> To: gja@lucent.com, karn@qualcomm.com Subject: Re: Kicking TCP Cc: pilc@grc.nasa.gov, vjs@calcite.rhyolite.com Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Phil Karn > >of my knowledge, there's nothing inherent in the RED scheme that > >requires randomly choosing a packet currently *in* the queue for > >dropping. (A minor optimization is to use the arrival of a new > > I thought it did, but it's been a while since I read up on it. The idea behind random drop (or so I think, and my recent words make my thoughts very suspect) is to make the probability that any stream loses a packet increase with the number of packets that the stream has in the queue. If you follow the easiest and old tactic of always dropping the newest packet, then greedy bursty streams get an unfair advantage. It's not very random to always drop the oldest or the newest, and not much better to choose randomly between the oldest and the newest packet (unless your queue has depth of 1, but no one cares about that case). Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Fri Mar 10 16:08:24 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17830 for ; Fri, 10 Mar 2000 16:08:19 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA18856 for pilc-outgoing; Fri, 10 Mar 2000 15:15:25 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA18780; Fri, 10 Mar 2000 15:15:15 -0500 (EST) Received: from katrinajoy (katrinajoy.lerc.nasa.gov [139.88.111.49]) by apataki-fi.lerc.nasa.gov with SMTP (NASA LeRC 8.7.4.1/2.01-local) id PAA09133; Fri, 10 Mar 2000 15:15:14 -0500 (EST) Message-Id: <4.1.20000310151552.00a66e70@popserve.lerc.nasa.gov> X-Sender: caivanc@popserve.lerc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 10 Mar 2000 15:22:54 -0500 To: Vernon Schryver From: William D Ivancic Subject: Re: Kicking TCP Cc: gja@lucent.com, karn@qualcomm.com, pilc@grc.nasa.gov, vjs@calcite.rhyolite.com In-Reply-To: <200003101952.MAA22403@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Regarding WRED, I believe you randomly drop at the input to the queue. You start dropping slowly and randomly at a predefined threshold and continue dropping more aggressively as the queue gets closer to its high limit at which point you take some other action (drop, reset precedence, put into another queue, or whatever else the specification allows and the router is capable of). Will Ivancic wivancic@grc.nasa.gov At 12:52 PM 3/10/00 -0700, Vernon Schryver wrote: >> From: Phil Karn > >> >of my knowledge, there's nothing inherent in the RED scheme that >> >requires randomly choosing a packet currently *in* the queue for >> >dropping. (A minor optimization is to use the arrival of a new >> >> I thought it did, but it's been a while since I read up on it. > >The idea behind random drop (or so I think, and my recent words make my >thoughts very suspect) is to make the probability that any stream loses >a packet increase with the number of packets that the stream has in the >queue. If you follow the easiest and old tactic of always dropping the >newest packet, then greedy bursty streams get an unfair advantage. > >It's not very random to always drop the oldest or the newest, and not >much better to choose randomly between the oldest and the newest packet >(unless your queue has depth of 1, but no one cares about that case). > > >Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Fri Mar 10 16:08:55 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18076 for ; Fri, 10 Mar 2000 16:08:54 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA18308 for pilc-outgoing; Fri, 10 Mar 2000 15:11:54 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA18276 for ; Fri, 10 Mar 2000 15:11:51 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA06253; Fri, 10 Mar 2000 15:11:51 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma006229; Fri, 10 Mar 00 15:11:44 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id MAA18720; Fri, 10 Mar 2000 12:11:43 -0800 Date: Fri, 10 Mar 2000 12:11:43 -0800 Message-Id: <200003102011.MAA18720@homer.ka9q.ampr.org> From: Phil Karn To: pilc@grc.nasa.gov Subject: Initial text on QoS Reply-to: karn@qualcomm.com Sender: owner-pilc@lerc.nasa.gov Precedence: bulk I've written this text to kick off the section on QoS, fairness vs performance, and congestion signalling. --Phil The IP header includes a 1-byte TOS (type of service) field. This field is broken into two parts: a 3-bit precedence field that indicates the relative importance of this packet compared to others, and a 4-bit "qualitative tradeoff" field to indicate if low delay, high throughput, high reliability or low cost is qualitatively more important for this particular packet. One TOS bit is reserved. Although the TOS field has not been heavily used in the past, it is becoming increasingly important to the provision of Quality of Service (QoS) features necessary for services such as Voice over IP (VoIP). Many subnetwork designers are faced with inherent tradeoffs between delay, throughput, reliability and cost. When this is the case, the subnetwork should provide an interface to IP that allows the IP TOS bits to control these tradeoffs on a per-packet basis. For example, when a subnetwork implements a hop-by-hop retransmission scheme to improve reliability, this invariably comes at the cost of increased delay variance. An IP packet presented to this subnetwork with the "low delay" bit set in its TOS field should disable hop-by-hop retransmission within the subnetwork for that particular packet. Another example is link forward error correction, which can increase reliability at the expense of throughput without significantly affecting delay. From owner-pilc@lerc.nasa.gov Fri Mar 10 16:44:17 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00907 for ; Fri, 10 Mar 2000 16:44:16 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA22714 for pilc-outgoing; Fri, 10 Mar 2000 15:44:55 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA22687 for ; Fri, 10 Mar 2000 15:44:53 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA10601; Fri, 10 Mar 2000 15:44:53 -0500 (EST) Received: from host60d9.alcatel.com(128.251.96.217) by seraph3.lerc.nasa.gov via smap (V5.0) id xma010584; Fri, 10 Mar 00 15:44:51 -0500 Received: from usa.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id OAA05567; Fri, 10 Mar 2000 14:44:30 -0600 (CST) Message-ID: <38C95E13.51F377D7@usa.alcatel.com> Date: Fri, 10 Mar 2000 14:41:55 -0600 From: Vincent Magret Organization: Alcatel USA, Inc. X-Sender: "Vincent Magret" X-Mailer: Mozilla 4.5 [en]C-CCK-MCD ANS2.00 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: PILC Subject: Re: Kicking TCP References: <200003092355.QAA23348@calcite.rhyolite.com> Content-Type: multipart/mixed; boundary="------------28D05812DFDEA4A57D6E4602" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. --------------28D05812DFDEA4A57D6E4602 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Vernon Schryver wrote: > > From: Phil Karn > > > ... > > > 1. have the link layer tell the TCP state machines to retransmit any > > > unacknowledged TCP bytes by forcing their retransmission timers > > > to zero? ... > > > It's more than a technical layering violation, because how would > > you do it if the TCP and the link layer are on separate machines? > > You'd need to define some communication mechanism, which was the > > intent of my ICMP SE message. > > Yes, but in many cases (e.g. mobile phones) the host and the router > are pretty close to each other. But I agree that reasonable queuing > next to the link is far better. What about the case where the mobile regain connectivity with another router (of Base station)? Then aren't we loosing all the advantage of queueing? Vincent > > > > ... > > Again, I agree. I will add text that encourages the subnetwork designer > > to use any internal information it may have about the state of the > > link or subnetwork to block the acceptance of IP packets if it is clear > > that those packets would be dropped, and to hold onto the most recent > > packets that it may have accepted before the link/subnet went down > > and to try to deliver them after the link/subnet comes back up. > > That sound great. > > Something I forget to mention in my previous note is that private > cooresondent pointed out that RED and other fancy queuing disciplines > tend to encourage dropping the most recent instead oldest packets. > > Vernon Schryver vjs@rhyolite.com --------------28D05812DFDEA4A57D6E4602 Content-Type: text/x-vcard; charset=us-ascii; name="vincent.magret.vcf" Content-Description: Card for Vincent Magret Content-Disposition: attachment; filename="vincent.magret.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Magret;Vincent tel;fax:+1 972 996 5902 tel;work:+1 972 996 2625 x-mozilla-html:FALSE org:;Network Strategy Group version:2.1 email;internet:vincent.magret@usa.alcatel.com adr;quoted-printable:;;1201 E. Campbell rd=0D=0AM-S 446-310;Ricahrdson;Texas;75081;USA fn:Vincent Magret end:vcard --------------28D05812DFDEA4A57D6E4602-- From owner-pilc@lerc.nasa.gov Fri Mar 10 17:35:50 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19244 for ; Fri, 10 Mar 2000 17:35:49 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA29763 for pilc-outgoing; Fri, 10 Mar 2000 16:38:13 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA29726 for ; Fri, 10 Mar 2000 16:38:10 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA17811; Fri, 10 Mar 2000 16:38:08 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma017604; Fri, 10 Mar 00 16:37:15 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id NAA19256; Fri, 10 Mar 2000 13:37:11 -0800 Date: Fri, 10 Mar 2000 13:37:11 -0800 Message-Id: <200003102137.NAA19256@homer.ka9q.ampr.org> From: Phil Karn To: cannara@attglobal.net CC: pilc@grc.nasa.gov In-reply-to: <38C953AD.734E99D7@attglobal.net> (message from Cannara on Fri, 10 Mar 2000 11:57:33 -0800) Subject: Re: Draft on Advice for Internet Subnetwork Designers Reply-to: karn@qualcomm.com References: <200003081340.IAA15226@noah.dma.isg.mot.com> <38C6977F.35048669@isi.edu> <200003092345.PAA09786@homer.ka9q.ampr.org> <38C86F9E.3F8BD601@attglobal.net> <38C92C5F.798967C@isi.edu> <38C953AD.734E99D7@attglobal.net> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >So, since TCP counts and tracks individual packets (ok, segments), and has >algorithms pasted on over the years to help router (ok, gateway) queues avoid >embarassment, why should anyone balk at giving it more help from any layer >below -- its backoff algorithm is there to help the network-layer queues, not That's fine, as long as the added lower-level functionality really does help performance overall. I've seen too many overly complicated subnetwork designs where this isn't the case, though. Phil From owner-pilc@lerc.nasa.gov Fri Mar 10 17:38:56 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20226 for ; Fri, 10 Mar 2000 17:38:56 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA29931 for pilc-outgoing; Fri, 10 Mar 2000 16:39:43 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA29881 for ; Fri, 10 Mar 2000 16:39:39 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA18010; Fri, 10 Mar 2000 16:39:39 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma017893; Fri, 10 Mar 00 16:38:34 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id NAA19260; Fri, 10 Mar 2000 13:38:34 -0800 Date: Fri, 10 Mar 2000 13:38:34 -0800 Message-Id: <200003102138.NAA19260@homer.ka9q.ampr.org> From: Phil Karn To: pilc@grc.nasa.gov Subject: New section on mobility Reply-to: karn@qualcomm.com Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Here's the text I just added to kick off the mobility section. Since the deadline is looming, I'm going to submit the LINK document as it currently stands, and update (again) the copy on my web page. --Phil Internet users are increasingly mobile. Not only are many Internet nodes laptop computers, but pocket organizers and mobile embedded systems are also becoming nodes on the Internet. These nodes may connect to many different access points on the Internet over time, and they expect this to be largely transparent to their activities. Except when they are not connected to the Internet at all, and for performance differences when they are connected, they expect that everything will "just work" regardless of their current Internet attachment point or local subnetwork technology. Mobility can be provided at any of several layers in the Internet protocol stack, and there is ongoing debate as to which are the most appropriate and efficient. Mobility is already an feature of certain application layer protocols; the Post Office Protocol (POP) [RFC1939] and the Internet Message Access Protocol (IMAP) [RFC2060] were created specifically to provide mobility in the receipt of electronic mail. Mobility can also be provided at the IP layer [RFC2002]. This mechanism provides greater transparency, viz., IP addresses that remain fixed as the nodes move, but at the cost of potentially significant network overhead and increased delay because of the non-optimum network routing and tunneling involved. Some subnetworks may provide internal mobility, transparent to IP, as a feature of their own internal routing mechanisms. To the extent that these simplify routing at the IP layer, reduce the need for mechanisms like Mobile IP, or exploit mechanisms unique to the subnetwork, this is generally desirable. This is especially true when the subnetwork covers a relatively small geographic area and the users move rapidly between the attachment points within that area. However, if the subnetwork is physically large and connects to other parts of the Internet at multiple geographic points, care should be taken to optimize the wide-area routing of packets between nodes on the external Internet and nodes on the subnet. This is generally done with "nearest exit" routing strategies. Because a given subnetwork may be unaware of the actual physical location of a destination on another subnetwork, it simply routes packets bound for the other subnetwork to the nearest gateway between the two. This implies some awareness of IP addressing and routing within the subnetwork. The subnetwork may wish to use IP routing internally for wide area routing and restrict subnetwork-specific routing to constrained geographic areas where the effects of suboptimal routing are minimized. From owner-pilc@lerc.nasa.gov Fri Mar 10 17:56:19 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25406 for ; Fri, 10 Mar 2000 17:56:19 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA01240 for pilc-outgoing; Fri, 10 Mar 2000 16:50:13 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA01224 for ; Fri, 10 Mar 2000 16:50:11 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA19402; Fri, 10 Mar 2000 16:50:10 -0500 (EST) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma019327; Fri, 10 Mar 00 16:49:31 -0500 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12TXHb-00008Z-00; Fri, 10 Mar 2000 21:49:19 +0000 Date: Fri, 10 Mar 2000 21:49:16 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: karn@qualcomm.com cc: pilc@grc.nasa.gov Subject: Re: Initial text on QoS In-Reply-To: <200003102011.MAA18720@homer.ka9q.ampr.org> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Fri, 10 Mar 2000, Phil Karn wrote: > The IP header includes a 1-byte TOS (type of service) field. This > field is broken into two parts: a 3-bit precedence field that > indicates the relative importance of this packet compared to others, > and a 4-bit "qualitative tradeoff" field to indicate if low delay, > high throughput, high reliability or low cost is qualitatively more > important for this particular packet. One TOS bit is reserved. Whoa. That all plays complete havoc with diffserv: 6-bit DSCP, and two bits reserved. The TOS definitions as above aren't widely used, and the diffserv architecture is effectively rewriting the field. > Although the TOS field has not been heavily used in the past, it is > becoming increasingly important to the provision of Quality of Service > (QoS) features necessary for services such as Voice over IP (VoIP). Very true - but not in its form as a TOS field per se. > Many subnetwork designers are faced with inherent tradeoffs between > delay, throughput, reliability and cost. When this is the case, the > subnetwork should provide an interface to IP that allows the IP TOS > bits to control these tradeoffs on a per-packet basis. For example, > when a subnetwork implements a hop-by-hop retransmission scheme to > improve reliability, this invariably comes at the cost of increased > delay variance. An IP packet presented to this subnetwork with the > "low delay" bit set in its TOS field should disable hop-by-hop > retransmission within the subnetwork for that particular > packet. IMO we *really* don't want to encourage link designers to look at some DSCP bit and assume low delay based on the assigned value when it is an artefact of numbering and has nothing to do with low delay; designing a link to interact well with some overblown QoS framework sinking in its own complexity is a whole new ball game, and imo is probably outside the scope of this draft. > Another example of improving link reliability - but this is somewhat orthogonal to the QoS discussion above, yes? You're not suggesting varying FEC depending on QoS settings, surely... > is link forward error correction, which can > increase reliability at the expense of throughput without > significantly affecting delay. L. PGP From owner-pilc@lerc.nasa.gov Fri Mar 10 18:09:20 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00668 for ; Fri, 10 Mar 2000 18:09:20 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA03956 for pilc-outgoing; Fri, 10 Mar 2000 17:14:57 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA03930 for ; Fri, 10 Mar 2000 17:14:55 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA21921; Fri, 10 Mar 2000 17:14:54 -0500 (EST) Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma021898; Fri, 10 Mar 00 17:14:33 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id PAA24618 for pilc@grc.nasa.gov env-from ; Fri, 10 Mar 2000 15:14:32 -0700 (MST) Date: Fri, 10 Mar 2000 15:14:32 -0700 (MST) From: Vernon Schryver Message-Id: <200003102214.PAA24618@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: Initial text on QoS Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Phil Karn > ... An IP packet presented to this subnetwork with the > "low delay" bit set in its TOS field should disable hop-by-hop > retransmission within the subnetwork for that particular > packet. Another example is link forward error correction, which can > increase reliability at the expense of throughput without > significantly affecting delay. Why turn off retransmission for "low delay"? The application protocols I can think of off hand that currently and commonly use "low delay" are NTP/UDP (as of a fairly recent change to (x?)ntpd), `timed` or TSP/UDP (another time protocol), telnet, and rlogind. I know of some other applications, but they're much less common and some are even proprietary, but follow those two families. Turning off retransmission for the UDP applications is sounds like a good idea, but not good for the TCP applications. For them, you want to retransmit to avoid the longer end-to-end timeout, and perhaps move them higher in your hop-by-hop retransmission queue. In other words, turning off hop-by-hop retransmissions for "low delay" sounds either too specific a remedy or to general. Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Fri Mar 10 18:15:27 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02993 for ; Fri, 10 Mar 2000 18:15:26 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA04583 for pilc-outgoing; Fri, 10 Mar 2000 17:20:57 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA04552 for ; Fri, 10 Mar 2000 17:20:54 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA22587; Fri, 10 Mar 2000 17:20:54 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma022570; Fri, 10 Mar 00 17:20:26 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id OAA19584; Fri, 10 Mar 2000 14:20:22 -0800 Date: Fri, 10 Mar 2000 14:20:22 -0800 Message-Id: <200003102220.OAA19584@homer.ka9q.ampr.org> From: Phil Karn To: L.Wood@eim.surrey.ac.uk CC: pilc@grc.nasa.gov In-reply-to: (message from Lloyd Wood on Fri, 10 Mar 2000 21:49:16 +0000 (GMT)) Subject: Re: Initial text on QoS Reply-to: karn@qualcomm.com References: Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >Whoa. That all plays complete havoc with diffserv: 6-bit DSCP, and two >bits reserved. The TOS definitions as above aren't widely used, and >the diffserv architecture is effectively rewriting the field. Okay, I wasn't aware of that, and I guess it's time to read up more on diffserv. Care to contribute some text? (I've already submitted the draft, but we can continue to edit the document for the next round). >IMO we *really* don't want to encourage link designers to look at some >DSCP bit and assume low delay based on the assigned value when it is What I wanted to say is that when a subnetwork designer is faced with a design tradeoff between delay/reliability/throughput/cost, instead of just picking an operating point he should provide "knobs" that IP can diddle to make the tradeoffs on a per-packet basis. >of improving link reliability - but this is somewhat orthogonal to the >QoS discussion above, yes? You're not suggesting varying FEC depending >on QoS settings, surely... Actually, yes. It makes quite a bit of sense in some environments, particularly those using spread spectrum/CDMA. Varying the FEC code rate and varying the power are closely related approaches. The Qualcomm HDR system uses a constant channel symbol rate and transmitter power and varies the modulation type and FEC code rate (and the user throughput) as a function of signal-to-interference ratio. Nothing says we couldn't bias those settings according to QoS bits if that were useful. Phil From owner-pilc@lerc.nasa.gov Fri Mar 10 18:26:08 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06255 for ; Fri, 10 Mar 2000 18:26:07 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA05514 for pilc-outgoing; Fri, 10 Mar 2000 17:29:58 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA05502 for ; Fri, 10 Mar 2000 17:29:56 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA23608; Fri, 10 Mar 2000 17:29:54 -0500 (EST) Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma023577; Fri, 10 Mar 00 17:29:26 -0500 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id OAA02452; Fri, 10 Mar 2000 14:29:24 -0800 (PST) Message-ID: <38C9772C.969B719F@isi.edu> Date: Fri, 10 Mar 2000 14:29:00 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: cannara@attglobal.net CC: "'pilc@grc.nasa.gov'" Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <200003011811.KAA21226@boreas.isi.edu> <38BE7D3E.71079764@erg.abdn.ac.uk> <38BEB03F.4B7D352A@isi.edu> <38BF7021.D1246081@erg.abdn.ac.uk> <38BFED49.4929A6AB@isi.edu> <38C00C62.AF841B3E@isi.edu> <38C8FC80.6C3BC7BB@erg.abdn.ac.uk> <38C930B6.2F06A0AE@isi.edu> <38C94DAB.28AF9669@attglobal.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Cannara wrote: > > Good. Why not add that the MTU at the lowest layer should be large enough to > handle all known tunnellings of all other bottom layers. This can't be determined a-priori, i.e., by the link designer. Big is good; if not big (or anyway), then either support fragmentation, or preferably support PMTU. Don't do anything that assumes knowledge of the MTU before it can be determined. Joe From owner-pilc@lerc.nasa.gov Fri Mar 10 19:08:16 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20899 for ; Fri, 10 Mar 2000 19:08:15 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA08286 for pilc-outgoing; Fri, 10 Mar 2000 18:05:12 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA08261 for ; Fri, 10 Mar 2000 18:05:10 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA27628; Fri, 10 Mar 2000 18:05:09 -0500 (EST) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma027574; Fri, 10 Mar 00 18:04:30 -0500 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12TYSE-0000gU-00; Fri, 10 Mar 2000 23:04:22 +0000 Date: Fri, 10 Mar 2000 23:04:19 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: karn@qualcomm.com cc: pilc@grc.nasa.gov Subject: Re: Initial text on QoS In-Reply-To: <200003102220.OAA19584@homer.ka9q.ampr.org> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Fri, 10 Mar 2000, Phil Karn wrote: > >Whoa. That all plays complete havoc with diffserv: 6-bit DSCP, and two > >bits reserved. The TOS definitions as above aren't widely used, and > >the diffserv architecture is effectively rewriting the field. > > Okay, I wasn't aware of that, and I guess it's time to read up more on > diffserv. Care to contribute some text? (I've already submitted the draft, > but we can continue to edit the document for the next round). okay. taking the general form of what you wrote... The IP header includes a type-of-service field [RFC791]. This was not widely used, and has been redefined as the 'codepoint', identifying a set of specified delivery requirements, in the differentiated services architecture [RFC2474]. This field is becoming increasingly important to the provision of Quality of Service (QoS) features necessary for a variety of services. Before considering using any labelling in this field to improve link performance, the subnetwork MUST be aware of the definition and use of the field within the local network. It is the responsibility of the local network to control the access to, and use of, this field. Many subnetwork designers are faced with inherent tradeoffs between reliability, delay, throughput, and cost. When this is the case, the subnetwork should use the codepoint to map the locally-understood QoS specifications to a set of tradeoff choices on a per-packet basis. For example, a subnetwork might implement a hop-by-hop retransmission scheme to improve reliability. An IP packet presented to this subnetwork with a codepoint indicating a low reliability requirement, via a high drop precedence setting, might not be subject to retransmission. Packets marked for a low drop precedence requirement, indicating preferential treatment, would be more likely to be held and retransmitted if required. L. PGP From owner-pilc@lerc.nasa.gov Fri Mar 10 22:27:49 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21430 for ; Fri, 10 Mar 2000 22:27:48 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA18731 for pilc-outgoing; Fri, 10 Mar 2000 21:32:59 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA18727 for ; Fri, 10 Mar 2000 21:32:58 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id VAA16372; Fri, 10 Mar 2000 21:32:57 -0500 (EST) Received: from servo.qualcomm.com(129.46.76.82) by seraph3.lerc.nasa.gov via smap (V5.0) id xma016367; Fri, 10 Mar 00 21:32:28 -0500 Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.14) id SAA01246; Fri, 10 Mar 2000 18:32:27 -0800 (PST) Date: Fri, 10 Mar 2000 18:32:27 -0800 (PST) Message-Id: <200003110232.SAA01246@servo.qualcomm.com> From: Phil Karn To: pilc@grc.nasa.gov Cc: karn@qualcomm.com Subject: ID bounce message Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Hi all, I got an automated bounce message from the Internet Drafts coordinator saying that my submission of the PILC LINK draft came after the deadline, even though I *know* I got it in before 5pm EST. I sent two copies, one from home and one from work. I sent the copy from work when I noticed a problem with the path through Time Warner from home. The copy from work went right through and completed about five minutes before the deadline. Hopefully the bounce came from the earlier home copy that got stuck. If not, this is just a bureaucratic annoyance, and we can continue to work from the copy on my personal web page: http://people.qualcomm.com/karn/pilc.txt --Phil From owner-pilc@lerc.nasa.gov Sun Mar 12 14:06:47 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22590 for ; Sun, 12 Mar 2000 14:06:47 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA08480 for pilc-outgoing; Sun, 12 Mar 2000 12:40:55 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA08457 for ; Sun, 12 Mar 2000 12:40:54 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA16492; Sun, 12 Mar 2000 12:40:52 -0500 (EST) Received: from ppp-44-41-188.wmar.club-internet.fr(213.44.41.188) by seraph3.lerc.nasa.gov via smap (V5.0) id xma015565; Sun, 12 Mar 00 12:38:27 -0500 Received: (from pplc@localhost) by ra.ensim.com (8.9.3/8.9.3) id JAA09193; Sun, 12 Mar 2000 09:36:35 -0800 Date: Sun, 12 Mar 2000 09:36:35 -0800 Message-Id: <200003121736.JAA09193@ra.ensim.com> From: Patrick Cipiere To: karn@qualcomm.com CC: gorry@erg.abdn.ac.uk, pilc@grc.nasa.gov In-reply-to: <200003081651.IAA01772@homer.ka9q.ampr.org> (message from Phil Karn on Wed, 8 Mar 2000 08:51:23 -0800) Subject: Re: Draft on Advice for Internet Subnetwork Designers Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Phil, > Reference: MPEG-2 or DVB reference. I did'nt see Gorry's answer, and did'nt see the references either in draft-ietf-pilc-link-design-02.txt so if you still need that DVB reference is ETSI EN 301 192 V1.2.1 (1999-06) MPEG-2 reference is ISO/IEC 13818 Patrick. From owner-pilc@lerc.nasa.gov Mon Mar 13 10:08:28 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09815 for ; Mon, 13 Mar 2000 10:08:23 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA00973 for pilc-outgoing; Mon, 13 Mar 2000 08:51:10 -0500 (EST) Received: from guns (guns.lerc.nasa.gov [139.88.44.160]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA00869 for ; Mon, 13 Mar 2000 08:50:59 -0500 (EST) Message-Id: <200003131350.IAA00869@lombok-fi.lerc.nasa.gov> To: pilc@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: new pilc I-Ds available Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Wild Night Date: Mon, 13 Mar 2000 08:50:58 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Folks- The updated PILC I-Ds are available from: http://pilc.grc.nasa.gov/pilc/ From what I have heard from the co-chairs, these will be in the normal Internet-Draft archives as soon as they make it through the queue. allman --- http://roland.grc.nasa.gov/~mallman/ From owner-pilc@lerc.nasa.gov Mon Mar 13 18:51:57 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03292 for ; Mon, 13 Mar 2000 18:51:56 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA23282 for pilc-outgoing; Mon, 13 Mar 2000 17:44:45 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA23249 for ; Mon, 13 Mar 2000 17:44:41 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA24331; Mon, 13 Mar 2000 17:44:40 -0500 (EST) Received: from out1.prserv.net(32.97.166.31) by seraph3.lerc.nasa.gov via smap (V5.0) id xma024298; Mon, 13 Mar 00 17:44:06 -0500 Received: from attglobal.net ([129.37.92.109]) by prserv.net (out1) with SMTP id <2000031322435825201se8ffe>; Mon, 13 Mar 2000 22:43:59 +0000 Message-ID: <38CD6F02.E3F17574@attglobal.net> Date: Mon, 13 Mar 2000 14:43:14 -0800 From: Cannara Reply-To: cannara@attglobal.net X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <200003081340.IAA15226@noah.dma.isg.mot.com> <38C6977F.35048669@isi.edu> <200003092345.PAA09786@homer.ka9q.ampr.org> <38C86F9E.3F8BD601@attglobal.net> <38C92C5F.798967C@isi.edu> <38C953AD.734E99D7@attglobal.net> <200003102137.NAA19256@homer.ka9q.ampr.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Yes, that goes without saying Phil. Alex Phil Karn wrote: > > >So, since TCP counts and tracks individual packets (ok, segments), and has > >algorithms pasted on over the years to help router (ok, gateway) queues avoid > >embarassment, why should anyone balk at giving it more help from any layer > >below -- its backoff algorithm is there to help the network-layer queues, not > > That's fine, as long as the added lower-level functionality really does > help performance overall. I've seen too many overly complicated subnetwork > designs where this isn't the case, though. > > Phil From owner-pilc@lerc.nasa.gov Mon Mar 13 20:32:52 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11609 for ; Mon, 13 Mar 2000 20:32:51 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA01246 for pilc-outgoing; Mon, 13 Mar 2000 19:44:45 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA01234 for ; Mon, 13 Mar 2000 19:44:44 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA07184; Mon, 13 Mar 2000 19:44:43 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007171; Mon, 13 Mar 00 19:44:08 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id QAA08975; Mon, 13 Mar 2000 16:43:45 -0800 Date: Mon, 13 Mar 2000 16:43:45 -0800 Message-Id: <200003140043.QAA08975@homer.ka9q.ampr.org> From: Phil Karn To: marie@teledesic.com CC: dan@dma.isg.mot.com, afalk@PanAmSat.com, pilc@grc.nasa.gov In-reply-to: <25D0C66E6D25D311B2AC0008C7913EE07B8134@tdmail2.teledesic.com> (message from Marie-Jose Montpetit on Thu, 9 Mar 2000 05:48:40 -0800) Subject: Re: Draft on Advice for Internet Subnetwork Designers Reply-to: karn@qualcomm.com References: <25D0C66E6D25D311B2AC0008C7913EE07B8134@tdmail2.teledesic.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >> >On the topic of packet discard especially on those subnet where capacity >> is >> >expensive or limited I would add that when possible packets marked form >> >another subnet should be discarded before transmission on the link. >> >> Is this an issue for the subnetwork designer, or for the router that >> drives the subnetwork? >If we start from the premise that the equipment that is connected to the >subnetwork is unaware of the particularities of the subnetwork, which I >think is usually the case, then it is an issue for the designer. I asked the question because I assume by "marked packet" you meant marking at the IP layer, e.g., with ECN. That implies that it's up to an IP router to drop the packet if it wishes, since subnetworks know nothing about IP (or about other subnetworks, for that matter). Phil From owner-pilc@lerc.nasa.gov Tue Mar 14 02:02:06 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16963 for ; Tue, 14 Mar 2000 02:02:06 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA15855 for pilc-outgoing; Tue, 14 Mar 2000 01:13:20 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA15840 for ; Tue, 14 Mar 2000 01:13:18 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id BAA04591; Tue, 14 Mar 2000 01:13:18 -0500 (EST) Received: from elk.aciri.org(192.150.187.21) by seraph3.lerc.nasa.gov via smap (V5.0) id xma004477; Tue, 14 Mar 00 01:13:04 -0500 Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.9.3/8.9.2) with ESMTP id WAA31460; Mon, 13 Mar 2000 22:11:34 -0800 (PST) (envelope-from floyd@elk.aciri.org) Message-Id: <200003140611.WAA31460@elk.aciri.org> To: gorry@erg.abdn.ac.uk cc: pilc@grc.nasa.gov From: Sally Floyd Subject: Re: PILC ASYM document Date: Mon, 13 Mar 2000 22:11:34 -0800 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >I disagree that TCP "works well" over all links. If you define >"well" as >meaning doesn't fail to delivery (eventually) then that's OK, but normally >that's >not my thinking. TCP is end-to-end, but link designers need to take on board >what is really happening. Once the subnet designers document is clear, I >suggest >we will probably see the need for the ASYM document. Yes, I agree completely about the need for the ASYM document. I think the fact that TCP currently lacks congestion control for traffic on the return path (for the case where the TCP flow's traffic on the return path consists only of ACK packets) is a significant weakness that happens to manifest particularly strongly in the case of asymmetric links. It seems to me that adding some form of congestion control for this return-path traffic will at some point become necessary. I don't view congestion control for ACK traffic as contorting TCP to accomodate the oddities of some defective link layer. I view it as addressing a fundamental requirement of the transport protocol to have effective end-to-end congestion control, as much as possible, for all of its traffic. - Sally -------------------------------- http://www.aciri.org/floyd/ -------------------------------- From owner-pilc@lerc.nasa.gov Tue Mar 14 02:19:26 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27176 for ; Tue, 14 Mar 2000 02:19:26 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA16548 for pilc-outgoing; Tue, 14 Mar 2000 01:30:35 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA16540 for ; Tue, 14 Mar 2000 01:30:33 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id BAA05859; Tue, 14 Mar 2000 01:30:33 -0500 (EST) Received: from elk.aciri.org(192.150.187.21) by seraph3.lerc.nasa.gov via smap (V5.0) id xma005818; Tue, 14 Mar 00 01:30:01 -0500 Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.9.3/8.9.2) with ESMTP id WAA31580; Mon, 13 Mar 2000 22:28:41 -0800 (PST) (envelope-from floyd@elk.aciri.org) Message-Id: <200003140628.WAA31580@elk.aciri.org> To: karn@qualcomm.com cc: vjs@calcite.rhyolite.com, pilc@grc.nasa.gov From: Sally Floyd Subject: Re: Kicking TCP Date: Mon, 13 Mar 2000 22:28:41 -0800 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Phil - >>of my knowledge, there's nothing inherent in the RED scheme that >>requires randomly choosing a packet currently *in* the queue for >>dropping. (A minor optimization is to use the arrival of a new > >I thought it did, but it's been a while since I read up on it. Nope. The basic RED scheme randomly drops arriving packets. You could have variants, if you wanted, where you randomly made the decision to drop a packet when a new packet arrived at the queue, but where instead of dropping the arriving packet, you dropped some other packet instead (the packet at the head of the queue, or some random packet in the queue). But I haven't really looked at any of these options. (I was also under the impression that dropping a packet in the middle of the queue was likely to be more expensive for the router than dropping the arriving packet...) I have a brief note about "RED with Drop From Front" on the RED web page at "http://www.aciri.org/floyd/red.html". - Sally -------------------------------- http://www.aciri.org/floyd/ -------------------------------- From owner-pilc@lerc.nasa.gov Tue Mar 14 02:51:53 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09402 for ; Tue, 14 Mar 2000 02:51:53 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA18250 for pilc-outgoing; Tue, 14 Mar 2000 02:02:04 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA18245 for ; Tue, 14 Mar 2000 02:02:03 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA08520; Tue, 14 Mar 2000 02:02:03 -0500 (EST) Received: from out5.prserv.net(32.97.166.35) by seraph3.lerc.nasa.gov via smap (V5.0) id xma008488; Tue, 14 Mar 00 02:01:45 -0500 Received: from attglobal.net ([129.37.22.173]) by prserv.net (out5) with SMTP id <20000314070135243027dkcoe>; Tue, 14 Mar 2000 07:01:35 +0000 Message-ID: <38CDE3A3.FA83CAEC@attglobal.net> Date: Mon, 13 Mar 2000 23:00:51 -0800 From: Cannara Reply-To: cannara@attglobal.net X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: pilc@grc.nasa.gov Subject: Re: PILC ASYM document References: <200003140611.WAA31460@elk.aciri.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit In general, we should not take a single transport protocol (TCP or any other) out of any family of protocols that carry data, and give it the responsibility of network "congestion control". This was done historically because TCP was dominant in the old Internet and so it could be used to effectively help routers with their queueing, when it was apparent proper network-layer design for high loads hadn't been done. Today, the mix of traffic continues to change in ways that increasingly expose this bandaid. Addressing the real problem at the network layer will be the key, as others have suggested. Imagining that TCP has an obligation and capability to control congestion remains an engineering mistake. The TCPs people actually use and see operational every day are extremely inefficient, in comparison with what could legitimately expect of the years of effort that went into its various algorithimic components. Part of this inefficiency is certainly laid to default parameter settings (timeouts, etc.). However, the fundamental flaw in the logic is that TCP has insufficient information to make proper decisions and is hampered further by provider policies on packet delivery. The network layer will need to manage its queues and drops and provide help to higher layers, not depend on them. Fortunately, the problems with TCP/IP's current interwining become extremely evident on the kinds of links discussed here. That should be our impetus to deal with the problems effectively rather than bureaucratically. Alex Sally Floyd wrote: > > >I disagree that TCP "works well" over all links. If you define > >"well" as > >meaning doesn't fail to delivery (eventually) then that's OK, but normally > >that's > >not my thinking. TCP is end-to-end, but link designers need to take on board > >what is really happening. Once the subnet designers document is clear, I > >suggest > >we will probably see the need for the ASYM document. > > Yes, I agree completely about the need for the ASYM document. I > think the fact that TCP currently lacks congestion control for > traffic on the return path (for the case where the TCP flow's > traffic on the return path consists only of ACK packets) is a > significant weakness that happens to manifest particularly strongly > in the case of asymmetric links. It seems to me that adding some > form of congestion control for this return-path traffic will at > some point become necessary. I don't view congestion control for > ACK traffic as contorting TCP to accomodate the oddities of some > defective link layer. I view it as addressing a fundamental > requirement of the transport protocol to have effective end-to-end > congestion control, as much as possible, for all of its traffic. > > - Sally From owner-pilc@lerc.nasa.gov Tue Mar 14 13:33:51 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10373 for ; Tue, 14 Mar 2000 13:33:46 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA18004 for pilc-outgoing; Tue, 14 Mar 2000 12:16:08 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA17971 for ; Tue, 14 Mar 2000 12:16:06 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA12091; Tue, 14 Mar 2000 12:16:05 -0500 (EST) Received: from elk.aciri.org(192.150.187.21) by seraph3.lerc.nasa.gov via smap (V5.0) id xma012040; Tue, 14 Mar 00 12:15:52 -0500 Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.9.3/8.9.2) with ESMTP id JAA35728; Tue, 14 Mar 2000 09:14:37 -0800 (PST) (envelope-from floyd@elk.aciri.org) Message-Id: <200003141714.JAA35728@elk.aciri.org> To: cannara@attglobal.net cc: pilc@grc.nasa.gov From: Sally Floyd Subject: Re: PILC ASYM document Date: Tue, 14 Mar 2000 09:14:36 -0800 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >Imagining that TCP has an obligation and capability to control congestion >remains an engineering mistake. Odd. The lessons that I would take from the last twelve years of TCP congestion control are that transport-level, end-to-end congestion control is remarkably robust; that it has successfully prevented congestion collapse and enabled the evolution of the Internet for the past twelve years; and that transport-level congestion control coupled with a minimal network level allows a great heterogeneity of link-level technologies and higher-level applications as well as the evolution of other transport-level congestion control mechanisms for diverse classes of applications (e.g., unreliable unicast, semi-reliable streaming multimedia, unreliable and reliable multicast, etc.). The further lessons that I would take from the last twelve years of TCP congestion control would be that TCP and other transport protocols can and should be made even more robust to a variety of behaviors in the underlying network (e.g., reordered packets due to link-level transmissions, congestion on the return path); and that adding some forms of explicit communication between the transport layer and higher or lower layers (e.g., Explicit Congestion Notification) can be of significant benefit. - Sally -------------------------------- http://www.aciri.org/floyd/ -------------------------------- From owner-pilc@lerc.nasa.gov Tue Mar 14 14:42:05 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07863 for ; Tue, 14 Mar 2000 14:42:04 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA02374 for pilc-outgoing; Tue, 14 Mar 2000 13:43:28 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA02331 for ; Tue, 14 Mar 2000 13:43:22 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA26182; Tue, 14 Mar 2000 13:43:22 -0500 (EST) Received: from mgate-01.teledesic.com(216.190.22.41) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026125; Tue, 14 Mar 00 13:42:50 -0500 Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2448.0) id ; Tue, 14 Mar 2000 10:39:11 -0800 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE07B8190@tdmail2.teledesic.com> From: Marie-Jose Montpetit To: "'karn@qualcomm.com'" Cc: dan@dma.isg.mot.com, afalk@PanAmSat.com, pilc@grc.nasa.gov Subject: RE: Draft on Advice for Internet Subnetwork Designers Date: Tue, 14 Mar 2000 10:31:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk I don't want to get in a nomenclature argument but by point was that if the subnetwork provides a transport layer and that transport layer itself has some queue management then some of the discard can be done ahead of the router. Marie-Jose -----Original Message----- From: Phil Karn [mailto:karn@ka9q.ampr.org] Sent: Monday, March 13, 2000 4:44 PM To: marie@teledesic.com Cc: dan@dma.isg.mot.com; afalk@PanAmSat.com; pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers >> >On the topic of packet discard especially on those subnet where capacity >> is >> >expensive or limited I would add that when possible packets marked form >> >another subnet should be discarded before transmission on the link. >> >> Is this an issue for the subnetwork designer, or for the router that >> drives the subnetwork? >If we start from the premise that the equipment that is connected to the >subnetwork is unaware of the particularities of the subnetwork, which I >think is usually the case, then it is an issue for the designer. I asked the question because I assume by "marked packet" you meant marking at the IP layer, e.g., with ECN. That implies that it's up to an IP router to drop the packet if it wishes, since subnetworks know nothing about IP (or about other subnetworks, for that matter). Phil From owner-pilc@lerc.nasa.gov Tue Mar 14 17:59:25 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24105 for ; Tue, 14 Mar 2000 17:59:24 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA02465 for pilc-outgoing; Tue, 14 Mar 2000 16:57:06 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA02451 for ; Tue, 14 Mar 2000 16:57:04 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA23649; Tue, 14 Mar 2000 16:57:03 -0500 (EST) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma023636; Tue, 14 Mar 00 16:57:03 -0500 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12UzIX-0001qq-00; Tue, 14 Mar 2000 21:56:17 +0000 Date: Tue, 14 Mar 2000 21:56:14 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Sally Floyd cc: cannara@attglobal.net, pilc@grc.nasa.gov Subject: Re: PILC ASYM document In-Reply-To: <200003141714.JAA35728@elk.aciri.org> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Tue, 14 Mar 2000, Sally Floyd wrote: > Odd. The lessons that I would take from the last twelve years of > TCP congestion control are that transport-level, end-to-end congestion > control is remarkably robust so robust (in the self-perpetuating sense) that improvements to it such as rate-based pacing cannot be incrementally deployed. (You can only incrementally deploy mechanisms that are equally or more aggressive for network capacity - bit of a quandary, that.) > that it has successfully prevented > congestion collapse and enabled the evolution of the Internet for > the past twelve years; and that transport-level congestion control > coupled with a minimal network level allows a great heterogeneity > of link-level technologies and higher-level applications as well > as the evolution of other transport-level congestion control > mechanisms for diverse classes of applications (e.g., unreliable > unicast, semi-reliable streaming multimedia, unreliable and reliable > multicast, etc.). To me, the growing emphasis on TCP-friendliness for these mechanisms indicates the limited scope for evolution available. The mechanisms need to display the same level of aggression as TCP to coexist well with TCP. Transport-level congestion control is certainly a success, but I suspect that improvements are being boxed into a corner - an evolutionary dead end, if you will - by the installed base. Ever-decreasing returns? (To extend the evolution analogy slightly further: TCP is a very very successful species of dinosaur, set to dominate the planet for millions of years. There are no global extermination events planned; there are currently few evolutionary pressures on TCP in the 'congestion control' competition space. Now, if there was a reason to deploy queuing mechanisms favouring e.g. rate-based pacing, which would be equivalent to altering the global temperature...) > The further lessons that I would take from the last twelve years of > TCP congestion control would be that TCP and other transport > protocols can and should be made even more robust to a variety of > behaviors in the underlying network (e.g., reordered packets due > to link-level transmissions, congestion on the return path) hear, hear. > and > that adding some forms of explicit communication between the > transport layer and higher or lower layers (e.g., Explicit Congestion > Notification) can be of significant benefit. although TCP seems to have been doing just fine without that thus far. L. PGP From owner-pilc@lerc.nasa.gov Tue Mar 14 17:59:57 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24284 for ; Tue, 14 Mar 2000 17:59:56 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA04368 for pilc-outgoing; Tue, 14 Mar 2000 17:14:21 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA04340 for ; Tue, 14 Mar 2000 17:14:18 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA25796; Tue, 14 Mar 2000 17:14:18 -0500 (EST) Received: from elk.aciri.org(192.150.187.21) by seraph3.lerc.nasa.gov via smap (V5.0) id xma025739; Tue, 14 Mar 00 17:13:42 -0500 Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.9.3/8.9.2) with ESMTP id OAA40375; Tue, 14 Mar 2000 14:12:30 -0800 (PST) (envelope-from floyd@elk.aciri.org) Message-Id: <200003142212.OAA40375@elk.aciri.org> To: L.Wood@eim.surrey.ac.uk cc: pilc@grc.nasa.gov From: Sally Floyd Subject: Re: PILC ASYM document Date: Tue, 14 Mar 2000 14:12:30 -0800 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Lloyd - >To me, the growing emphasis on TCP-friendliness for these mechanisms >indicates the limited scope for evolution available. The mechanisms >need to display the same level of aggression as TCP to coexist well >with TCP. I agree that the requirement for TCP-friendliness limits the scope for evolution of best-effort traffic competing in FIFO queues with TCP. I think of diffserv as the mechanism that will allow transport-level evolution past TCP-friendliness. E.g., I could imagine a class of traffic, labeled by the diffserv field, that is segregated from best-effort TCP, and that operates by its own rules. E.g., a class for congestion-based pricing; a class for per-flow scheduling and users optimizing their own utility functions; a class for flows all using class-X-compatible congestion control, etc. (I don't know what the mechanism is for ensuring that all routers along the path understand diffserv class X, or something else appropriate, but I imagine that will come...) I don't understand what prevents the incremental deployment of rate-based pacing, by the way. Are you suggesting that rate-based TCP flows competing with regular TCP flows would face starvation? I wouldn't think so. - Sally -------------------------------- http://www.aciri.org/floyd/ -------------------------------- From owner-pilc@lerc.nasa.gov Wed Mar 15 04:11:11 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12765 for ; Wed, 15 Mar 2000 04:11:10 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA28992 for pilc-outgoing; Wed, 15 Mar 2000 01:25:15 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03-vs.lerc.nasa.gov [139.88.145.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id AAA23054; Wed, 15 Mar 2000 00:10:37 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id XAA07225; Tue, 14 Mar 2000 23:31:06 -0500 (EST) Received: from leonis.nus.edu.sg(137.132.1.18) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007190; Tue, 14 Mar 00 23:30:52 -0500 Received: from engtanlk.nus.edu.sg (eng203162.pc.nus.edu.sg [137.132.203.162]) by leonis.nus.edu.sg (8.9.3/8.9.3) with SMTP id KAA10082; Wed, 15 Mar 2000 10:15:26 +0800 (SST) Message-ID: <01d901bf8e25$67331b80$a2cb8489@engtanlk.nus.edu.sg> To: From: "ICON'2000 Secretariat" Subject: LAST day to call for papers. Have you submitted your paper? Date: Wed, 15 Mar 2000 10:15:25 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D6_01BF8E68.75565B80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01D6_01BF8E68.75565B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All A Gentle Reminder * Kindly ignore this email if you have received this before. Thank you for your kind attention. The 8th IEEE International Conference On Networks will be held from September 5- 8, 2000 in Singapore. The aim of the conference is to = provide an international forum for experts to promote, share and discuss various issues and developments in the broad field of computer and communication networks. We thus seek and solicit your contributions in the form of original/unpublished papers, tutorials, and topics for special sessions/panel discussions. More information on the scope of the conference and the guidelines for the submission of contributions can be obtained at this web site :http://www.comp.nus.edu.sg/~icon/ We look forward to your participation. Thank you. Icon 2000 organizing Committee ------=_NextPart_000_01D6_01BF8E68.75565B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All
 
A Gentle Reminder

* Kindly ignore this email if you have = received=20 this before.
Thank you for your kind attention.

The 8th IEEE International Conference On Networks will be held=20 from

September 5- 8, 2000 in Singapore. The aim of the conference = is to=20 provide

an international forum for experts to promote, share and = discuss=20 various

issues and developments in the broad field of computer = and=20 communication

networks. We thus seek and solicit your=20 contributions

in the form of original/unpublished papers, = tutorials, and=20 topics for

special sessions/panel discussions. More information = on the=20 scope of the

conference and the guidelines for the submission of=20 contributions can

be obtained at this web site :http://www.comp.nus.edu.sg/~ic= on/



We=20 look forward to your participation. Thank you.

Icon 2000 = organizing=20 Committee
------=_NextPart_000_01D6_01BF8E68.75565B80-- From owner-pilc@lerc.nasa.gov Wed Mar 15 05:04:44 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00561 for ; Wed, 15 Mar 2000 05:04:44 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA02632 for pilc-outgoing; Wed, 15 Mar 2000 02:36:04 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03-vs.lerc.nasa.gov [139.88.145.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA02595 for ; Wed, 15 Mar 2000 02:35:57 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA02148; Wed, 15 Mar 2000 02:35:56 -0500 (EST) Received: from unknown(32.97.166.35) by seraph3.lerc.nasa.gov via smap (V5.0) id xma000383; Wed, 15 Mar 00 02:30:20 -0500 Received: from attglobal.net ([32.100.71.178]) by prserv.net (out5) with SMTP id <2000031507272724300klamce>; Wed, 15 Mar 2000 07:27:28 +0000 Message-ID: <38CF3B33.6AFBF1D0@attglobal.net> Date: Tue, 14 Mar 2000 23:26:43 -0800 From: Cannara Reply-To: cannara@attglobal.net X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: pilc@grc.nasa.gov Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <25D0C66E6D25D311B2AC0008C7913EE07B8190@tdmail2.teledesic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit This may be controversial, but I'd like to add that the use of "subnetwork" is misleading and a better name would help. Subnetwork could be applied at any layer, including the application, so it doesn't reflect the meaning of a perhaps purely physical medium, a tunnelled path, etc. Since we already confuse students with "gateway" and "subnet" in the TCP/IP world, I hope we can get a better term. Alex Marie-Jose Montpetit wrote: > > I don't want to get in a nomenclature argument but by point was that if the > subnetwork provides a transport layer and that transport layer itself has > some queue management then some of the discard can be done ahead of the > router. > > Marie-Jose [clip] From owner-pilc@lerc.nasa.gov Wed Mar 15 07:17:35 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20128 for ; Wed, 15 Mar 2000 07:17:34 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA15500 for pilc-outgoing; Wed, 15 Mar 2000 06:21:34 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id GAA15489 for ; Wed, 15 Mar 2000 06:21:33 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA26224; Wed, 15 Mar 2000 06:21:32 -0500 (EST) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026213; Wed, 15 Mar 00 06:21:26 -0500 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12VBrZ-0000EY-00; Wed, 15 Mar 2000 11:21:17 +0000 Date: Wed, 15 Mar 2000 11:21:14 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Sally Floyd cc: pilc@grc.nasa.gov Subject: Re: PILC ASYM document In-Reply-To: <200003142212.OAA40375@elk.aciri.org> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Tue, 14 Mar 2000, Sally Floyd wrote: > >To me, the growing emphasis on TCP-friendliness for these mechanisms > >indicates the limited scope for evolution available. The mechanisms > >need to display the same level of aggression as TCP to coexist well > >with TCP. > > I agree that the requirement for TCP-friendliness limits the scope > for evolution of best-effort traffic competing in FIFO queues with > TCP. I think of diffserv as the mechanism that will allow > transport-level evolution past TCP-friendliness. Yes - however, making diffserv adequately TCP-friendly (how do you handle the asymmetry of most TCP connections? What happens when responsive TCP and unresponsive UDP-based traffic share a class?) is a problem in itself. > I don't understand what prevents the incremental deployment of > rate-based pacing, by the way. There's currently a lack of clear performance benefit as motivation. No performance benefit or slight degradation == no incentive to change. > Are you suggesting that rate-based > TCP flows competing with regular TCP flows would face starvation? > I wouldn't think so. Aggarwal et al's paper had Reno consistently outperforming rate-based pacing (end of section D) from slow start with large buffer sizes. That's IMO sufficient disincentive to deploy rate-based pacing as is. http://www.cs.washington.edu/homes/savage/ Understanding the Performance of TCP Pacing, Amit Aggarwal, Stefan Savage, and Tom Anderson, to appear in Proceedings of the 2000 IEEE Infocom Conference, Tel-Aviv, Israel, March, 2000. L. PGP From owner-pilc@lerc.nasa.gov Wed Mar 15 10:40:31 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13578 for ; Wed, 15 Mar 2000 10:40:30 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA08702 for pilc-outgoing; Wed, 15 Mar 2000 09:38:26 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA08659 for ; Wed, 15 Mar 2000 09:38:21 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA18446; Wed, 15 Mar 2000 09:38:20 -0500 (EST) Received: from mail.cis.ohio-state.edu(164.107.115.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018386; Wed, 15 Mar 00 09:37:52 -0500 Received: from gamma.cis.ohio-state.edu (gamma.cis.ohio-state.edu [164.107.112.13]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id JAA06128 for ; Wed, 15 Mar 2000 09:37:51 -0500 (EST) Received: from localhost (mukul@localhost) by gamma.cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id JAA15622 for ; Wed, 15 Mar 2000 09:37:51 -0500 (EST) X-Authentication-Warning: gamma.cis.ohio-state.edu: mukul owned process doing -bs Date: Wed, 15 Mar 2000 09:37:51 -0500 (EST) From: mukul goyal cc: pilc@grc.nasa.gov Subject: Re: PILC ASYM document In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Wed, 15 Mar 2000, Lloyd Wood wrote: > On Tue, 14 Mar 2000, Sally Floyd wrote: > > > >To me, the growing emphasis on TCP-friendliness for these mechanisms > > >indicates the limited scope for evolution available. The mechanisms > > >need to display the same level of aggression as TCP to coexist well > > >with TCP. > > > > I agree that the requirement for TCP-friendliness limits the scope > > for evolution of best-effort traffic competing in FIFO queues with > > TCP. I think of diffserv as the mechanism that will allow > > transport-level evolution past TCP-friendliness. > > Yes - however, making diffserv adequately TCP-friendly (how do you > handle the asymmetry of most TCP connections? What happens when > responsive TCP and unresponsive UDP-based traffic share a class?) is a > problem in itself. I think that Sally was suggesting that some traffic classes in diffserv can be used by non-TCP-friendly traffic. Just for information, the other problem regarding TCP and UDP sharing a traffic class has been studied in some details. We have an Internet Draft on the issue. Our finding is that you have to mark 'excess' traffic of TCP and UDP flows differently in order to achieve fair distribution of excess resources. (Here, excess means unreserved resources.) The draft can be seen at: http://www.cis.ohio-state.edu/~jain/ietf/afstdy.htm I think there is a draft/paper on the issue from Nortel folks also (N Seddigh et al). From owner-pilc@lerc.nasa.gov Wed Mar 15 11:40:19 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08183 for ; Wed, 15 Mar 2000 11:40:16 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA20723 for pilc-outgoing; Wed, 15 Mar 2000 10:48:31 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA20673 for ; Wed, 15 Mar 2000 10:48:27 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA29443; Wed, 15 Mar 2000 10:48:25 -0500 (EST) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma029399; Wed, 15 Mar 00 10:48:13 -0500 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12VG1p-0003ok-00; Wed, 15 Mar 2000 15:48:09 +0000 Date: Wed, 15 Mar 2000 15:48:06 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: mukul goyal cc: pilc@grc.nasa.gov Subject: Re: PILC ASYM document In-Reply-To: Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk [This is now off-topic for pilc; discussion ends here.] On Wed, 15 Mar 2000, mukul goyal wrote: > On Wed, 15 Mar 2000, Lloyd Wood wrote: > | On Tue, 14 Mar 2000, Sally Floyd wrote: > | > On Tue, 14 Mar 2000, Lloyd Wood wrote: > | > |To me, the growing emphasis on TCP-friendliness for these mechanisms > | > |indicates the limited scope for evolution available. The mechanisms > | > |need to display the same level of aggression as TCP to coexist well > | > |with TCP. > | > > | > I agree that the requirement for TCP-friendliness limits the scope > | > for evolution of best-effort traffic competing in FIFO queues with > | > TCP. I think of diffserv as the mechanism that will allow > | > transport-level evolution past TCP-friendliness. > | > | Yes - however, making diffserv adequately TCP-friendly (how do you > | handle the asymmetry of most TCP connections? What happens when > | responsive TCP and unresponsive UDP-based traffic share a class?) is a > | problem in itself. > > I think that Sally was suggesting that some traffic classes in diffserv > can be used by non-TCP-friendly traffic. > > Just for information, the other problem regarding TCP and UDP sharing a > traffic class has been studied in some details. We have an Internet Draft > on the issue. Our finding is that you have to mark 'excess' traffic of TCP > and UDP flows differently in order to achieve fair distribution of excess > resources. Oh, draft-goyal-diffserv-afstdy-00.txt. Unlike the position expressed in the conclusions of your draft, we have shown that it is not necessary for the classifier to distinguish between TCP and UDP packets in order to meaningfully utilize the three drop precedences while treating TCP and UDP fairly. (Distinguishing between TCP and UDP in the network is generally a bad idea, and then there's IPSec.) http://www.ee.surrey.ac.uk/Personal/G.Pavlou/Publications/Conference-papers/Andrik-00a-abstract.html A fair traffic conditioner for the assured service in a differentiated services Internet I. Andrikopoulos, L. Wood, G. Pavlou to appear in the proceedings of the IEEE International Conference on Communications (ICC 2000), New Orleans, June 2000. L. PGP > (Here, excess means unreserved resources.) The draft can be > seen at: > http://www.cis.ohio-state.edu/~jain/ietf/afstdy.htm > > I think there is a draft/paper on the issue from Nortel folks also (N > Seddigh et al). From owner-pilc@lerc.nasa.gov Wed Mar 15 12:12:07 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21620 for ; Wed, 15 Mar 2000 12:12:06 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA27025 for pilc-outgoing; Wed, 15 Mar 2000 11:25:24 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA26988 for ; Wed, 15 Mar 2000 11:25:22 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA05544; Wed, 15 Mar 2000 11:25:19 -0500 (EST) Received: from mail.cis.ohio-state.edu(164.107.115.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma005471; Wed, 15 Mar 00 11:24:43 -0500 Received: from gamma.cis.ohio-state.edu (gamma.cis.ohio-state.edu [164.107.112.13]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id LAA13546; Wed, 15 Mar 2000 11:24:43 -0500 (EST) Received: from localhost (mukul@localhost) by gamma.cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id LAA18805; Wed, 15 Mar 2000 11:24:43 -0500 (EST) X-Authentication-Warning: gamma.cis.ohio-state.edu: mukul owned process doing -bs Date: Wed, 15 Mar 2000 11:24:43 -0500 (EST) From: mukul goyal To: Lloyd Wood cc: pilc@grc.nasa.gov Subject: Re: PILC ASYM document In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk I guess I will sort this out with Lloyd offline and may be post a summary of the conclusions reached on this list! On Wed, 15 Mar 2000, Lloyd Wood wrote: > [This is now off-topic for pilc; discussion ends here.] > > On Wed, 15 Mar 2000, mukul goyal wrote: > > On Wed, 15 Mar 2000, Lloyd Wood wrote: > > | On Tue, 14 Mar 2000, Sally Floyd wrote: > > | > On Tue, 14 Mar 2000, Lloyd Wood wrote: > > | > |To me, the growing emphasis on TCP-friendliness for these mechanisms > > | > |indicates the limited scope for evolution available. The mechanisms > > | > |need to display the same level of aggression as TCP to coexist well > > | > |with TCP. > > | > > > | > I agree that the requirement for TCP-friendliness limits the scope > > | > for evolution of best-effort traffic competing in FIFO queues with > > | > TCP. I think of diffserv as the mechanism that will allow > > | > transport-level evolution past TCP-friendliness. > > | > > | Yes - however, making diffserv adequately TCP-friendly (how do you > > | handle the asymmetry of most TCP connections? What happens when > > | responsive TCP and unresponsive UDP-based traffic share a class?) is a > > | problem in itself. > > > > I think that Sally was suggesting that some traffic classes in diffserv > > can be used by non-TCP-friendly traffic. > > > > Just for information, the other problem regarding TCP and UDP sharing a > > traffic class has been studied in some details. We have an Internet Draft > > on the issue. Our finding is that you have to mark 'excess' traffic of TCP > > and UDP flows differently in order to achieve fair distribution of excess > > resources. > > Oh, draft-goyal-diffserv-afstdy-00.txt. > > Unlike the position expressed in the conclusions of your draft, we > have shown that it is not necessary for the classifier to distinguish > between TCP and UDP packets in order to meaningfully utilize the three > drop precedences while treating TCP and UDP fairly. (Distinguishing > between TCP and UDP in the network is generally a bad idea, and > then there's IPSec.) > > http://www.ee.surrey.ac.uk/Personal/G.Pavlou/Publications/Conference-papers/Andrik-00a-abstract.html > > A fair traffic conditioner for the assured service in a differentiated > services Internet > I. Andrikopoulos, L. Wood, G. Pavlou > to appear in the proceedings of the IEEE International > Conference on Communications (ICC 2000), New Orleans, June 2000. > > L. > > PGP > > > > (Here, excess means unreserved resources.) The draft can be > > seen at: > > http://www.cis.ohio-state.edu/~jain/ietf/afstdy.htm > > > > I think there is a draft/paper on the issue from Nortel folks also (N > > Seddigh et al). > > > From owner-pilc@lerc.nasa.gov Thu Mar 16 16:14:51 2000 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21469 for ; Thu, 16 Mar 2000 16:14:49 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA11007 for pilc-outgoing; Thu, 16 Mar 2000 15:20:23 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA10966 for ; Thu, 16 Mar 2000 15:20:21 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA11408; Thu, 16 Mar 2000 15:20:17 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.0) id xma011322; Thu, 16 Mar 00 15:19:40 -0500 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.194.130]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id VAA06436; Thu, 16 Mar 2000 21:19:31 +0100 (MET) Received: from eifel.eed.ericsson.se (ki-75.kiedt.ericsson.se [147.214.100.75]) by chapelle.eed.ericsson.se (8.9.1/8.9.1) with ESMTP id VAA15044; Thu, 16 Mar 2000 21:19:28 +0100 (MET) Message-Id: <4.2.0.58.20000316202823.009df6a0@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 16 Mar 2000 21:17:33 +0100 To: karn@qualcomm.com From: Reiner Ludwig Subject: Re: Initial text on QoS Cc: pilc@grc.nasa.gov In-Reply-To: <200003102011.MAA18720@homer.ka9q.ampr.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk catching up on old mails .... Yes, I think the text you have written, Phil, is *really* a step in the right direction. Basically, there are two different link layer design philosophies (this has been mentioned before on this list): 1. "one size fits all", i.e., one IP packet is just as good as the next. 2. something what we call "flow adaptive", i.e. distinguishing flow types at the link layer for the purpose of adapting link layer error control (ARQ, FEC, power control, spreading factor control, ...) to try to best meet a flow's application layer QoS requirements. There are many benefits from the latter: (A) higher e2e performance, (B) less load on the Internet because link layer error recovery saves e2e retransmissions (C) more efficient utilization of radio resources like transmission power (battery), etc., etc. For flow adaptive links to work, it would be soooo great to have the old TOS byte and its definitions - deployed. Unfortunaly this is not the case. Moreover, as already noted by Lloyd, diffserv has redefined the TOS byte and unfortunately does not allow the required e2e marking of, e.g., reliable (TCP, NFS, Reliable-Multicast, ...) vs. delay-senstive (RTP, ...) flows. Maybe PILC can at some point request such CPs when diffserv work goes into a new round ... However, I don't know whether such required e2e markings (that don't change once set by the source) are at all compatible with the diffserv model which allows that an IP packet's CP can change from domain to domain :-( ///Reiner At 21:11 10.03.00 , Phil Karn wrote: >I've written this text to kick off the section on QoS, fairness vs >performance, >and congestion signalling. --Phil > >The IP header includes a 1-byte TOS (type of service) field. This >field is broken into two parts: a 3-bit precedence field that >indicates the relative importance of this packet compared to others, >and a 4-bit "qualitative tradeoff" field to indicate if low delay, >high throughput, high reliability or low cost is qualitatively more >important for this particular packet. One TOS bit is reserved. > >Although the TOS field has not been heavily used in the past, it is >becoming increasingly important to the provision of Quality of Service >(QoS) features necessary for services such as Voice over IP (VoIP). > >Many subnetwork designers are faced with inherent tradeoffs between >delay, throughput, reliability and cost. When this is the case, the >subnetwork should provide an interface to IP that allows the IP TOS >bits to control these tradeoffs on a per-packet basis. For example, >when a subnetwork implements a hop-by-hop retransmission scheme to >improve reliability, this invariably comes at the cost of increased >delay variance. An IP packet presented to this subnetwork with the >"low delay" bit set in its TOS field should disable hop-by-hop >retransmission within the subnetwork for that particular >packet. Another example is link forward error correction, which can >increase reliability at the expense of throughput without >significantly affecting delay. From owner-pilc@lerc.nasa.gov Thu Mar 16 16:49:21 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04445 for ; Thu, 16 Mar 2000 16:49:20 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA17668 for pilc-outgoing; Thu, 16 Mar 2000 16:01:43 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA17625 for ; Thu, 16 Mar 2000 16:01:39 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA17695; Thu, 16 Mar 2000 16:01:38 -0500 (EST) Received: from motgate.mot.com(129.188.136.100) by seraph3.lerc.nasa.gov via smap (V5.0) id xma017665; Thu, 16 Mar 00 16:01:06 -0500 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA14310; Thu, 16 Mar 2000 14:01:03 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA15470; Thu, 16 Mar 2000 14:01:02 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id QAA26386; Thu, 16 Mar 2000 16:01:01 -0500 (EST) Message-Id: <200003162101.QAA26386@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: karn@qualcomm.com cc: pilc@grc.nasa.gov Subject: Re: Initial text on QoS In-reply-to: Your message of "Fri, 10 Mar 2000 12:11:43 EST." <200003102011.MAA18720@homer.ka9q.ampr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Mar 2000 16:01:03 -0500 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Actually, I had some rather different things in mind for this section. Sorry to be so late with this, I've been thinking about it for a while, and was having difficulty organizing my thoughts. There's more to be said, but enough delay (so to speak! :-) Dan ----------------------------- The Internet has historically provided a single, undifferentiated best effort service. As applications have emerged that have specific quality-of-service (QoS) requirements, mechanisms have been, and continue to be developed to support them. QoS, in the broadest sense, is defined as the set of service attributes that the provider of a service offers to the user of a service. These service attributes can be categorized as relating to performance, availability, security or cost. However, this memo, like most treatments of QoS, considers only the set of performance attributes. In the context of the IP and subnet layers, the performance attributes of most interest are: -- throughput -- delay -- delay jitter -- packet loss ratio -- errored packet rate This memo does not attempt to define these. In a layered architecture, a layer enhances and/or degrades the service provided to it by the layer below, so as to provide a service to the layer above. Layers (especially the IP layer and below) contain impairments which degrade performance. Examples of impairments include variable delays due to queueing and scheduling, congestive discard and errored discard. Mechanisms in the layers can enhance one service attribute possibly at the expense of another. For example, a retransmission mechanism in a subnet enhances (decreases) the packet loss ratio offered to the IP layer, at the expense of degrading (increasing) delay variation. IP, however, does not contain such mechanisms, since strict application of the end-to-end principle relegates such functions to the TCP layer and above. The Internet has historically provided an undifferentiated best effort service with no quantifiable service attributes. As applications have emerged that have specific performance requirements, mechanisms have been, and continue to be developed to support them. .in +5 -- IP Integrated Services (Intserv) [RFC1633] provides finely granular QoS guarantees to individual flows. It uses stateful mechanisms: a 'soft' state is installed in routers along the path using a Reservation Protocol (RSVP) [RFC2750], which includes bandwidth reservations. Reservations are admitted or not based on whether the requested resources are available. State is 'soft' because its lifetime is limited, and thus must be refreshed periodically. Two integrated services are presently defined for Intserv. A Guaranteed Service (GS) [RFC2212] offers firm bounds on maximum end-to-end queueing delay (but not delay jitter) for flows that meet an agreed traffic specification (TSpec). A Controlled Load Service (CLS) offers no quantitative guarantees, but promises packet loss and delay closely approximating the QoS that same flow would receive from an unloaded network. The mechanisms used by Intserv, especially RSVP, have been found to have scaling problems with respect to wide deployment in the Internet [RFC2208] -- IP Differentiated Services (DiffServ) [RFC2475] is intended to provides coarse-grained QoS guarantees to aggregated flows. Scalability is expected to be realized by confining stateful mechanisms to the borders of a DiffServ domain. These border nodes mark (or enforce marking) of packets with a DiffServ codepoint (DSCP -- the 6 most significant bits of the former TOS byte or Traffic Class byte of the IPv4 or IPv6 datagram, respectively), which selects a defined per-hop behavior (PHB). That PHB defines the forwarding behavior which the packet will experience in each node of the DiffServ domain. A collection of packets with the same DSCP crossing a link in a particular direction is called a Behavior Aggregate (BA). Resources are allocated to behavior aggregates. No per-flow or per-BA signalling protocols are currently defined. DiffServ defines PHBs and not services. However, PHBs can be used by service providers in combination with other mechanisms (such as markers, shapers, policers and schedulers) to provide services. Three PHB groups are defined. The legacy class selector PHB group [RFC2474] provides a relative priority; this was provided to grandfather legacy use of the IP precedence field in the TOS byte of the IPv4 datagram. The Expedited Forwarding (EF) PHB [RFC2598] requires that the departure rate of a BA's packets from any diffserv node must equal or exceed a configurable rate. The EF PHB can be used to build low loss, low latency, low jitter, assured bandwidth, end-to-end services through DS domains. The Assured Forwarding (AF) PHB group [RFC2597] provides four independently forwarded AF classes. Within each AF class, a packet can be assigned one of three different levels of drop precedence. A DS node does not reorder IP packets of the same microflow if they belong to the same AF class. The AF PHB can be used, for example, to provide a so-called Olympic service, which has different levels (gold, silver, bronze), offering relatively better or worse delay and loss probability. Note that services constructed using DiffServ can offer QoS guarantees only on BAs, and not on individual microflows. .in -5 In general, the tradeoff between granularity and scaling tends to favor use of Intserv in edge domains (i.e., those most involved in serving hosts) and Diffserv in core domains. Subnet designers should consider whether and how their subnets can support Intserv or Diffserv. The following points should be addressed: -- If the subnet is designed to provide a constant rate service with no contention for subnet resources (e.g., pure TDM/TDMA), IntServ or DiffServ mechanisms can be used directly. -- Otherwise, means need to be provided to differentiate flows, aggregated flows or connections at the subnet layer. These need to be treated independently for purposes of discarding, queueing and scheduling. This can be done using stateful mechanisms (such as labels or connection identifiers), stateless mechanisms analogous to DSCPs or n-tuples within the subnet packet header (e.g., source and destination address and SAP). One or more flows at the IP layer can be associated with (or carried over) a flow or connection at the subnet layer. -- Mappings need to be made between the service elements supported by the subnet and the Intserv services or Diffserv [service? BA? PHB? -- things have gotten confusing in Diffserv, and maybe we can fill this in after Adelaide]. -- As part of those mappings, the subnet needs to be able to offer absolute guarantees and possibly relative assurances to the IP layer. Absolute priority mechanisms have been atrractive to subnet designers as they are easy to implement. However, they are not sufficient to provide absolute guarantees. Similarly, in order to support Diffserv class selectors, subnets (i.e., ATM) which have offered only absolute guarantees have had to be rearchitected to also support relative assurances. -- As noted elsewhere in this memo, mobility can strongly affect the kinds of guarantees that can be offered, and the confidence with which such guarantees can be offered. -- Different service objectives can result in different mechanisms or local paramters associated with those objectives. As an example, if the user of an Intserv service is highly intolerant of fixed delay, but more tolerant of packet loss, the subnet service might elect not to use FEC, or to use a less deep (and thus less robust) interleaver. -- Considerations on queueing, discard and scheduling discussed elsewhere in this memo also affect the QoS offered by the subnet. From owner-pilc@lerc.nasa.gov Thu Mar 16 17:03:42 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09524 for ; Thu, 16 Mar 2000 17:03:41 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA20483 for pilc-outgoing; Thu, 16 Mar 2000 16:21:16 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA20437 for ; Thu, 16 Mar 2000 16:21:13 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA20428; Thu, 16 Mar 2000 16:21:10 -0500 (EST) Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.0) id xma020368; Thu, 16 Mar 00 16:20:38 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23910; Thu, 16 Mar 2000 16:20:34 -0500 (EST) Message-Id: <200003162120.QAA23910@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-asym-01.txt Date: Thu, 16 Mar 2000 16:20:34 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : TCP Performance Implications of Network Asymmetry Author(s) : H. Balakrishnan, V. Padmanabhan Filename : draft-ietf-pilc-asym-01.txt Pages : 15 Date : 15-Mar-00 This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio networks, for different underlying reasons. However, the net effect on TCP performance is the same in both cases: performance degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender. This document details several solutions to these problems, which use a combination of local link-layer techniques and end-to-end mechanisms. Solutions to the problem of asymmetry are two-pronged: (i) techniques to manage the reverse channel used by ACKs, typically using header compression or reducing the frequency of TCP ACKs, and (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self-clocking. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-asym-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-asym-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-asym-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000315132949.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-asym-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-asym-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315132949.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Thu Mar 16 17:03:45 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09559 for ; Thu, 16 Mar 2000 17:03:44 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA20456 for pilc-outgoing; Thu, 16 Mar 2000 16:21:12 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA20413 for ; Thu, 16 Mar 2000 16:21:10 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA20417; Thu, 16 Mar 2000 16:21:09 -0500 (EST) Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.0) id xma020317; Thu, 16 Mar 00 16:20:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23812; Thu, 16 Mar 2000 16:20:20 -0500 (EST) Message-Id: <200003162120.QAA23812@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-pep-02.txt Date: Thu, 16 Mar 2000 16:20:20 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : Performance Enhancing Proxies Author(s) : J. Border, G. Montenegro, J. Griner, M. Kojo Filename : draft-ietf-pilc-pep-02.txt Pages : 39 Date : 15-Mar-00 This document provides a high level overview of Performance Enhancing Proxies. Different types of Performance Enhancing Proxies are described as well as the mechanisms used to improve performance. In addition, motivations for their development and use are described along with some the consequences of using them, especially in the context of the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-pep-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-pep-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-pep-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000315132939.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-pep-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-pep-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315132939.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Thu Mar 16 17:05:50 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10301 for ; Thu, 16 Mar 2000 17:05:49 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA20375 for pilc-outgoing; Thu, 16 Mar 2000 16:20:30 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA20339 for ; Thu, 16 Mar 2000 16:20:25 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA20333; Thu, 16 Mar 2000 16:20:24 -0500 (EST) Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.0) id xma020316; Thu, 16 Mar 00 16:20:15 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23758; Thu, 16 Mar 2000 16:20:11 -0500 (EST) Message-Id: <200003162120.QAA23758@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-slow-03.txt Date: Thu, 16 Mar 2000 16:20:11 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : End-to-end Performance Implications of Slow Links Author(s) : S. Dawkins, G. Montenegro, V. Magret, M. Kojo Filename : draft-ietf-pilc-slow-03.txt Pages : 14 Date : 15-Mar-00 This document makes performance-related recommendations for users of network paths that traverse 'very low bit-rate' links. 'Very low bit-rate' implies 'slower than we would like'. This recommendation may be useful in any network where hosts can saturate available bandwidth, but the design space for this recommendation explicitly includes connections that traverse 56 Kb/second modem links or 4.8 Kb/second wireless access links - both of which are widely deployed. This document discusses general-purpose mechanisms. Where application-specific mechanisms can outperform the relevant general-purpose mechanism, we point this out and explain why. This document has some recommendations in common with RFC 2689, 'Providing integrated services over low-bitrate links', especially in areas like header compression. This document focuses more on traditional data applications for which 'best-effort delivery' is appropriate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-slow-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-slow-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-slow-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000315132929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-slow-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-slow-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315132929.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Thu Mar 16 17:17:47 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15407 for ; Thu, 16 Mar 2000 17:17:46 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA22144 for pilc-outgoing; Thu, 16 Mar 2000 16:32:57 -0500 (EST) Received: from seraph2.lerc.nasa.gov (firewall-user@guardian02.lerc.nasa.gov [139.88.146.11]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA22129 for ; Thu, 16 Mar 2000 16:32:55 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id QAA02013; Thu, 16 Mar 2000 16:32:55 -0500 (EST) Received: from odin.ietf.org(132.151.1.176) by seraph2.lerc.nasa.gov via smap (V5.0) id xma023855; Thu, 16 Mar 00 16:20:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23706; Thu, 16 Mar 2000 16:20:05 -0500 (EST) Message-Id: <200003162120.QAA23706@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-error-03.txt Date: Thu, 16 Mar 2000 16:20:04 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : End-to-end Performance Implications of Links with Errors Author(s) : S. Dawkins, G. Montenegro, V. Magret, M. Kojo, N. Vaidya Filename : draft-ietf-pilc-error-03.txt Pages : 17 Date : 15-Mar-00 The rapidly-growing World Wide Web is being accessed by an increasingly wide range of devices over an increasingly wide variety of links. At least some of these links do not provide the reliability that hosts expect, and this expansion into unreliable links causes some Internet protocols, especially TCP [RFC793], to perform poorly. Specifically, TCP congestion avoidance procedures [RFC2561], while appropriate for connections that lose traffic primarily because of congestion and buffer exhaustion, interact badly with connections that traverse links with high uncorrected error rates. The result is that senders may spend an excessive amount of time waiting on acknowledgements that aren't coming, whether these losses are due to data losses in the forward path or acknowledgement losses in the return path, and then, although these losses are not due to congestion-related buffer exhaustion, the sending TCP then transmits at substantially reduced traffic levels as it probes the network to determine A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-error-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-error-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000315132916.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-error-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-error-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315132916.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Thu Mar 16 18:55:30 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22008 for ; Thu, 16 Mar 2000 18:55:29 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA02971 for pilc-outgoing; Thu, 16 Mar 2000 18:06:24 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA02959 for ; Thu, 16 Mar 2000 18:06:23 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA05699; Thu, 16 Mar 2000 18:06:23 -0500 (EST) Received: from motgate.mot.com(129.188.136.100) by seraph3.lerc.nasa.gov via smap (V5.0) id xma005649; Thu, 16 Mar 00 18:05:56 -0500 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id QAA25469 for ; Thu, 16 Mar 2000 16:05:55 -0700 (MST)] Received: [from vail.rsch.comm.mot.com (vail.rsch.comm.mot.com [145.1.80.110]) by mothost.mot.com (MOT-mothost 2.0) with SMTP id QAA24530 for ; Thu, 16 Mar 2000 16:05:54 -0700 (MST)] Received: from mysoreluxlt.rsch.comm.mot.com by vail.rsch.comm.mot.com (5.65v3.2/1.1.10.5/LJR-1) id AA09489; Thu, 16 Mar 2000 17:05:52 -0600 Message-Id: <38D168D0.A137488A@rsch.comm.mot.com> Date: Thu, 16 Mar 2000 17:05:52 -0600 From: Jayanth Mysore Organization: Motorola Labs X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-2 i686) X-Accept-Language: en Mime-Version: 1.0 To: Dan Grossman Cc: karn@qualcomm.com, pilc@grc.nasa.gov Subject: Re: Initial text on QoS References: <200003162101.QAA26386@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dan Grossman wrote: > Actually, I had some rather different things in mind for this section. Sorry > to be so late with this, I've been thinking about it for a while, and was > having difficulty organizing my thoughts. There's more to be said, but enough > delay (so to speak! :-) > > Dan > > ----------------------------- > The Internet has historically provided a single, undifferentiated best effort > service. As applications have emerged that have specific quality-of-service > (QoS) requirements, mechanisms have been, and continue to be developed to > support them. > > QoS, in the broadest sense, is defined as the set of service attributes that > the provider of a service offers to the user of a service. These service > attributes can be categorized as relating to performance, availability, > security or cost. However, this memo, like most treatments of QoS, considers > only the set of performance attributes. In the context of the IP and subnet > layers, the performance attributes of most interest are: > -- throughput > -- delay > -- delay jitter > -- packet loss ratio > -- errored packet rate > This memo does not attempt to define these. > > In a layered architecture, a layer enhances and/or degrades the service > provided to it by the layer below, so as to provide a service to the layer > above. Layers (especially the IP layer and below) contain impairments which > degrade performance. Examples of impairments include variable delays due to > queueing and scheduling, congestive discard and errored discard. Mechanisms > in the layers can enhance one service attribute possibly at the expense of > another. For example, a retransmission mechanism in a subnet enhances > (decreases) the packet loss ratio offered to the IP layer, at the expense of > degrading (increasing) delay variation. IP, however, does not contain such > mechanisms, since strict application of the end-to-end principle relegates > such functions to the TCP layer and above. > > The Internet has historically provided an undifferentiated best effort service > with no quantifiable service attributes. As applications have emerged that > have specific performance requirements, mechanisms have been, and continue to > be developed to support them. > .in +5 > -- IP Integrated Services (Intserv) [RFC1633] provides finely granular QoS > guarantees to individual flows. It uses stateful mechanisms: a 'soft' state > is installed in routers along the path using a Reservation Protocol (RSVP) > [RFC2750], which includes bandwidth reservations. Reservations are admitted > or not based on whether the requested resources are available. State is > 'soft' because its lifetime is limited, and thus must be refreshed > periodically. Two integrated services are presently defined for Intserv. A > Guaranteed Service (GS) [RFC2212] offers firm bounds on maximum end-to-end > queueing delay (but not delay jitter) for flows that meet an agreed traffic > specification (TSpec). A Controlled Load Service (CLS) offers no quantitative > guarantees, but promises packet loss and delay closely > approximating the QoS that same flow would receive from an unloaded network. > > The mechanisms used by Intserv, especially RSVP, have been found to have > scaling problems with respect to wide deployment in the Internet [RFC2208] > > -- IP Differentiated Services (DiffServ) [RFC2475] is intended to provides > coarse-grained QoS guarantees to aggregated flows. Scalability is expected to > be realized by confining stateful mechanisms to the borders of a DiffServ > domain. These border nodes mark (or enforce marking) of packets with a > DiffServ codepoint (DSCP -- the 6 most significant bits of the former TOS byte > or Traffic Class byte of the IPv4 or IPv6 datagram, respectively), which > selects a defined per-hop behavior (PHB). That PHB defines the forwarding > behavior which the packet will experience in each node of the DiffServ domain. > A collection of packets with the same DSCP crossing a link in a particular > direction is called a Behavior Aggregate (BA). Resources are allocated to > behavior aggregates. > > No per-flow or per-BA signalling protocols are currently defined. DiffServ > defines PHBs and not services. However, PHBs can be used by service providers > in combination with other mechanisms (such as markers, shapers, policers and > schedulers) to provide services. > > Three PHB groups are defined. The legacy class selector PHB group [RFC2474] > provides a relative priority; this was provided to grandfather legacy use of > the IP precedence field in the TOS byte of the IPv4 datagram. The Expedited > Forwarding (EF) PHB [RFC2598] requires that the departure rate of a BA's > packets from any diffserv node must equal or exceed a configurable rate. The > EF PHB can be used to build low loss, low latency, low jitter, assured > bandwidth, end-to-end services through DS domains. The Assured Forwarding (AF) > PHB group [RFC2597] provides four independently forwarded AF classes. Within > each AF class, a packet can be assigned one of three different levels of drop > precedence. A DS node does not reorder IP packets of the same microflow if > they belong to the same AF class. The AF PHB can be used, for example, to > provide a so-called Olympic service, which has different levels (gold, silver, > bronze), offering relatively better or worse delay and loss probability. > > Note that services constructed using DiffServ can offer QoS guarantees only on > BAs, and not on individual microflows. -- Core stateless approaches (Dynamic Packet State ) : Recently there have been proposals for supporting per flow commitments to flows using scalable cores. These approaches may potentially mature into standards in due course of time, given the richness of the services they can support. These architectures require edge routers to maintain per-flow state, while the core routers maintain no per-flow state. In the data path, edges mark packets of a flow with the minimum necessary state information required by a distributed algorithm implemented by an island of core routers. The core routers do not have to perform any packet classification, and update the state information on the packet header to achieve the committed end to end performance. They also propose admisison control algorithms that require no per flow state to support guaranteed services. Such schemes offer the advantage of supporting per flow commitments, using a scalable network architecture. > .in -5 > > In general, the tradeoff between granularity and scaling tends to favor use of > Intserv in edge domains (i.e., those most involved in serving hosts) and > Diffserv in core domains. (or alternately, core stateless approaches end to end) > > > Subnet designers should consider whether and how their subnets can support > Intserv or Diffserv. The following points should be addressed: > -- If the subnet is designed to provide a constant rate service with no > contention for subnet resources (e.g., pure TDM/TDMA), IntServ or DiffServ > mechanisms can be used directly. > -- Otherwise, means need to be provided to differentiate flows, aggregated > flows or connections at the subnet layer. These need to be treated > independently for purposes of discarding, queueing and scheduling. This can > be done using stateful mechanisms (such as labels or connection identifiers), > stateless mechanisms analogous to DSCPs or n-tuples within the subnet packet > header (e.g., source and destination address and SAP). One or more flows at > the IP layer can be associated with (or carried over) a flow or connection at > the subnet layer. > -- Mappings need to be made between the service elements supported by the > subnet and the Intserv services or Diffserv [service? BA? PHB? -- things have > gotten confusing in Diffserv, and maybe we can fill this in after Adelaide]. > -- As part of those mappings, the subnet needs to be able to offer absolute > guarantees and possibly relative assurances to the IP layer. Absolute > priority mechanisms have been atrractive to subnet designers as they are easy > to implement. However, they are not sufficient to provide absolute > guarantees. Similarly, in order to support Diffserv class selectors, subnets > (i.e., ATM) which have offered only absolute guarantees have had to be > rearchitected to also support relative assurances. > -- As noted elsewhere in this memo, mobility can strongly affect the kinds of > guarantees that can be offered, and the confidence with which such guarantees > can be offered. > -- Different service objectives can result in different mechanisms or local > paramters associated with those objectives. As an example, if the user of an > Intserv service is highly intolerant of fixed delay, but more tolerant of > packet loss, the subnet service might elect not to use FEC, or to use a less > deep (and thus less robust) interleaver. > -- Considerations on queueing, discard and scheduling discussed elsewhere in > this memo also affect the QoS offered by the subnet. > -Jayanth Mysore, Motorola Labs From owner-pilc@lerc.nasa.gov Fri Mar 17 09:33:55 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19637 for ; Fri, 17 Mar 2000 09:33:54 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA25067 for pilc-outgoing; Fri, 17 Mar 2000 08:23:48 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA25014 for ; Fri, 17 Mar 2000 08:23:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA15435; Fri, 17 Mar 2000 08:23:42 -0500 (EST) Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.0) id xma015398; Fri, 17 Mar 00 08:23:31 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22371; Fri, 17 Mar 2000 08:23:29 -0500 (EST) Message-Id: <200003171323.IAA22371@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-link-design-02.txt Date: Fri, 17 Mar 2000 08:23:28 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : Advice for Internet Subnetwork Designers Author(s) : P. Karn, J. Touch, J. Mahdavi, D. Grossman, G. Montenegro, A. Falk, M. Montpetit, G. Fairhurst Filename : draft-ietf-pilc-link-design-02.txt Pages : 21 Date : 16-Mar-00 This document provides advice to the designers of digital communication equipment, link layer protocols and packet switched subnetworks (collectively referred to as subnetworks) who wish to support the Internet protocols but who may be unfamiliar with the architecture of the Internet and the implications of their design choices on the performance and efficiency of the Internet. This document represents an evolving consensus of the members of the IETF Performance Implications of Link Characteristics (PILC) working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-link-design-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-link-design-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000316144725.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-link-design-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-link-design-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000316144725.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Fri Mar 17 10:31:09 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11916 for ; Fri, 17 Mar 2000 10:31:09 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA05863 for pilc-outgoing; Fri, 17 Mar 2000 09:38:04 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA05835 for ; Fri, 17 Mar 2000 09:38:01 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA25077; Fri, 17 Mar 2000 09:38:01 -0500 (EST) Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.0) id xma025029; Fri, 17 Mar 00 09:37:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21087; Fri, 17 Mar 2000 09:37:38 -0500 (EST) Message-Id: <200003171437.JAA21087@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-asym-01.txt Date: Fri, 17 Mar 2000 09:37:37 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : TCP Performance Implications of Network Asymmetry Author(s) : H. Balakrishnan, V. Padmanabhan Filename : draft-ietf-pilc-asym-01.txt Pages : 15 Date : 15-Mar-00 This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio networks, for different underlying reasons. However, the net effect on TCP performance is the same in both cases: performance degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender. This document details several solutions to these problems, which use a combination of local link-layer techniques and end-to-end mechanisms. Solutions to the problem of asymmetry are two-pronged: (i) techniques to manage the reverse channel used by ACKs, typically using header compression or reducing the frequency of TCP ACKs, and (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self-clocking. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-asym-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-asym-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-asym-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000315132949.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-asym-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-asym-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315132949.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Fri Mar 17 10:45:06 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17539 for ; Fri, 17 Mar 2000 10:45:06 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA06772 for pilc-outgoing; Fri, 17 Mar 2000 09:44:49 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA06743 for ; Fri, 17 Mar 2000 09:44:47 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA25899; Fri, 17 Mar 2000 09:44:47 -0500 (EST) Received: from unknown(208.217.183.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma025870; Fri, 17 Mar 00 09:44:10 -0500 Received: by atlconn1.panamsat.com with Internet Mail Service (5.5.2650.10) id ; Fri, 17 Mar 2000 09:44:08 -0500 Message-ID: <8046A317B5F4D21186610008C7EBB696F056CF@grnexch1.panamsat.com> From: "Falk, Aaron" To: "'pilc@grc.nasa.gov'" Cc: "Spencer Dawkins (E-mail)" , "'Gabriel Montenegro'" , "'vincent.magret@aud.alcatel.com'" , "Markku Kojo (E-mail)" , "'vaidya@cs.tamu.edu'" , "Vern Paxson (E-mail)" Subject: Working group last call for ERROR and SLOW Date: Fri, 17 Mar 2000 09:39:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk draft-ietf-pilc-error-03.txt and draft-ietf-pilc-slow-03.txt are both pretty mature and may be ready for submission to the IESG as Best Current Practice RFPs. Let's kick off a working group last call to end around March 31st. If you have any comments on the drafts, now is the time to get them in. They are available at: http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-03.txt http://www.ietf.org/internet-drafts/draft-ietf-pilc-slow-03.txt --aaron --- Aaron Falk Director - Internet Services Development PanAmSat Corporation Greenwich, Connecticut, USA * Phone: 203.861.8326 * Mobile: 203.912.5689 * Fax: 203.861.8677 * mailto:afalk@panamsat.com * http://www.panamsat.com From owner-pilc@lerc.nasa.gov Fri Mar 17 10:51:27 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20273 for ; Fri, 17 Mar 2000 10:51:26 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA09797 for pilc-outgoing; Fri, 17 Mar 2000 10:03:47 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA09760 for ; Fri, 17 Mar 2000 10:03:34 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA28659; Fri, 17 Mar 2000 10:03:33 -0500 (EST) Received: from unknown(208.217.183.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma028555; Fri, 17 Mar 00 10:02:47 -0500 Received: by atlconn1.panamsat.com with Internet Mail Service (5.5.2650.10) id ; Fri, 17 Mar 2000 10:02:45 -0500 Message-ID: <8046A317B5F4D21186610008C7EBB696F056D0@grnexch1.panamsat.com> From: "Falk, Aaron" To: "'agenda@ietf.org'" Cc: "'pilc@grc.nasa.gov'" , "Spencer Dawkins (E-mail)" , "Vern Paxson (E-mail)" Subject: Draft PILC Agenda for IETF-47, Adelaide, Australia Date: Fri, 17 Mar 2000 09:58:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Peformance Implications of Link Characteristics Working Group AGENDA TUESDAY, March 28, 2000 1415-1515 Afternoon Sessions II Adelaide Convention Centre in Adelaide, Australia Room 4&5 5 minutes: Agenda-bashing 5 minutes: Working Group Status 5 minutes: draft-ietf-pilc-error-03.txt 5 minutes: draft-ietf-pilc-slow-03.txt 10 minutes: draft-ietf-pilc-asym-01.txt 10 minutes: draft-ietf-pilc-link-design-02.txt 10 minutes: draft-ietf-pilc-pep-02.txt For information on IETF-47 see http://www.ietf.org/meetings/IETF-47.html For copies of drafts see http://www.ietf.org/ids.by.wg/pilc.html From owner-pilc@lerc.nasa.gov Fri Mar 17 19:29:43 2000 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17325 for ; Fri, 17 Mar 2000 19:29:42 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA14754 for pilc-outgoing; Fri, 17 Mar 2000 18:24:21 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA14726 for ; Fri, 17 Mar 2000 18:24:18 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA02581; Fri, 17 Mar 2000 18:24:18 -0500 (EST) Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma002560; Fri, 17 Mar 00 18:24:04 -0500 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id PAA19122 for ; Fri, 17 Mar 2000 15:24:03 -0800 (PST) Message-ID: <38D2BE75.7CFE74FA@isi.edu> Date: Fri, 17 Mar 2000 15:23:33 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: pilc@grc.nasa.gov Subject: Announcing X-Bone VPN/overlay software release References: <200003110232.SAA01246@servo.qualcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit The following may be of interest to PILC - to setup IP testbeds... -- Joe ----------- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx x x x XX XX X-BONE Overlay System x x X X x x XX Software Release x x X X x x XX XX March 2000 x x x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx The X-Bone system for automated deployment of VPN / overlay networks is now publicly available. This is the first major public release, v1.2. X-Bone dynamically deploys and manages Internet overlays to reduce configuration effort and increase network component sharing. X-Bone discovers, configures, and monitors network resources to create overlays over existing IP networks. The X-Bone is implemented in Perl, and open source is provided. The X-Bone can be used for: - deploying VPNs - sharing lab or wide-area networks for multiple, concurrent projects for testing protocols and apps on new topologies X-Bone uses two-layer IP in IP tunneled overlays and supports existing applications and unmodified routing, multicast, and DNS services. X-Bone also support IPSec within overlays. Applications can use the X-Bone without modification or recompilation. The X-Bone is available for the following operating systems: - FreeBSD CAIRN 2.5, 3.*, 3.* + KAME IPsec patches - Linux RedHat 6.0, 6.0 + NIST Cerberus IPsec patches, 6.1 The FreeBSD port and Linux RPM have been submitted to the FreeBSD ports and RedHat Linux RPMs sites; further information and details and the port and RPM files are currently available at: http://www.isi.edu/xbone/ - Joe Touch Project Leader, X-Bone group, USC/ISI touch@isi.edu http://www.isi.edu/touch +1 (310) 448-9151 ------------------------------------------------------------------- Effort sponsored by the Defense Advanced Research Projects Agency (DARPA)and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-98-1-0200. Copyright (c) 1998-2000 by the University of Southern California. All rights reserved. ------------------------------------------------------------------- From owner-pilc@lerc.nasa.gov Mon Mar 20 18:50:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03248 for ; Mon, 20 Mar 2000 18:50:02 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA08880 for pilc-outgoing; Mon, 20 Mar 2000 17:50:21 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA08846 for ; Mon, 20 Mar 2000 17:50:19 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA06696; Mon, 20 Mar 2000 17:50:18 -0500 (EST) Received: from unknown(208.217.183.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma006610; Mon, 20 Mar 00 17:49:46 -0500 Received: by atlconn1.panamsat.com with Internet Mail Service (5.5.2650.10) id ; Mon, 20 Mar 2000 17:49:45 -0500 Message-ID: <8046A317B5F4D21186610008C7EBB696F056FD@grnexch1.panamsat.com> From: "Falk, Aaron" To: "'pilc@grc.nasa.gov'" Cc: "Spencer Dawkins (E-mail)" , "'Gabriel Montenegro'" , "'vincent.magret@aud.alcatel.com'" , "Markku Kojo (E-mail)" , "'vaidya@cs.tamu.edu'" , "Vern Paxson (E-mail)" Subject: Extended: Working group last call for ERROR and SLOW Date: Mon, 20 Mar 2000 17:45:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Let's extend the last call a week, to 4/7, to make things easier on those who will be traveling. --aaron > > draft-ietf-pilc-error-03.txt and draft-ietf-pilc-slow-03.txt > are both pretty > mature and may be ready for submission to the IESG as Best > Current Practice > RFPs. Let's kick off a working group last call to end around > March 31st. If > you have any comments on the drafts, now is the time to get them in. > > They are available at: > > http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-03.txt > > http://www.ietf.org/internet-drafts/draft-ietf-pilc-slow-03.txt > > --aaron > From owner-pilc@lerc.nasa.gov Thu Mar 30 19:21:25 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23851 for ; Thu, 30 Mar 2000 19:21:24 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA14823 for pilc-outgoing; Thu, 30 Mar 2000 18:21:50 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA14755 for ; Thu, 30 Mar 2000 18:21:44 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA18357; Thu, 30 Mar 2000 18:21:44 -0500 (EST) Received: from breeze.lcs.mit.edu(18.31.0.83) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018321; Thu, 30 Mar 00 18:21:03 -0500 Received: from breeze.lcs.mit.edu (hari@localhost [127.0.0.1]) by breeze.lcs.mit.edu (8.8.7/8.8.7) with ESMTP id SAA12600; Thu, 30 Mar 2000 18:23:18 -0500 Message-Id: <200003302323.SAA12600@breeze.lcs.mit.edu> X-Mailer: exmh version 2.0.2 Reply-To: Hari Balakrishnan X-url: http://wind.lcs.mit.edu/~hari/ To: Xavi cc: pilc@grc.nasa.gov Subject: Re: Snoop mailing list In-reply-to: Your message of "Fri, 31 Mar 2000 01:13:52 +0200" <38E3DFB0.5A916A6C@menta.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Thu, 30 Mar 2000 18:23:18 -0500 From: Hari Balakrishnan Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id SAA14810 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Xavi, As far as I know, there isn't one. Hari On Fri, 31 Mar 2000 01:13:52 +0200, you wrote: > Hi there, > > Excuse me for the slightly off-topic question, I'd be very grateful if > anybody could tell me if there's a mailing-list or newsgroup devoted to > the Snoop protocol. Has there been one ever? Any other and perhaps more > appropriate forum where to ask? > Thanks in advance, > > Xavi De Porrata > Dept. de Matemātica Aplicada i Telemātica > Universitat Politčcnica de Catalunya > From owner-pilc@lerc.nasa.gov Thu Mar 30 19:21:32 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23861 for ; Thu, 30 Mar 2000 19:21:30 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA14082 for pilc-outgoing; Thu, 30 Mar 2000 18:11:17 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA14059 for ; Thu, 30 Mar 2000 18:11:13 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA17295; Thu, 30 Mar 2000 18:11:13 -0500 (EST) Received: from sahara.cablecat.com(212.78.128.11) by seraph3.lerc.nasa.gov via smap (V5.0) id xma017223; Thu, 30 Mar 00 18:10:31 -0500 Received: from menta.net (dom5-29.menta.net [212.78.156.29]) by sahara.cablecat.com (8.8.8+Sun/8.8.8) with ESMTP id BAA22583 for ; Fri, 31 Mar 2000 01:10:25 +0200 (MET DST) Message-ID: <38E3DFB0.5A916A6C@menta.net> Date: Fri, 31 Mar 2000 01:13:52 +0200 From: Xavi X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: pilc@grc.nasa.gov Subject: Snoop mailing list Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by sahara.cablecat.com id BAA22583 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id SAA14067 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Hi there, Excuse me for the slightly off-topic question, I'd be very grateful if anybody could tell me if there's a mailing-list or newsgroup devoted to the Snoop protocol. Has there been one ever? Any other and perhaps more appropriate forum where to ask? Thanks in advance, Xavi De Porrata Dept. de Matemātica Aplicada i Telemātica Universitat Politčcnica de Catalunya From owner-pilc@lerc.nasa.gov Fri Mar 31 04:45:34 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11413 for ; Fri, 31 Mar 2000 04:45:33 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA12180 for pilc-outgoing; Fri, 31 Mar 2000 03:34:37 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id DAA12176 for ; Fri, 31 Mar 2000 03:34:36 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA05314; Fri, 31 Mar 2000 03:34:35 -0500 (EST) Received: from kuma.cc.upv.es(158.42.4.6) by seraph3.lerc.nasa.gov via smap (V5.0) id xma005243; Fri, 31 Mar 00 03:33:47 -0500 Received: from vega.upv.es (vega.cc.upv.es [158.42.4.1]) by kuma.upv.es (8.9.3/8.9.3) with ESMTP id KAA11740; Fri, 31 Mar 2000 10:33:14 +0200 Received: from disca.upv.es (montgo.disca.upv.es [158.42.50.203]) by vega.upv.es (8.8.4/8.8.5) with SMTP id KAA28520; Fri, 31 Mar 2000 10:33:06 +0200 (METDST) Received: from ieee.org by disca.upv.es (SMI-8.6/SMI-SVR4) id KAA27132; Fri, 31 Mar 2000 10:45:51 +0100 Message-ID: <38E46321.46FBA326@ieee.org> Date: Fri, 31 Mar 2000 10:34:41 +0200 From: Miguel Sanchez Organization: Universidad Politecnica de Valencia X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Xavi CC: pilc@grc.nasa.gov Subject: Re: Snoop mailing list References: <38E3DFB0.5A916A6C@menta.net> Content-Type: multipart/alternative; boundary="------------80A2044C3640BF75A845B33E" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --------------80A2044C3640BF75A845B33E Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by kuma.upv.es id KAA11740 Content-Transfer-Encoding: quoted-printable You can find useful information and publications in here: http://www.cs.berkeley.edu/~hari/papers/snoop.html Best, Miguel Xavi wrote: > Hi there, > > Excuse me for the slightly off-topic question, I'd be very grateful if > anybody could tell me if there's a mailing-list or newsgroup devoted to > the Snoop protocol. Has there been one ever? Any other and perhaps more > appropriate forum where to ask? > Thanks in advance, > > Xavi De Porrata > Dept. de Matem=E0tica Aplicada i Telem=E0tica > Universitat Polit=E8cnica de Catalunya -- Miguel Sanchez Lopez | misan@ieee.org Universidad Politecnica de Valencia | voice:+3496 387 9700 Camino de Vera, 14 | fax: +3496 387 7579 46071 VALENCIA (Spain) | --------------80A2044C3640BF75A845B33E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit You can find useful information and publications in here:

http://www.cs.berkeley.edu/~hari/papers/snoop.html

Best,

Miguel

Xavi wrote:

Hi there,

Excuse me for the slightly off-topic question, I'd be very grateful if
anybody could tell me if there's a mailing-list or newsgroup devoted to
the Snoop protocol. Has there been one ever? Any other and perhaps more
appropriate forum where to ask?
Thanks in advance,

Xavi De Porrata
Dept. de Matemàtica Aplicada i Telemàtica
Universitat Politècnica de Catalunya

-- 
Miguel Sanchez Lopez                            |       misan@ieee.org
Universidad Politecnica de Valencia             | voice:+3496 387 9700  
Camino de Vera, 14                              | fax:  +3496 387 7579 
46071 VALENCIA (Spain)                          |
  --------------80A2044C3640BF75A845B33E--