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

["Jerome Henry (jerhenry)" <[e-mail]>]

Hi Greg,

I must say that Sebastien's argument also resonate with me (and I may be old school). The traffic types listed in the draft as NQB (interactive voice and video, gaming, machine to machine applications, then further also voice chat and DNS lookup) are all defined in various other RFCs (RFC8325 for 802.11 of course, but also RFC 4594 for most of them), with their associated recommended DSCP value. One element that they have in common is that they may individually be innocuous, but a large amount of them would obviously generate congestion. In the case of Wi-Fi, there may be several queues (usually 4 to 5 or 8 to 9), but in the end, there is only one radio, and any traffic will compete for this limited resource. Maybe what stops us (at least me) is a poor understanding of what exactly would be these NQB flows. I am debating with myself to decide if they are flows that have not been classified or categorized before, of if they are flows that are already classified, and that the NQB draft suggest should be classified differently (thus requiring an update of several other documents).
The case of 'interactive voice' or 'voice chat' is case in point. As I understand these flows (again, I may be old school), they would require a very different treatment from DNS requests. And at the same time, I am lost as to why delaying a DNS lookup (to a reasonable extend) would be damaging to the user experience or the DNS service on the client or server. Would you help me understand these NQB traffic flows more in details?
Also, I read in the thread what appears to me as a contradiction, that we are required to work with the current state of implementations where there is a default mapping of the first 3 bits of DSCP to UP (I would suggest trying other brands, I can give you quite a few names __), and that we are therefore stuck with this mapping and logic, but yet these same products should implement a new queue structure. Why would we be stuck with mapping and not with the queue structure?

Best regards,
Jerome 


On 9/10/19, 5:29 PM, "tsvwg on behalf of Greg White" <[e-mail] on behalf of [e-mail]> wrote:

    Hi Sebastian, 
    
    See below marked [GW].
    
    
    
    On 9/10/19, 1:23 PM, "Sebastian Moeller" <[e-mail]> wrote:
        Hi Greg,
        > On Sep 10, 2019, at 20:29, Greg White <[e-mail]> wrote:
        > Yes, my focus (both from the perspective of the systems that I work on, and from the perspective of where I think NQB differentiation is most valuable) is on last mile and WiFi.       
        	[SM] Except with the current very loose definition of which flows qualify for NQB marking, NQB seems to only merit AC_BE, which is already the default, so is NQB actually going to be valuable for wifi?
        > In terms of interconnection, there could be multiple ways to handle this.  My view is that the endpoint application has the best a priori knowledge of its sending behavior, so it is good to leverage that (and either validate it or not, depending on what is most appropriate for the situation).  
        	[SM] not validating the behavior but giving special powers (like the originally proposed AC-VI/AC_VO on wifi) seems like a genuinely optimistic ideas. 
        
    
    [GW] What validation is done today for applications that mark their packets as AC_VO or AC_VI?  I think that WMM is another one of those cases where the tragedy of the commons seems imminently possible, yet it largely hasn't occurred.  But, I hear you about being more clear about which flows are intended to be marked NQB. We certainly don't want to recommend something that creates the tragedy. Perhaps we've left it too ambiguous in the draft, so that needs some review.  It was not the intent that capacity-seeking flows (even L4S) mark their packets as NQB.  The target flows would be ones where the sender has a degree of confidence that it will not exceed the available capacity of the path.  Also, I think validation of NQB behavior is a very useful tool, and it is in fact mandatory to implement for DOCSIS links.  Other links (including WiFi) could implement it as well.  For example, WiFi APs or Stations could monitor queue depth or queue latency for the AC_VI (or AC_VO, whichever NQB maps to) queue and re-direct NQB traffic to AC_BE, either in a flow-aware way (probably preferred) or possibly even in a flow-blind way.  In other situations it may not be necessary (e.g. in controlled environments or on links that support FQ), or it may not be feasible.  
    
    
    
        > This would argue for networks to adopt a policy of not bleaching the NQB value on traffic arriving from interconnections, and utilizing queue protection if necessary to validate NQB behavior.   That said, there are other ways that network operators can identify NQB traffic without solely relying on endpoint marking (and DSCP preservation across interconnects).  I know some operators are investigating such techniques.      
        	[SM] if the name has any relevance, one could treat each flow as non-queue-building until there is enough evidence to change that classification (like fq_codel treats all new flows as sparse initially until their observed bahavior merits a different classification).
      
    
    [GW] Exactly.  That is one mechanism that has been discussed.  A possible downside to that approach is that once the flow has demonstrated that it is QB (by building a queue in the NQB buffer) and subsequent packets are classified to the QB buffer, it is possible that the QB buffer was empty when those packets arrived, and they end up being transmitted before the tail packets in the NQB buffer, i.e. out of order delivery.   Flow startup for traditional TCP flows (even those that support RACK) can be sensitive to out of order delivery, so if this happens frequently it could be an issue.
    
    
    
    
        Best Regards
        	Sebastian
        
        
        >  
        > -Greg
        >  
        > From: "[e-mail]" <[e-mail]>
        > Date: Monday, September 9, 2019 at 12:57 AM
        > To: Greg White <[e-mail]>
        > Cc: "[e-mail]" <[e-mail]>
        > Subject: AW: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
        >  
        > Hi Greg,
        >  
        > to me that reads as if you are mainly interested in a specified NQB DSCP for the last mile. A packet received at interconnection with a DSCP which hasn’t been agreed between sending and receiving domain will be re-written (speaking for the part of the network I work with). 
        >  
        > That’s ok, as DiffServ involves policy management anyway.
        >  
        > Regards,
        >  
        > Ruediger
        >  
        > Von: Greg White <[e-mail]> 
        > Gesendet: Freitag, 6. September 2019 19:18
        > An: Geib, Rüdiger <[e-mail]>
        > Cc: [e-mail]
        > Betreff: Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
        >  
        > Hi Ruediger,
        >  
        > Many networks can (and do) configure the DSCP to PHB mappings and policies in accordance with their own intended usage.  In particular, DOCSIS links and LTE links (likely others as well) can be configured in a manner that complies with the PHB definition.  In other cases, it may be either necessary or sufficient (or both) to support NQB traffic without fully complying with the PHB (of course this isn’t new with NQB).
        >  
        > One of the high level goals is to ensure that the benefits of differentiating NQB traffic are not lost when that traffic traverses a WiFi link (since in many of the target use cases it does).  WiFi gear will likely not support all of the aspects of the PHB definition (at least current equipment will not).  We are essentially limited to 4 queues (BK, BE, VI, VO) and their associated CSMA parameters.  An additional constraint that we’re faced with is that in many cases the mapping from DSCP to AC is essentially fixed – it is either operationally hard or impossible to change.
        >  
        > Of the WiFi APs that we’ve tested (a sample of current generation .11ac devices, covering several chipsets) 100% of them use the “default mapping” of DSCP to AC as follows.
        >  
        > DSCP
        > WMM Access Category
        > 001xxx, 010xxx
        > Background (AC_BK)
        > 000xxx, 011xxx
        > Best Effort (AC_BE)
        > 10xxxx
        > Video (AC_VI)
        > 11xxxx
        > Voice (AC_VO)
        >  
        > Living within this constraint, and trying to make the best of it, we’ve selected as a default DSCP the 0b101010 value, which would get mapped into the Video Access Category (along with CS4, AF41, AF42, AF43, CS5, VA, EF).  This would ensure that, in large part, NQB traffic is handled in a separate queue from the queue-building bulk data traffic (the vast majority of which uses AC_BE or AC_BK).
        >  
        > I would not expect that it would be important for NQB marked traffic to be differentiated in core network switches or routers, which in many cases do not provide deep (10’s to 100’s of ms) buffers.  So, in these switches NQB would likely be treated the same as Default (or whichever local use codepoint is used for best effort).
        >  
        > A characteristic of the NQB PHB as implemented in DOCSIS is that it provides low latency, low latency variation, and low loss for an NQB marked flow as long as the flow is “well behaved”.  If an NQB-marked flow is not well behaved then it experiences greater latency variation, greater loss, and potential re-ordering.   A well behaved flow is one that does not materially cause queue build-up in the network, i.e. its instantaneous rate does not materially exceed the instantaneous available bandwidth of the path.
        >  
        > In managed networks, or in cases where SLAs are provided, it seems to me that an operator should determine whether traffic that is already in a defined service class would benefit from being further differentiated based on QB vs NQB behavior (like, as you suggested using various AF marks), or whether certain existing service classes can be grouped into QB vs NQB meta-classes, depending on the technology limitations at each hop (MPLS, Ethernet, WiFi, LTE, DOCSIS, etc).  The result of this determination could require the use of non-default (i.e. non-standard) marking of NQB traffic in some cases.
        >  
        > -Greg
        >  
        >  
        >  
        > From: "[e-mail]" <[e-mail]>
        > Date: Thursday, September 5, 2019 at 2:03 AM
        > To: Greg White <[e-mail]>
        > Cc: "[e-mail]" <[e-mail]>
        > Subject: AW: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
        >  
        > 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]> on behalf of David Black <[e-mail]>
        > Date: Friday, August 30, 2019 at 9:41 AM
        > To: "[e-mail]" <[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]
        > ----------------------------------------------------------------