From: Eric Dumazet <eric.dumazet@gmail.com>
To: 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: Fri, 01 Apr 2016 19:21:49 -0700 [thread overview]
Message-ID: <1459563709.6473.305.camel@edumazet-glaptop3.roam.corp.google.com> (raw)
In-Reply-To: <20160401.221632.846129753053296932.davem@davemloft.net>
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 ;) )
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 2:21 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 [this message]
2016-04-02 20:26 ` Rick Jones
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=1459563709.6473.305.camel@edumazet-glaptop3.roam.corp.google.com \
--to=eric.dumazet@gmail.com \
--cc=aduyck@mirantis.com \
--cc=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.