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

[Bob Briscoe <[e-mail]>]

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

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

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

>
> 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] 
> <mailto:[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] <mailto:[e-mail]>
>
>     ----------------------------------------------------------------
>

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