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

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 28 Apr 2020 10:52:22 +0200

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/
>
>