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

[Bob Briscoe <[e-mail]>]

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

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.

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.

==Capability negotiation==
* The description of the handshake isn't complete. It only describes the 
SYN, not the SYN-ACK.
* 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.


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"? Also, does a retransmission have to 
have the same TARR option on it as the original (I would say not)?

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.

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

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. As well as IPsec, you 
could mention the TCP Authentication Option. 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.


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.

HTH



Bob

On 26/02/2021 13:22, Carles Gomez Montenegro wrote:
> Dear TCPM WG,
>
> As it can be seen below, we recently updated the TCP ACK Rate Request
> (TARR) option draft.
>
> Main changes:
>
> - There are now two formats: a shorter one to announce support of the TARR
> option, and a larger one which conveys the value of R, among others.
> The two formats can be distinguished by the "Length" field value (while
> keeping the same "Kind" value).
>
> - In the second format, the Ignore Order field is now reduced to just 1
> bit, and "R" is reduced to 7 bits. Therefore, the total format size
> decreases from 7 bytes to 6 bytes.
>
> - We added content in the security considerations section.
>
> Also, after submission of the draft, we contacted IANA to request
> allocation of ExID 0x00AC (aiming to somehow allude to "ACK") for the
> option, as it is an RFC 6994-style experimental TCP option. The ExID value
> has already been allocated:
> https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-exids
>
> Comments are welcome!
>
> Thanks,
>
> Carles (on behalf of the authors)
>
>
> ---------------------------- Original Message ----------------------------
> Subject: New Version Notification for
> draft-gomez-tcpm-ack-rate-request-02.txt
> From:    [e-mail]
> Date:    Fri, February 19, 2021 3:30 pm
> To:      "Carles Gomez" <[e-mail]>
>           "Jon Crowcroft" <[e-mail]>
> --------------------------------------------------------------------------
>
>
> A new version of I-D, draft-gomez-tcpm-ack-rate-request-02.txt
> has been successfully submitted by Carles Gomez and posted to the
> IETF repository.
>
> Name:		draft-gomez-tcpm-ack-rate-request
> Revision:	02
> Title:		TCP ACK Rate Request Option
> Document date:	2021-02-19
> Group:		Individual Submission
> Pages:		8
> URL:
> https://www.ietf.org/archive/id/draft-gomez-tcpm-ack-rate-request-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-gomez-tcpm-ack-rate-request/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-gomez-tcpm-ack-rate-request
> Htmlized:
> https://tools.ietf.org/html/draft-gomez-tcpm-ack-rate-request-02
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-gomez-tcpm-ack-rate-request-02
>
> Abstract:
>     TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism
>     that allows reducing protocol overhead in many scenarios.  However,
>     Delayed ACKs may also contribute to suboptimal performance.  When a
>     relatively large congestion window (cwnd) can be used, less frequent
>     ACKs may be desirable.  On the other hand, in relatively small cwnd
>     scenarios, eliciting an immediate ACK may avoid unnecessary delays
>     that may be incurred by the Delayed ACKs mechanism.  This document
>     specifies the TCP ACK Rate Request (TARR) option.  This option allows
>     a sender to indicate the ACK rate to be used by a receiver, and it
>     also allows to request immediate ACKs from a receiver.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/