From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vn0-x233.google.com (mail-vn0-x233.google.com [IPv6:2607:f8b0:400c:c0f::233]) (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 66EB521F619 for ; Sat, 6 Jun 2015 04:15:49 -0700 (PDT) Received: by vnbg190 with SMTP id g190so1838110vnb.6 for ; Sat, 06 Jun 2015 04:15:48 -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=D6mEekIDKxw80151hEvLFvkhKAc8Az/rLrrGOU2xquM=; b=pJmVf3sVfUswljGIQuJBX+BpZ5u1gEP9lQaTRRLCcWrlfME2WW+o8We+Zdb/8+szgi oEE1XRmO3PM9zqmBmFS/eZiLlXRRbzQ+Kqe24Ok1UjttQKR8BiZygrHQVcuq9aGEak6i DLzw9x7Rs1+lQo4KfGojdrkWq9kc6IG66Njn5nmuHy2RKzlJVQ+e8k7sNsQ857O48Llg +uS72I3rdQpO7b5fF5DszDhnUo0Asa7hY76oQpMMg2Bpo7DGMQwkHxlDcDiin7irrQA2 Hne+UBLifCtOuoP9jH2iUWGO+ajj1rf68nzljZwx9kQGKGDyoXELXso+VtHoeu50KEHu Usnw== MIME-Version: 1.0 X-Received: by 10.52.136.9 with SMTP id pw9mr14014948vdb.44.1433589348799; Sat, 06 Jun 2015 04:15:48 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Sat, 6 Jun 2015 04:15:48 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Sat, 6 Jun 2015 04:15:48 -0700 (PDT) In-Reply-To: References: Date: Sat, 6 Jun 2015 14:15:48 +0300 Message-ID: From: Jonathan Morton To: David Lang Content-Type: multipart/alternative; boundary=bcaec52e658be39ec20517d7876d Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] lower bounds for latency X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 11:16:18 -0000 --bcaec52e658be39ec20517d7876d Content-Type: text/plain; charset=UTF-8 It's an interesting viewpoint, at least, and probably should stimulate some thought about what happens with very small BDPs. In this case we're talking about a BDP below 3KB per flow, including light times, permitted queuing delays, and link occupancy time of a single packet (which by itself guarantees that the total BDP is always at least one packet). A point that I think gets missed in discussions involving delayed acks, is that it's always possible to force an immediate ack from the receiver, simply by setting the Push flag. A TCP sender could use that if its cwnd is forced down to 2 segments or less, without more invasive changes, in order to maintain traditional ack clocking. However, with only one packet in flight, loss of that packet would result in an RTO, which I think would be much more severe a penalty than AQMs generally assume they are giving. This is a related problem to having too small a receive window. I happened to be doing some thinking about TCP Pacing yesterday, and how it might compare to or be convertible into a truly rate based TCP congestion control. It might be relevant to summarise my thoughts here: Pacing is generally thought of as spreading the transmission times of individual packets throughout the RTT interval corresponding to each congestion window. This is straightforward to implement in theory - calculate the earliest permitted transmission time of packet N+1 as the transmission time of packet N plus the length of packet N multiplied by the RTT estimate divided by the congestion window length (in bytes). This construct assumes the availability of a high resolution timer for scheduling packets, but so does Bob's proposal. The equation above does not include a term for where in the window the packet lies. This is intentional - that information is not needed. If pacing is thus applied even to packets transmitted out of order (ie. retransmissions), and the test against the end of the cwnd in existing TCP is removed (but not, of course, the rwnd test), then we easily get a rate based TCP congestion control which, as it turns out, can scale down to a single segment cwnd without incurring the risk of a single packet drop causing an RTO. It is then relatively straightforward to extend this behaviour to cope with sub-segment cwnd, either by measuring cwnd in bytes rather than segments, or by introducing a scale factor for RTTe which is incremented in lieu of attempting to halve a cwnd of 1. - Jonathan Morton --bcaec52e658be39ec20517d7876d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It's an interesting viewpoint, at least, and probably sh= ould stimulate some thought about what happens with very small BDPs. In thi= s case we're talking about a BDP below 3KB per flow, including light ti= mes, permitted queuing delays, and link occupancy time of a single packet (= which by itself guarantees that the total BDP is always at least one packet= ).

A point that I think gets missed in discussions involving de= layed acks, is that it's always possible to force an immediate ack from= the receiver, simply by setting the Push flag. A TCP sender could use that= if its cwnd is forced down to 2 segments or less, without more invasive ch= anges, in order to maintain traditional ack clocking.

However, with only one packet in flight, loss of that packet= would result in an RTO, which I think would be much more severe a penalty = than AQMs generally assume they are giving. This is a related problem to ha= ving too small a receive window.

I happened to be doing some thinking about TCP Pacing yester= day, and how it might compare to or be convertible into a truly rate based = TCP congestion control. It might be relevant to summarise my thoughts here:=

Pacing is generally thought of as spreading the transmission= times of individual packets throughout the RTT interval corresponding to e= ach congestion window. This is straightforward to implement in theory - cal= culate the earliest permitted transmission time of packet N+1 as the transm= ission time of packet N plus the length of packet N multiplied by the RTT e= stimate divided by the congestion window length (in bytes).

This construct assumes the availability of a high resolution= timer for scheduling packets, but so does Bob's proposal.

The equation above does not include a term for where in the = window the packet lies. This is intentional - that information is not neede= d. If pacing is thus applied even to packets transmitted out of order (ie. = retransmissions), and the test against the end of the cwnd in existing TCP = is removed (but not, of course, the rwnd test), then we easily get a rate b= ased TCP congestion control which, as it turns out, can scale down to a sin= gle segment cwnd without incurring the risk of a single packet drop causing= an RTO.

It is then relatively straightforward to extend this behavio= ur to cope with sub-segment cwnd, either by measuring cwnd in bytes rather = than segments, or by introducing a scale factor for RTTe which is increment= ed in lieu of attempting to halve a cwnd of 1.

- Jonathan Morton

--bcaec52e658be39ec20517d7876d--