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

[Bob Briscoe <[e-mail]>]

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:[phone]  | 
> fax:[phone] River Green Parkway  |  Duluth, GA 
> [e-mail] <mailto:[e-mail]>   | 
> broadcom.com <http://broadcom.com>
>

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