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

[Bob Briscoe <[e-mail]>]

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

On 21/03/2022 18:36, Carles Gomez Montenegro wrote:
> 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
>

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