From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0B0763B25E for ; Fri, 6 May 2016 15:58:21 -0400 (EDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id u46JwIjY016071; Fri, 6 May 2016 12:58:18 -0700 Date: Fri, 6 May 2016 12:58:18 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Jonathan Morton cc: cake@lists.bufferbloat.net In-Reply-To: Message-ID: References: <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <2D83E4F6-03DD-4421-AAE0-DD3C6A8AFCE0@gmail.com> <1577AB06-3C14-43D1-92AD-E37CEDCB8E11@gmail.com> <8F329CCB-038C-4EF4-A01D-DB8C093AE6B2@gmx.de> <20160506083114.0730d9f1@xeon-e3> <26BC8860-0485-4052-A8AC-574737B878E6@gmail.com> <89951A22-6568-4A07-BC52-5142DADB95BC@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="680960-2070786906-1462564471=:1768" Content-ID: Subject: Re: [Cake] Fwd: [Codel] fq_codel_drop vs a udp flood X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 19:58:22 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-2070786906-1462564471=:1768 Content-Type: TEXT/PLAIN; CHARSET=utf-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Fri, 6 May 2016, David Lang wrote: > On Fri, 6 May 2016, Jonathan Morton wrote: > >>> On 6 May, 2016, at 22:14, David Lang wrote: >>> >>> On Fri, 6 May 2016, Jonathan Morton wrote: >>> >>>>> On 6 May, 2016, at 21:50, David Lang wrote: >>>>> >>>>> what IP id are you referring to? I don't remember any such field in the >>>>> packet header. >>>> >>>> It’s the third halfword. >>> >>> half a word is hardly enough to be unique across the Internet, anything >>> that small would lead to lots of attackes that inserted garbage data into >>> threads. >> >> It doesn’t need to be globally unique. It merely identifies, in >> conjunction with src/dst address pair (so 80 bits in total), a particular >> sequence of fragments to be reassembled into the original packet. If the >> fourth halfword is zero (or has only the Don’t Fragment bit set), the IP ID >> field has no meaning. Hence the entire second word can be considered >> fragmentation related. >> >> I agree that it’s not a very robust mechanism; it breaks under extensive >> packet reordering at high packet rates (circumstances which are probably >> showing up in iperf tests against flow-isolating AQMs). It would be better >> not to have fragmentation at the IP layer at all. But it’s not as bad as >> you say; it does work for low packet rates, which is all it was intended >> for. >> >> Here’s my preferred reference diagram: >> https://nmap.org/book/tcpip-ref.html > > rfc-6864 shows that this field is not used the way you think it is in > practice (if it was, nobody would have been able to exceed 6.4Mbps) > > Given all the things that can cause fragmentation on virtually every packet > (tunnels/vpns), and the fact that having this be unique would restrict all > traffice between a given source and destination to 6.4Mbps, I am extremely > doubtful that it is used the way that rfc-6864 suggests (after all it's a > recent RFC, 2013) > > I know that I've looked at packet dumps that have shown fragmented data and > seen the port numbers in the fragment headers. > > I'd bet that in practice firewalls/etc ignore the IP ID field. from rfc-6864 Many current devices support fragmentation that ignores the IPv4 Don't Fragment (DF) bit. Such devices already transit traffic from sources that reuse the ID. If fragments of different datagrams reusing the same ID (within the source address/destination address/protocol tuple) arrive at the destination interleaved, fragmentation would fail and traffic would be dropped. Either such interleaving is uncommon or traffic from such devices is not widely traversing these DF-ignoring devices, because significant occurrence of reassembly errors has not been reported. DF-ignoring devices do not comply with existing standards, and it is not feasible to update the standards to allow them as compliant. They ignore the possibility that the OS reassembly is doing something different than they are thinking. David Lang --680960-2070786906-1462564471=:1768 Content-Type: TEXT/PLAIN; CHARSET=utf-8 Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: INLINE X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQ2FrZSBtYWls aW5nIGxpc3QKQ2FrZUBsaXN0cy5idWZmZXJibG9hdC5uZXQKaHR0cHM6Ly9saXN0cy5idWZmZXJi bG9hdC5uZXQvbGlzdGluZm8vY2FrZQo= --680960-2070786906-1462564471=:1768--