[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Path-switch-triggered congestion (Was: RE: Extending shim6 to use multiple locator pairs simultaneously)



On 03/23/06 at 8:56am +0100, Iljitsch van Beijnum <iljitsch@muada.com> wrote:

> On 22-mrt-2006, at 23:30, Scott Leibrand wrote:
>
> > But how much of a problem is this in reality?  Say you are
> > transmitting at 1Gbps (1,000,000 kbps), and get switched to a 28.8
> > kbps modem link. Since each packet lost halves the sending rate, and
> > you've reduced your throughput by a factor of approximately 2^15, it
> > should take approximately 15 dropped packets to throttle back the
> > sending rate sufficiently.
>
> That's with congestion avoidance, which kicks in for individual lost
> packets. If you lose a lot of them you're in slow start.
>
> But you're not considering delay and window size. If you're doing 1
> Gbps over a somewhat long distance (let's say 40 ms round trip delay)
> then you need a ~ 5 MB window. If you were to pump such a large
> window into 28 kbps you'd saturate that link for 23 minutes...

Sure I am.  No one buffers 23 minutes of data, so all the extra would
simply be dropped, and the buffer would then drain at line rate.

> Even assuming a regular 64k window (which would limit your
> datatransfer with 40 ms RTT to 13 Mbps) you'd be saturating that 28k
> link for 18 seconds.

Possibly, if the buffer(s) is/are that deep.  However, if that is the
case, then you would also be able to buffer 18 seconds of data simply by
running multiple TCP sessions across the slow link.  It doesn't require a
rehoming event to fill buffers, because the only way TCP will slow down is
when the network stops buffering and starts dropping packets.

> > IMO this is not a show-stopping problem, as TCP will throttle back
> > fairly quickly, and the impact should be limited to approximately the
> > depth of the slow link's buffer.  That's not to say it's not worth
> > addressing (in the TSVWG), but it doesn't seem to me like something
> > that should hold up shim6...
>
> Well, let's just do some experimenting when we have implementations.

Agreed.  In parallel, we should probably put into the API a way to tell
Layer 4 that we've rehomed, so that TCP can do whatever it thinks best in
that situation.

-Scott