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

Gorry,

On 30/04/2020 09:36, Gorry Fairhurst wrote:
> 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:
>>
>>> - 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.

[BB] If it's likely that we need to move beyond slow-start behaviour in 
future, building heuristics around slow-start is the worst possible step 
we could take. That's the ossification I'm talking about.

When we implemented paced chirping, it was really hard not to confuse 
the heuristics in Linux receivers. Linux receivers are built to detect 
the end of today's slow-start behaviour. Our sender wasn't using 
anything like slow start behaviour, which triggered their heuristics 
much too early.

Magically increasing the delack ratio after 100 packets is another 
behaviour we must not encourage.

Sender control of the DelAck ratio can be really simple. Then we have a 
simple solution that will last for ever.
We must not dig the heuristics and magic numbers hole any deeper.

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

[BB] Sender control of the receiver's DelAck ratio would be always 
better and never worse in these cases. It might not solve the lack of 
path knowledge. But wherever path knowledge can be gathered, sender 
control of the receiver's DelAck ratio would then be useful/necessary.

Then, any sender can implement "link-specific methods" unilaterally (or 
not if it chooses). Sndr-rcvr co-ordination is an important piece that's 
missing.

You seem to be generating confusion. There is still good reason to add a 
generally useful missing capability (sender control of receiver DelACK 
ratio), whether or not other capabilities might sometimes be missing in 
certain odd scenarios.

Do one thing and do it well.

>>>
>>> * 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).

[BB] I certainly agree with the need to base this on experience.
However, all we have at the moment is experience of protocols /without/ 
sender control of the DelAck behaviour of the receiver. That's useful 
experience, but only to demonstrate the /problem/.

It would be good to hear some empirical experience of protocols /with/ 
sender control.

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

[BB] As above. Data about the existing Internet without the proposed 
capability is useful to characterize the problem. But need to be aware 
of its limitations at characterizing the solution-space proposed here.

Bob

>> Thanks for elaborating.
>>
>>
>>
>> Bob
> Gorry
>>
>>
>>>
>>> Gorry
>>>
>>>
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/