svn commit: r280759 - head/sys/netinet

[Slawa Olhovchenkov]

On Mon, Mar 30, 2015 at 03:45:00PM +0200, Hans Petter Selasky wrote:

> Gleb,
> 
> On 03/30/15 14:59, Hans Petter Selasky wrote:
> > On 03/30/15 14:51, Gleb Smirnoff wrote:
> >>    Hans,
> >>
> >
> > Gleb: Can you answer my question first:
> >
> > Should the 16-bit IP ID field carry any useful information or not?
> >
> 
> > Yes:
> >
> >     An identifying value assigned by the sender to aid in assembling the
> >     fragments of a datagram.
> 
> The numbering should be somewhat sane and when you are suggesting that a 
> multi-line function and cache line issues will hit the system hard, 
> which I don't doubt, functions like "unrhdr()" are probably out of the 
> question?
> 
> >> Let me ask again: are you serious? Do you suggest to delay transmitting
> >> network packets with a DELAY()?
> 
> Yes! It doesn't have to be done by the software. It can be done by the 
> ethernet hardware too!
> 
> >>
> >> H> Or maybe we can add an IPv4 option to escape a 32-bit IP ID field and
> >> H> don't use the 16-bit IP ID field.
> >>
> >> Is that also serious? Do you suggest to change layout of IP packet?
> >>
> 
> IPv4 packets can carry additional options which is part of the standard 
> IPv4 packet layout, though routers which perform fragmentation would 
> need to support it ...
> 
> 
> Does this discussion mean that IPv4 traffic which is subject to 
> fragmentation has a transmission rate limit depending on the roundtrip 
> time to avoid risking bad defragmentation issues?

You can't be know about needing fragmenatation.
Fragmentation occur on remote transit routers, w/o information packet
source.
Any packet (w/o DF) can be fragmented.
In some cases pakets one flow can be dispatched by different path and
fragmented only on the one path.