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

From: Andrew McGregor <[email-masked]>
Date: Wed, 15 May 2019 13:32:27 +1000

---------- Forwarded message ---------
From: Andrew McGregor <[email-masked]>
Date: Fri, May 10, 2019 at 10:32 AM
Subject: Re: TSVWG: WGLC reviews of ECN encapsulation drafts
To: Black, David <[email-masked]>, <
[email-masked]>
Cc: [email-masked] <[email-masked]>, Scheffenegger, Richard <
[email-masked]>, Brian Trammell ([email-masked])
<[email-masked]>, Black, David <[email-masked]>, Wesley Eddy
<[email-masked]>

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. Particularly, if an aggregated PDU is
congestion marked in total, is it correct to mark all the contained IP
frames? 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.

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 <[email-masked]> 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
>
> +1 (774) 350-9323 *New *   Mobile: +1 (978) 394-7754
>
> [email-masked]
>
> ----------------------------------------------------------------
>
>
>

---

From: Andrew McGregor <[email-masked]>
Date: Wed, 15 May 2019 13:32:39 +1000

---------- Forwarded message ---------
From: Andrew McGregor <[email-masked]>
Date: Fri, May 10, 2019 at 2:10 PM
Subject: Re: TSVWG: WGLC reviews of ECN encapsulation drafts
To: Black, David <[email-masked]>, <
[email-masked]>
Cc: [email-masked] <[email-masked]>, Scheffenegger, Richard <
[email-masked]>, Brian Trammell ([email-masked])
<[email-masked]>, Black, David <[email-masked]>, Wesley Eddy
<[email-masked]>

Hi all,

I have reviewed draft-ietf-tsvwg-rfc6040update-shim, and in my opinion it
is good to publish.

I note the RFCXXX instructions to the RFC editor and corresponding
parenthetical notes, it may be as well, if not already done, to ask what
form the editors prefer those to be in.

Hope this helps,
Andrew

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 15 May 2019 19:08:24 +0100

Andrew,

Thank you v much for reviewing this hefty tome. Inline...

On 15/05/2019 04:32, Andrew McGregor wrote:
> From: *Andrew McGregor* <[email-masked] 
> <mailto:[email-masked]>>
> To: Black, David <[email-masked] <mailto:[email-masked]>>, 
> <[email-masked] 
> <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]..uk> 
> <[email-masked] <mailto:[email-masked]>>, Scheffenegger, 
> Richard <[email-masked] 
> <mailto:[email-masked]>>, Brian Trammell 
> ([email-masked] <mailto:[email-masked]>) 
> <[email-masked]..ethz.ch <mailto:[email-masked]>>, Black, 
> David <[email-masked] <mailto:[email-masked]>>, Wesley 
> Eddy <[email-masked] <mailto:[email-masked]>>
>
>
> Hi all,
>
> 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.

> 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.

> 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 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.

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?

Thx for the nits.

>
> Nits:
> "doesn't" seems to be used frequently, which doesn't seem appropriate 
> in every case.
>
> On Thu, Dec 20, 2018 at 11:31 AM Black, David <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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):
>
>     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
>
>     [email-masked] <mailto:[email-masked]>
>

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

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 15 May 2019 22:57:12 +0100

Andrew,

Thank you v much for reviewing this hefty tome. I've added one more 
sentence inline (after "incomprehensibly"), cos I fired the last email 
off a bit early...

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 incomprehensibly?

These are meant to be guildelines on how to write a detailed spec for a 
particular L2 technology. AFAICT, what I wrote in S.4.6. covers all the 
cases you mention, and I believe it is necessary and sufficient. You 
obviously think not, but I can't work out why yet.

Thx for the nits.

Bob

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 16 May 2019 08:09:28 +1000

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 <[email-masked]> wrote:

> Cc: [email-masked] <[email-masked]..uk> <[email-masked]>,
> Scheffenegger, Richard <[email-masked]>, Brian Trammell
> ([email-masked]) <[email-masked]..ethz.ch
> <[email-masked]>>, Black, David <[email-masked]>, Wesley
> Eddy <[email-masked]>
>
>
> Hi all,
>
> like LTE, WiFi, and DOCSIS.
>
> 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.

> 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

>> review, so that I can schedule the WGLC appropriately..
>>

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 16 May 2019 00:18:58 +0100

Andrew, inline tagged [BB]

On 15/05/2019 23:09, Andrew McGregor wrote:
> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Andrew,
>
>>     <[email-masked] <mailto:[email-masked]>>,
>>     Scheffenegger, Richard <[email-masked]
>>     <[email-masked]..ethz.ch <mailto:[email-masked]>>,
>>     Black, David <[email-masked]
>>     <mailto:[email-masked]>>, Wesley Eddy <[email-masked]
>>     <mailto:[email-masked]>>
>>
>>
>>     Hi all,
>>
>>     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.
>
>     marking of packets. But that would necessarily involve holding
>     back markings. The text in S.4.6 says don't do that, rightly IMO.
>
>
>>     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 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.
>
>
[BB] That was what I suspected from reading between your lines.
>
>     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.
[BB] I think the section is missing a statement of the problem. I've 
added the following para, after the first sentence about terminology:

"Where an AQM marks the ECN field of IP packets as they queue into a 
layer-2 link, there will be no problem with framing boundaries, because 
the ECN markings would be applied directly to IP packets. The guidance 
in this section is only applicable where an ECN capability is being 
added to a layer-2 protocol so that layer-2 frames can be ECN-marked by 
an AQM at layer-2. This would only be necessary where AQM will be 
applied at pure layer-2 nodes (without IP-awareness). Where framing 
boundaries do not necessarily align with packet boundaries, the 
following guidance will be needed. It explains how to propagate ECN 
markings from layer-2 frame headers when they are stripped off and IP 
PDUs with different boundaries are reassembled for forwarding. "

HTH

Bob

>
> Thanks,
> Andrew
>
>
>
>     Thx for the nits.
>
>
>>
>>     Nits:
>>     "doesn't" seems to be used frequently, which doesn't seem
>>     appropriate in every case.
>>
>>     On Thu, Dec 20, 2018 at 11:31 AM Black, David
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         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):
>>
>>                         - 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
>>