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. _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
