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

[Luca Muscariello <[e-mail]>]

Greg,

Is there any intention to also grant access to the low latency queue to
applications that do not mark?
Also, if I got this whole mechanism right (big IF), it seems like entering
the low latency queue is only based on marking.
This way it looks like the queue is  easy to access and the mechanism
reacts to bad behaviour afterwards.
Does not this risk to create spurious packet enqueues into the low latency
queue? Or worse malicious sources
to make the low latency queue DoSable?

Luca




On Wed, Mar 13, 2019 at 2:03 PM Greg White <[e-mail]> wrote:

> 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]> 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]>
> Date: Monday, March 11, 2019 at 6:26 PM
> To: Greg White <[e-mail]>
> Cc: Dave Taht <[e-mail]>, Jonathan Morton <[e-mail]>, "
> [e-mail]" <[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] 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]" <
> [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.
>
>         The IETF Secretariat
>
>
>
>
>