Re: [tcpm] Sender control of Delayed ACKs (was Re: More motivating scenarios for tcpm-ack-pull)

Carles Gomez Montenegro <carlesgo@entel.upc.edu> Tue, 28 April 2020 08:53 UTC

Return-Path: <carlesgo@entel.upc.edu>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5624D3A1109 for <tcpm@ietfa.amsl.com>; Tue, 28 Apr 2020 01:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeEEMruT9GsA for <tcpm@ietfa.amsl.com>; Tue, 28 Apr 2020 01:53:11 -0700 (PDT)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108923A1101 for <tcpm@ietf.org>; Tue, 28 Apr 2020 01:53:10 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 03S8qMPD055016; Tue, 28 Apr 2020 10:52:22 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 6A33C1D53C1; Tue, 28 Apr 2020 10:52:21 +0200 (CEST)
Received: from 83.53.208.128 by webmail.entel.upc.edu with HTTP; Tue, 28 Apr 2020 10:52:22 +0200
Message-ID: <f41618b1adb935f5b4f2b970ee0dcb33.squirrel@webmail.entel.upc.edu>
In-Reply-To: <220dabb7-c4bb-d2f2-4b56-29a2de62a71c@bobbriscoe.net>
References: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net> <13486113479ebcb344247daedda10467.squirrel@webmail.entel.upc.edu> <CAEeTejJC4KLbjLNWmVxPXwDtrC=rjrcOsVnwjEym2uEhJZq7cw@mail.gmail.com> <3f4d3d94-24a8-4ed8-a752-ae5242907d43@gmx.at> <ef6c55535a860b37056cd014ad178416.squirrel@webmail.entel.upc.edu> <db2a849d-a26f-d741-a039-1622c478ee50@gmx.at> <fde0262a-0206-92bf-b529-4043cacc8030@bobbriscoe.net> <391035ee6f57baa407f9be225db8dfbc.squirrel@webmail.entel.upc.edu> <44192613-4e05-bffa-a810-ef261d78d190@bobbriscoe.net> <aff57f8918989339649e324481502f6c.squirrel@webmail.entel.upc.edu> <220dabb7-c4bb-d2f2-4b56-29a2de62a71c@bobbriscoe.net>
Date: Tue, 28 Apr 2020 10:52:22 +0200
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: tcpm IETF list <tcpm@ietf.org>, Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk>
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at dash
X-Virus-Status: Clean
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Tue, 28 Apr 2020 10:52:22 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/QB5J_s1tiWbOuxgYvU7g9YbuuOw>
Subject: Re: [tcpm] Sender control of Delayed ACKs (was Re: More motivating scenarios for tcpm-ack-pull)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Apr 2020 08:53:15 -0000

Hi Bob,

Thanks a lot for your further feedback below.

We will update the document as per your comments after tomorrow's WG meeting.

By the way, thanks for suggesting a request for WG adoption. We plan to
make the request during our slot in tomorrow's meeting.

Cheers,

Carles


> Carles,
>
> On 26/03/2020 14:06, Carles Gomez Montenegro wrote:
>> Hi Bob,
>>
>> Thanks a lot once again for all your comments!
>>
>> As you may have seen, we just published a -01, with the aim to address
>> your comments.
>>
>> Please find below our inline responses:
>>
>>> Carles & Jon,
>>>
>>> Yes, if the tcpm WG was prepared to consider adopting this, I'd support
>>> it.
>>>
>>> A few comments:
>>>
>>> I'm not sure I would limit it to "suppression" of delayed ACKs, and I
>>> don't just mean it should include releasing suppression. In many
>>> circumstances the sender would be happy with less frequent ACKs than
>>> the
>>> receiver is generating. E.g. with high performance data transfers, 1/16
>>> would often be fine when there are hundreds of packets in flight. But,
>>> because the receiver can't be sure whether the sender would suffer one
>>> of the downsides to delaying ACKs, it maintains a conservatively low
>>> delayed ACK ratio.
>>>
>>> So perhaps a better scope (and title) would be "Sender control of
>>> Delayed ACKs in TCP"?
>>>
>>> I've added 'in TCP', because I think it's useful to make the scope
>>> concrete. But I think this doc could also be useful for other transport
>>> protocols, particularly QUIC.
>> Agreed!
>>
>> We have updated accordingly the document (including the title and
>> abstract).
>>
>>> S3.1 & S3.2 Slow start & High bit rate environments and short data
>>> segments
>>>
>>>      However, use of Delayed ACKs reduces the amount
>>>      of ACKs received by the sender, thus reducing the rate of cwnd
>>>      growth, increasing transfer time and reducing throughput, when
>>>      compared with sending an ACK for each incoming data segment.
>>>
>>> I think ABC (appropriate byte counting) allows the sender to
>>> unilaterally address that concern without needing ACK Pull [RFC3465].
>> Thanks for the comment. Version -01 now reflects that ABC could be used
>> to
>> address the concern, while also mentioning that it remains as an
>> experimental mechanism, not fully included in RFC 5681.
>>
>>> The reference to 'more rapidly get up to speed during slow-start
>>> without
>>> overshoot' is a bit opaque. Rather than "describing by reference", it
>>> needs to describe the lack of ability to send patterns of packets (e.g.
>>> chirps) and be able to time the gaps between the ACKs. At minimum, the
>>> citation should refer to Appendix B.4, which was the mechanism proposed
>>> to do ACK pull at the time.
>> Agreed. We have added a more explicit description in -01, and we also
>> refer to Appendix B.4.
>>
>>> S.3.4 Beyond classic ACK transmission behavior
>>>
>>> It ought to mention that many link technologies (Satellite, DOCSIS,
>>> LTE,
>>> WiFi, ...?) do TCP ACK thinning 'cos TCP doesn't do it itself, but it
>>> improves performance (when the ACK stream becomes the bottleneck for
>>> the
>>> forward path, because many reverse paths have pathetic bandwidth, esp.
>>> if a parallel upload is going on).
>>>
>>> See "ACK Scaling and Performance on AsymmetricPaths"
>>> https://erg.abdn.ac.uk/~downloads/ackscaling.pdf
>> Agreed. Added in -01. And thanks for the pointer!
>
> [BB]
>                  Examples of technologies where deployments
> have
>                  been reported to do ACK thinning include
> satellite
> links, DOCSIS
>                  cable networks, mobile cellular networks,
> among others.
>
> For DOCSIS at least I know that it's not just a case of "deployments
> have been reported". TCP ACK thinning is in the DOCSIS spec [DOCSIS3.1].
>
> Also, I've just been talking with a colleague, who tells me that in WiFi
> (sorry, don't know how widely this applies), if there are multiple TCP
> ACKs for the same flow in the transmit queue, it will remove them all
> except the last when it transmits the queue. Also [Kim06] includes
> pseudocode for a model of WiFi ACK thinning.
>
>
>   [DOCSIS3.1] CableLabs, "MAC and Upper Layer Protocols Interface
> (MULPI) Specification, CM-SP-MULPIv3.1", Data-Over-Cable Service
> Interface Specifications DOCSIS(R) 3.1,
> <https://specification-search.cablelabs.com/CM-SP-MULPIv3.1>.
>
> [Kim06] Hyogon Kim, Hyogon Kim, Heejo Lee, Heejo Lee, Sangmin Shin and
> Inhye Kang, "On the Cross-Layer Impact of TCP ACK Thinning on IEEE
> 802.11 Wireless MAC Dynamics"     DOI: 10.1109/VTCF.2006.463 In Proc.
> 64th IEEE Vehicular Technology Conference, VTC 25-28 (September 2006)
>
>
>
> Nit:
> s/may allow alleviating congestion on that path/
>   /may allow congestion on that path to be alleviated/
>
>
>>
>>> 4.2. Per-segment granularity
>>>
>>> Between per-segment and permanent, there's per-connection suppression.
>>> I'm not saying that would be any use, I'm just saying it doesn't have
>>> to
>>> be permanent.
>> Agreed! Added in -01.
>>
>>> 4.4 Support for enabling generic ACK ratios
>>>
>>> This reminds me of a subtle additional requirement. When you move from
>>> ACK pull to controlling the ACK ratio, there's an important distinction
>>> between a sender's packet stopping the receiver delaying the ACK for
>>> /that/ packet (as in ACK pull), vs. setting the receiver's Delayed ACK
>>> policy for /that and subsequent/ packets.
>>>
>>> This raises the question, should the mechanism use soft state (repeated
>>> in every packet), or connection state (remembered by the receiver)?
>>> Which is hinted at in your section on "safe return to normal
>>> operation".x
>> We have added text in section 4.4, with the aim to incorporate your
>> comments above.
>
> [BB]
>
>                  The desired generic ACK ratio is intended
> to be in
> force for the
>                  current data segment, and for subsequent data
> segments
> (at least,
>                  during a time interval of a duration that may
> depend on
> several
>                  factors).
>
> I didn't mean to say "that packet and subsequent packets" should be the
> only requirement. The original ACK pull pattern where the pull is just
> for "that packet" is also a valid possibility. They are just different
> models. If the mechanism ends up using a field in the main TCP header,
> then presumably it will be sent on every packet, and therefore there's
> no need to say what the behaviour should be in the absence of any
> request on subsequent packets.
>
>
>>
>>> 4.10+ Extra requirement: Who's in control?
>>>
>>> The receiver cannot be expected to control ACKs in any way the sender
>>> wants, which it will not always be able to honour anyway. So the
>>> semantics have to be of a hint, not a request or a command. Then
>>> there's
>>> the question of whether the receiver just does what it wants, or
>>> whether
>>> it ought to tell the sender it's not doing what it was asked.
>>>
>>> It might seem that the the receiver silently not doing what it's told
>>> is
>>> the simple case. However,  it adds complexity to anything trying to
>>> rely
>>> on the behaviour (e.g. the slow start examples).
>> We have added the new requirement, and have edited its content, based on
>> your input.
>
> [BB] Thanks for picking up all my comments so willingly.
>
> It occurs to me that there's probably not much point in a message from
> the receiver saying whether it is complying with the request or not. The
> sender can detect which ACKs are arriving, so it knows the truth,
> whatever the receiver says it's doing. It sort-of might be useful to
> know what the receiver says it's trying to do, to know how the network
> might be intervening. But, if ground truth doesn't match what the
> receiver says it's doing, the sender doesn't know whether the receiver
> is lying, or whether the network is thinning ACKs.
>
>>> A good first draft.
>>> Thank you.
>> Once again, thanks a lot for your comments!
>
> [BB] I suggest you ask the chairs how to go about asking for an adoption
> call, given that ought to be able to happen on the ML given we might not
> have a f2f meeting for some time.
>
> Cheers
>
>
>
> Bob
>
>>
>> Best regards,
>>
>> Carles
>>
>>
>>> Bob
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
>