Re: [tsvwg] New Version Notification for draft-white-tsvwg-lld-00.txt

[Greg White <[e-mail]>]

Luca,

We may work on improving the informative text in that section in order to make the behavior more clear without puzzling through the pseudocode.


  1.  A packet enters the QP algorithm if it is classified to the low latency queue.  By default, the intention is to use ((DSCP==NQB) OR (ECN==ECT(1)) OR (ECN==CE)) (see the NQB draft and ECN-L4S-ID draft) to identify likely NQB flows (but this can be changed if needed).  The algorithm of course doesn’t care how the packets get marked, but our view is that the original application (or OS) should be the one that does the marking. For either marking, there is no incentive to lie.
  2.  The algorithm sanctions (redirects to the classic queue) on a per-packet basis.  So, a microflow that only briefly causes queuing will have some of its packets sanctioned during that episode only, and even during that episode, all of its packets are scored.  Note, in some cases this could result in out-of-order delivery, which might be a minor disincentive for persistently QB flows mismarking themselves as NQB.
  3.  See above.

Greg

From: Luca Muscariello <[e-mail]>
Date: Wednesday, March 13, 2019 at 2:37 PM
To: Greg White <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [tsvwg] New Version Notification for draft-white-tsvwg-lld-00.txt

Greg,

Thanks for the reference.
I have a few questions. I read the document just once so, don't be surprised if I got something wrong.

1) A packet enters the low latency queue if it is marked. Who is responsible for the marking?
Is the original application to do that?

2) Once a packet enters the low latency queue, the flow, or microflow,
is tracked in a (micro)flow table by reporting a function of the queue occupancy.  How do updates of the table
take place? Insert is clear unless the flow is banned, update is clear. Remove is only clear to me when the flow is moved
out of the low latency queue once it  started to get too much resources. Remove in the general case is not clear to me. Timers?

3)  It seems like the mechanism trusts the packet marker until the queue protection mechanism takes
a different decision. How can a marker be redeemed and related  packets be readmitted to the low latency queue?


Thanks
Luca

On Mon, Mar 11, 2019 at 7:18 PM Greg White <[e-mail]<mailto:[e-mail]>> wrote:
Hi Luca,

You can find the details in Annex P of the DOCSIS MULPIv3.1 spec.
https://specification-search.cablelabs.com/CM-SP-MULPIv3.1

-Greg


From: Luca Muscariello <[e-mail]<mailto:[e-mail]>>
Date: Monday, March 11, 2019 at 6:26 PM
To: Greg White <[e-mail]>
Cc: Dave Taht <[e-mail]<mailto:[e-mail]>>, Jonathan Morton <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt

Hi Greg,

I'm curious about the queue protection function in the LLD document.
It seems to assume that a flow table is maintained to determine if a flow
has the right to enter the low latency queue.

Can you give more details about that component? Or point me to a reference?

Thanks
Luca


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

    TSVWG,

    I've posted a new informative draft that gives an overview of the new Low Latency DOCSIS specification (see links below).  This overview may be interesting to TSVWG participants because it includes support for L4S (https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled) and for the NQB PHB (https://datatracker.ietf.org/doc/html/draft-white-tsvwg-nqb).

    Best Regards,
    Greg



    On 3/11/19, 5:05 PM, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> wrote:


        A new version of I-D, draft-white-tsvwg-lld-00.txt
        has been successfully submitted by Greg White and posted to the
        IETF repository.

        Name:           draft-white-tsvwg-lld
        Revision:       00
        Title:          Low Latency DOCSIS - Technology Overview
        Document date:  2019-03-11
        Group:          Individual Submission
        Pages:          25
        URL:            https://www.ietf.org/internet-drafts/draft-white-tsvwg-lld-00.txt
        Status:         https://datatracker.ietf.org/doc/draft-white-tsvwg-lld/
        Htmlized:       https://tools.ietf.org/html/draft-white-tsvwg-lld-00
        Htmlized:       https://datatracker.ietf.org/doc/html/draft-white-tsvwg-lld


        Abstract:
           NOTE: This document is a reformatted version of [LLD-white-paper].

           The evolution of the bandwidth capabilities - from kilobits per
           second to gigabits - across generations of DOCSIS cable broadband
           technology has paved the way for the applications that today form our
           digital lives.  Along with increased bandwidth, or "speed", the
           latency performance of DOCSIS technology has also improved in recent
           years.  Although it often gets less attention, latency performance
           contributes as much or more to the broadband experience and the
           feasibility of future applications as does speed.

           Low Latency DOCSIS technology (LLD) is a specification developed by
           CableLabs in collaboration with DOCSIS vendors and cable operators
           that tackles the two main causes of latency in the network: queuing
           delay and media acquisition delay.  LLD introduces an approach
           wherein data traffic from applications that aren't causing latency
           can take a different logical path through the DOCSIS network without
           getting hung up behind data from applications that are causing
           latency, as is the case in today's Internet architectures.  This
           mechanism doesn't interfere with the way applications share the total
           bandwidth of the connection, and it doesn't reduce one application's
           latency at the expense of others.  In addition, LLD improves the
           DOCSIS upstream media acquisition delay with a faster request-grant
           loop and a new proactive scheduling mechanism.  LLD makes the
           internet experience better for latency sensitive applications without
           any negative impact on other applications.

           The latest generation of DOCSIS equipment that has been deployed in
           the field - DOCSIS 3.1 - experiences typical latency performance of
           around 10 milliseconds (ms) on the Access Network link.  However,
           under heavy load, the link can experience delay spikes of 100 ms or
           more.  LLD systems can deliver a consistent 1 ms delay on the DOCSIS
           network for traffic that isn't causing latency, imperceptible for
           nearly all applications.  The experience will be more consistent with
           much smaller delay variation.

           LLD can be deployed by field-upgrading DOCSIS 3.1 cable modem and
           cable modem termination system devices with new software.  The
           technology includes tools that enable automatic provisioning of these
           new services, and it also introduces new tools to report statistics
           of latency performance to the operator.

           Cable operators, DOCSIS equipment manufacturers, and application
           providers will all have to act in order to take advantage of LLD.
           This white paper explains the technology and describes the role that
           each of these parties plays in making LLD a reality.




        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<http://tools.ietf.org>.

        The IETF Secretariat