Re: [tsvwg] Technical discussion 3 of draft-ietf-tsvwg-aqm-dualq-coupled-08

David Pullen <david.pullen@broadcom.com> Mon, 17 December 2018 18:50 UTC

Return-Path: <david.pullen@broadcom.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 786F2130F09 for <tsvwg@ietfa.amsl.com>; Mon, 17 Dec 2018 10:50:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.46
X-Spam-Level:
X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 4ehW4i-dDqg8 for <tsvwg@ietfa.amsl.com>; Mon, 17 Dec 2018 10:50:02 -0800 (PST)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 2E2C5130F04 for <tsvwg@ietf.org>; Mon, 17 Dec 2018 10:50:02 -0800 (PST)
Received: by mail-qk1-x732.google.com with SMTP id 189so7957538qkj.8 for <tsvwg@ietf.org>; Mon, 17 Dec 2018 10:50:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1+oC+kj3gUWfhSEFlz+7SSyg5K91OuzXZD3X+2JnsNE=; b=g9gJfsFY7/WRO6I2MxTh+iKlYJF+d6C9uWM2SDeIYU1dcgSispHWvOAL9/wrCcCr3v ibXHljbSv+4vtlwYFe80Z7mvCs+XgtApLLumsgOvOdM3iPgOg3vd3DLmDs2pFFuRyEIu An38ajVReU3UVifLNhCVWMWUzNnZxEnfusqkc=
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=1+oC+kj3gUWfhSEFlz+7SSyg5K91OuzXZD3X+2JnsNE=; b=H9jtSnvhxbFO+g2inaO8SzMWy4j7ODX02szw21X+U0Kqq4vtwwaWInSE5pI7qbGoBa B3nTa4ht7H8FZ2vBzwttGGnpjChKmWuhn3BEvO0O6JRfQqDnMcUrMzjtvnoruod6WC9N ptn0kWTXlrIqY2ughbn0BNS4vJ8nTz9VB8miugEBKmmwi/SK9c0KfRoEDEynR9wsooMX Rmf61rIYMEmJohaVSRN3fC/ncgCuNLQ5lQMYMGP95BgQrRJiZPMlQ1cq1mUhq7jplOPF kSdAGr4IWdFVUqGxQ6QLiumFzXqx2IQcap8QE76KRtUesWQ7cUAJT93f4wLmLtRxwpg8 cdDA==
X-Gm-Message-State: AA+aEWbMc+EIi2dwK2Z9LiXclqPT0rMRv8iFM2kj+RdqpjhAiS0gTf6o vz7NfASsNzYWm9X1dJTUbAZ8Y3O3B5XYUMO+EdCYeA==
X-Google-Smtp-Source: AFSGD/WS3mMu/4o4FpV6Ymnxixwq30+Vh59wPr2Nqndtrgl4Vn4KgKxNPsAu3mCkGs+8UIfIuM5+ZvvsKolnlAXRxHw=
X-Received: by 2002:a37:484c:: with SMTP id v73mr12997652qka.196.1545072601145; Mon, 17 Dec 2018 10:50:01 -0800 (PST)
MIME-Version: 1.0
References: <CAA+foQUsOGeSpqqJw6OSJxJOg8p9fZ_L9fVvP1HThSBsiuGNYw@mail.gmail.com> <0df1608a-314e-9266-9cc5-9f3913ac33a0@bobbriscoe.net>
In-Reply-To: <0df1608a-314e-9266-9cc5-9f3913ac33a0@bobbriscoe.net>
From: David Pullen <david.pullen@broadcom.com>
Date: Mon, 17 Dec 2018 13:50:09 -0500
Message-ID: <CAA+foQVq+zao_AKAEciU-JPppnwguXygvWeC7az4hF7C0MZ32g@mail.gmail.com>
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: tsvwg@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008b64f6057d3c3ff8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/hOK2LWhqM2I95VL4iOjKMxa5jyM>
Subject: Re: [tsvwg] Technical discussion 3 of draft-ietf-tsvwg-aqm-dualq-coupled-08
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: Mon, 17 Dec 2018 18:50:06 -0000

Hi Bob,

Regarding part 2, I think the proposed text looks reasonable.

Apologies for the confusion regarding my question in part 1. The question
is related to what the L queue AQM should do if it decides that a CE-marked
packet (or a non-ECT packet) should be marked - and mainly is related to
the state of the AQM itself. Obviously, the packet has already been marked
(or could not be marked), so there is nothing to be done about that. But
should the AQM remember that it could not mark a packet that it would like
to have marked, and thus mark the first future packet that is ECT(0) or
ECT(1)? Or should it forget this failed mark decision and just move on?

Thanks,
  - Dave

David Pullen
Distinguished Engineer  |  Wired Networking, Cable Modems
Broadcom

office: 678.475.3143  |  mobile: 678.477.4108  |  fax: 770.232.0211
4385 River Green Parkway  |  Duluth, GA 30096
david.pullen@broadcom.com   |   broadcom.com



On Mon, Dec 17, 2018 at 12:54 PM Bob Briscoe <ietf@bobbriscoe.net> wrote:

> David,
>
> 1/ I can see that there's a problem here, but I'm not sure I fully follow
> the question. Section 2.5.1.1 is about unexpected cases. A CE-marked packet
> in the L queue is handled in the previous section, because it is an
> expected case. And actually, CE-marked packets can also be expected in the
> C queue (see item #2 below).
>
> I think perhaps this is too subtle to leave unstated, which is possibly
> why you have raised this question. So I suspect we need to alter the
> introductory para to section 2.5.1.1 to explain all this. But before
> proposing any changes, I'll wait to hear whether I've understood your
> question.
>
>
> 2/ That's not all. While checking the draft, I referred back to section
> 2.3 "Traffic Classification" where in the first para it summarizes the
> L4S-ID draft. I noticed that it only says that the draft "requires the
> sender to use the ECT(1) codepoint". So I shall clarify that by making
> the following alterations:
>
> CURRENT:
>
>    Both the Coupled AQM and DualQ mechanisms need an identifier to
>    distinguish L and C packets.  Then the coupling algorithm can achieve
>    coexistence without having to inspect flow identifiers, because it
>    can apply the appropriate marking or dropping probability to all
>    flows of each type.  A separate
>    specification [I-D.ietf-tsvwg-ecn-l4s-id <https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08#ref-I-D.ietf-tsvwg-ecn-l4s-id>] requires the sender to use
>    the ECT(1) codepoint of the ECN field as this identifier, having
>    assessed various alternatives.  An additional process document has
>    proved necessary to make the ECT(1) codepoint available for
>    experimentation [RFC8311 <https://tools.ietf.org/html/rfc8311>].
>
>
> PROPOSED:
>
>    Both the Coupled AQM and DualQ mechanisms need an identifier to
>    distinguish L and C packets.  Then the coupling algorithm can achieve
>    coexistence without having to inspect flow identifiers.  A separate
>    specification [I-D.ietf-tsvwg-ecn-l4s-id <https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08#ref-I-D.ietf-tsvwg-ecn-l4s-id>] defines the ECT(1) and CE
>    codepoints of the IP-ECN field as the identifiers for classification
>    into the L queue (it also allows certain CE packets to be classified
>    into the C queue).  An additional process document has
>    proved necessary to make the ECT(1) codepoint available for
>    experimentation [RFC8311 <https://tools.ietf.org/html/rfc8311>].
>
>
> REASONING:
>
>    - I've removed "because it can apply the appropriate marking or
>    dropping probability to all flows of each type" given I think it adds
>    little except confusion.
>    - I've focused on which codepoints identify L packets in the network,
>    because what the sender sets is not the whole story.
>
> Thoughts?
>
>
> Bob
>
> On 17/12/2018 15:55, David Pullen wrote:
>
> Hi Bob,
>
> In section 2.5.1.1, there is a bullet list that describes the expected
> behavior for different conditions (ECT(0), ECT(1), not-ECT), but doesn't
> describe what to do if the codepoint is CE.
>
> This topic probably should have been combined with technical discussion 2,
> since it is related...
>
> Thanks,
>   - Dave
>
> David Pullen Distinguished Engineer  |  Wired Networking, Cable Modems
> Broadcom office: 678.475.3143  |  mobile: 678.477.4108  |  fax:
> 770.232.0211 4385 River Green Parkway  |  Duluth, GA 30096
> david.pullen@broadcom.com   |   broadcom.com
>
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
>