From: Rick Jones <rick.jones2@hpe.com>
To: Eric Dumazet <eric.dumazet@gmail.com>,
David Miller <davem@davemloft.net>
Cc: alexander.duyck@gmail.com, aduyck@mirantis.com,
herbert@gondor.apana.org.au, tom@herbertland.com,
jesse@kernel.org, edumazet@google.com, netdev@vger.kernel.org
Subject: Re: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864
Date: Sat, 2 Apr 2016 13:26:45 -0700 [thread overview]
Message-ID: <57002B05.8070005@hpe.com> (raw)
In-Reply-To: <1459563709.6473.305.camel@edumazet-glaptop3.roam.corp.google.com>
On 04/01/2016 07:21 PM, Eric Dumazet wrote:
> On Fri, 2016-04-01 at 22:16 -0400, David Miller wrote:
>> From: Alexander Duyck <alexander.duyck@gmail.com>
>> Date: Fri, 1 Apr 2016 12:58:41 -0700
>>
>>> RFC 6864 is pretty explicit about this, IPv4 ID used only for
>>> fragmentation. https://tools.ietf.org/html/rfc6864#section-4.1
>>>
>>> The goal with this change is to try and keep most of the existing
>>> behavior in tact without violating this rule? I would think the
>>> sequence number should give you the ability to infer a drop in the
>>> case of TCP. In the case of UDP tunnels we are now getting a bit more
>>> data since we were ignoring the outer IP header ID before.
>>
>> When retransmits happen, the sequence numbers are the same. But you
>> can then use the IP ID to see exactly what happened. You can even
>> tell if multiple retransmits got reordered.
>>
>> Eric's use case is extremely useful, and flat out eliminates ambiguity
>> when analyzing TCP traces.
>
> Yes, our team (including Van Jacobson ;) ) would be sad to not have
> sequential IP ID (but then we don't have them for IPv6 ;) )
Your team would not be the only one sad to see that go away.
rick jones
> Since the cost of generating them is pretty small (inet->inet_id
> counter), we probably should keep them in linux. Their usage will phase
> out as IPv6 wins the Internet war...
>
>
next prev parent reply other threads:[~2016-04-02 20:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-01 18:05 [net PATCH 0/2] Fixes for GRO and GRE tunnels Alexander Duyck
2016-04-01 18:05 ` [net PATCH 1/2] GRE: Disable segmentation offloads w/ CSUM and we are encapsulated via FOU Alexander Duyck
2016-04-01 18:05 ` [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864 Alexander Duyck
2016-04-01 18:49 ` Eric Dumazet
2016-04-01 19:24 ` David Miller
2016-04-01 19:58 ` Alexander Duyck
2016-04-01 21:13 ` Subash Abhinov Kasiviswanathan
2016-04-02 2:16 ` David Miller
2016-04-02 2:21 ` Eric Dumazet
2016-04-02 20:26 ` Rick Jones [this message]
2016-04-02 6:02 ` Alexander Duyck
2016-04-02 1:57 ` Herbert Xu
2016-04-02 2:15 ` Eric Dumazet
2016-04-02 2:19 ` Herbert Xu
2016-04-02 2:26 ` Eric Dumazet
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57002B05.8070005@hpe.com \
--to=rick.jones2@hpe.com \
--cc=aduyck@mirantis.com \
--cc=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=jesse@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=tom@herbertland.com \
/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;
as well as URLs for NNTP newsgroup(s).