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

[Bob Briscoe <[e-mail]>]

Carles,

An alternative encoding idea would be a 2-bit field (unspecified where 
at the point, but 2 bits might be small enough to extend some other 
related option).

00 : hold
01: increase
10: set to 1
11: decrease

(If you want, you can think of this as a 2-bit signed integer in 2s 
complement arithmetic, with 10 as a special case ;)

The increase/decrease might either be defined as +/- 1 or 
multiply/divide by 2 (i.e. bit-shift +/- 1).

This would be rather delicate, being sensitive to loss and reordering. 
But it has the advantage of compactness.
It does not support the ignore reordering feature in recent drafts, but 
I'm not sure how necessary that is.


Bob

On 14/03/2021 23:20, Bob Briscoe wrote:
> 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/