Re: [tsvwg] [on list again] [offlist] L4S DSCP (was: L4S drafts: Next Steps)

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

Sebastian

My understanding is that _nobody_ outside your quite small group is asking
for this extra DSCP dependency for the L4S experiment. 
Furthermore I don't see how you are about to get support and energy to
standardize/implement DSCP feedback in QUIC and RTCP (and TCP) in the near
future. 
So my conclusion is that the only objective with this lengthy discussion, as
well as the other dead cat recently placed on the table (deprecate RFC3168),
is to delay L4S as much as possible or just grind it down with repeated
discussions that go in circles. 

But now you got almost 2 years to express your opinion, it's time to move
on.

/Ingemar

> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Sebastian Moeller
> Sent: den 31 mars 2021 10:27
> To: Bob Briscoe <[e-mail]>; tsvwg IETF list <[e-mail]>
> Subject: Re: [tsvwg] [on list again] [offlist] L4S DSCP (was: L4S drafts:
Next
> Steps)
> 
> Hi Bob
> 
> since this is relevant as a document on how little research you use to
back up
> your FUD, I moved this back on list.
> 
> 
> 
> > On Mar 31, 2021, at 00:32, Bob Briscoe <[e-mail]> wrote:
> >
> > Rod, Sebastian,
> >
> > You're correct that a receiver with an open source OSs like Linux or
FreeBSD
> can access the DSCP.
> 
> 	[SM] A fact that you could have researched yourself before asking
> your broad question "is DSCP feed-back/reception actually possible". The
> fact that you did not, makes clear that your argument was not in good
faith,
> but intended to paint any DSCP proposal as untenable, independent on the
> underlaying facts.
> 
> > But the main closed source ones cannot.
> 
> 	[SM] Can not, or, Bob has still not done his hoemwork?
> Have a look at
> https://www.fekt.vut.cz/conf/EEICT/archiv/sborniky/EEICT_2012_sbornik/03
> doktorskeprojekty/10pocitacovesystemy/01-xkrkos04.pdf:
> "This paper describes the design and implementation of a driver for
network
> traffic mark- ing to ensure Quality of Service provision on Microsoft
Windows
> based terminal devices."
> It seems quite obvious that to achieve that the developer has had to
access
> the DSCP bits from within kernel space, and lo and behold, it was possible
ot
> do so from a kernel space driver.
> 
> BUT the bigger issue is, that currently no TCP Prague prototype exists for
> anything but Linux, so it is a bit disingenuous to argue about platforms
you do
> not even considered so far at all.
> So, please strike windows of your list for now.
> 
> 
> >
> > In Windows,
> 
> 	[SM] See above, it seems your assessment of what is possible in
> windows might have been driven more by your desired outcome than
> windows capabilities, sorry.
> 
> > MacOS and iOS,
> 
> 	[SM] Mmmh, given that Macos (and iOS) inherited a lot of their
> networking facilities from FreeBSD if I am not mistaken, are you sure that
the
> method that works in FreeBSD will not also work in Apple's OSs?
> 
> 
> > the sending app cannot even choose the DSCP it uses.
> 
> 	[SM] That is different from what we actually require here, for an
in-
> kernel protocol driver, it seems irrelevant whether user space can
read/set
> DSCPs no? That fact that you confuse this makes me believe you are not
> aiming at learning something here, but simply are trying to muddy the
> waters.
> 
> > The API only allows it to select from a list of application types, then
the
> stack determines which DSCP to use for this application (dependent on uPNP
> queries to the access router, or defaults otherwise).
> 
> 	[SM] Again assuming that is true, how is that relevant to an
in-kernel
> protocol?
> 
> >
> > Whatever, I've responded off-list, because the higher-order point that I
> already stated on the list is that the receiving application doesn't know
> anything about the CC that the sender is using, so it won't have any logic
to
> go looking for this DSCP.
> 
> 	[SM] Except that even unidirectional L4S CC will require AccECN
> negotiation for the link, which requires an updates protocol at the other
end,
> as no major operating system supports AccECN by default yet. This is
again,
> smoke and mirrors instead of a honest discussion. And again I see that you
> plan to force-recruit all internet users into your little experiment,
without
> first asking for their consent... that is not going to work well, given
the sorry
> state of the L4S core technologies.
> 
> Sebastian
> 
> P.S.: I really dislike the fact tat you turn any attempt of en open
discussion
> into a debate instead.
> 
> 
> 
> >
> >
> > Bob
> >
> > On 30/03/2021 14:26, Rodney W. Grimes wrote:
> >>> Bob,
> >>>
> >>> since you asked,
> >>>
> >>>> On Mar 30, 2021, at 10:21, Bob Briscoe <[e-mail]> wrote:
> >>>> [....]
> >>>>
> >>>> [BB] None of these 3 quotes about NQB are anything to do with DSCP
> feedback, nor reading the DSCP at the receiver.
> >>> In Linux look at include/net/dsfield.h
> >>> (https://protect2.fireeye.com/v1/url?k=28f09509-776bac22-28f0d592-86
> >>> 6038973a15-468a77759b2e090e&q=1&e=a4b34fc4-b4d7-4080-bca4-
> e40a6fc5d9
> >>>
> a8&u=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Fin
> >>> clude%2Fnet%2Fdsfield.h%23L16) This will give the ability inside the
> >>> kernel to get and set DSCPs for IPv4 and IPv6...
> >>> Given that TCP Prague lives inside the kernel itself that should not
be to
> hard to use.
> >>> That will not help for other OSs, but since these do not have L4S
> compatible protocols today (with TCP Prague being the closest to
> compatibility) that should not be a show stopper.
> >> Sebastian, Bob, twvwg,
> >> I am aware that FreeBSD has similiar features, and some of the
> >> userland daemons and clients can even be configured to use DSCP's.
> >>
> >>
> >>> Best Regards
> >>> 	Sebastian
> >> Regards,
> >
> > --
> >
> __________________________________________________________
> ______
> > Bob Briscoe
> https://protect2.fireeye.com/v1/url?k=023db00c-5da68927-023df097-
> 866038973a15-5a76d97f5aa5ed60&q=1&e=a4b34fc4-b4d7-4080-bca4-
> e40a6fc5d9a8&u=http%3A%2F%2Fbobbriscoe.net%2F
> >