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

Luca Muscariello <luca.muscariello@gmail.com> Wed, 13 March 2019 20:37 UTC

Return-Path: <luca.muscariello@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8881311BF for <tsvwg@ietfa.amsl.com>; Wed, 13 Mar 2019 13:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YXq2v7b9al8 for <tsvwg@ietfa.amsl.com>; Wed, 13 Mar 2019 13:37:48 -0700 (PDT)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987731311DA for <tsvwg@ietf.org>; Wed, 13 Mar 2019 13:37:48 -0700 (PDT)
Received: by mail-ot1-x32f.google.com with SMTP id g1so3030276otj.11 for <tsvwg@ietf.org>; Wed, 13 Mar 2019 13:37:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q4ED30WM14Cehon35A80XahUPNmoJEiXA1HxHKSeOHc=; b=l/mj6N+ZlHZfDuWS7dVgYolJWi2H22itLOgp/SYVX87BmT3Ekk2FKuNKvloj7u+1vs dd1pTGY1vSqhQrQqsTa+ve7+D98xO8+LYvC7gzduGNbaDs8TjwSZaUdNVnSlfTZ/2pXm OOh6c7OnB5HRpx3qUr3iAclxt7PPzMoGFEwUB5JJc/R8rZujxs1sbtyoMt3zvlSmNimr OWAYxofXB66A70O90DMv5MsazegDO4mivb6WBPrmPlqHkn4Y9dFO74cxw2WikQbsl5UR 9e4YvhWRO7ldzvi5VJTNSCSyWBOh8cU+5AUNPvAI/eagAZ/eAEg5M77YseSrGo1aHDhp 0Hlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q4ED30WM14Cehon35A80XahUPNmoJEiXA1HxHKSeOHc=; b=jPf2bBsKJoDzv8KIgYMpZ8PpRrQ8WoNOV1J9875isH7VbFK0SPQ1y2TOZOiUKflcar 3aWhIspypmfp5S43xpY/mUtAkxJ0RxycbdCdP8bl0Z/wYdtJQifSqZkv5pk+sSExxb+L VwdTmQyi9D+vsFIeP1Co2h3PDDKzzkrh80Hn/kZg9IJJKjqW7LEVg8x9cACBhNNAzGVw PRPGKCGVvhf8OZRLMB2DB50r+XdIsqf0dTS1L0Nz6QqLEdSTf45y2bFTYWRrGEXUr1kl kvoPw7LwygnyUE7FBOa9uItnzcH3X+Zjqk3c9GI6XxDgDge5sLRgEUHPA5H6oh73xUWf gp9w==
X-Gm-Message-State: APjAAAW828A8LM2Ha6Ygd+BReFQLgW5Hq/XrPLt1swhLLh7VFPsincfj dCkkklwljQV2N+0yZYZmLmFzGVPvOrLW1mZA4Pw=
X-Google-Smtp-Source: APXvYqw8NLWWNXDTwNUlhiVoZZJACsP6aneubybIW4dcgrI/0slc9yYosb9sCLc2qqYojVCD8cLP3kjPMnZzs9D752c=
X-Received: by 2002:a05:6830:144a:: with SMTP id w10mr28034558otp.154.1552509467352; Wed, 13 Mar 2019 13:37:47 -0700 (PDT)
MIME-Version: 1.0
References: <0289E1B3-9AFF-4633-A9B1-6BAEE96B7692@cablelabs.com>
In-Reply-To: <0289E1B3-9AFF-4633-A9B1-6BAEE96B7692@cablelabs.com>
From: Luca Muscariello <luca.muscariello@gmail.com>
Date: Wed, 13 Mar 2019 13:37:36 -0700
Message-ID: <CAHx=1M6US_HYjXfqtRr8RbGEe5QxPjjnivLkKMHHBpqMQRyP8g@mail.gmail.com>
To: Greg White <g.white@cablelabs.com>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004fe4c20583ffc73e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/bTyg8V7yZBrO87Su0GVuJwF21Ik>
Subject: Re: [tsvwg] New Version Notification for draft-white-tsvwg-lld-00.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Mar 2019 20:37:59 -0000

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 <g.white@cablelabs.com> 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 <luca.muscariello@gmail.com>
> Date: Monday, March 11, 2019 at 6:26 PM
> To: Greg White <g.white@CableLabs.com>
> Cc: Dave Taht <dave@taht.net>, Jonathan Morton <chromatix99@gmail.com>, "
> tsvwg@ietf.org" <tsvwg@ietf.org>
> 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" <
> tsvwg-bounces@ietf.org on behalf of g.white@CableLabs.com> 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, "internet-drafts@ietf.org" <
> internet-drafts@ietf.org> 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
>
>
>
>
>
>