Re: [tsvwg] L4S and the RACK requirement

[Bob Briscoe <[e-mail]>]

Lloyd,

Yes, I'm v much aware of the attacks in that paper, incl. the spoofed 
DupACK attack. But I hadn't written them in as additional motivation, 
cos I'm trying to keep this draft's scope to requirements for interop.

I'll mention this in the informational appendix tho, and I guess I could 
point to it as an additional benefit under security considerations.

Thanks.


Bob

On 18/02/2019 12:36, lloyd.wood=[e-mail] wrote:
> Am I the only person who remembers Savage attacks from ack splitting 
> and packet counting?
>
> http://cseweb.ucsd.edu/~savage/papers/CCR99.pdf
>
> there's the support for the MUST NOT, at least. I's not the lack of 
> scale that is the major issue there, it's being open to abuse. ack 
> counting didn't work...
>
> Time is a tricky thing to handle with vatying scale, as delay-tolerant 
> networking has shown.
>
>
> Lloyd Wood
> [e-mail]
>
> On Wednesday, February 13, 2019, 5:00 am, Wesley Eddy 
> <[e-mail]> wrote:
>
>     In discussion among the TSVWG chairs, we are concerned about lack of
>     consensus on the requirement currently in L4S ID draft (
>     https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05
>     <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05 >)
>     regarding
>     the need for RACK-like behavior in a transport that uses the L4S
>     queue.
>
>     The statement in the draft is:
>
>         A scalable congestion control MUST detect loss by counting in
>     units
>     of time, which is scalable, and MUST NOT count in units of packets
>     (as
>     in the 3 DupACK rule of traditional TCP), which is not scalable (see
>     Appendix A.1.7 for rationale).
>
>     By saying this, it seems to rule out DCTCP and some other existing
>     code
>     that might be used with L4S (and DCTCP discussed in the draft as an
>     example scalable transport, even though it violates this rule (?)).
>     This seems like a bit of a problem for making L4S usable.  I guess
>     maybe
>     TCP Prague code fixes this, but isn't as widely available yet?
>
>     The discussion in the appendix is good at explaining what I think the
>     real goal is here, which is to enable major reduction in latency from
>     link-layer (or other underlying transport network) re-ordering
>     buffers.
>     We want that in order to meet the low latency goals, which makes
>     total
>     sense.
>
>     So, my question is whether the "MUST" is really more appropriately
>     turned into a "SHOULD" guidance?  Given that we expect reordering
>     to be
>     possible (and maybe normal) over hops supporting L4S, then the
>     congestion control algorithm SHOULD have mechanisms that allow it to
>     perform robustly.  If it doesn't, it only hurts itself, not any other
>     traffic, so there seems to be no real reason to say "MUST" (someone
>     violating it doesn't break the Internet or cause interop issues,
>     etc).
>     As I understand it, this would allow the examples like DCTCP to be
>     relevant for use with L4S as well.
>
>     Does Bob or anyone else have thoughts on this?
>

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