From owner-tcp-impl@lerc.nasa.gov Fri Oct 13 19:23: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 SMTP id TAA13181 for ; Fri, 13 Oct 2000 19:23:27 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA24194 for tcp-impl-outgoing; Fri, 13 Oct 2000 16:30:52 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA24155 for ; Fri, 13 Oct 2000 16:30:49 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA15267; Fri, 13 Oct 2000 16:30:49 -0400 Received: from palrel3.hp.com(156.153.255.226) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014915; Fri, 13 Oct 00 16:30:18 -0400 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by palrel3.hp.com (Postfix) with ESMTP id 4C54A72B for ; Fri, 13 Oct 2000 13:30:03 -0700 (PDT) Received: from cup.hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id NAA25672 for ; Fri, 13 Oct 2000 13:30:02 -0700 (PDT) Message-ID: <39E770CA.5A71C271@cup.hp.com> Date: Fri, 13 Oct 2000 13:30:02 -0700 From: Rick Jones Organization: the Unofficial HP X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: DF and IP ID Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit If an implementation of IP sets the DF bit in the header, does it need to worry about using unique IP datagram identifiers? rick -- rachel marina jones, 09/24 0317, 7lbs, 7oz, 20" these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, OR post, but please do NOT do BOTH... my email address is raj in the cup.hp.com domain... From owner-tcp-impl@lerc.nasa.gov Sat Oct 14 13:00:05 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04278 for ; Sat, 14 Oct 2000 13:00:04 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA10828 for tcp-impl-outgoing; Sat, 14 Oct 2000 10:49:21 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA10807 for ; Sat, 14 Oct 2000 10:49:19 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA17793; Sat, 14 Oct 2000 10:49:18 -0400 Received: from ihemail2.lucent.com(192.11.222.163) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017653; Sat, 14 Oct 00 10:48:32 -0400 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA28627 for ; Sat, 14 Oct 2000 10:48:27 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA28617 for ; Sat, 14 Oct 2000 10:48:26 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4Y6352N8>; Sat, 14 Oct 2000 15:48:25 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C048773BF@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: tcp-impl@grc.nasa.gov, "'Rick Jones'" Subject: RE: DF and IP ID Date: Sat, 14 Oct 2000 15:48:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk I agree the IP ID may be useless in that case. However, I'm courious to understand the benefit of implementing an implementation that cannot appropriately set the IP-ID in the cases when it is needed (i.e, does it make sense to have such an implementation, and in which case?). alessio > ---------- > From: Rick Jones[SMTP:raj@cup.hp.com] > Sent: 13 October 2000 21:30 > To: tcp-impl@grc.nasa.gov > Subject: DF and IP ID > > If an implementation of IP sets the DF bit in the header, does it need > to worry about using unique IP datagram identifiers? > > rick > -- > rachel marina jones, 09/24 0317, 7lbs, 7oz, 20" > these opinions are mine, all mine; HP might not want them anyway... :) > feel free to email, OR post, but please do NOT do BOTH... > my email address is raj in the cup.hp.com domain... > From owner-tcp-impl@lerc.nasa.gov Sat Oct 14 13:00: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 SMTP id NAA04289 for ; Sat, 14 Oct 2000 13:00:24 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA10449 for tcp-impl-outgoing; Sat, 14 Oct 2000 10:36:14 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA10441 for ; Sat, 14 Oct 2000 10:36:13 -0400 (EDT) From: kuznet@ms2.inr.ac.ru Received: by seraph3.lerc.nasa.gov; id KAA15641; Sat, 14 Oct 2000 10:36:12 -0400 Received: from minus.inr.ac.ru(193.233.7.97) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015620; Sat, 14 Oct 00 10:36:10 -0400 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id SAA11334; Sat, 14 Oct 2000 18:25:21 +0400 Message-Id: <200010141425.SAA11334@ms2.inr.ac.ru> Subject: Re: DF and IP ID To: raj@cup.hp.com (Rick Jones) Date: Sat, 14 Oct 2000 18:25:21 +0400 (MSK DST) Cc: tcp-impl@grc.nasa.gov In-Reply-To: <39E770CA.5A71C271@cup.hp.com> from "Rick Jones" at Oct 13, 0 01:30:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hello! > If an implementation of IP sets the DF bit in the header, does it need > to worry about using unique IP datagram identifiers? They are useless. F.e. IPv6, where all the packets have implicit DF, generates identification only for fragmented packets or in packets, which are allowed to be fragmented by adding explicit frag header. There are no reasons not to downgrade this finding to IPv4. In fact, linux-2.4 does this. Alexey Kuznetsov From owner-tcp-impl@lerc.nasa.gov Sat Oct 14 14:30:29 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04636 for ; Sat, 14 Oct 2000 14:30:29 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA13514 for tcp-impl-outgoing; Sat, 14 Oct 2000 12:19:35 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA13507 for ; Sat, 14 Oct 2000 12:19:24 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA03904; Sat, 14 Oct 2000 12:19:23 -0400 Received: from palrel3.hp.com(156.153.255.226) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003864; Sat, 14 Oct 00 12:19:08 -0400 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by palrel3.hp.com (Postfix) with ESMTP id 2836798B; Sat, 14 Oct 2000 09:19:06 -0700 (PDT) Received: (from raj@localhost) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) id JAA27370; Sat, 14 Oct 2000 09:19:05 -0700 (PDT) From: Rick Jones Message-Id: <200010141619.JAA27370@tardy.cup.hp.com> Subject: Re: DF and IP ID To: kuznet@ms2.inr.ac.ru Date: Sat, 14 Oct 2000 09:19:05 -0700 (PDT) Cc: tcp-impl@grc.nasa.gov In-Reply-To: <200010141425.SAA11334@ms2.inr.ac.ru> from "kuznet@ms2.inr.ac.ru" at Oct "14," 2000 "06:25:21" pm X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > > If an implementation of IP sets the DF bit in the header, does it need > > to worry about using unique IP datagram identifiers? > > They are useless. > > F.e. IPv6, where all the packets have implicit DF, generates > identification only for fragmented packets or in packets, which > are allowed to be fragmented by adding explicit frag header. > There are no reasons not to downgrade this finding to IPv4. > > In fact, linux-2.4 does this. Are there any places where the DF bit might get cleared along the way? Perhaps NAT or firewall or something? Or perhaps if there was a change in the flow where the point of origin decided to clear the DF bit on its own? How about the "be conservative in what you send" half of the Internet Axiom? rick jones From owner-tcp-impl@lerc.nasa.gov Sat Oct 14 15:25: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 SMTP id PAA04905 for ; Sat, 14 Oct 2000 15:25:24 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA14872 for tcp-impl-outgoing; Sat, 14 Oct 2000 13:07:47 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA14864 for ; Sat, 14 Oct 2000 13:07:46 -0400 (EDT) From: kuznet@ms2.inr.ac.ru Received: by seraph3.lerc.nasa.gov; id NAA11070; Sat, 14 Oct 2000 13:07:45 -0400 Received: from minus.inr.ac.ru(193.233.7.97) by seraph3.lerc.nasa.gov via smap (V5.5) id xma010915; Sat, 14 Oct 00 13:06:58 -0400 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA11942; Sat, 14 Oct 2000 20:50:52 +0400 Message-Id: <200010141650.UAA11942@ms2.inr.ac.ru> Subject: Re: DF and IP ID To: raj@cup.hp.com (Rick Jones) Date: Sat, 14 Oct 2000 20:50:52 +0400 (MSK DST) Cc: tcp-impl@grc.nasa.gov In-Reply-To: <200010141619.JAA27370@tardy.cup.hp.com> from "Rick Jones" at Oct 14, 0 09:19:05 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hello! > Are there any places where the DF bit might get cleared along the way? It is its goal not to be ever cleared. 8) > Perhaps NAT Dynamic NAT which has to defragment packets to transform them (it is the only place where DF can be cleared), has to regenerate IP IDs in any case otherwise flows from different hosts will collide. > How about the "be conservative in what you send" half of the > Internet Axiom? You are allowed to make plain sillogisms from MUSTs made in base RFCs. 8) Note also, that taking into account that at modern rates 16bit IP ID finally lost its sense (~100 different packets with one src/dst/protocol/ID in flight is rule. 8)), path MTU discovery became mandatory years ago and fragmentation (sorry, not fragmentation, but tagging each packet) on big internet is simply impossible. In fact, avoiding useless lossage of too small ID space for almost all the packets except for really fragmented ones is the only solution to this problem. Alexey Kuznetsov From owner-tcp-impl@lerc.nasa.gov Sun Oct 15 04:15: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 SMTP id EAA06957 for ; Sun, 15 Oct 2000 04:15:25 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA02204 for tcp-impl-outgoing; Sat, 14 Oct 2000 22:59:45 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id WAA02192 for ; Sat, 14 Oct 2000 22:59:40 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id WAA10128; Sat, 14 Oct 2000 22:59:40 -0400 Received: from starburst.demon.co.uk(194.222.114.233) by seraph3.lerc.nasa.gov via smap (V5.5) id xma009972; Sat, 14 Oct 00 22:58:42 -0400 Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id DAA09567; Sun, 15 Oct 2000 03:49:54 +0100 From: Richard Wendland Message-Id: <200010150249.DAA09567@starburst.demon.co.uk> Subject: Re: DF and IP ID To: raj@cup.hp.com (Rick Jones) Date: Sun, 15 Oct 2000 03:49:53 +0100 (BST) Cc: kuznet@ms2.inr.ac.ru, tcp-impl@grc.nasa.gov Reply-To: richard@wendland.org.uk (Richard Wendland) In-Reply-To: <200010141619.JAA27370@tardy.cup.hp.com> from "Rick Jones" at Oct 14, 2000 09:19:05 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > > > If an implementation of IP sets the DF bit in the header, does it need > > > to worry about using unique IP datagram identifiers? > > Are there any places where the DF bit might get cleared along the way? > Perhaps NAT or firewall or something? Clearing DF seems like the kind of thing some HTTP load balancers would do. Though if they clear DF, hopefully they'd set their own ID as well, but I wouldn't always bet on it. As an example of this kind of thing, look closely at HTTP traffic to www.drugstore.com, which appears to use some kind of load balancer. It looks like most of the conversation is mediated by some device which clears DF, but the FIN & FIN ACK is left for NT4 to send unmediated so has DF set. In this case, as this device seems to set its own ID, there wouldn't have been a problem had the web server OS set ID zero. But it seems a good idea "to be conservative in what you send", and follow traditional behaviour of always providing an ID that would work for fragmentation. Here's some example tcpdump output: client.1588 > www.drugstore.com.80: S 993978469:993978469(0) win 16384 (DF) (ttl 64, id 37921) www.drugstore.com.80 > client.1588: S 1775436697:1775436697(0) ack 993978470 win 8192 (ttl 45, id 56701) client.1588 > www.drugstore.com.80: . ack 1 win 17520 (DF) (ttl 64, id 37923) client.1588 > www.drugstore.com.80: P 1:45(44) ack 1 win 17520 (DF) (ttl 64, id 37924) www.drugstore.com.80 > client.1588: P 1:576(575) ack 45 win 8192 (ttl 45, id 56745) # from now on www.drugstore.com sets DF, # with traffic direct from NT4 with a larger window and TTL www.drugstore.com.80 > client.1588: F 576:576(0) ack 45 win 8716 (DF) (ttl 108, id 62163) client.1588 > www.drugstore.com.80: . ack 577 win 17520 (DF) (ttl 64, id 37928) client.1588 > www.drugstore.com.80: F 45:45(0) ack 577 win 17520 (DF) (ttl 64, id 37929) www.drugstore.com.80 > client.1588: . ack 46 win 8716 (DF) (ttl 108, id 3028) Richard -- Richard Wendland richard@wendland.org.uk From owner-tcp-impl@lerc.nasa.gov Sun Oct 15 04: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 SMTP id EAA07026 for ; Sun, 15 Oct 2000 04:36:27 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA05151 for tcp-impl-outgoing; Sun, 15 Oct 2000 00:07:17 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id AAA05137 for ; Sun, 15 Oct 2000 00:07:16 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id AAA19326; Sun, 15 Oct 2000 00:07:15 -0400 Received: from colin.muc.de(193.149.48.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma019205; Sun, 15 Oct 00 00:06:35 -0400 Received: by colin.muc.de id <140604-2>; Sun, 15 Oct 2000 06:06:24 +0200 Message-ID: <20001015060619.55614@colin.muc.de> From: Andi Kleen To: kuznet@ms2.inr.ac.ru Cc: Rick Jones , tcp-impl@grc.nasa.gov Subject: Re: DF and IP ID References: <200010141619.JAA27370@tardy.cup.hp.com> <200010141650.UAA11942@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <200010141650.UAA11942@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Sat, Oct 14, 2000 at 09:33:19PM +0200 Date: Sun, 15 Oct 2000 06:06:20 +0200 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Sat, Oct 14, 2000 at 09:33:19PM +0200, kuznet@ms2.inr.ac.ru wrote: > Hello! > > > Are there any places where the DF bit might get cleared along the way? > > It is its goal not to be ever cleared. 8) Unfortunately there are lots of tunnels who effectily ignore it. They add an outer header that decreases the MTU of the link. Normally they should send an fragmentation required ICMP to the sender, but with the many pmtu blackholes on the internet that breaks often, so they fragment instead. The fragments are likely to not carry DF bits. [Yes, it is broken, but it is reality] -Andi From owner-tcp-impl@lerc.nasa.gov Sun Oct 15 17:27: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 SMTP id RAA10636 for ; Sun, 15 Oct 2000 17:27:51 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA05166 for tcp-impl-outgoing; Sun, 15 Oct 2000 15:19:27 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA05158 for ; Sun, 15 Oct 2000 15:19:25 -0400 (EDT) From: kuznet@ms2.inr.ac.ru Received: by seraph3.lerc.nasa.gov; id PAA28635; Sun, 15 Oct 2000 15:19:25 -0400 Received: from minus.inr.ac.ru(193.233.7.97) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028461; Sun, 15 Oct 00 15:18:25 -0400 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id XAA23801; Sun, 15 Oct 2000 23:07:59 +0400 Message-Id: <200010151907.XAA23801@ms2.inr.ac.ru> Subject: Re: DF and IP ID To: ak@muc.de (Andi Kleen) Date: Sun, 15 Oct 2000 23:07:59 +0400 (MSK DST) Cc: raj@cup.hp.com, tcp-impl@grc.nasa.gov In-Reply-To: <20001015060619.55614@colin.muc.de> from "Andi Kleen" at Oct 15, 0 06:06:20 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hello! > Unfortunately there are lots of tunnels who effectily ignore it. ... > [Yes, it is broken, but it is reality] Andi, ID in tunneled packet has nothing in common with original one. 8) Alexey From owner-tcp-impl@lerc.nasa.gov Sun Oct 15 17:35: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 SMTP id RAA10671 for ; Sun, 15 Oct 2000 17:35:44 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA05753 for tcp-impl-outgoing; Sun, 15 Oct 2000 15:40:38 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA05749 for ; Sun, 15 Oct 2000 15:40:37 -0400 (EDT) From: kuznet@ms2.inr.ac.ru Received: by seraph3.lerc.nasa.gov; id PAA02671; Sun, 15 Oct 2000 15:40:36 -0400 Received: from minus.inr.ac.ru(193.233.7.97) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002436; Sun, 15 Oct 00 15:39:52 -0400 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id XAA23882; Sun, 15 Oct 2000 23:29:59 +0400 Message-Id: <200010151929.XAA23882@ms2.inr.ac.ru> Subject: Re: DF and IP ID To: richard@wendland.org.uk Date: Sun, 15 Oct 2000 23:29:59 +0400 (MSK DST) Cc: raj@cup.hp.com, tcp-impl@grc.nasa.gov In-Reply-To: <200010150249.DAA09567@starburst.demon.co.uk> from "Richard Wendland" at Oct 15, 0 03:49:53 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hello! > Clearing DF seems like the kind of thing some HTTP load balancers > would do. Servers sitting behind such balancer must have pmtu discovery disabled. It is not useful in such case. Actually, known to me splicers handle DF absolutely correctly and even more! Some of them enforce pmtu discovery to keep mss in right state. 8) So that instead of disabling DF on servers, which support it, it is not so bad idea to replace bad balancer with real one yet. Alexey From owner-tcp-impl@lerc.nasa.gov Sun Oct 15 18:50: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 SMTP id SAA10976 for ; Sun, 15 Oct 2000 18:50:17 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA07819 for tcp-impl-outgoing; Sun, 15 Oct 2000 16:46:09 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA07808 for ; Sun, 15 Oct 2000 16:46:07 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA14609; Sun, 15 Oct 2000 16:46:07 -0400 Received: from colin.muc.de(193.149.48.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014423; Sun, 15 Oct 00 16:45:01 -0400 Received: by colin.muc.de id <140612-2>; Sun, 15 Oct 2000 22:44:44 +0200 Message-ID: <20001015224440.17763@colin.muc.de> From: Andi Kleen To: kuznet@ms2.inr.ac.ru Cc: Andi Kleen , raj@cup.hp.com, tcp-impl@grc.nasa.gov Subject: Re: DF and IP ID References: <20001015060619.55614@colin.muc.de> <200010151907.XAA23801@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <200010151907.XAA23801@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Sun, Oct 15, 2000 at 09:08:07PM +0200 Date: Sun, 15 Oct 2000 22:44:40 +0200 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Sun, Oct 15, 2000 at 09:08:07PM +0200, kuznet@ms2.inr.ac.ru wrote: > Hello! > > > Unfortunately there are lots of tunnels who effectily ignore it. > ... > > [Yes, it is broken, but it is reality] > > Andi, ID in tunneled packet has nothing in common with original one. 8) Just the DF is effectively gone (that was my whole point) -Andi From owner-tcp-impl@lerc.nasa.gov Mon Oct 16 04:22: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 SMTP id EAA00579 for ; Mon, 16 Oct 2000 04:22:28 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA29747 for tcp-impl-outgoing; Mon, 16 Oct 2000 02:15:54 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id CAA29735 for ; Mon, 16 Oct 2000 02:15:48 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id CAA07853; Mon, 16 Oct 2000 02:15:47 -0400 Received: from mercury.sun.com(192.9.25.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007790; Mon, 16 Oct 00 02:15:25 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA08204; Sun, 15 Oct 2000 23:15:03 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.89.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id XAA25400; Sun, 15 Oct 2000 23:15:02 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.1+Sun/8.11.1) with SMTP id e9G6F1f779455; Sun, 15 Oct 2000 23:15:01 -0700 (PDT) Date: Sun, 15 Oct 2000 23:14:45 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DF and IP ID To: Rick Jones Cc: kuznet@ms2.inr.ac.ru, tcp-impl@grc.nasa.gov In-Reply-To: "Your message with ID" <200010141619.JAA27370@tardy.cup.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Are there any places where the DF bit might get cleared along the way? > Perhaps NAT or firewall or something? Or perhaps if there was a change > in the flow where the point of origin decided to clear the DF bit on > its own? How about the "be conservative in what you send" half of the > Internet Axiom? I've seen discussions about some PPPoE equipment used for frame relay which either clears DF or fragments packets even if DF was set. This "feature" was viewed as needed since some senders of packets with DF bit set sit behind firewalls that discard all ICMP packets. So "conservative in what you send" is probably a good idea since folks do "creative" things out there. Erik From owner-tcp-impl@lerc.nasa.gov Mon Oct 16 11:04: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 SMTP id LAA07066 for ; Mon, 16 Oct 2000 11:04:02 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA27580 for tcp-impl-outgoing; Mon, 16 Oct 2000 08:43:52 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA27535 for ; Mon, 16 Oct 2000 08:43:48 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id IAA17885; Mon, 16 Oct 2000 08:43:48 -0400 Received: from twig.rodents.montreal.qc.ca(216.46.5.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016936; Mon, 16 Oct 00 08:42:50 -0400 Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id IAA25349; Mon, 16 Oct 2000 08:42:36 -0400 (EDT) Date: Mon, 16 Oct 2000 08:42:36 -0400 (EDT) From: der Mouse Message-Id: <200010161242.IAA25349@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: tcp-impl@grc.nasa.gov Subject: Re: DF and IP ID Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > I've seen discussions about some PPPoE equipment used for frame relay > which either clears DF or fragments packets even if DF was set. This > "feature" was viewed as needed since some senders of packets with DF > bit set sit behind firewalls that discard all ICMP packets. Um, surely the correct fix, when faced with a broken site, is to get it fixed, not to break other software to "fix" it? Yes, it's annoying. I'm behind a low-MTU link and relatively often see what I have been calling "the won't frag disease" - indeed, one of my own connectivity provider's websites has it. But "fixing" brokenness by breaking something else only encourages that brokenness, by avoiding the penalty that usually accompanies brokenness. Not that you people on this list *can* fix all such brokenness even if you agree with me. But I don't see it as reason for us to care about it and try to spec around it, any more than a (hypothetical, as far as I know) site that dropped anything to an even port number would make it appropriate to assign only odd port numbers. der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@lerc.nasa.gov Mon Oct 16 14:01: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 SMTP id OAA12089 for ; Mon, 16 Oct 2000 14:01:11 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA29883 for tcp-impl-outgoing; Mon, 16 Oct 2000 11:36:18 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA29846 for ; Mon, 16 Oct 2000 11:36:15 -0400 (EDT) From: kuznet@ms2.inr.ac.ru Received: by seraph3.lerc.nasa.gov; id LAA22057; Mon, 16 Oct 2000 11:36:13 -0400 Received: from minus.inr.ac.ru(193.233.7.97) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021848; Mon, 16 Oct 00 11:36:03 -0400 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA05926; Mon, 16 Oct 2000 19:25:36 +0400 Message-Id: <200010161525.TAA05926@ms2.inr.ac.ru> Subject: Re: DF and IP ID To: ak@muc.de (Andi Kleen) Date: Mon, 16 Oct 2000 19:25:36 +0400 (MSK DST) Cc: ak@muc.de, raj@cup.hp.com, tcp-impl@grc.nasa.gov In-Reply-To: <20001015224440.17763@colin.muc.de> from "Andi Kleen" at Oct 15, 0 10:44:40 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hello! > Just the DF is effectively gone (that was my whole point) That's why on Linux tunnels over IP sych fragmentaion is not used by default. And it is difficult to turn it on. 8) Alexey From owner-tcp-impl@lerc.nasa.gov Mon Oct 16 14:13: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 SMTP id OAA12375 for ; Mon, 16 Oct 2000 14:13:34 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA03243 for tcp-impl-outgoing; Mon, 16 Oct 2000 11:55:48 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA03212 for ; Mon, 16 Oct 2000 11:55:45 -0400 (EDT) From: kuznet@ms2.inr.ac.ru Received: by seraph3.lerc.nasa.gov; id LAA11774; Mon, 16 Oct 2000 11:55:43 -0400 Received: from minus.inr.ac.ru(193.233.7.97) by seraph3.lerc.nasa.gov via smap (V5.5) id xma010124; Mon, 16 Oct 00 11:54:22 -0400 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA06150; Mon, 16 Oct 2000 19:38:25 +0400 Message-Id: <200010161538.TAA06150@ms2.inr.ac.ru> Subject: Re: DF and IP ID To: Erik.Nordmark@Eng.Sun.COM Date: Mon, 16 Oct 2000 19:38:25 +0400 (MSK DST) Cc: raj@cup.hp.com, tcp-impl@grc.nasa.gov In-Reply-To: from "Erik Nordmark" at Oct 15, 0 11:14:45 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hello! > bit set sit behind firewalls that discard all ICMP packets. OK. Next time when I will have a head ache, I try to use guillotine. Seems, it is the most conservative method of therapy. 8) When setting DF I do this not for fun. Fragmenting of such frame "is NOT permitted" (note capitals in rfc791). Period. Alexey From owner-tcp-impl@lerc.nasa.gov Mon Oct 16 14: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 SMTP id OAA13136 for ; Mon, 16 Oct 2000 14:45:46 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA06182 for tcp-impl-outgoing; Mon, 16 Oct 2000 12:10:41 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA06143 for ; Mon, 16 Oct 2000 12:10:38 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA01127; Mon, 16 Oct 2000 12:10:37 -0400 Received: from palrel1.hp.com(156.153.255.242) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000713; Mon, 16 Oct 00 12:10:15 -0400 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by palrel1.hp.com (Postfix) with ESMTP id A405F8FD; Mon, 16 Oct 2000 09:10:09 -0700 (PDT) Received: (from raj@localhost) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) id JAA13932; Mon, 16 Oct 2000 09:10:09 -0700 (PDT) From: Rick Jones Message-Id: <200010161610.JAA13932@tardy.cup.hp.com> Subject: Re: DF and IP ID To: kuznet@ms2.inr.ac.ru Date: Mon, 16 Oct 2000 09:10:09 -0700 (PDT) Cc: tcp-impl@grc.nasa.gov In-Reply-To: <200010161538.TAA06150@ms2.inr.ac.ru> from "kuznet@ms2.inr.ac.ru" at Oct "16," 2000 "07:38:25" pm X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit is it _really_ all that hard to generate a "proper" IP ID in a stack that it would not be worth doing even when DF is set to satisfy the conservative in what is sent axiom? rick jones From owner-tcp-impl@lerc.nasa.gov Mon Oct 16 14:47: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 SMTP id OAA13200 for ; Mon, 16 Oct 2000 14:47:34 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA11304 for tcp-impl-outgoing; Mon, 16 Oct 2000 12:39:36 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA11254 for ; Mon, 16 Oct 2000 12:39:32 -0400 (EDT) From: kuznet@ms2.inr.ac.ru Received: by seraph3.lerc.nasa.gov; id MAA06043; Mon, 16 Oct 2000 12:39:31 -0400 Received: from minus.inr.ac.ru(193.233.7.97) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005601; Mon, 16 Oct 00 12:39:11 -0400 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA06481; Mon, 16 Oct 2000 20:26:28 +0400 Message-Id: <200010161626.UAA06481@ms2.inr.ac.ru> Subject: Re: DF and IP ID To: raj@cup.hp.com (Rick Jones) Date: Mon, 16 Oct 2000 20:26:28 +0400 (MSK DST) Cc: tcp-impl@grc.nasa.gov In-Reply-To: <200010161610.JAA13932@tardy.cup.hp.com> from "Rick Jones" at Oct 16, 0 09:10:09 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hello! > is it _really_ all that hard to generate a "proper" IP ID in a stack It is not hard to generate "some" IP ID. But it is theoretically impossible to generate "proper" one. Please, reread my first mail. ID in DF packets is not generated to make it __reliable__ in the cases when it is really required. If some engine on internet _uses_ IP ID in all the packets for some purpose, it is fatally broken and has no rights to exist. I am sorry, but 16bit ID become obsolete simultaneously with inventing 10Mbit ethernet. And rates are sort of a bit higher nowadays. 100 times. 8) Alexey From owner-tcp-impl@lerc.nasa.gov Mon Oct 16 16:17: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 SMTP id QAA15325 for ; Mon, 16 Oct 2000 16:17:50 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA20988 for tcp-impl-outgoing; Mon, 16 Oct 2000 13:35:41 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA20938 for ; Mon, 16 Oct 2000 13:35:39 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA06902; Mon, 16 Oct 2000 13:35:38 -0400 Received: from palrel1.hp.com(156.153.255.242) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005954; Mon, 16 Oct 00 13:34:47 -0400 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by palrel1.hp.com (Postfix) with ESMTP id B7CEEF96; Mon, 16 Oct 2000 10:34:42 -0700 (PDT) Received: (from raj@localhost) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) id KAA16255; Mon, 16 Oct 2000 10:34:42 -0700 (PDT) From: Rick Jones Message-Id: <200010161734.KAA16255@tardy.cup.hp.com> Subject: Re: DF and IP ID To: kuznet@ms2.inr.ac.ru Date: Mon, 16 Oct 2000 10:34:42 -0700 (PDT) Cc: tcp-impl@grc.nasa.gov In-Reply-To: <200010161626.UAA06481@ms2.inr.ac.ru> from "kuznet@ms2.inr.ac.ru" at Oct "16," 2000 "08:26:28" pm X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Please, reread my first mail. ID in DF packets is not generated to > make it __reliable__ in the cases when it is really required. If > some engine on internet _uses_ IP ID in all the packets for some > purpose, it is fatally broken and has no rights to exist. I am > sorry, but 16bit ID become obsolete simultaneously with inventing > 10Mbit ethernet. And rates are sort of a bit higher nowadays. 100 > times. 8) I will acknowledge that it is possible, even likely, for a non-trivial number of "IP flows" to have their ID wrap within MSL. I will also acknowledge that something that silently clears a DF bit is broken. However, it still seems that having even a 16-bit IP ID for each flow is better than nothing, even with DF set. No, it is not perfect. Nothing in the Internet is. That, I suspect, is part of the rationale behind "Be conservative in what you send." Particularly since it should not be all that difficult for an IP implementation to do. Given current bitrates, and times of wrap-around would you also then say that every TCP connection must use large windows and timestamps? rick jones From owner-tcp-impl@lerc.nasa.gov Mon Oct 16 16:22: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 SMTP id QAA15409 for ; Mon, 16 Oct 2000 16:22:43 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA24769 for tcp-impl-outgoing; Mon, 16 Oct 2000 13:58:55 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA24745 for ; Mon, 16 Oct 2000 13:58:53 -0400 (EDT) From: kuznet@ms2.inr.ac.ru Received: by seraph3.lerc.nasa.gov; id NAA27607; Mon, 16 Oct 2000 13:58:51 -0400 Received: from minus.inr.ac.ru(193.233.7.97) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027324; Mon, 16 Oct 00 13:58:33 -0400 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA07718; Mon, 16 Oct 2000 21:48:46 +0400 Message-Id: <200010161748.VAA07718@ms2.inr.ac.ru> Subject: Re: DF and IP ID To: raj@cup.hp.com (Rick Jones) Date: Mon, 16 Oct 2000 21:48:46 +0400 (MSK DST) Cc: tcp-impl@grc.nasa.gov In-Reply-To: <200010161734.KAA16255@tardy.cup.hp.com> from "Rick Jones" at Oct 16, 0 10:34:42 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hello! > rationale behind "Be conservative in what you send." I am so conservative that astonished myself. 8) That's why I select IDs carefully. > Given current bitrates, and times of wrap-around would you also then > say that every TCP connection must use large windows and timestamps? What's about timestamps, no doubts. Advertising timestamps is another example of real conservatism. What's about large windows, it is not a must but desired. At least windows less than 64K are harmful. Alexey From owner-tcp-impl@lerc.nasa.gov Mon Oct 16 16:51: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 SMTP id QAA16079 for ; Mon, 16 Oct 2000 16:51:46 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA29497 for tcp-impl-outgoing; Mon, 16 Oct 2000 14:26:11 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA29468 for ; Mon, 16 Oct 2000 14:26:09 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA22578; Mon, 16 Oct 2000 14:26:08 -0400 Received: from palrel3.hp.com(156.153.255.226) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021745; Mon, 16 Oct 00 14:25:04 -0400 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by palrel3.hp.com (Postfix) with ESMTP id 1BA85748 for ; Mon, 16 Oct 2000 11:25:02 -0700 (PDT) Received: from cup.hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id LAA17693 for ; Mon, 16 Oct 2000 11:25:01 -0700 (PDT) Message-ID: <39EB47FD.B5B1AC7F@cup.hp.com> Date: Mon, 16 Oct 2000 11:25:01 -0700 From: Rick Jones Organization: the Unofficial HP X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: bottom line question on DF and IP IDs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit so, now that there has been a bit of discussion on the topic, i'll ask the root question that has been on my mind: Is a system which does not provide unique IP datagram identifiers when the DF bit is set compliant with the RFC's concerning IPv4? rick jones -- rachel marina jones, 09/24 0317, 7lbs, 7oz, 20" these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, OR post, but please do NOT do BOTH... my email address is raj in the cup.hp.com domain... From owner-tcp-impl@lerc.nasa.gov Mon Oct 16 18:32: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 SMTP id SAA17148 for ; Mon, 16 Oct 2000 18:32:17 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA16413 for tcp-impl-outgoing; Mon, 16 Oct 2000 16:14:14 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA16392 for ; Mon, 16 Oct 2000 16:14:11 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA05501; Mon, 16 Oct 2000 16:14:10 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005350; Mon, 16 Oct 00 16:14:02 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id e9GKE1x13289 for tcp-impl@grc.nasa.gov env-from ; Mon, 16 Oct 2000 14:14:01 -0600 (MDT) Date: Mon, 16 Oct 2000 14:14:01 -0600 (MDT) From: Vernon Schryver Message-Id: <200010162014.e9GKE1x13289@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: bottom line question on DF and IP IDs Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: Rick Jones > To: tcp-impl@grc.nasa.gov > so, now that there has been a bit of discussion on the topic, i'll ask > the root question that has been on my mind: > > Is a system which does not provide unique IP datagram identifiers when > the DF bit is set compliant with the RFC's concerning IPv4? Are you perchance thinking of a system that does TCP segmentation and so IP packetization far from the host with the TCB and rest of the TCP and IP state machines? Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Mon Oct 16 19:31: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 SMTP id TAA17508 for ; Mon, 16 Oct 2000 19:31:45 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA26424 for tcp-impl-outgoing; Mon, 16 Oct 2000 17:31:56 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA26413 for ; Mon, 16 Oct 2000 17:31:55 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA28214; Mon, 16 Oct 2000 17:31:54 -0400 Received: from hilbert.umkc.edu(134.193.4.60) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028039; Mon, 16 Oct 00 17:31:45 -0400 Received: (qmail 379205 invoked from network); 16 Oct 2000 21:31:03 -0000 Received: from nicol1.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.62) by hilbert.umkc.edu with SMTP; 16 Oct 2000 21:31:03 -0000 Message-ID: <39EB738D.E7ED88B1@kasey.umkc.edu> Date: Mon, 16 Oct 2000 16:30:53 -0500 From: "David L. Nicol" Organization: University of Missouri - Kansas City supercomputing infrastructure X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12-mosix i586) X-Accept-Language: en MIME-Version: 1.0 To: der Mouse CC: tcp-impl@grc.nasa.gov Subject: Re: DF and IP ID References: <200010161242.IAA25349@Twig.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit der Mouse wrote: > Yes, it's annoying. I'm behind a low-MTU link and relatively often see > what I have been calling "the won't frag disease" - indeed, one of my > own connectivity provider's websites has it. sounds like you need a tunnel peer. Most public tunnel peers are set up towards anonymity, but that is not a problem -- David Nicol 816.235.1187 nicold@umkc.edu "After jotting these points down, we felt better." From owner-tcp-impl@lerc.nasa.gov Mon Oct 16 19:33:41 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 SMTP id TAA17530 for ; Mon, 16 Oct 2000 19:33:40 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA25457 for tcp-impl-outgoing; Mon, 16 Oct 2000 17:21:32 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA25421 for ; Mon, 16 Oct 2000 17:21:29 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA22550; Mon, 16 Oct 2000 17:21:28 -0400 Received: from arachnid.ehsco.com(209.31.7.46) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022168; Mon, 16 Oct 00 17:20:57 -0400 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 356 for ; Mon, 16 Oct 2000 14:20:50 -0700 Message-ID: <39EB7130.9BE87E88@ehsco.com> Date: Mon, 16 Oct 2000 14:20:48 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Re: DF and IP ID References: <200010161748.VAA07718@ms2.inr.ac.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > > Given current bitrates, and times of wrap-around would you also then > > say that every TCP connection must use large windows and timestamps? > > What's about timestamps, no doubts. Advertising timestamps is another > example of real conservatism. The thing about timestamps is that they have the potential to be useful in almost every situation (although the potential is realized more often in some specific scenarios). Even though they are a waste of capacity for a majority of the connections, they have the potential to be useful and therefore yes, their usage is the most conservative approach. > What's about large windows, it is not a must but desired. > At least windows less than 64K are harmful. Always using 64k windows is not conservative, in fact excessively-large windows are just as harmful as excessively-small windows. If nothing else, a window that is too large will always result in some form of congestion-related loss as the true limits of the circuit are discovered. Optimal window sizes are the most effective, self-tuning windows (route-based entries that reflect true capacity characteristics) would therefore be the most conservative if anybody used them. Nobody does so to my knowledge however. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-tcp-impl@lerc.nasa.gov Thu Oct 26 15:21:18 2000 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10156 for ; Thu, 26 Oct 2000 15:21:18 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA12714 for tcp-impl-outgoing; Thu, 26 Oct 2000 09:10:45 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA12701 for ; Thu, 26 Oct 2000 09:10:43 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA15965; Thu, 26 Oct 2000 09:10:42 -0400 Received: from iraun1.ira.uka.de(129.13.10.90) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015879; Thu, 26 Oct 00 09:10:00 -0400 Received: from blackfoot.telematik.informatik.uni-karlsruhe.de by iraun1 (PP) with ESMTP; Thu, 26 Oct 2000 15:08:38 +0200 Received: from telematik.informatik.uni-karlsruhe.de (tpc17.telematik.informatik.uni-karlsruhe.de [129.13.42.117]) by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id PAA13108; Thu, 26 Oct 2000 15:08:24 +0200 (MET DST) Message-ID: <39F82D12.28D1E882@telematik.informatik.uni-karlsruhe.de> Date: Thu, 26 Oct 2000 15:09:38 +0200 From: Klaus Wehrle Organization: University of Karlsruhe - Institute of Telematics X-Mailer: Mozilla 4.7 [de] (WinNT; U) X-Accept-Language: de MIME-Version: 1.0 CC: Lars.Wolf@rz.uni-karlsruhe.de, Ralf.Steinmetz@KOM.tu-darmstadt.de, d.hutchison@lancaster.ac.uk Subject: IWQoS 2001 - Call for Papers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit --> We apologize if you receive multiple copies of this. <-- ======================================================================= Preliminary *CALL FOR PAPERS* NINTH INTERNATIONAL WORKSHOP on QUALITY of SERVICE (IWQoS) http://www.uni-karlsruhe.de/~iwqos/ June 6-8, 2000 University of Karlsruhe Karlsruhe, Germany Workshop Theme ============== IWQoS is a very successful series of workshops providing an international forum for the presentation and discussion of new research and ideas on quality of service (QoS) -- the IWQoS2001 workshop in Karlsruhe follows the IWQoS events held in Columbia, Napa, London, and Pittsburgh. It is a premier forum for all work related to QoS -- especially in networking but also QoS aspects outside of networking are considered as very important as well, e.g., QoS in operating systems, QoS in servers, advanced middleware services and according technical issues such as quality, safety and security, admission, accounting, mobility. The objective of this Ninth International Workshop on Quality of Service is to bring together researchers, developers, and practitioners working in all these areas to discuss recent innovative results and future directions. The list of topics of interest includes (but is not limited to) - experiences with QoS (measurements, tests, evaluations) - QoS in heterogeneous networks - QoS routing - QoS and active networks - QoS for wireless and mobile - charging, accounting, and pricing for QoS - QoS support for applications and services - QoS in servers and endsystems - QoS support for information appliances - QoS control for middleware and platform support for QoS - QoS and adaptation mechanisms - resource management and control - analytical and simulation models for QoS - safety and security aspects - programmability and language aspects Important Dates =============== - Paper deadline: February 18, 2001 - Notification: April 2, 2001 - Final papers due: April 15, 2001 Committees ========== Co-Chairs --------- Lars Wolf, University of Karlsruhe David Hutchison, Lancaster University Ralf Steinmetz, GMD IPSI IWQoS Steering Committee ------------------------ Jon Crowcroft, UCL Rich Friedrich, HP Labs Edward Knightly, Rice University Peter Steenkiste, CMU Hui Zhang, CMU IWQoS2001 Program Committee (preliminary) --------------------------- Nina Bhatti, University of Arizona Gordon Blair, University of Lancaster Jose Brustoloni, Bell Labs Andrew Campbell, Columbia University Georg Carle, GMD FOKUS Jon Crowcroft, UCL Bruce Davie, Cisco Hermann de Meer, UCL, London Jan de Meer, GMD FOKUS Serge Fdida, LIP6 Rich Friedrich, HP Labs Kevin Jeffay, Univ. North Carolina Edward Knightly, Rice University Jim Kurose, U.Mass. Jorg Liebeherr, University of Virginia Qingming Ma, Cisco Klara Nahrstedt, University of Illinois Andrew Odlyzko, AT&T Research Jim Roberts, France Telecom Cormac Sreenan, Univ. College Cork Peter Steenkiste, CMU John Wroclawski, MIT Local Organization ------------------ Lars Wolf, University of Karlsruhe Klaus Wehrle, University of Karlsruhe Further General Information =========================== http://www.uni-karlsruhe.de/~iwqos/ mailto:iwqos@uni-karlsruhe.de