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

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 21 Mar 2022 19:36:14 +0100

Hi again, Bob,

Thanks as well for this third message of yours.

Please find below my inline responses:

> Carles,
>
> I've written a few of my review comments about
> draft-gomez-tcpm-ack-rate-request-02 in the two recent threads about
> this draft. Here are the remainder...

Thank you very much for your comprehensive feedback!

> I think it would be useful at this stage to describe the pros and cons
> of one or two alternative encoding schemes, rather than just assert one
> scheme.

In -03 they are briefly described (as "OPTION 1" and "OPTION 2").

The first encoding is simple, but it is limited to a maximum value of 63.

The second encoding is more complex, but it covers a greater range of
values, with a maximum value of 1024 and lower granularity for high
values.

> I don't believe the message can have the meaning "The receiver MUST
> modify its ACK rate to..." A TARR message can only be advisory (a
> request not an order), because the receiver might not have the resources
> to send ACKs as often as requested. Also, it would be an obvious attack
> (e.g. everyone gangs up on a server by disabling delayed ACKs and
> uploading loads of data). If the receiver does not comply it doesn't
> need to explicitly refuse the request, it just sends as frequently as it
> can in response.

Agreed. In -03, this was modified to a SHOULD. We also added reasons why
it is not a MUST, as per your comment above.

> ==Capability negotiation==
> * The description of the handshake isn't complete. It only describes the
> SYN, not the SYN-ACK.

Agreed. We have described the SYN-ACK now.

> * It occurs to me that initiating on the SYN isn't really necessary,
> because DelACKs do not start until after the SYN-ACK. Given lack of
> space on the SYN, how about saying the TARR option MUST NOT be on a SYN.
> If the server supports TARR, it includes the TARR option on the SYN-ACK,
> and it doesn't send any further TARR until it has seen a TARR option
> from the client.
> if the client supports TARR, it SHOULD respond with the TARR option on
> the first ACK and the first data packet (if there is one).
>
> If you don't like this, second-best would certainly be to aggregate with
> other options on the SYN (as in Yoshi's presentation), given option
> space on the SYN is so scarce.

Thanks for the proposal. It makes sense. Perhaps it would be good to know
what others may think about it, and we plan to ask in the tcpm meeting
about it.

> The scheme should define the semantics of a TARR message from sender to
> receiver. Does it mean "for this packet only" or "from this packet
> onwards until another TARR packet"?

It means the latter. We have clarified it in section 3.

> Also, does a retransmission have to
> have the same TARR option on it as the original (I would say not)?

Agreed, our answer is "no". Added in section 3.

> I notice you've stipulated that the TARR option is in the TCP header of
> a data packet. Is there any reason to preclude one on a pure ACK?
> Admttedly TARR on an ACK doesn't seem so useful, but if you do preclude
> it, code has to exist to specifically ignore TARR on a pure ACK, which
> seems to add unnecessary complexity.

Agreed. We removed the specific mention of "data" in "data packet".

> I don't think the units should be "per full-sized data segment". They
> should just be "per data segment".

We applied this update.

> Security Considerations:
> I'm not sure there's much point strongly recommending TLS in this doc,
> then saying it doesn't protect the TCP headers.

Actually, we aimed to provide a general picture for a reader, and
precisely then explain that TLS won't help protect the TCP headers.

> As well as IPsec, you
> could mention the TCP Authentication Option.

Agreed. Added in -03.

> I think you are entitled to
> say that it is still relatively hard for an off-path attacker to hijack
> an unprotected TCP session. It would be worth recommending that RFC5961
> is used to check packet validity. And say that TARR option MUST be
> ignored on a packet that is deemed invalid.

Agreed. Added in -03 as well.

> I've briefly collected together points I've made in other threads here:
> * N is redundant. There's no need to request immediate ACKs for N
> packets, when the sender can send an updated TARR request after N packets.
> * Rather than make R=0 have the special meaning of ACK every packet,
> ack-ratio = 1 already means that. So just define ack-ratio = R+1
> * Lower precision would be sufficient for higher ack ratios.
> * With a 6-bit field, could encode R as 4-bit mantissa plus 2-bit
> exponent, in base 4 or base 16.
>  Â  o Then you'd have 2 bits spare, perhaps one for the "ignore
> reordering" flag (I) and one reserved for future use (always nice).
> * With the "ignore reordering" flag (I), I think the semantics of loss
> detection would need to be redefined.

I believe all the points above have been covered, pending the Ignore Order
discussion mentioned.

> HTH

It does!!

Once again, many thanks,

Carles

> Bob

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 22 Mar 2022 18:27:01 +0000

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.

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"

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

    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.

     Ignore Order field

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

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

    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.

Also s/RFC2581/RFC5681/ (updated)

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

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).
I like the V field (flag?).

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

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

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

Bob

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 23 Mar 2022 09:18:14 +0000

thanks very much for this detailed review/feedback....

I wasn't sure about the ignore order thing either....
> mention
> below), and it's good to give the WG two options for how best to proceed 
> on
> the encoding.
> 
> 
> 
> 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"
> 
> 
> 
> 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).
> 
> 
> 
>    duplicate ACK when an out-of-order segment arrives [RFC2581  
> <https://datatracker.ietf.org/doc/html/rfc2581>], thus in
> 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.
> 
> 
> 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.)
> 
> 
> 
> 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).
> 
> 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.
> 
> 
> 
> necessary to consider only any *new/worse* vulnerabilities that TARR would
> open up as well as those already there from hijacking.
> 
> 
> 
> 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.)
> 
> 
> 
> Bob
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 23 Mar 2022 12:15:24 +0100

> thanks very much for this detailed review/feedback....

+100.

We plan to update the draft very soon, aiming to address your comments, Bob.

> I wasn't sure about the ignore order thing either....

Same here... :)

This feature was once suggested in a WG meeting, but it appears that
perhaps it is not so useful, so we might consider removing it in the next
draft update.

I plan to ask about this later today in the WG meeting.

Cheers,

Carles

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 23 Mar 2022 04:42:55 -0700

I am not very sure, but I guess if we use TCP RACK and ignore reordering,
it will mean we rely on only timer based retransmission scheme completely.
There might be some situations where it works more efficiently than using
dup acks.
--
Yoshi

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Ian Swett <[email-masked]>
Date: Wed, 23 Mar 2022 12:11:06 -0400

The QUIC Ack Frequency draft (draft-ietf-quic-ack-frequency
<https://datatracker.ietf.org/doc/draft-ietf-quic-ack-frequency/>) has an
ignore order feature, but QUIC also has the ability to deliver data in any
order.  There are some use cases that make sense for QUIC.

For TCP, the use case would be networks where it's known reordering is
prevalent.  Today there are a lot of devices on the path that try to keep
TCP segments in order, but these add complexity to the network. If no one
has networks with more prevalent reordering or plans to build them, then
maybe there's not a compelling use case for ignore order here?

Ian

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 30 Mar 2022 13:05:25 +0200

Hi Bob,

Many thanks for your review of -03 !

> mention below), and it's good to give the WG two options for how best to

Many thanks!

> If there is little benefit, we could remove the I flag. "Do one thing,

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

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

> any TCP option ignores it [RFC2211; §4.2.2.5]. But it is OK to say it

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.

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

> honour a request, mandating that it just 'processes' a request is rather

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?

> feedback R packets after the immediate ACK.

We reworded the text.

> Also s/RFC2581/RFC5681/ (updated)

We applied this change as well.

> the IETF decides which one to use. They will not be two alternatives if

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.

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

> stable. I doubt it could get up to speed very well with R=20.

We reworded the text in -04.

> would open up as well as those already there from hijacking.

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

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