Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!

[<[e-mail]>]

Hi Greg,

the policy of the company I work for is: EF marked traffic received on a peering interface is remarked. DiffServ traffic destined to a retail access is subject to admission control, if that traffic is not expected to experience congestion.

The latter might change with high-speed access links. If the users and the above traffic have a hard time congesting these access links, the admission control requirement may not be strictly required.

If NQB traffic is supposed to be sent to third parties without an SLA at peering links being in place, proper selection of the DSCP matters. Without a deeper thought, a DSCP 000xx1 may be a proper choice in that case. Without an SLA being in place, the forwarding to be expected is default forwarding. If NQB is supposed to define a default-like behavior for a serious traffic share, it should be marked by a DSCP in the range 000 xxx at interconnection.

If an SLA is expected to be in place at peerings, any traffic without admission control should face a higher packet drop probability if destined to a retail access, than admission controlled traffic. If I assume the admission controlled traffic to be marked AFx1, NQB traffic in the same queue should be marked AFx2 (or AFx3). I’m open to discuss queue depths and expected traffic properties for a suitable AF class. RFC 8100 proposes to specify DSCPs only at interconnection. That may be a starting point, should SLAs on NQB at peerings be within commercial scope (that’s a non-technical issue, of course).

The choice of a DSCP for traffic which is created and terminated within a single domain doesn’t need to specified – here the PHB specification is important and the behavior of that traffic in the presence of traffic from other PHBs. I’d again opt for AFx2 or AFx3 (hoping that the NQB PHB specification allows for a useful implementation suiting AFx1 and NQB traffic in the same queue, expecting both to expect no congestion, AFx1 traffic to be admission controlled if present and NQB having features to reduce bandwidth if congestion is imminent).

I’m not sure what is expected from a backbone network supporting NQB (and other DiffServ PHBs). MPLS supports 8 traffic classes or codepoints, respectively. This coding space includes the codepoints required for ECN (codepoints, not bits).

I appreciate more standard DSCPs based on a clear and consented definition of the corresponding PHBs. Default marking, LE, EF and Network Management are good examples.

My take – sorry if I misunderstood some of your design aims, should that be the case.

Regards,

Ruediger

Von: tsvwg <[e-mail]> Im Auftrag von Greg White
Gesendet: Donnerstag, 5. September 2019 01:02
An: Black, David <[e-mail]>; [e-mail]
Betreff: Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!

Thanks David.

On your item 3, could you clarify what you mean?   RFC 8325 does not discuss a “non queue building” service class, and so I don’t see a technical inconsistency between the NQB draft and RFC8325.  There has been some discussion on the list as to whether IETF should recommend that NQB be mapped to UP_6/AC_VO or UP_5/AC_VI, but in at least one of those cases where it was suggested to change the draft, the rationale for doing so was based on an incorrect assumption that NQB-marked traffic would by definition include capacity-seeking flows (e.g. L4S).  As I stated on list, I don’t have a problem with changing it to UP_5/AC_VI if that is the consensus.  But, the reason for mapping NQB to UP_6/AC_VO is so that both RFC8325 and “default mapping” 802.11 devices map EF, VA and NQB together to the same UP/AC, and so that both types of devices map these traffic types one AC level “higher” than elastic traffic sources (e.g. AF3x).  I’d like to see a more reasoned argument as to why NQB should be grouped with AF3x traffic as opposed to EF & VA before making a change.

-Greg



From: tsvwg <[e-mail]<mailto:[e-mail]>> on behalf of David Black <[e-mail]<mailto:[e-mail]>>
Date: Friday, August 30, 2019 at 9:41 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!

In the Montreal TSVWG meeting, there was a strong sense of the room that the TSVWG WG should adopt draft-white-tsvwg-nqb as a starting point for work on an NQB PHB.   The WG call for adoption on this list has been open for over a week, since August 21, and having seen only one objection on the list to adoption of the draft (from Dave Taht), the WG chairs (Gorry, Wes and David) have concluded that the WG rough consensus is to adopt this draft.  It’s important to emphasize that the draft is adopted as a *starting point* for TSVWG work, i.e., the current draft content does not represent the rough consensus of the WG.  Significant work will be required to produce an actual PHB spec that is suitable for implementation – see the recent RFC 8622 on the LE PHB (https://datatracker.ietf.org/doc/rfc8622/) for an example of what a PHB spec looks like.

There are a few items that will need attention before the initial -00 WG version of the NQB draft is submitted – these are to avoid confusion about what the WG intends to do:

1)      The draft needs to be clear that the use of the 0x2A DSCP value as the default for this PHB is a *suggestion by the authors that is subject to change*.  Whether to use that DSCP or a different one is a WG decision; the plan is to discuss and select the default DSCP value starting (and hopefully concluding) in September.

2)      The criticisms on this list of the “queue protection” requirement in the draft are largely accurate.   The draft needs at least an Editor’s Note that this material will be revised, as while the DOCSIS mechanism is an example of how to do queue protection, it is not appropriate to require implementation of that mechanism.   A plausible plan that I have discussed with the authors is to write a set of functional/behavioral requirements for NQB “traffic protection” that can be satisfied by a “queue protection” mechanism such as the DOCSIS mechanism, or by a suitably configured FQ AQM implementation.

3)      RFC 8325 reflects the IETF consensus on how to map between Diffserv and WiFi QoS, hence the 8.3 section of the NQB draft needs to be modified to be consistent with RFC 8325.

4)      Similarly, the 8.2 section of the NQB draft needs to be modified to reflect the conclusion of discussion on this topic in Montreal.
Those 4 changes are necessary in the -00 WG version of the NQB draft.

In addition, related to item 2), my expectation (which is open to further discussion) that “traffic protection” will be a “MUST” requirement, perhaps with some well-specified exceptions (including explanations of why the exceptions are ok).   This is because “traffic protection” (e.g., “queue protection” or a suitably configured FQ AQM) appears to be necessary in general to keep queue-building traffic out of the NQB traffic aggregate, as allowing such traffic degrades the properties of the NQB PHB.

Thanks, --David (TSVWG co-chair, will be shepherd for NQB draft).
----------------------------------------------------------------
David L. Black, Senior Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
[phone] New    Mobile: [phone]
[e-mail]<mailto:[e-mail]>
----------------------------------------------------------------