diff for duplicates of <7065ab9e99967e429c20028f4426e2ff@localhost> diff --git a/a/1.txt b/N1/1.txt index cf247eb..37f63cb 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,32 +1,62 @@ 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 diff --git a/a/content_digest b/N1/content_digest index bbcaec8..a17443e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -19,34 +19,64 @@ "\n" "On Wed, 14 Jul 2010 23:49:17 -0400, Bill Fink wrote:\n" "\n" + "\n" + "\n" "> A long, long time ago, I suggested a Path BW Discovery mechanism\n" + "\n" "> to the IETF, analogous to the Path MTU Discovery mechanism, but\n" + "\n" "> it didn't get any traction. Such information could be extremely\n" + "\n" "> useful to TCP endpoints, to determine a maximum window size to\n" + "\n" "> use, to effectively rate limit a much stronger sender from\n" + "\n" "> overpowering a much weaker receiver (for example 10-GigE -> GigE),\n" + "\n" "> resulting in abominable performance across large RTT paths\n" + "\n" "> (as low as 12 Mbps), even in the absence of any real network\n" + "\n" "> contention.\n" "\n" + "\n" + "\n" "Much weaker middlebox? The windowing mechanism should be sufficient to\n" + "\n" "avoid endpoints from over-commiting.\n" "\n" + "\n" + "\n" "Anyway, your proposed draft (I didn't searched for it) sound like a\n" + "\n" "mechanism similar to RFC 4782: Quick-Start for TCP and IP.\n" "\n" "\n" + "\n" + "\n" + "\n" " This document specifies an optional Quick-Start mechanism for\n" + "\n" " transport protocols, in cooperation with routers, to determine an\n" + "\n" " allowed sending rate at the start and, at times, in the middle of a\n" + "\n" " data transfer (e.g., after an idle period). While Quick-Start is\n" + "\n" " designed to be used by a range of transport protocols, in this\n" + "\n" " document we only specify its use with TCP. Quick-Start is designed\n" + "\n" " to allow connections to use higher sending rates when there is\n" + "\n" " significant unused bandwidth along the path, and the sender and all\n" + "\n" " of the routers along the path approve the Quick-Start Request.\n" "\n" "\n" + "\n" + "\n" + "\n" Cheers, Hagen -8247e3cccf8005437aa74623949a21af161fd57074749b1b9003875195c3bd35 +e9601dd80b199d07dc11e85497d324cf65d138d68cffe100e6886db5a114f11a
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.