From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 832C521F33E for ; Sun, 21 Jun 2015 10:05:57 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so57232168wic.1 for ; Sun, 21 Jun 2015 10:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=a8fYpZFezH3sJt7NEJpz3QUyfm0mteB0YdpC8mxkAsM=; b=iVdDCvMMjp7ElSuplRNNT2R5KHUZ8ZYHZuxoz5xwzWYTf32PSqdlAVLnlBuI7F+5sU e/WfesaHHV4c8YWlOSOBliZRZ1BqYnA75t1mC08zkIEkTLdNUpbYD8hanIHL+u8OMf8T TMNibQ2L+VQyBm6D2frB5sdtXCRz+lJyp5Iewus0QeRVEvzkqutkxZ/9CR/2EpLiO5SY a+QUoYPLcU1xIaUfLDRuUVfPmYQ4C6RcFPQlt/f77ocuC6270eN9SZ+dpWgwGzqYhGkJ +0dVI/9KbAYBfQYwZ4byV4JbWTm7epy9dnZbuR3ouzpTmnPli3J4veUWVG7PHXTIy+QG +PRw== X-Received: by 10.194.2.68 with SMTP id 4mr43134303wjs.82.1434906355163; Sun, 21 Jun 2015 10:05:55 -0700 (PDT) Received: from volcano.localdomain (host-89-243-100-103.as13285.net. [89.243.100.103]) by mx.google.com with ESMTPSA id q9sm13178987wiz.23.2015.06.21.10.05.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jun 2015 10:05:54 -0700 (PDT) Message-ID: <5586EEF0.7090302@gmail.com> Date: Sun, 21 Jun 2015 18:05:52 +0100 From: Alan Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Benjamin Cronce References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070409040701060301030502" Cc: bloat Subject: Re: [Bloat] TCP congestion detection - random thoughts X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2015 17:06:27 -0000 This is a multi-part message in MIME format. --------------070409040701060301030502 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Ben Some possible Sunday reading relating to these thoughts :). https://lwn.net/Articles/645115/ "Delay-gradient congestion control" [2015, Linux partial implementation] our Dave's reply to a comment: https://lwn.net/Articles/647322/ Quote "there is a huge bias (based on the experimental evidence) that classic delay based tcps lost out to loss based in an undeployable fashion" - not to argue the quote either way. But there's some implicit references there that are relevant. Primarily a well-documented result on TCP Vegas. AIUI Vegas uses increased delay as well as loss/marks as a congestion signal. As a result, it gets a lower share of the bottleneck bandwidth when competing with other TCPs. Secondly uTP has a latency (increase) target (of 100ms :p), _deliberately_ to de-prioritize itself. (This is called LEDBAT and has also been implemented as a TCP). Alan On 21/06/15 17:19, Benjamin Cronce wrote: > Just a random Sunday morning thought that has probably already been > thought of before, but I currently can't think of hearing it before. > > My understanding of most TCP congestion control algorithms is they > primarily watch for drops, but drops are indicated by the receiving > party via ACKs. The issue with this is TCP keeps pushing more data > into the window until a drop is signaled, even if the rate received is > not increased. What if the sending TCP also monitors rate received and > backs off cramming more segments into a window if the received rate > does not increase. > > Two things to measure this. RTT which is part of TCP statistics > already and the rate at which bytes are ACKed. If you double the > number of segments being sent, but in a time frame relative to the > RTT, you do not see a meaningful increase in the rate at which bytes > are being ACKed, may want to back off. > > It just seems to me that if you have a 50ms RTT and 10 seconds of > bufferbloat, TCP is cramming data down the path with no care in the > world about how quickly data is actually getting ACKed, it's just > waiting for the first segment to get dropped, which would never happen > in an infinitely buffered network. > > TCP should be able to keep state that tracks the minimum RTT and > maximum ACK rate. Between these two, it should not be able to go over > the max path rate except when attempting to probe for a new max or > min. Min RTT is probably a good target because path latency should be > relatively static, however path free-bandwidth is not static. The > desirable number of segments in flight would need to change but would > be bounded by the max. > > Of course naggle type algorithms can mess with this because when ACKs > occur is no longer based entirely when a segment is received, but also > by some other additional amount of time. If you assume that naggle > will coalesce N segments into a single ACK, then you need to add to > the RTT, the amount of time at the current PPS, how long until you > expect another ACK assuming N number of segments will be coalesced. > This would be even important for low latency low bandwidth paths. > Coalesce information could be assumed, negotiated, or inferred. > Negotiated would be best. > > Anyway, just some random Sunday thoughts. > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --------------070409040701060301030502 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Ben

Some possible Sunday reading relating to these thoughts :).

https://lwn.net/Articles/645115/ "Delay-gradient congestion control" [2015, Linux partial implementation]

our Dave's reply to a comment:

https://lwn.net/Articles/647322/

Quote "there is a huge bias (based on the experimental evidence) that classic delay based tcps lost out to loss based in an undeployable fashion"

- not to argue the quote either way.  But there's some implicit references there that are relevant.  Primarily a well-documented result on TCP Vegas.  AIUI Vegas uses increased delay as well as loss/marks as a congestion signal.  As a result, it gets a lower share of the bottleneck bandwidth when competing with other TCPs.  Secondly uTP has a latency (increase) target (of 100ms :p), _deliberately_ to de-prioritize itself.  (This is called LEDBAT and has also been implemented as a TCP).

Alan


On 21/06/15 17:19, Benjamin Cronce wrote:
Just a random Sunday morning thought that has probably already been thought of before, but I currently can't think of hearing it before.

My understanding of most TCP congestion control algorithms is they primarily watch for drops, but drops are indicated by the receiving party via ACKs. The issue with this is TCP keeps pushing more data into the window until a drop is signaled, even if the rate received is not increased. What if the sending TCP also monitors rate received and backs off cramming more segments into a window if the received rate does not increase.

Two things to measure this. RTT which is part of TCP statistics already and the rate at which bytes are ACKed. If you double the number of segments being sent, but in a time frame relative to the RTT, you do not see a meaningful increase in the rate at which bytes are being ACKed, may want to back off.

It just seems to me that if you have a 50ms RTT and 10 seconds of bufferbloat, TCP is cramming data down the path with no care in the world about how quickly data is actually getting ACKed, it's just waiting for the first segment to get dropped, which would never happen in an infinitely buffered network.

TCP should be able to keep state that tracks the minimum RTT and maximum ACK rate. Between these two, it should not be able to go over the max path rate except when attempting to probe for a new max or min. Min RTT is probably a good target because path latency should be relatively static, however path free-bandwidth is not static. The desirable number of segments in flight would need to change but would be bounded by the max.

Of course naggle type algorithms can mess with this because when ACKs occur is no longer based entirely when a segment is received, but also by some other additional amount of time. If you assume that naggle will coalesce N segments into a single ACK, then you need to add to the RTT, the amount of time at the current PPS, how long until you expect another ACK assuming N number of segments will be coalesced. This would be even important for low latency low bandwidth paths. Coalesce information could be assumed, negotiated, or inferred. Negotiated would be best.

Anyway, just some random Sunday thoughts.


_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

--------------070409040701060301030502--