netdev
[Top] [All Lists]

Re: [RFC/PATCH] "strict" ipv4 reassembly

To: David Stevens <dlstevens@xxxxxxxxxx>
Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Nivedita Singhvi <niv@xxxxxxxxxx>
Date: Wed, 18 May 2005 15:39:00 -0700
Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx, netdev-bounce@xxxxxxxxxxx, rick.jones2@xxxxxx, Thomas Graf <tgraf@xxxxxxx>
In-reply-to: <OFD80D42F2.31DFC921-ON88257005.007ABBCD-88257005.007B23EA@xxxxxxxxxx>
References: <OFD80D42F2.31DFC921-ON88257005.007ABBCD-88257005.007B23EA@xxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla Thunderbird 0.8 (X11/20041020)
David Stevens wrote:
netdev-bounce@xxxxxxxxxxx wrote on 05/18/2005 02:46:54 PM:


Thomas Graf <tgraf@xxxxxxx> wrote:

Wild thought: We could introduce a new ip option stating that the id
generator uses a serial approach which would give us the possibility
to measure the absolute distance and resolve this issue in a perfect
matter for everyone supporting this extension. ;->


Well Linux does that anyway (apart from Suse) so all we need to do
is to tell everyone doing NFS over gigabit to use Linux :)


        If you're going to add an IP option, you can eliminate the
problem entirely. Just add an "extended IP ID" IP option and give
it as many bits as you want-- make that the high order of an n+16-bit
IP ID.
        The IP timestamp option, if done per frag and required to be
the same for all frags, could be used in this way, since you
presumably won't wrap without incrementing that by at least 1. :-)

                                                        +-DLS

Whatever happened to UDP Path MTU? While we're at this, can't
we start kicking some path-MTU-broken butt?


thanks,
Nivedita

<Prev in Thread] Current Thread [Next in Thread>