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

From: "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>
Date: Mon, 1 Jul 2019 16:35:50 +0000

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 <[email-masked]> On Behalf Of Greg White
Sent: 28 June 2019 21:21
To: [email-masked]
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, "[email-masked]" <[email-masked]> 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

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 2 Jul 2019 08:31:17 +0000

Kevin, Diego, excellent feedback, thanks.

We will take your comments about 5G (and a better characterisation of
the history of the default bearer in mobile networks) in on the next
iteration.

Kevin: that lab testing idea of yours looks very intriguing.  Last year
we - Pedro Aranda Gutiérrez and I - did work on the LTE simulator and
the results were very promising.  However, for reasons beyond our will
we couldn’t finalise the experiments with the real equipment, so having
a further level of validation in the lab would be excellent.

Cheers, t

On 01/07/2019, 17:36, "tsvwg on behalf of Smith, Kevin, (R&D) Vodafone Group" <[email-masked] on behalf of [email-masked]> wrote:

    Two comments:

    All best,
    Kevin

    C2 General

    -----Original Message-----
    From: tsvwg <[email-masked]> On Behalf Of Greg White
    Sent: 28 June 2019 21:21
    To: [email-masked]
    Subject: [tsvwg] FW: New Version Notification for draft-white-tsvwg-nqb-02.txt

    All,

    Best Regards,
    Greg

        Abstract:

        The IETF Secretariat

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Claire Perrier <[email-masked]>
Date: Fri, 12 Jul 2019 17:39:03 +0000

Hi,

As LLD WG Cable Labs members, Videotron is really interested in the evolutions of the DOCSIS proposed by Cable Labs in this LLD WG . We want to optimize our Docsis network and be able to compete with other (optical) networks. ( for gaming first ... but we see many other opportunities (Mobile convergence...) ).

During summer we plan to test the feature with one of our manufacturer and we hope that the DSCP marking for non-QB  will be standardized as it seems to be part of its solution.

So we will follow with interest the standardization conclusion and hope we are in the right way in order to implement this solution as soon as possible .

Thanks,
Claire PERRIER ( Videotron)

Claire Perrier
Ingenieur Pr. Evolution Des Reseaux, Technologie et produits
Vidéotron
L'entreprise de télécommunications la plus appréciée de ses clients. videotron.com/distinctions<http://www.videotron.com/distinctions>
________________________________
612, rue Saint-Jacques, Montréal (Québec)  H3C 4M8
Tél. : 514 759-2333 poste | [email-masked]<mailto:[email-masked]>
Devez-vous imprimer ce courriel ?
Avis de confidentialité : Ce message, transmis par courriel, est confidentiel, peut être protégé par le secret professionnel et est à l'usage exclusif du destinataire dont l'adresse figure ci-dessus. Toute autre personne est par la présente avisée qu'il lui est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous avez reçu ce courriel par erreur, veuillez m'en informer par courrier électronique et détruire immédiatement ce message et toute copie de celui-ci. Merci.
Confidentiality notice: The content of this e-mail is confidential, may be privileged and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing, distributing or reproducing it. If you have received this e-mail by error, please notify me by e-mail and delete all copies. Thank you.

---

From: Bjørn Ivar Teigen <[email-masked]>
Date: Mon, 15 Jul 2019 09:14:59 +0200

>From the perspective of home network optimisation this makes a lot of
sense. Wi-Fi is often the bottleneck link so its great that Wi-Fi has been
addressed as well.

Best regards,
-- 
Bjørn Ivar Teigen
Data Scientist
Domos, Machine Learning for the Home
www.domos.no

---

From: "Ozer, Sebnem" <[email-masked]>
Date: Tue, 23 Jul 2019 01:16:37 +0000

As Comcast we are interested in identifying NQB traffic with a standardized marking that can be used end-to-end across different network segments. We believe that we can use a standardized DSCP (0x2A codepoint as defined in this proposal) to support Low Latency services in our DOCSIS and other access networks. This is an important standardization proposal for us as we think its adoption would help us towards an open and interoperable solution.
Thanks,
Sebnem