Re: [tsvwg] plan for L4S issue #29

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

Hi Ruediger
Please see inline

/Ingemar

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: den 30 september 2020 11:16
> To: Ingemar Johansson S <[e-mail]>
> Cc: [e-mail]
> Subject: AW: Re: [tsvwg] plan for L4S issue #29
> 
> Hi Ingemar,
> 
> One observation, I think it is mainly L4S which is discussed very
> intensively by this list. My perception is:
> 
> - some discuss L4S and available features and try to improve it
> - some discuss L4S and require features not available yet (but so far
> provide little input in improving L4S)
> - and some discuss their expectations on transport protocols using ECN
> codepoints and try to help improving the TSVWG specifications discussed
> and/or deployed today.
> 
> To me, controlled, careful and reasonable experimentation with a following
> evaluation looks like a useful approach. That might initially be more of a
> "test user" thing, not code released for the wild. A set of different
> players may be useful too (e.g., I don't know whether an access router
> vendor offers an L4S implementation, and availability of applications or
> content expected to benefit from L4S transport certainly would be very
> helpful).

[IJ] As I see it, this is how it will play out initially, we are talking
about gradual rollout of L4S enabled nodes. It won't happen overnight,
especially when we discuss 3GPP equipment. Also we have the chicken and egg
problem to overcome, application developers must build in L4S support in the
applications and network vendors and operators need to deploy and enable
L4S. This need to happen in parallel and requires a bit of education and
promotion. 
But somewhere one need to take the step and say , "we should go for this",
things will never happen if we decide to wait a few more years until we know
better. As I see things, the only way to learn in this context is by doing.
It will take a few years, but that is OK too as it will give time to
upgrade/replace devices that may not work with L4S.  

> 
> Regards,
> 
> Ruediger
> 
> -----Ursprüngliche Nachricht-----
> Von: tsvwg <[e-mail]> Im Auftrag von Ingemar Johansson S
> Gesendet: Mittwoch, 30. September 2020 10:35
> An: [e-mail]
> Cc: [e-mail]; Ingemar Johansson S
> <[e-mail]>
> Betreff: Re: [tsvwg] plan for L4S issue #29
> 
> Hi
> 
> I think that issue #29 can be closed and moved to ICCRG.
> 
> My impression, based on earlier discussions on this mailing list is that
> possible RFC3168 bottlenecks such as home gateways can be updated to
> support
> L4S alongside with other necessary updates that are done to block e.g.
> security threats.
> 
> In addition, this discussion is a non-issue for 4G/5G access as RFC3168
ECN
> is AFAIK not at all implemented or publicly available in 4G/5G.
> 
> Also think that it is reasonable to go for algorithms that can do
detection
> rather than fall back. This can be documented/referenced to in the L4S ops
> draft started by Greg White, that is published later on.
> 
> The important thing is that I don’t see any reasons why L4S issue #29
should
> block WGLC for the L4S drafts.
> 
> What worries me deeply is that this activity tend to get stalled in
endless
> discussions and deep analysis what people may or may not have said and
> that
> sucks energy from the group.
> Also I notice that SCE is still brought up even though it had very limited
> support in the group while L4S has quite large support. Why do we still
> discuss SCE here ?. We really need to move forward, now!.
> Therefore I would encourage that the persons who are against L4S instead
> spend their time and energy on work to make the L4S drafts advance
> through
> WGLC and contribute to the L4S ops draft.
> 
> Regards
> /Ingemar
> ================================
> Ingemar Johansson  M.Sc.
> Master Researcher
> 
> Ericsson Research
> RESEARCHER
> GFTL ER NAP NCM Netw Proto & E2E Perf
> Labratoriegränd 11
> 977 53, Luleå, Sweden
> Phone [phone]
> SMS/MMS [phone]
> [e-mail]
> www.ericsson.com
> 
>  Talk about a dream, try to make it real
>                   Bruce Springsteen
> =================================