Re: [tsvwg] Some comments on NQB (part 2) - DSCP policy

[Sebastian Moeller <[e-mail]>]

Hi Greg,


> On May 6, 2022, at 01:51, Greg White <[e-mail]> wrote:
> 
> See [GW].
> 
> On 5/4/22, 1:42 AM, "[e-mail]" <[e-mail]> wrote:
> 
>    Greg, Gorry
> 
>    I favour an approach on the recommended marking respecting that DiffServ is operational in some networks for more than a decade.
> 
>    I think, an approach to maintain DSCP 45 on an end-to-end basis is likely to fail without SLAs at interconnection. That's why I oppose to that. And as I said, the motivation to have this DSCP to support NQB on outdated WiFi boxes to me is not what standards should be written for. 
> 
> [GW] But, we've heard the opposite from other network operators, who feel that 45 end-to-end is simplest.  And, we've heard the view that IP precedence is deprecated and is not what standards should be written for.

	[SM] I think that is not the ideal interpretation of the data, there are some technologies that allow differential priority treatment that are limited to << 6bit worth of priority classes, e.g. IEEE 802.1Q only supports a 3bit Priority code point (PCP), MPLS also offers only 3bits in its EXP field. I would assume any operator that uses hardware that either employs MPLS or IEEE 802.1Q for differential treatment, will limit itself to 3bits worth of different PHBs...
I assume that one could map from 6bit DSCP values to 3 bit representations at the points of encapsulation and leave the DSCPs alone, but my limited understanding of networking tells me it can be advantageous to have redundant information that is easy to check, e.g. are the outer and inner priority labels in sync is easier if one keeps say a set of 3bits in the DSCP field matching to the 3bit field in the outer layer. I naively would also assume that this would allow to delegate all DSCP re-mapping/bleaching/... decisions to the edge nodes while internal nodes could simply encapsulae by copying the designeated 3bits from the already sanitized DSCP field to the outer later's priority field.
	I would not see this as a use of IP precedence... but rather taking all the freedom diffserv allows, while leaving a sliver of a chance of also allowing end to end signaling via the other set of bits not used by an ISP.


>  Also, similar to what I indicated in my response to David, I don't know what you mean by "outdated WiFi boxes".  We're talking about nearly every WiFi device on the planet and nearly all of the ones that are available for purchase today.  

	[SM] Yes, but that is a problem for the safety arguments in the NQB draft, since in reality nothing in WiFi is going to change as a result of the NQB draft. So with DSCP45 NQB will do exactly what it argues against it will use a priority based approach without any rate limits or other behavioral control. At that point it is as good/bad as using EF today is, so why should any EF user switch to NQB? You seem to argue that you want to minimize the cost of switching from say EF to NQB, but without any real advantage of doing so, any cost is going to be too high.


> That's a deployed base that is probably two orders of magnitude larger than the DT network (and growing).  If we had to pick one or the other, I would go with interoperation with Wi-Fi rather than interoperation with DT.   

	[SM] But that is not what you seem to be proposing. Interoperation with existing WiFi would be to be a good netizen and NOT use the higher priority ACs without any anti-abuse mechanism in place (e.g. per-flow/per-class rate-limiting), but using DSCP45 on existing APs/stations is doing exactly that, exploiting WMM's unfortunate default DSCP to AC mappings. The argument that mistake has been made multiple times in the past IMHO does not justify repeating that same mistake over again.


> 
> [GW] I think we all need to agree that there is a lot of history with different established practices in place for DSCP usage, and we need to be willing to be flexible. No one is arguing from a position of architectural purity here (well, perhaps Gorry is to some degree), so I think it is a matter of coming up with recommendations that give us the best chance of having the widest support with the least effort and confusion.   

	[SM] Seems similar to the classic safety versus convenience argument... not convinced the WG/IETF should opt for convenience here, sorry. Especially since it is easy to make the whole thing opt-in with existing standardized and deployed methods allowing to assure that if NQB gets used over a WiFi network that operator delpoying it had a decent chance of making sure all of NQB's safety considerations and recommendations were followed.


Regards
	Sebastian


> 
> 
> 
> 
> 
> 
> 
>    Which scenarios do apply?
>    a) Access provider supports NQB at Access Gateway: 
>        a1) fixed & mobile networks: the Access Gateway is likely a QoS policy point, (Multi-Field) classification and re-marking are operational.
>        a2) I'm not sure about broadband network Access Gateway policy functions.. could these support NQB 
>               without being QoS policy point? If yes, is that prevalent?     -I try to be careful, no blaming intended-
>    b) Access provider supports QoS at Access Gateway, but doesn't want to support NQB: then the Gateway is likely a policy point and re-marking is to be expected (in a negative sense could well be DSCP 000 000).
>    c) Access provider doesn't support QoS at Access Gateway, but wants at least outdated WiFi gear to benefit from NQB. Then DSCP 45 may make sense.
>    d) Access provider really doesn't care about QoS at any location. Then DSCP 45 may make sense.
> 
>    In cases b), c) and d), the Access Gateway is forwarding NQB like default (and NQB inherits default performance). Than all the effort is at best only about the WiFi AP. To me that's not justifying an end-to-end marking scheme likely conflicting with providers operating a1). As Greg has mentioned, the home network gateway may deal with the issue (and that should become part of the draft).
> 
>    Regards, Ruediger
> 
>    <snip>
> 
>