Re: [tcpm] some comments on draft-gomez-tcpm-ack-rate-request-02.

Carles,

On 05/03/2021 12:34, Carles Gomez Montenegro wrote:
> Hi Yoshi,
>
> Thanks a lot for your insightful comments!
>
> Also, sorry for the late response.
>
> Please find inline responses to your comments below:
>
>> Hi,
>> I've read the draft. I like the basic concept of the draft and think it's
>> useful in some ways. I put some comments belows.
>>
>> 1: In general, I would like to see some more example usages or guidances
>> of
>> the features described in the draft.
>>      For example, one of my naive questions is how often we want to change
>> the frequency of ACKs.
>>      In 'small' or 'large' scenarios in the draft, it seems to me that it
>> might be sufficient to use the same ACK frequency during the connection.
>>      It would be good if the draft describes the needs of changing
>> frequency.
> Agreed, we will add some guidance in this regard.
>
> Yes, in many scenarios it may make sense to just set the ACK frequency
> once during the connection.
>
> We'll think further about whether there could be particular scenarios
> where the ACK frequency might need to be changed during the connection
> lifetime.

[BB] Here's a couple of reasons why the DelACK ratio would change during 
the lifetime of a flow.

1/ I am interested in being able to use a facility like TARR to suppress 
delACKs in order to measure the RTT of each packet, particularly during 
flow start-up, but then release that constraint once the flow has started.

A Linux receiver has a heuristic to detect slow start and suppress 
DelACKs just for that period.  But variants of slow-start at the sender 
such as hystart, hystart++ etc. alter the ending of slow-start, so they 
can confuse the heuristics at the receiver. Similarly we've been working 
with a technique called paced chirping, which confuses the heuristics. 
Or put another way, if someone invents a better approach than slow 
start, but it confuses the heuristics at the receiver, it means that the 
receiver's heuristics have ossified the existing slow-start behaviour at 
the sender. In contrast, an explicit signal between the peers like TARR 
allows for evolution.

2/ In the high cwnd scenarios, the sender wants the DelACK ratio to 
still ensure a minimum number of ACKs per RTT. Obviously cwnd is not 
instantly large - it grows from the start of the flow onwards, and when 
the flow starts, the sender doesn't know what it will reach. Also, the 
window changes as other traffic comes and goes or the link capacity 
changes. So clearly the sender will need to keep updating the DelACK ratio.

==Units==

This last example raises the question of whether the number of packets 
between ACKs is the correct unit to use for the DelACK ratio. If the 
sender is trying to ensure there are say 4 ACKs per RTT, you might 
naively think it would be better to tell the receiver that. I worked 
through this question of units here:
https://github.com/quicwg/base-drafts/issues/1978#issuecomment-436553339
pasted below

>>> Packets? bytes? time? fraction of RTT?
>>>
>>> Think of this question in two stages:
>>> Q1. what units the sender starts from
>>> Q2. what units the message is in, which the sender has to derive from Q1
>>>
>>> If the message was a fraction of 1 RTT, the receiver would have to 
>>> calulate the sender's RTT. It can do that, using ACKs of ACKs, but 
>>> that implies work and delay.
>>>
>>> In all cases that I could see in #1428 
>>> <https://github.com/quicwg/base-drafts/issues/1428>, the sender had 
>>> all the info to translate from one unit to another (it knows its own 
>>> SMSS, its window, its RTT). This leaves Q2, to which a good enough 
>>> answer is packets (which also compresses the message size).
>>>

more...

>
>> 2:  "a TARR-option-capable receiving TCP MUST modify its ACK rate to one
>> ACK every R full-sized received data segments from the sender, as long as
>> packet reordering does not occur"
>>      -> Do this mean if recorder happens, TARR option will be ignored?
>>          Let's say if you send packet 1 with TARR and packet 2 without
>> TARR,
>> if packet 2 arrives earlier than packet1, the TARR option in packet1 will
>> be ignored?
>>          How about storing the highest seqno that carries TARR and compare
>> it when you receive packets with TARR?
> Well, yes, the phrase "as long as packet reordering does not occur" might
> not be clear enough here. The intent was to say that one ACK will be sent
> every R full-sized received data segments, but if there is reordering,
> then a different amount/rate of ACKs may be sent for a while.
>
> Anyway, your suggestion is very useful, since the behavior in a scenario
> like the one in your example needs to be clear as well.
>
> Therefore, we take two action points from this comment: clarifying the
> text, and also incorporating your suggestion.
>
>> 3:  "If all bits of this field are set to 0, the field indicates a request
>> by the sender for the receiver to trigger one or more ACKs immediately. "
>>      -> For me, this might be read as if it can request to send back
>> multiple ACKs immediately. How about changing it 'without delay' or
>> something?
> Agreed, we will edit the text.
>
>> 4:  "Otherwise, the field carries the binary encoding of the number of
>> full-sized segments"
>>      -> I'm not sure about the meaning of binary encoding here. does it
>> mean storing 1-255 values or else?
> Yes, that is the intended meaning (well, for 1-127 values with the new
> field size).
>
> The original intent was to be clear on how to represent the value, but is
> perhaps "binary encoding" misleading?
>
>> 5: I have some concerns on ignoring reorder.
>>      In case of QUIC, even if reorder is ignored, timer-based loss
>> detection
>> scheme can still find packet losses.
>>      However, in TCP, RACK might not be always supported, so it might take
>> significant amount of time to find losses if this feature is enabled.
>>      I think the doc needs to discuss this point and it would be good to
>> have some guidelines here.
> Agreed!

[BB] It wasn't clear to me what problem was intended to be addressed by 
the 'ignore reordering' flag.
If it was that the sender is using time-based detection, so it tells the 
receiver it doesn't need ACKs of out of order packets, that would make 
sense. But perhaps you had a different use-case in mind?

>
>> 6: Similar to 1:, I am a bit wondering about the use case of N field in
>> TARR option.
>>     I can imagine this would be useful if an endpoint uses Hystart++ or
>> similar approach.
>>     However, is it still useful for other cases such as plain slow-start
>> algorithm?
>>     I think it would be better to have some usage guidelines for N as well.
> Agreed. We will add this guidance.

[BB] It seemed to me that the ability to suppress ACKs for N packets 
would be redundant. Because the sender can send a different TARR option 
after N packets to ask the receiver to change the DelACK ratio. This 
would seem more useful in 2 respects:
1) It doesn't consume any option space
2) Typically the sender doesn't know exactly when its need for quick 
ACKs will end, until it does end.

>
>>     Also, since N looks finite number, I'm wondering how to set R=0 for the
>> entire connection. Or, we shouldn't do such a thing?
> Good point!
>
> Perhaps we can define a special value for N meaning "infinity".
>
> There are also considerations similar to the earlier question on whether
> the expected behavior would be the same for the whole connection lifetime.
> Perhaps, in some cases, setting N to "infinity" might represent an
> improvement (since the option would only be sent once). However, if this
> can represent any potential issue, a different setting should be chosen
> for N.
>
> Let's provide guidance on this.

[BB] I have some other comments on the draft, but I'll send a separate 
review email for those that don't relate directly to Yoshi's thread.

Cheers

Bob

>
> We will incorporate your comments in our next draft update.
>
> Thanks!
>
> Cheers,
>
> Carles
>
>
>
>> Thanks,
>> --
>> Yoshi
>> _______________________________________________
>> 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/