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

[Greg White <[e-mail]>]

See [GW2]

On 9/11/19, 5:44 AM, "Sebastian Moeller" <[e-mail]> wrote:
    > [GW] What validation is done today for applications that mark their packets as AC_VO or AC_VI?    
    	[SM] As far as I know almost no validation, but do to the traditional DSCP bleaching over the internet and the reluctance of most applications to twiddle with DSCP bits, most traffic will be in the AC_BE, but admittedly rather by chance than by design. In addition the IEEE's default DSCP to AC mappings are quite conservative (like mapping EF to AC_VI not AC_VO) making high volume traffic in the higher ACs relatively unlikely with such DSCPs that might survive internet passage. But with NQB's desirable approach to be transmitted e2e, that is going to change.
 

[GW2] According to one recent study, roughly 50% of ASes bleach DSCP, so yes a decent percentage of traffic that traverses an interconnect before reaching the WiFi link will end up in AC_BE, but other traffic will not.  None of the traffic generated by local devices on the WiFi network gets bleached.   All OSes that I'm aware of provide open APIs for applications to select their desired DSCP.  In the case of Windows, applications (unless they are privileged) are limited to selecting from a set of 4 DSCPs that map to the 4 WMM Access Categories.  Applications do use these, without validation or policing (at least in residential environments, in enterprise WiFi systems it may be a different story).  In my experience approximately 10% of packets are sent as non-AC_BE (~4% BK, ~1% VI, ~5% VO) in current WiFi networks, though I'm sure there is wide variability depending on the applications in use.  Moreover, I would find it hard to believe that either RFC8325 or the default mappings were defined under the assumption that ALL traffic arriving at a WiFi AP on its WAN port would be guaranteed to be default DSCP.  Given this, I see no justifiable reason for NQB to map to AC_BE in traditional WiFi gear.  The traffic expected to be labeled NQB is sparse unresponsive traffic or smooth low-data rate flows, which is compatible with AC_VO.   We've proposed a DSCP that, conservatively, aligns with the mapping of CS4, AF41, AF42, AF43, CS5, VA and EF to AC_VI in default mapping equipment, and aligns with the mapping of VA, EF and CS6 to AC_VO in RFC8325 equipment.  As I said previously, I don't have a strong view on VI vs VO for RFC8325, but since RFC8325 (unfortunately) maps some capacity-seeking bulk data traffic to AC_VI, I believe that it is more appropriate that NQB sparse traffic be VO in those systems.  The draft has a recommendation that all devices supporting NQB implement a queue protection mechanism for NQB traffic, which for RFC8325 devices supplements all of the detailed recommendations* on protecting QoS in section 8 of RFC8325, which still remain intact.  So, my view is that AC_VI for NQB in RFC8325 equipment is defensible.  

*Note that RFC8325 makes all of these protections RECOMMENDED, not REQUIRED, in alignment with the NQB draft's handling of queue protection.

[GW2]  A point to be repeated here is that this proposed mapping of DSCP to WMM was not driven by the goal of giving priority (either bandwidth priority or latency priority) to NQB traffic, but rather to have it queued separately from QB traffic.  In existing WiFi gear, that isn't possible without using different ACs and we have to work within the limitations of the equipment.   Perhaps the NQB draft should make this more clear.  In other words, the draft should clearly require that WiFi APs that claim compliance with the NQB PHB definition have a separate queue for NQB traffic.  If that separate queue is then scheduled alongside a QB queue, both using AC_BE, that would be compliant.


    > [GW] 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.
    	[SM] Great, maybe this can be made more explicit?
    
[GW2] Yes, I have this on my to do list.   I was modeling the NQB draft on some of the PHB RFCs that were very explicit about PHB requirements, but fairly vague on what applications should use it. 


    >  [GW] 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.  
    	[SM] With a variable bandwidth/rate path like wifi, the sender's confidence might not be the best measure? I would guess the hops operating the RF link would be in a better position to predict the path capacity in the immediate future?
   
[GW2]  There are many applications that can a) be very confident in their belief that they will not exceed the available capacity of the path, and b) that would benefit from not being grouped with capacity-seeking traffic that is causing latency and loss in the network.   Keep in mind that the concept of segregating QB & NQB traffic isn't so that we can guarantee deterministic latency for NQB traffic.  This isn't DETNET.  The goal is to allow NQB applications to have statistically much better latency characteristics than they do today. 


    >  [GW] Other links (including WiFi) could implement it as well.   
    	[SM] I fear I am less optimistic, and would argue that without this implemented wifi should be very careful to prioritize NQB (unless we can agree on NQB qualifying behavior that makes harm very unlikely).

[GW2] I'm confident that we come up with language to more clearly describe NQB traffic in a manner that is compatible with the descriptions of other DSCPs that share an AC with it.  I assume this (perhaps in addition to something like I mentioned above about segregation being the only requirement for the PHB) would satisfy you, no? 


    > [GW] 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.  
    	[SM] All good ideas; the question to me is more in light of the lack of such mechanisms would it not be safer to default to AC_BE and only selectively elevate NQB traffic if the radio controller/AP is NQB aware? 
    	I ask because I just did a flent rrul_CS8 (that is bi-directional greedy TCP traffic with one flow dscp-marked for each CS) test-run on my home net, and saw my macbook's sent CS6 and CS7 flows almost starve all other traffic, including CS6/CS7 marked traffic from the AP; I am not confident, that the hardware out there is ready for significant traffic volumes on AC_VO/AC_VI yet... (happy to share the flent data file on request).
    	Now, I realize that NQB is not intended for bulk flows, but as long as the marking is not actively verified (and maybe even bleached on detected mis-marking) the intention does not matter that much, NQB-mismarking will give a considerable bandwidth and latency improvement. With access links getting faster and faster, wifi is becoming more and more a (transient) bottleneck making this issue sensitive.
    
[GW2]  I hope we're past this in the discussion now, but just in case we're not:   I don't think that NQB materially changes this situation.  Today (effectively) no traffic has its WMM selection policed.  It is totally up to the application to decide if it wants to mark its packets CS7 or not, and no one is mandated by the IETF to stop them.  Don't get me wrong, I am not opposed to WiFi devices implementing queue protection (or the QoS protection features in RFC8325), in fact they SHOULD do so (if they want to comply with the draft anyway).  But as long as the traffic types that are recommended to be marked NQB (i.e. sparse/smooth relatively low data rate flows) are compatible with the types of traffic that are recommended to be marked EF, CS6, etc. then I think we're covered.  

[GW2] I really don’t follow your insistence on the IETF mandating that implementers build in safeguards like this.  Recommendations are great, and I support them. 

[GW2] I know you are a fan of fq_codel.  What do you implement in your router that detects and prevents an application from sharding its traffic across multiple queues?  If you aren't preventing this simple and powerful exploit, then maybe your router should be banned from the internet!  (this is a joke, in case anyone misunderstands)