Re: [tsvwg] L4S vs SCE

[Steven Blake <[e-mail]>]

On Wed, 2019-11-20 at 21:22 +0800, Roland Bless wrote:
> Hi,
> 
> On 20.11.19 at 13:40 De Schepper, Koen (Nokia - BE/Antwerp) wrote:
> > I agree with Ingemar. Related to the chances for failing: as
> > history learned us, the only real world chance for failing would be
> > that the technology would not be taken up in deployments. This
> > whole codepoint conflict is mainly damaging/creating this
> > deployment 'issue'. The other so called show stoppers are less of
> > an issue for most people that worked on CCs. Blowing 'issues' (not
> > yet implemented/integrated/tested code and bugs) out of proportion
> > is not the way to go forward here.
> >  
> > To give an example:
> > As mentioned in another thread already: the L4S codepoint, where
> > there's a new queue and new CCs, creates a clean-slate opportunity.
> > This is an opportunity to select new desired behavior.
> Yes, but as I also expressed my concerns w.r.t. the L4S codepoint
> earlier, at the cost of binding this to a quite fixed set of L4S 
> behaviors and "burning" the last ECT codepoint. Personally, I like
> concepts with a little bit more potential to be useful for future 
> development (evolvability) of congestion controls, e.g., BBRv2 and
> LoLa could also benefit from an SCE-like marking...
> Therefore, a compromise could be to define ECT(1) with "some
> congestion experienced" semantics that could also be used for L4S.
> In order to further disambiguate and use the particular L4S semantics
> of Dual Queue AQM etc. one could use an additional DSCP as
> L4S classifier: I currently don't see the need to follow the argument
> of providing L4S orthogonal to DiffServ (and for me L4S is specifying
> a PHB).
> In case L4S doesn't take off one can at least use the SCE semantics
> and reassign the DSCP (or in case of success make it later orthogonal
> to DiffServ). Due to the newly opened pool of DSCPs one may have a
> chance of finding a DSCP that has a high probability of
> getting through from end-to-end.


YES!! Dual-Q is defining PHBs. Packets are steered to PHBs via DSCP
marking. Experimental DSCPs are available. Parallel experiments can be
isolated by DSCP. Let's not break this simple architecture for an
experiment.



Regards,

// Steve