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

[Yoshifumi Nishida <[e-mail]>]

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.

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?

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?

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?

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.

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

Thanks,
--
Yoshi