netdev - Re: Raise initial congestion window size / speedup slow start?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7065ab9e99967e429c20028f4426e2ff@localhost>
Date:	Fri, 16 Jul 2010 11:03:18 +0200
From:	Hagen Paul Pfeifer <hagen@...u.net>
To:	Bill Fink <billfink@...dspring.com>
Cc:	David Miller <davem@...emloft.net>, <rick.jones2@...com>,
	<lists@...dgooses.com>, <davidsen@....com>,
	<linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>
Subject: Re: Raise initial congestion window size / speedup slow  start?

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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html