netdev
[Top] [All Lists]

Re: Fragment ID wrap workaround (read-only, untested).

To: David Stevens <dlstevens@xxxxxxxxxx>
Subject: Re: Fragment ID wrap workaround (read-only, untested).
From: Andi Kleen <ak@xxxxxxx>
Date: Thu, 15 Jul 2004 11:27:17 +0200
Cc: "Rusty Russell (IBM)" <rusty@xxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <OF339FA69C.C0404720-ON88256ED2.002C1123-88256ED2.002E61B7@xxxxxxxxxx>
References: <1089871078.3571.56.camel@bach> <OF339FA69C.C0404720-ON88256ED2.002C1123-88256ED2.002E61B7@xxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Thu, Jul 15, 2004 at 02:28:05AM -0600, David Stevens wrote:
> My idea for solving this problem is to create an estimator for the
> reassembly timer. The fundamental problem as I see it is that the
> reassembly timer is fixed, and about 6000 times too long on a
> fast network (and worse the faster networks get).

Won't that make the worst case behaviour on a congested link much worse?

e.g. consider a very congested link with variable RTTs. Or a 
link that works relatively smoothly and suddenly the RTT increases.

Yes, running fragmentation over those is not a good idea, but
still it should not be made worse.

Your variable timer even with a smoothing algorithm in the RTT 
estimator will expire far too early and very likely drop a lot more 
fragments in this scenario than before.

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.

-Andi


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