Prev: kmemleak: Introduce a default off mode for kmemleak
Next: kmemleak: Add DocBook style comments to kmemleak.c
From: Hagen Paul Pfeifer on 16 Jul 2010 05:10

On Wed, 14 Jul 2010 23:49:17 -0400, Bill Fink wrote:

> A long, long time ago, I suggested a Path BW Discovery mechanism
> to the IETF, analogous to the Path MTU Discovery mechanism, but
> it didn't get any traction. Such information could be extremely
> useful to TCP endpoints, to determine a maximum window size to
> use, to effectively rate limit a much stronger sender from
> overpowering a much weaker receiver (for example 10-GigE -> GigE),
> resulting in abominable performance across large RTT paths
> (as low as 12 Mbps), even in the absence of any real network
> contention.

Much weaker middlebox? The windowing mechanism should be sufficient to
avoid endpoints from over-commiting.

Anyway, your proposed draft (I didn't searched for it) sound like a
mechanism similar to RFC 4782: Quick-Start for TCP and IP.


This document specifies an optional Quick-Start mechanism for
transport protocols, in cooperation with routers, to determine an
allowed sending rate at the start and, at times, in the middle of a
data transfer (e.g., after an idle period). While Quick-Start is
designed to be used by a range of transport protocols, in this
document we only specify its use with TCP. Quick-Start is designed
to allow connections to use higher sending rates when there is
significant unused bandwidth along the path, and the sender and all
of the routers along the path approve the Quick-Start Request.


Cheers, Hagen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: kmemleak: Introduce a default off mode for kmemleak
Next: kmemleak: Add DocBook style comments to kmemleak.c