Re: [tsvwg] Comments on L4S drafts

[Ingemar Johansson S <[e-mail]>]

Hi Jake + all

Please see inline

/Ingemar


> -----Original Message-----
> From: Holland, Jake <[e-mail]>
> Sent: den 14 juni 2019 20:28
> To: Ingemar Johansson S <[e-mail]>; Bob Briscoe
> <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [tsvwg] Comments on L4S drafts
> 
> Hi Ingemar,
> (bcc: ecn-sane, to keep them apprised on the discussion).
> 
> Thanks for chiming in on this.  A few comments inline:
> 
> On 2019-06-08, 12:46, "Ingemar Johansson S"
> <[e-mail]> wrote:
> > Up until now it has been quite a challenge to make ECN happen, I
> > believe that part of the reason has been that ECN is not judged to
> > give a large enough gain.
> 
> Could you elaborate on this point?
> 
> I haven't been sure how to think about the claims in the l4s drafts that operators
> will deploy it rapidly because of performance.
> 
> Based on past analyses (e.g. the classic ECN rollout case study in RFC
> 8170 [1]), I thought network operators had a very "safety first" outlook on these
> things, and that rapid deployment for performance benefits seemed like wishful
> thinking.
> 
> But I'd be interested to know more about why that view might be mistaken.
[IJ] I believe that it is easy to end up in a lot of speculation. I don't believe that the safety first thinking makes much sense, yes it has sometimes been used as a counter argument. Part of the problem is perhaps that ECN was introduced into 3GPP for VoLTE. And then when ECN is proposed for its original use in 3GPP (=Generic transport protocol agnostic feature) it gets hard to make it stick. With that said, ECN is supported in both LTE and NR standards (TS36.300, TS38.300). It is however rarely deployed. One could speculate around the reasons, I believe that one big reason can be that traditional ECN does not show a large enough delta improvement to make it worthwhile. I can of course be wrong , I don't possess a crystal ball 😊


> 
> > Besides this, L4S has the nice
> > property that it has potential to allow for faster rate increase when
> > link capacity increases.
> 
> I think section 3.4 of RFC 8257 says the rate increase would be the
> same:
> https://tools.ietf.org/html/rfc8257#section-3.4
>    A DCTCP sender grows its congestion window in the same way as
>    conventional TCP.
> 
> I guess this is referring to the paced chirping for rapid growth idea presented last
> time?
> https://datatracker.ietf.org/meeting/104/materials/slides-104-iccrg-
> implementing-the-prague-requirements-in-tcp-for-l4s-01#page=20
> 
> I'm a little unclear on how safe this can be made, but I agree it seems useful if it
> can work well.
[IJ] Yes DCTCP use traditional additive increase. I have personally done a few experiments in this area, nothing that is good enough to show as the experiments were very limited. One possible idea can be to make the bandwidth probing in BBR(v2) more aggressive. And there may also be possibilities with Paced chirping too

> 
> Do you think the L4S benefits will still be sufficient if this point about faster
> growth doesn't hold up (and/or could be replicated regardless of L4S), or is it
> critical to providing sufficient benefit in 3GPP?
[IJ] No, I don't believe that it is critical, it is definitely a welcome bonus if it is possible.

> 
> (Note: I'm not taking a position on this point, just asking about how much this
> point matters to the 3GPP support, as you see it.)
> 
> > I see many applications that can benefit greatly from L4S, besides
> > AR/VR, there is also an increased interest in the deployment of remote
> > control capabilities for vehicles such as cars, trucks and drones, all
> > of which require low latency video streaming.
> 
> Remote control over the internet instead of a direct radio link is an interesting
> use case.  Do you happen to know the research about delay parameters that
> make the difference between viable or not viable for RC?

> 
> This touches on one of the reasons I've been skeptical that the benefits will drive
> a rapid deployment--in most of the use cases I've come up with, it seems like
> reducing delay from ~200-500ms down to ~15-30ms (as seems achievable even
> for single queue with classic AQM) would give almost all the same benefits as
> reducing from ~15-30ms down to 1ms.
[IJ] The thing I like with L4S is that it reduces standing queues down to almost zero, which gives a very fast reaction time when throughput drops. In addition L4S gives frequent signals of congestion, which makes it easier for a congestion control algorithm to know when it is close to the congestion knee.

> 
> Of course, there's a difference in that last 14-29ms, but for instance for gaming
> reaction time it's well under the thresholds that make a difference for humans
> (the low end of which is at 45ms, according to [2]), so it seems like the value in
> that market would be captured by classic ECN, and therefore since classic ECN
> deployment hasn't caught on yet, I had to conclude that the performance gains
> to enable that market aren't sufficient to drive wide adoption.
> 
> So I'm curious to know more about the use cases that get over that hump from
> an operator's point of view, and what you've seen that leads you to believe the
> additional gains of L4S from will make the difference on those use cases where
> classic ECN wasn't adequate.
[IJ] I guess for this part, there need to be more input from operators

> 
> > My bottomline is that I believe L4S provides with a clear benefit that
> > is large enough to be more widely accepted in 3GPP. SCE is as I see it
> > more like something that is just a minor enhancement to ECN and is therefore
> much
> > harder to sell in to 3GPP.
> 
> Thanks, this is good to know.
> 
> To me one benefit of SCE over L4S is that it seems safer to avoid relying on an
> ambiguous signal (namely a CE that we don't know which kind of AQM set it) in a
> control system, while still providing high- fidelity info about the network device
> congestion, where available.
> 
> I agree that it's not completely clear exactly how the congestion controllers can
> capitalize on that info, but to me it still seems worth considering.
> 
> So although I'll support L4S if it really covers all the safety issues and performs
> better, I'd be more comfortable with the signaling if there's a way to make SCE
> do the same job, especially if the endpoint implementation is simpler to get
> robustly deployed.
> 
> So really, I'm hoping for a bakeoff to decide this, because one of my concerns is
> that L4S still doesn't have an implementation that does all the things the drafts
> say are needed for safety on the internet, even though the initial proof of
> concept demoing the performance gains was presented 7 years ago.  It's good
> that it's getting closer, but the long implementation cycle (which still doesn't
> have all the features required by the drafts) is a concern for me from the
> "running code" point of view.
> 
> On this point of view, it's possible that a parallel track might get further faster,
> especially if it doesn't need the same special cases to be safe, which is part of
> why I've been tentatively supportive.
> 
> And although I can see how the queue classification is a major issue that could
> make the difference, especially with the very promising dualq proposal, it also
> seems true that in addition to CPEs, there are promising avenues for carrier-
> scale FQ systems (e.g [3], [4]) that could solve that.  It makes me think that even
> if SCE only gets low-latency with FQ and otherwise causes no harm, it's not clear
> it'll be a slower path to ubiquitous deployment (and by the way, this approach
> also would handle the opt-in access control problem).
> 
> Of course, this will presumably collapse to one answer at some point, but I'll
> argue that it's worthwhile to give a good look to the alternate proposal...
> 
> Anyway, thanks for the comments, I think it's good to see more discussion on
> this.
> 
> Best regards,
> Jake
> 
> [1] Appendix A.1 RFC 8170 https://tools.ietf.org/html/rfc8170#appendix-A.1
> [2] https://protect2.fireeye.com/url?k=997ee527-c5f43093-997ea5bc-
> 866a015dd3d5-
> 1d25c70963170b1e&q=1&u=https%3A%2F%2Fojs.bibsys.no%2Findex.php%2FNI
> K%2Farticle%2Fview%2F9 says 45ms [3] http://ppv.elte.hu/ [4]
> https://ieeexplore.ieee.org/document/8419697
>