From: David Lang <david@lang.hm>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
cake@lists.bufferbloat.net
Subject: Re: [Cake] Fwd: [Codel] fq_codel_drop vs a udp flood
Date: Fri, 6 May 2016 12:54:31 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1605061242160.1768@nftneq.ynat.uz> (raw)
In-Reply-To: <89951A22-6568-4A07-BC52-5142DADB95BC@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2035 bytes --]
On Fri, 6 May 2016, Jonathan Morton wrote:
>> On 6 May, 2016, at 22:14, David Lang <david@lang.hm> wrote:
>>
>> On Fri, 6 May 2016, Jonathan Morton wrote:
>>
>>>> On 6 May, 2016, at 21:50, David Lang <david@lang.hm> 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.
David Lang
next prev parent reply other threads:[~2016-05-06 19:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAA93jw6QLyx9EaS+ntB0D3duoysu_Z-UYyQfHnRa=pfqPDfWOw@mail.gmail.com>
[not found] ` <1462125592.5535.194.camel@edumazet-glaptop3.roam.corp.google.com>
[not found] ` <865DA393-262D-40B6-A9D3-1B978CD5F6C6@gmail.com>
[not found] ` <1462128385.5535.200.camel@edumazet-glaptop3.roam.corp.google.com>
[not found] ` <C5D365DA-18EE-446E-9D25-41F48B1C583E@gmail.com>
[not found] ` <1462136140.5535.219.camel@edumazet-glaptop3.roam.corp.google.com>
[not found] ` <CACiydbKUu11=zWitkDha0ddgk1-G_Z4-e1+=9ky776VktF5HHg@mail.gmail.com>
[not found] ` <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com>
[not found] ` <CACiydbKeKUENncrc-NmYRcku-DGVeGqqzYMqsCqKdxPsR7yUOQ@mail.gmail.com>
[not found] ` <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com>
[not found] ` <CACiydbL26Jj3EcEL4EmqaH=1Dm-Q0dpVwoWxqUSZ7ry10bRgeg@mail.gmail.com>
[not found] ` <CAA93jw5Y3DSzuOZo=S6_dsUqJvy_3ThNe6tMic2ZJ14kQPnFHg@mail.gmail.com>
[not found] ` <CACiydb+kOLNBwEn+gDU3fZrXEQxp5FMFLH_mDS1ZO5J8r9yiBA@mail.gmail.com>
[not found] ` <2D83E4F6-03DD-4421-AAE0-DD3C6A8AFCE0@gmail.com>
[not found] ` <CAA93jw6Aj3Rcsm=Q=KZVrW_TGThVwu6pRAN3nNQ4tvSODY_zUg@mail.gmail.com>
2016-05-06 4:35 ` Dave Taht
2016-05-06 4:44 ` Jonathan Morton
2016-05-06 4:57 ` Dave Taht
2016-05-06 8:49 ` moeller0
2016-05-06 9:00 ` David Lang
2016-05-06 9:36 ` moeller0
2016-05-06 15:31 ` Stephen Hemminger
2016-05-06 18:50 ` David Lang
2016-05-06 18:53 ` Jonathan Morton
2016-05-06 19:14 ` David Lang
2016-05-06 19:33 ` Jonathan Morton
2016-05-06 19:54 ` David Lang [this message]
2016-05-06 19:58 ` David Lang
2016-05-06 23:14 ` Benjamin Cronce
2016-05-07 2:09 ` David Lang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.02.1605061242160.1768@nftneq.ynat.uz \
--to=david@lang.hm \
--cc=cake@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox