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

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.

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

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

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

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