[tcpm] A longer follow-up on my comment on draft-gomez-tcpm-delack-suppr-reqs

[Gorry Fairhurst <[e-mail]>]

First of all thank you for bringing this topic to the WG. I do think it 
is important that we discuss what ACKs are used for, how we expect them 
to be used and what the practical implications are for using ACKs across 
Internet paths.

About the slides, I didn't have much time at the Mic. so maybe I sounded 
rather harsh, but I would suggest we do need to set a relatively high 
bar to adopting a piece of work in this space ... and we do need data 
and real understanding of what we are trying to fix and how we can avoid 
making it worse by accident in other cases.

We went through a rather lengthy discussion in tsvwg on a similar (but 
different) topic regarding immediate negative acknowledgment for SCTP 
(RFC 7053- SACK-IMMEDIATELY Extension for SCTP) and found there were a 
few key places where for that protocol this did make sense.

However, I actually don't believe your list of issues (i). Here is 
why... (I am interested if you think differently or know more).

I've tried to roughly follow your points:

* Slow start
- I agree Delayed ACKs increase slow start, the more you delay the 
bigger the impact. However, the impact is for cases where ACKs are 
delayed on intervals comparable with or more than the Path RTT.
- DAASS is a simple fix, that appears to help a lot when there is data 
waiting for the arrival of the delayed ACK. ABC is important also (well 
what I think people understand by ABC - rather than the RFC on this).
* High bit rate environments and short data segments

If you really don’t want delayed ACKs, the protocol using TCP ought to 
disable nagle. Or you would perhaps use DAASS... I’m not sure which 
problem you speak about?


* Beyond classic ACK transmission behavior
I do agree that Delayed ACKs preclude using sender behaviors intended to 
quickly and non-intrusively probe for available capacity during slow 
start. This is important to me, but I am very wary about the idea of 
sending more ACKs to do this, and we need to be careful to gain 
sufficient information about what the receiver has seen - not just to 
get a bunch of separate (each cumulative) ACKs. This really doesn’t give 
much fidelity to the sender. I’d be happy to talk more about what might 
be better!
* IoT scenarios
I can see the argument of an ACK energy cost for the IoT device. At 
least, I would assume IoT devices can be tuned, and the apps they talk 
to can be tuned. Appropriate guidance helps!

* Bursty Apps
I think you can add varying workloads as something important.  By which 
I mean apps that do transactional stuff, or are controlled by 
applications where the data transmission need varies.When we looked at 
CWV and the ideas that the applications control the traffic patterns in 
one group of applications, we also noted that these applications change 
the way they use the network. That’s important for a timely restart to 
growing the cwnd (etc). Such applications can also be very sensitive to  
network delay.  These are probably also of interest!

So....  the reason for hesitancy overall is I see this as tricky space 
to get correct.

There are many places where fewer ACKs are good - if you have per ACK 
interrupt costs - if the capacity consumed by ACKs is important - the 
cost of sending in the link technology is high - etc. This is 
complicated for TCP (and much less so for QUIC - because QUIC has a 
notion of pacing; QUIC’s loss recovery is different; and QUIC’s ACKs are 
not easily thinned, at least at present). Any TCP method has to live 
with networks that experience pain from more ACKs, but also may deploy 
(various) mitigations.


There are also cases where you’d like more information than a delayed 
ACK provides (e.g. chirping and similar probing methods) and there are 
application pathologies that would love an ACK at the end of a packet 
burst (be that 1 or 100s of packets). Any method has to live with a wide 
variety of paths and applications.

Happy to discuss more. And I suspect other people may also respond on 
list. We have lots of data for QUIC and TCP - but most of our data 
focusses on testbeds or on actual broadband satellite services.

Gorry