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

From: David Pullen <[email-masked]>
Date: Mon, 17 Dec 2018 10:55:58 -0500

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
[email-masked]   |   broadcom.com

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 17 Dec 2018 17:53:59 +0000

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:
> 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 
> [email-masked] <mailto:[email-masked]>   | 
> broadcom.com <http://broadcom.com>
>

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

---

From: David Pullen <[email-masked]>
Date: Mon, 17 Dec 2018 13:50:09 -0500

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

On Mon, Dec 17, 2018 at 12:54 PM Bob Briscoe <[email-masked]> 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'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,
> 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

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 21 Dec 2018 17:47:43 +0000

David,

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

> On Mon, Dec 17, 2018 at 12:54 PM Bob Briscoe <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     David,
>
>     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:
>
>         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
>
>>     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.
>>
>>     [email-masked] <mailto:[email-masked]>
>>       | broadcom.com <http://broadcom.com>
>>
>
>     -- 
>     Bob Briscoehttp://bobbriscoe.net/
>