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

[[e-mail]]

Greg,

I can't tell what the exact QoS deployments of operators competing in Germany are, but I know that at least the larger operators negotiate QoS for all types of interconnection. Some DiffServ related home gateway interface specifications are public, as there is no home gateway operator lock in in Germany (meaning DSCP marking policies helpful for e.g. Wifi gear could be specified there too, and home gateway vendors can support it - I agree, that this "no operator home gateway lock in" is likely specific for Germany an few other countries).

I know that Bob worked on BT's DiffServ QoS a long time ago, when he was working with BT. I'd expect Orange to run some QoS differentiation too, but don't know details (M. Boucadair is active on BGP related QoS signaling in IETF, one may ask him). I also don't know details about US and Asian deployments, or whether these exist at all. I'd recommend not to ignore these deployments, if you'd like to increase benefit for consumers (noting that no one knows all these daggering QoS deployments). 

I'd think the best way of reaching the widest support is looking for consent and part of that is respecting existing operational environments to largest extent possible.

Your message doesn't state that operators you've been talking with support DiffServ. Could you clarify that? They don't seem to be able or willing to re-mark DSCPs at access policy points (which are the QoS policy management points in fixed and mobile networks). You didn't answer my question related to broadband cable network Access Policy points yet, I'd appreciate you doing that.
To the extent I can tell, no IP packet viable for some differentiated service passes a mobile edge or fixed network access policy point without being Multi-Field classified. I don't think our vendors sold us equipment having QoS features just and only built for DT.

You write: "And, we've heard the view that IP precedence is deprecated and is not what standards should be written for." - Could you be more precise, so that I understand, what you mean by that? Dou you want to say that classification based on DSCP ranges is not conforming to DiffServ standards? If your answer is yes, please point to a suitable reference. 

I'm not sure, whether https://datatracker.ietf.org/doc/html/rfc8837 is supported across carrier backbones. If you or anyone else can shed some light on that, I'd appreciate. It's another example for a recently specified DSCP scheme not requiring any particular operator support apart from transparent transport of DSCPs.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail]> 
Gesendet: Freitag, 6. Mai 2022 01:52
An: Geib, Rüdiger <[e-mail]>; [e-mail]
Cc: [e-mail]
Betreff: Re: [tsvwg] Some comments on NQB (part 2) - DSCP policy

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.  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.  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.   

[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.   







    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>