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

[Bob Briscoe <[e-mail]>]

Sebastian,

Unfortunately, yet more correction is needed, just to clear my name of 
your accusations, which were off topic, which is why I took this 
conversation off list. But you've insisted it's onlist, so (sigh) pls 
see inline, tagged [BB]...

On 31/03/2021 09:26, Sebastian Moeller wrote:
> 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.

[BB] Nothing in my emails was about whether one /can/ access the DSCP.
When you replied with "Since you asked," I hadn't asked.
I had said "[BB] None of these 3 quotes about NQB are anything to do 
with DSCP feedback, nor reading the DSCP at the receiver."

But you went on to tell me anyway, that one can access the DSCP in Linux.

Like most people on the list I already knew that you can (in FOSS OSs). 
Indeed, you've been able to access the DSCP in Linux since 1998 when 
Diffserv was first defined, and I'm sure FBSD was siimilar.

I took this off list 'cos it wasn't relevant.

What I said was nothing like it is not /possible/ to alter standards 
track protocols to feed back the DSCP. The point was that:
a) no-one is going to be motivated to alter all the standards track 
transport protocol specifications to feed back the DSCP just so that 
your DSCP scheme will work
b) it would give L4S deployment an additional dependency on L4S logic at 
the receiver, when that is currently not the case.


Please don't be so quick to blame me, when I think it was just you 
reading my email too fast.
In general, I think many on this list would appreciate you reading more, 
and writing less.


Bob

PS. Rod, your info about FBSD was understandable, given Sebastian had 
made it look like it would be relevant.


>
>> 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/03doktorskeprojekty/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://elixir.bootlin.com/linux/latest/source/include/net/dsfield.h#L16)
>>>> 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                               http://bobbriscoe.net/
>>

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