netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: David Stevens <dlstevens@us.ibm.com>
Cc: netdev@oss.sgi.com, rusty@au1.ibm.com
Subject: Re: Fragment ID wrap workaround (read-only, untested).
Date: Thu, 15 Jul 2004 18:27:35 +0200	[thread overview]
Message-ID: <20040715182735.3787c8b1.ak@suse.de> (raw)
In-Reply-To: <OF97127705.C0C08B6A-ON88256ED2.004DB9A5-88256ED2.005146DA@us.ibm.com>

On Thu, 15 Jul 2004 07:49:13 -0700
David Stevens <dlstevens@us.ibm.com> wrote:

> 
> > Yes, running fragmentation over those is not a good idea, but
> > still it should not be made worse.
> 
> Delivery to the user of incorrect data is the problem, and, no, it doesn't
> make that worse. :-) The scenario, to make it clear for everyone, is a]

The data corruption problem only starts to become a real issue
at Gigabit Speeds and faster. Normally such congested links are much slower

> small loss rate on a fast network leads to reassembling packets with the
> same IP ID that are not the same packet when the ID wraps before the frag
> queue timer has expired. If you're blasting away on a gigabit network (or
> faster) and you drop one fragment (or more) from a packet you've received,
> that frag queue will be there 65536 packets later when you reuse the same 
> ID
> for a different packet. I think that works out to be 7 secs or so at full
> rate-- well within the 1-4 minute typical frag queue timer on most 
> systems.

[...]

I'm well aware of the Gigabit+ NFS problem. My standard suggestion to solve
it is to just get rid of NFS over UDP - it always was a bad idea.

My point was just that you're concentrating on that one only,
but you're potentially causing more problems for slow links.
The stack has to work well both for slow and fast links though.


> 
> > In general handling a link where the RTT increases would seem
> > tricky with your scheme. Unlike TCP there is no retransmit
> > to save the day.
> 
> In the particular case (NFS over UDP), there is both a retransmit (done
> by RPC) and significant loss rate to start with. As long as the time-out
> is conservative, I don't think this has to affect other cases
> significantly.

NFS over UDP is just a bad idea. Don't do it. NFS over TCP 
works fine these days and should be the prefered choice for everybody.

I don't really see the point of risking problems with slower links
just to fix a fundamentally flawed protocol.

And you cannot rely on all UDP based protocols doing this as well.

-Andi

  parent reply	other threads:[~2004-07-15 16:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-15  5:57 Fragment ID wrap workaround (read-only, untested) Rusty Russell (IBM)
2004-07-15  8:28 ` David Stevens
2004-07-15  9:27   ` Andi Kleen
2004-07-15 14:49     ` David Stevens
2004-07-15 16:24       ` John Heffner
2004-07-15 16:27       ` Andi Kleen [this message]
2004-07-15 16:54         ` David Stevens
2004-07-15 17:02           ` Andi Kleen
2004-07-27 12:38       ` Olaf Kirch
  -- strict thread matches above, loose matches on Subject: below --
2004-07-15  6:36 Rusty Russell (IBM)
2004-07-15 17:34 ` Andi Kleen

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=20040715182735.3787c8b1.ak@suse.de \
    --to=ak@suse.de \
    --cc=dlstevens@us.ibm.com \
    --cc=netdev@oss.sgi.com \
    --cc=rusty@au1.ibm.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).