Re: [tsvwg] New Version Notification for draft-white-tsvwg-nqb-02.txt

[Greg White <[e-mail]>]

Kevin and Diego,

Thanks for your support of adoption of the draft, and for the comments on the draft.  I've made the suggested changes in comment 1 already in my local copy of the draft so that will be taken care of in the next posting.  

Regarding the first point in comment 2, my expectation would be that deep buffers are critical mainly for capacity-seeking traffic.   So they would be needed for the traffic that would typically be considered QB, as well as potentially for L4S traffic.   For non-capacity-seeking NQB traffic, I would think that it would be possible to utilize a shallow(er) buffer, but any queue-protection function that is validating NQB behavior would need to take into consideration the fact that the channel capacity is highly variable, and thus provide leniency for traffic that caused a temporary queue to form during deep troughs in the channel capacity.  What do you think?

Even for L4S (which is not the subject of this draft), my intuition would be that queuing delays can be significantly reduced (at least statistically) as compared to classic cubic or reno TCP, though it might not be feasible to reach the sub-ms queuing delay at 99th percentile as can be achieved in wired networks.

On the second point in comment 2, we'll rework that text a bit.  Maybe, as you say, it is fine to just write something like: 'operators traditionally have utilized a single bearer, but configuring two bearers can give these advantages', rather than getting into the various reasons why they've not done something similar to this in the past. 

-Greg




On 7/1/19, 1:23 PM, "tsvwg on behalf of Diego R. Lopez" <[e-mail] on behalf of [e-mail]> wrote:

    Hi,
    
    I fully agree with Kevin in what I think are his two main points: it Is beneficial for radio access and you should take into account new 5G parameters in 8.2. And I think adoption would be highly desirable.
    
    Be goode,
    --
    "Esta vez no fallaremos, Doctor Infierno"
    
    Dr Diego R. Lopez
    Telefonica I+D
    https://www.linkedin.com/in/dr2lopez/
    
    e-mail: [e-mail]
    Tel:         [phone]
    Mobile:  [phone]
    ----------------------------------
    
    On 01/07/2019, 18:36, "tsvwg on behalf of Smith, Kevin, (R&D) Vodafone Group" <[e-mail] on behalf of [e-mail]> wrote:
    
        Thanks Greg and Thomas, this indeed looks beneficial for cellular networks, and I would be happy to discuss radio lab testing. It will be interesting to compare against best effort on 5G NR which has a reduced Time Transmission Interval (~7 times more frequent transmissions).
    
        Two comments:
        (1) Historically the addition of bearers was prohibitive due to expense, but that is now easier with the rise in Multi-RAB (Radio Access Bearer) devices. Note however that the definition of bearers and QOS changes in 5G, so a suggested addition is to append that to this sentence in 8.2:
    
        > To support the NQB PHB, the mobile network MUST be configured to give UEs a dedicated, low-latency, non-GBR, EPS bearer with QCI 7 in
           addition to the default EPS bearer; >> or a Data Radio Bearer with 5QI 7 in a 5G system.
    
        (Reference: Table 5.7.4-1: Standardized 5QI to QoS characteristics mapping in 3GPP TS 23.501, 'System Architecture for 5G'.
        Acronym: QI = QoS Identifier )
    
        (2) I think the key point for 8.2 is the volatility of cellular radio links due to rapidly changing SINR (Signal-to-Interference-plus-Noise Ratio) incurred by  devices. This causes sudden and drastic bandwidth fluctuations, as described in https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-02 , and especially under handover scenarios. As a result, and as a means to utilise as many radio resource blocks as possible when they become available, cellular operators often run deep buffers at the scheduler. This is not ideal for NQB traffic, hence the need to investigate your proposal.
    
        The point about why operators typically run default bearers for Internet traffic is more complex than written here - other factors include historic cost and support of additional bearers, requirements to publish dropped voice call percentages, Net Neutrality in EU etc. , so I'm not sure it's worth going into detail; rather just to note the use of a single default "best effort" bearer.
    
        All best,
        Kevin
    
    
        C2 General
    
        -----Original Message-----
        From: tsvwg <[e-mail]> On Behalf Of Greg White
        Sent: 28 June 2019 21:21
        To: [e-mail]
        Subject: [tsvwg] FW: New Version Notification for draft-white-tsvwg-nqb-02.txt
    
        All,
    
        Thomas Fossati and I have posted an updated draft of the proposed NQB DSCP/PHB.  This version incorporates the relevant text from draft-fossati-tsvwg-lola, and discusses intersection with RFC8325 (DSCP-WMM mapping), thereby extending the use-case discussion beyond DOCSIS to include both mobile networks and WiFi.  I believe that we took into account all of the comments received on the previous draft (thanks all who provided comments), but please let us know if we missed something or if you believe we could/should have addressed them differently.
    
        The technology proposed is independent of (but compatible with) the L4S architecture.
    
        My hope is that TSVWG can consider this draft for adoption as a WG draft.
    
        Best Regards,
        Greg
    
    
        On 6/28/19, 12:31 PM, "[e-mail]" <[e-mail]> wrote:
    
    
            A new version of I-D, draft-white-tsvwg-nqb-02.txt
            has been successfully submitted by Greg White and posted to the
            IETF repository.
    
            Name:draft-white-tsvwg-nqb
            Revision:02
            Title:Identifying and Handling Non Queue Building Flows in a Bottleneck Link
            Document date:2019-06-28
            Group:Individual Submission
            Pages:12
            URL:            https://www.ietf.org/internet-drafts/draft-white-tsvwg-nqb-02.txt
            Status:         https://datatracker.ietf.org/doc/draft-white-tsvwg-nqb/
            Htmlized:       https://tools.ietf.org/html/draft-white-tsvwg-nqb-02
            Htmlized:       https://datatracker.ietf.org/doc/html/draft-white-tsvwg-nqb
            Diff:           https://www.ietf.org/rfcdiff?url2=draft-white-tsvwg-nqb-02
    
            Abstract:
               This draft proposes the definition of a standardized DiffServ code
               point (DSCP) to identify Non-Queue-Building flows (for example:
               interactive voice and video, gaming, machine to machine
               applications), along with a Per-Hop-Behavior (PHB) that provides a
               separate queue for such flows.
    
               The purpose of such a marking scheme is to enable networks to provide
               and utilize queues that are optimized to provide low latency and low
               loss for such Non-Queue-Building flows (e.g. shallow buffers,
               optimized media access parameters, etc.).
    
               This marking scheme and PHB has been developed primarily for use by
               access network segments, where queuing delays and queuing loss caused
               by Queue-Building protocols are manifested.  In particular,
               applications to cable broadband links and mobile network radio and
               core segments are discussed.
    
    
    
    
            Please note that it may take a couple of minutes from the time of submission
            until the htmlized version and diff are available at tools.ietf.org.
    
            The IETF Secretariat
    
    
    
    
    
    ________________________________
    
    Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
    
    The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
    
    Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição