From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (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 C72E721F283 for ; Sun, 21 Jun 2015 12:34:04 -0700 (PDT) Received: by yhan67 with SMTP id n67so95620011yha.3 for ; Sun, 21 Jun 2015 12:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=muZTgctEO393p+fxoLmu3+TTPiLmYAE8liiSxAnrRb0=; b=aOM/lKiZ3x69t2yKF8wAGp9BxXgW2AppJ52tpDQ8Cl/vEQEgm9zV9U+kRZgFOrGojD GIyiAD9LykA7HPT7/xRr/PJIZm1/zZbWbI1iTL4RMMYoWHAmbut8xzjd1b5ZpuJwopI3 1YRz1N9ozBRkcmQh2nHFSV/qbKK+DJaxgyDCcGTMzXI15IgqPvALpZn1UW++OAR1/MVV pFQt4kUAge243v7UufrWtGyiuFZ0fRmm5DHK85btQ2XEv+xEqWltV4qb6sDTrTCY8TDu gtCr3JPE4Tjv4x+q5Q8EAUmUplllaZInA/AcvLsOxHvs6PyHzkQ32E1kl823UvafdUmo akhw== MIME-Version: 1.0 X-Received: by 10.129.133.70 with SMTP id v67mr30236140ywf.158.1434915243503; Sun, 21 Jun 2015 12:34:03 -0700 (PDT) Received: by 10.129.148.194 with HTTP; Sun, 21 Jun 2015 12:34:03 -0700 (PDT) In-Reply-To: <5586EEF0.7090302@gmail.com> References: <5586EEF0.7090302@gmail.com> Date: Sun, 21 Jun 2015 14:34:03 -0500 Message-ID: From: Benjamin Cronce To: Alan Jenkins Content-Type: multipart/alternative; boundary=001a114f079a5f371c05190c3d6f 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 19:34:33 -0000 --001a114f079a5f371c05190c3d6f Content-Type: text/plain; charset=UTF-8 I'll have to find some time to look at those links. I guess I wasn't thinking of using latency to determine the rate but only nudge the rate, but use it only to determine to back off for a bit to allow the buffer to empty, but maintain the same rate overall. So if you have a 60ms RTT but a 50ms min RTT, keep your current rate but skip one segment periodically or maybe only make it a smaller segment like 1/2 the max size, but not often enough to make a large difference. Maybe allow latency to only reduce the current target rate by no more than 5% or something. I guess the starting pattern could be something like this 1) build up, 2x segments per ACK 2) make sure ACKd bytes increases at the same rate as bytes sent 3) once bytes ACKd stops increasing, attempt to reduce segment size or skip a packet until current RTT is near the target RTT, but no more 5% Of course this is only good for discovering the current free bandwidth. There needs to be a way to periodically probe to discover new free bandwidth. The idea was the max detected should rarely change, so don't be aggresive when probing near the max, but when below the max, attempt to find free bandwidth by adding additional segments and seeing if the ACKd byte rate increases. If it does, start growing. I don't have an engineering background, just playing with thoughts. [Bloat] TCP congestion detection - random thoughts > > Alan Jenkins alan.christopher.jenkins at gmail.com > Sun Jun 21 10:05:52 PDT 2015 > Previous message: [Bloat] TCP congestion detection - random thoughts > Next message: [Bloat] TCP congestion detection - random thoughts > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > 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. > --001a114f079a5f371c05190c3d6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'll have to find some time= to look at those links.

I guess I wasn't thinking= of using latency to determine the rate but only nudge the rate, but use it= only to determine to back off for a bit to allow the buffer to empty, but = maintain the same rate overall. So if you have a 60ms RTT but a 50ms min RT= T, keep your current rate but skip one segment periodically or maybe only m= ake it a smaller segment like 1/2 the max size, but not often enough to mak= e a large difference. Maybe allow latency to only reduce the current target= rate by no more than 5% or something.

=
I guess the starting pattern could be some= thing like this
1) build up, 2x segments pe= r ACK
2) make sure ACKd bytes increases at = the same rate as bytes sent
3) once bytes A= CKd stops increasing, attempt to reduce segment size or skip a packet until= current RTT is near the target RTT, but no more 5%

Of course this is only good f= or discovering the current free bandwidth. There needs to be a way to perio= dically probe to discover new free bandwidth. The idea was the max detected= should rarely change, so don't be aggresive when probing near the max,= but when below the max, attempt to find free bandwidth by adding additiona= l segments and seeing if the ACKd byte rate increases. If it does, start gr= owing.

I don't have an engineering background, just playing with thoughts.


[Bloat] TCP congestion detection - random thou= ghts
>=C2=A0
> Alan Jenkins alan.christopher.jenkins at gmail.com=C2=A0
> Sun Jun 21 10= :05:52 PDT 2015
> Previous message: [Blo= at] TCP congestion detection - random thoughts
> Next message: [Bloat] TCP congestion detection - random thoughts
> Messages sorted by: [ date ] [ thread ]= [ subject ] [ author ]
> Hi Ben
>=C2=A0
> So= me possible Sunday reading relating to these thoughts :).
>=C2=A0
> https://lwn.net/Articles/645115/ &qu= ot;Delay-gradient congestion control"=C2=A0
> [2015, Linux partial implementation]
>=C2=A0
> our Dave's reply t= o a comment:
>=C2=A0
> https://lwn.= net/Articles/647322/
>=C2=A0
> Quote "there is a huge bias (based on th= e experimental evidence) that=C2=A0
> cl= assic delay based tcps lost out to loss based in an undeployable fashion&qu= ot;
>=C2=A0
> - not to argue the quote either way.=C2=A0 But there's some im= plicit=C2=A0
> references there that are= relevant.=C2=A0 Primarily a well-documented result=C2=A0
> on TCP Vegas.=C2=A0 AIUI Vegas uses increased delay a= s well as loss/marks as=C2=A0
> a conges= tion signal.=C2=A0 As a result, it gets a lower share of the=C2=A0
> bottleneck bandwidth when competing with other= TCPs. Secondly uTP has a=C2=A0
> latenc= y (increase) target (of 100ms :p), _deliberately_ to de-prioritize=C2=A0
> itself. =C2=A0(This is called LEDBAT and= has also been implemented as a TCP).
>= =C2=A0
> Alan
>=C2=A0
>=C2=A0
> On 21/06/15 17:19, Benjamin Cronce wrote:
> > Just a random Sunday morning thought that ha= s probably already been=C2=A0
> > tho= ught of before, but I currently can't think of hearing it before.
=
> >
> &= gt; My understanding of most TCP congestion control algorithms is they=C2= =A0
> > primarily watch for drops, bu= t drops are indicated by the receiving=C2=A0
> > party via ACKs. The issue with this is TCP keeps pushing more d= ata=C2=A0
> > into the window until a= drop is signaled, even if the rate received is=C2=A0
> > not increased. What if the sending TCP also monitors r= ate received and=C2=A0
> > backs off = cramming more segments into a window if the received rate=C2=A0
> > does not increase.
> >
> > Two things to me= asure this. RTT which is part of TCP statistics=C2=A0
> > already and the rate at which bytes are ACKed. If you = double the=C2=A0
> > number of segmen= ts being sent, but in a time frame relative to the=C2=A0
> > RTT, you do not see a meaningful increase in the ra= te at which bytes=C2=A0
> > are being= ACKed, may want to back off.
> >
> > It just seems to me that if you have= a 50ms RTT and 10 seconds of=C2=A0
> &g= t; bufferbloat, TCP is cramming data down the path with no care in the=C2= =A0
> > world about how quickly data = is actually getting ACKed, it's just=C2=A0
> > waiting for the first segment to get dropped, which would nev= er happen=C2=A0
> > in an infinitely = buffered network.
> >
> > TCP should be able to keep state that tracks the= minimum RTT and=C2=A0
> > maximum AC= K rate. Between these two, it should not be able to go over=C2=A0
> > the max path rate except when attempting t= o probe for a new max or=C2=A0
> > mi= n. Min RTT is probably a good target because path latency should be=C2=A0
> > relatively static, however path fr= ee-bandwidth is not static. The=C2=A0
> = > desirable number of segments in flight would need to change but would= =C2=A0
> > be bounded by the max.
> >
>= > Of course naggle type algorithms can mess with this because when ACKs= =C2=A0
> > occur is no longer based e= ntirely when a segment is received, but also=C2=A0
> > by some other additional amount of time. If you assume th= at naggle=C2=A0
> > will coalesce N s= egments into a single ACK, then you need to add to=C2=A0
> > the RTT, the amount of time at the current PPS, how= long until you=C2=A0
> > expect anot= her ACK assuming N number of segments will be coalesced.=C2=A0
> > This would be even important for low latency = low bandwidth paths.=C2=A0
> > Coales= ce information could be assumed, negotiated, or inferred.=C2=A0
> > Negotiated would be best.
> >
> > Anyway, j= ust some random Sunday thoughts.
>=C2=A0=
--001a114f079a5f371c05190c3d6f--