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

See some more explanation in line.

On 29/04/2020 22:58, Bob Briscoe wrote:
> Gorry,
>
> On 29/04/2020 18:54, Gorry Fairhurst wrote:
>>
>>
>> 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.
> I appreciate you taking time to qualify your initial harsh words. I 
> would ask you to still take even more time over this review. People 
> listen to you on this subject, and I think you are glossing over large 
> areas of the issue too quickly.
>
>> - DAASS is a simple fix, that appears to help a lot when there is 
>> data waiting for the arrival of the delayed ACK. 
>
> Any heuristic at the receiver to detect the end of a pattern of 
> start-up such as slow-start, ossifies that pattern into the Internet. 
> Sender control of the DelACK ratio removes that ossification.
>
I initially thought the same, DAASS tried to fix multiple problems. 
However, as regards DAASS  reducing the waiti for the ACK to a rounds of 
initial cwnd growth, I think the key understanding is the sender use of 
byte accounting (for stretch-ACKs) not individual ACKs, (that might 
imply a need for some burst-mitigation for stretch ACKs, because you 
reduce ACK clocking).

I like what I understand Chrome's QUIC does:  In the first 100 received 
packets, send an ACK for each packet (could be each pair of packets).  
This rapidly grows a cwnd of about 140 packets (assuming exponetial 
growth). Once the cwnd is >100 then an ACK covering 10 packets/segments 
becomes a small proportion of the cwnd (the additional delay from 
per-packet ACKs is small). The receiver can moves to a larger default 
ACK ratio.

>
>> ABC is important also (well what I think people understand by ABC - 
>> rather than the RFC on this).
>
> Yes.
>
>> * 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!
>
> Indeed, ACK frames in QUIC that give the arrival times of data packets 
> are an alternative - as long as they are not stretched beyond the time 
> at which they would have been useful.
>
Interesting, I think.
> But we are more limited for space in TCP. As long as a TCP server is 
> serving bulk and short flows, it can put more effort into receiving 
> more ACKs during flow startup, and save its processing power by using 
> less frequent ACKs for the majority of its data - transmitted in 
> congestion avoidance.
>
>
Also seems true.
>> * 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!
>
> Tuning is for a scenario, not for widely differing scenarios. The 
> message of this draft is that a connection sometimes needs to be able 
> to adapt its ACK ratio at run-time. Not every IoT device is always 
> deployed for just one scenario. Neither is its peer. To me this says 
> adaptation mustn't be complex (and doesn't have to be).
>
Heterogeniety of the network segments is tricky. Some optimisations 
could be handled by link-specific methods - header compression perhaps 
is an example, other things need to be adapted end-to-end. However, 
end-to-end transport has to work for all types of path (links) - and 
often does not know the path.
>>
>> * 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!
>
> Yes.
>
>>
>> So....  the reason for hesitancy overall is I see this as tricky 
>> space to get correct.
>
> But trickiness is the point of starting this requirements document, 
> isn't it?
> Please can you articulate better why you seem negative about this 
> exercise?
>>
>> 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.
>
> Yes. But reading between the lines I hear you say "Don't start this 
> exercise".
> Pls explicitly articulate your implicit message.
>
The slide asked about adopting this work - my words were against doing 
that at that time with that revision of this document.

I miss seeing presentations with results and showing the thinking. I  
wonder if we need a specific agenda slot to focus on such topics. I 
expect we'll learn a lot from some data from a variety of 
problem-spaces/use-cases, especially if the timeslot is sufficient to 
include thinking and experience from people outside of TCPM. (That's 
another thought - and probably should be another thread).

>>
>> 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.
>
> Thanks for elaborating.
>
>
>
> Bob
Gorry
>
>
>>
>> Gorry
>>
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>