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

Bob Briscoe <ietf@bobbriscoe.net> Fri, 21 December 2018 17:47 UTC

Return-Path: <ietf@bobbriscoe.net>
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 ECAAC130E4C for <tsvwg@ietfa.amsl.com>; Fri, 21 Dec 2018 09:47:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3
X-Spam-Level: ***
X-Spam-Status: No, score=3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 GmvGx0kGqQp0 for <tsvwg@ietfa.amsl.com>; Fri, 21 Dec 2018 09:47:49 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E056D12875B for <tsvwg@ietf.org>; Fri, 21 Dec 2018 09:47:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vTVC5ma0Ub6eeBzuRIaKn6eUIoogljOJ5RixpG+D/Ew=; b=A1F80zZCP6IuBWJIL3u0z3VT6 kEGe8FhknXoFVPQqQvVcx+Ec0XxjoWs5+xBHhRMu/M23/KlcaIgM9kbPH0MuI2f3HuqERtKOQRpKO PhTD3oYcpVXexUj+o7ACCMU98mvveMffUJoieqjR2bIgUlTFnDEZgNwaIQwjCpo+ZqgplrxDSQ6EE KNbOYJ/Z50ntx4iyx25CRU68X4vxkBHQxO9GkayZWsp9+vAxOUugsBKMZpfd8jIVJ0oxVF+e43xUh qeXJ+Bq/+lOEVKdjfR3a7wID0oRA5blQpRIedYvshqWQ65QWmJuuQpZGWZb6bYuButttawhZlyS6O SNp9K050g==;
Received: from host-79-78-166-168.static.as9105.net ([79.78.166.168]:59876 helo=[192.168.2.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <ietf@bobbriscoe.net>) id 1gaOtk-0000qN-TU; Fri, 21 Dec 2018 17:47:47 +0000
To: David Pullen <david.pullen@broadcom.com>
Cc: tsvwg@ietf.org
References: <CAA+foQUsOGeSpqqJw6OSJxJOg8p9fZ_L9fVvP1HThSBsiuGNYw@mail.gmail.com> <0df1608a-314e-9266-9cc5-9f3913ac33a0@bobbriscoe.net> <CAA+foQVq+zao_AKAEciU-JPppnwguXygvWeC7az4hF7C0MZ32g@mail.gmail.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <54ac64b3-016c-0dea-3787-3d010c083c4c@bobbriscoe.net>
Date: Fri, 21 Dec 2018 17:47:43 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <CAA+foQVq+zao_AKAEciU-JPppnwguXygvWeC7az4hF7C0MZ32g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------3BFC6B36A6E905CA48A5DEEE"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/T2sNuusMaqLeQ7TdXAI5IhiZSg0>
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: Fri, 21 Dec 2018 17:47:52 -0000

David,

On 17/12/2018 18:50, David Pullen wrote:
> 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?

OK, I now understand the question, which is actually just as relevant to 
any AQM, so I wouldn't want to add particular requirements about this in 
the DualQ AQM draft.

The general answer is that an AQM should not correct for trying to mark 
a packet that is already marked anyway.

To my mind this actually gives a more appropriate result anyway. Because 
the probability of marking a packet can be defined as the probability 
that adding that packet would cause congestion (for whatever definition 
of congestion you care to use). So, when two links on the path are 
congested, the congestion signal to the end system should be the 
combined probability that addition of that packet will congest either 
link. And to combine two probabilities p1 & p2, the signal should be p = 
1 - (1-p1)*(1-p2), which is what happens naturally when you just ignore 
attempts to mark packets that are already marked.

For instance, if p1 = 2% and p2 = 3%, p should not be 5%, which it would 
be if the AQM carried over marks on packets already marked. The combined 
signal, p, should be 4.94%.

This also has other nice properties

  * when two or more links a heavily congested, it would be obviously
    wrong to try to mark with the sum of the probabilities if it was > 100%
  * after a long period of very high congestion, it won't continue to
    carry over marks for a long time after the congestion has actually
    subsided;
  * it doesn't require an AQM to hold marking state.

Given I don't think any of this needs to be written in the DualQ draft, 
should the IETF write it somewhere else? Well, ideally it could have 
been mentioned in RFC 7567 (AQM recommendations). But I think it's not 
really an interop issue, so I'm happy to leave it as something that 
certain vendors might do 'right' and others not.


Bob

PS. I wrote about this once, at equation (6) in the Appendix to this paper:
https://conferences.sigcomm.org/sigcomm/2005/paper-BriJac.pdf#page=12





>
> Thanks,
>   - Dave
>
> David PullenDistinguished Engineer  |  Wired Networking, Cable 
> ModemsBroadcomoffice:678.475.3143  | mobile:678.477.4108  | 
> fax:770.232.02114385 River Green Parkway  |  Duluth, GA 
> 30096david.pullen@broadcom.com <mailto:david.pullen@broadcom.com>   | 
> broadcom.com <http://broadcom.com>
>
>
>
> On Mon, Dec 17, 2018 at 12:54 PM Bob Briscoe <ietf@bobbriscoe.net 
> <mailto: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 PullenDistinguished Engineer  |  Wired Networking, Cable
>>     ModemsBroadcomoffice:678.475.3143  | mobile:678.477.4108  |
>>     fax:770.232.02114385 River Green Parkway  |  Duluth, GA
>>     30096david.pullen@broadcom.com <mailto:david.pullen@broadcom.com>
>>       | broadcom.com <http://broadcom.com>
>>
>
>     -- 
>     ________________________________________________________________
>     Bob Briscoehttp://bobbriscoe.net/
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/