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

[Jon Crowcroft <[e-mail]>]

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

I wasn't sure about the ignore order thing either....
> 
> 
> 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/
>