Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-rate-request-02.txt]

[Carles Gomez Montenegro <[e-mail]>]

Hi Bob,

Many thanks for your review of -03 !

Please find below our inline responses:

> Carles, Jon
>
> I would support this draft being adopted (as I've said numerous times
> before).
>
>
> I believe I agree with everything you've proposed (except the one I
> mention below), and it's good to give the WG two options for how best to
> proceed on the encoding.

Many thanks!

> The one I'm unsure about is Ignore Order, 'cos I haven't seen anything
> that says what the benefit is (there might be one, I just haven't seen
> it).
> If there is little benefit, we could remove the I flag. "Do one thing,
> and do it well"

Based on similar feedback from many folks, we have decided to remove the
Ignore Order feature in -04.

> It hits the problem of scarce option space on the SYN, so I would
> suggest it goes forward as an independent option, but that it is also a
> candidate for being aggregated in draft-nishida-tcpm-agg-syn-ext, if
> that ever goes anywhere. You might want to mention these two
> possibilities (I don't think they are mutually exclusive).

Sorry: we missed referring to draft-nishida-tcpm-agg-syn-ext in -04, but
we keep it in our records for future updates.

>     Review comments for draft-03:
>
>
>       §3.1 Sender behavior
>
>     A TCP sender MUST NOT include the TARR option in TCP segments to be
>     sent if the TCP receiver does not support the TARR option.
>
> This is semi-redundant, because in general a host that doesn't recognize
> any TCP option ignores it [RFC2211; §4.2.2.5]. But it is OK to say it
> anyway, I guess.

We decided to keep it (at least in -04), because it may be good to make
sure that the additional TARR option bits are not sent unnecessarily.

>      Ignore Order field
>
> Nitty point: Can 1 bit be called a field?:
> s/I field/I flag/ (throughout)?

Interesting. :)

Perhaps the answer could be "yes" (i.e., a field can have any size,
including just 1 bit), although it is true that "flag" may be more
efficient as a term as it conveys also the information of which is the
size of the field.

Anyway, the "I field" has been removed in -04.

>       §3.2 Receiver behavior
>
>
>     A receiving TCP conforming to this specification MUST process a TARR
>     option present in a received segment.
>
> You could delete this para. Given the next para says it doesn't have to
> honour a request, mandating that it just 'processes' a request is rather
> pointless.

We've been thinking for some time about this comment, and we see your
point. There may be two approaches compatible with the paragraph that
follows in the draft:

- Mandating the receiver to always process a TARR option. After that, the
receiver may decide whether it honours the request or not.

- Allowing the receiver to decide not to process a TARR option.

We currently tend to prefer the first one, where the receiver makes a
decision based on the knowledge of the ACK rate being requested. In the
second one, the receiver decides blindly, and perhaps it may be good to
allow the sender to at least be listened to.

Perhaps there may be other considerations?

>     If packet reordering occurs, a TCP receiver should send an immediate
>     duplicate ACK when an out-of-order segment arrives [RFC2581
> <https://datatracker.ietf.org/doc/html/rfc2581>], thus in
>     such cases the TCP receiver will not comply with the request.
>
> It's a bit odd to say a compliant receiver doesn't comply. Suggest
> reword to say that complying with TARR protocol still requires host to
> dupACK out-of-order packets immediately.
> BTW, I assume the rcvr can still reset its counter, and send the next
> feedback R packets after the immediate ACK.

We reworded the text.

> Also s/RFC2581/RFC5681/ (updated)

We applied this change as well.

>       §4 Option Format
>
>
> FWIW, for the semantics of the R field, I prefer OPTION 2, 'cos it's
> much more future-proofed, and doesn't require a check for the special
> value of zero.
> (You might want to make it clear that these options are only there while
> the IETF decides which one to use. They will not be two alternatives if
> the RFC is published.)

We've clarified in the draft that these are two options being considered
while we decide which one to use.

Thanks for the detailed analysis and feedback on your support for OPTION 2.

> I still don't see a rationale for the 'Ignore Order' facility. I
> understand how it would work, but you need to say what benefit it would
> offer (or otherwise remove it).
> If we didn't have Ignore Order, you could have one more bit for the
> mantissa of R (or for the integer encoding).

The Ignore Order feature has been removed in -04. So now there is one more
available bit. This provides a greater range of possible approaches to
consider/discuss.

If we just add the bit to the R field as in -04, then the maximum values
for R could be:

- R = 127 (OPTION 1)
- R = 2048 (OPTION 2, assuming the new bit is added to the mantissa "m")

Another approach could be to just keep this extra bit as a second reserved
bit and keep the R field to a size of 6 bits (if that is deemed
sufficient).

> I like the V field (flag?).

Thanks!

>
>       §5 Changing during a connection
>
>      when conditions are rather stable ... for the whole lifetime of a
>     TCP connection
>
> Isn't this an oxymoron? A flow has to start, and until it has become
> stable, it's always not stable. And a flow doesn't know that conditions
> are going to be stable until they have been for some time. The reason
> I'm saying this is, say a flow could work well with R = 20 once its
> stable. I doubt it could get up to speed very well with R=20.

We reworded the text in -04.

>       §7 Security Considerations
>
>      An attacker might be able to impersonate a legitimate sender,
>
>
> It would be worth saying that, if an attacker can impersonate a legit
> sender, it can mount all sorts of more harmful attacks, so it would be
> necessary to consider only any *new/worse* vulnerabilities that TARR
> would open up as well as those already there from hijacking.

Agreed. We reworded the text trying to capture your comment.

> In this section, it ought to point to the justification for making use
> of R optional in §3.2. (Most reviews of drafts by the Security Area
> expect them to only read the Security Considerations section, so it's
> common to point to other parts of the draft they need to read.)

Good idea. We have added a pointer to section 3.2.

Once again, many thanks for your detailed feedback!

Cheers,

Carles (on behalf of the authors)


>
> Bob