Re: [tsvwg] Fwd: TSVWG: WGLC reviews of ECN encapsulation drafts

[Andrew McGregor <[e-mail]>]

Thanks Bob,

That clarifies it for me, maybe we just need to add one or two sentences to
avoid others tripping over the same point.  Comments inline.

On Thu, May 16, 2019 at 4:08 AM Bob Briscoe <[e-mail]> wrote:

> Andrew,
>
> Thank you v much for reviewing this hefty tome. Inline...
>
> On 15/05/2019 04:32, Andrew McGregor wrote:
>
>
>
> ---------- Forwarded message ---------
> From: Andrew McGregor <[e-mail]>
> Date: Fri, May 10, 2019 at 10:32 AM
> Subject: Re: TSVWG: WGLC reviews of ECN encapsulation drafts
> To: Black, David <[e-mail]>, <
> [e-mail]>
> Cc: [e-mail] <[e-mail]..uk> <[e-mail]>,
> Scheffenegger, Richard <[e-mail]>, Brian Trammell
> ([e-mail]) <[e-mail]..ethz.ch
> <[e-mail]>>, Black, David <[e-mail]>, Wesley
> Eddy <[e-mail]>
>
>
> Hi all,
>
> I have reviewed draft-ietf-tsvwg-ecn-encap-guidelines.
>
> I find only one issue of any substance. That is, the definition of a PDU
> and the discussion on reframing and congestion marking in section 4.6 seems
> to me to apply more to fragmenting MACs like ATM than to aggregating MACs
> like LTE, WiFi, and DOCSIS.
>
> I don't think LTE and DOCSIS can be called aggregating MACs in the same
> way that WiFi is. Their link layer forwards a byte stream chopped up into
> segments/frames so the boundaries of packet and of segments/frames don't
> generally align. Whereas I believe a WiFi frame always contains an integer
> number of packets.
>

Correct, a WiFi AMPDU contains several complete packets plus perhaps some
extra MAC-layer IEs. Each IP packet has an 802.11 header attached, and the
AMPDU has an 802.11 header of its own which can contain extra IEs beyond
just the aggregation header. By definition, if there's only one packet,
it's a PDU not an AMPDU.

Particularly, if an aggregated PDU is congestion marked in total, is it
> correct to mark all the contained IP frames?
>
> Yes. For instance, if the AQM is currently marking 0.1% of aggregated PDUs
> (randomly - without regard to their size), then marking all the packets
> within each marked MPDU will also mark 0.1% of packets on average.
>
> You might think it would be better to somehow spread out the 0.1% marking
> of packets. But that would necessarily involve holding back markings. The
> text in S.4.6 says don't do that, rightly IMO.
>

Agreed, extra delay for that reason would be counterproductive.


> What if, like WiFi, the lower layer supports non-congestive drops for
> single PDUs within an MPDU, and could conceivably also support congestion
> marking separately? One could imagine defining congestion in terms of
> airtime rather than octets for wireless MACs, for example.
>
> If the lower layer chooses to ECN-mark packets as they arrive at the queue
> into the layer, that's fine. Then there is no re-framing problem for the
> ECN markings. That's how AQM dropping and ECN marking is done in DOCSIS.
>

I think this point is what I missed.

I suspect a link layer would generally only need the L2 protocol to support
> ECN marking where there might be pure L2 nodes with no IP awareness. For
> instance, in LTE, an eNodeB is often not IP-aware, so if an AQM at the
> eNodeB was going to ECN-mark in-band, the RLC protocol would have to be
> modified to support ECN marks. Then, when RLC PDUs were decapsulated, the
> reframing rules for ECN marking in S.4.6 would come into play.
>

Ah, OK. I see how this works now.

I'm not sure yet whether or what I need to change in section 4.6. Given the
> above, can you help me understand what I've written incomprehenisbly?
>

I think the text is comprehensible and correct as it stands, if you can
think of a way to make that specific point more obvious that would be good.
If not, I don't object, it's subtle.

Thanks,
Andrew


>
>
> Thx for the nits.
>
>
>
> Nits:
> "doesn't" seems to be used frequently, which doesn't seem appropriate in
> every case.
>
> "feed-up-an-forward" typo in the second-last paragraph of the conclusion.
>
> Hope this helps,
> Andrew
>
> On Thu, Dec 20, 2018 at 11:31 AM Black, David <[e-mail]>
> wrote:
>
>> Gentlemen (Gorry, Richard, Brian and Andrew):
>>
>>
>>
>> Once upon a time (this past summer in Montreal), I believe that each of
>> you volunteered to review the two ECN encapsulation drafts during a Working
>> Group Last Call (WGLC):
>>
>>                 - draft-ietf-tsvwg-ecn-encap-guidelines
>> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/>
>>
>>                 - draft-ietf-tsvwg-rfc6040update-shim
>> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/>
>>
>> I subsequently dropped the ball on this :-(.
>>
>>
>>
>> I’m now planning to start a combined WGLC on these two drafts sometime in
>> January.   Would each of you please let me know:
>>
>>                 - Whether you’re still able to and interested in
>> reviewing these drafts during WGLC, and
>>
>>                 - Any time preferences or restrictions on when to do the
>> review, so that I can schedule the WGLC appropriately..
>>
>> I have no problem with a longer-than-usual WGLC time period to enable
>> reviews from talented folks such as you.
>>
>>
>>
>> Thanks, --David
>>
>> ----------------------------------------------------------------
>>
>> David L. Black, Senior Distinguished Engineer
>>
>> Dell EMC, 176 South St., Hopkinton, MA  01748
>>
>> [phone] *New *   Mobile: [phone]
>>
>> [e-mail]
>>
>> ----------------------------------------------------------------
>>
>>
>>
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
>