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

Bob Briscoe <ietf@bobbriscoe.net> Wed, 15 May 2019 23:19 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DDC12016B for <tsvwg@ietfa.amsl.com>; Wed, 15 May 2019 16:19:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NU4g52rXjPJJ for <tsvwg@ietfa.amsl.com>; Wed, 15 May 2019 16:19:02 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E340512002F for <tsvwg@ietf.org>; Wed, 15 May 2019 16:19:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9K4USGTu/8YHGiAVFfvNG5ypkwDQbA3VP/Te3kn94nI=; b=ldnnQhf9lLELfoOj2RdraQBR9 aul2QboBVdLkeo2L7+WkiY4CsdS3QiStx3w+6tXmMMZc4V9HvQVmIP3/YEqB/+3WbOgF6bo1Ta4nT oP5SviyIYKXKbrJYqaU0rMiwZUQFSK/lE9mUJjBa+bJOG5V6if8tH5ipNG4fYnCh0bqIBGzxKu/Df axyUIFjMlxX/o5Z2Mx8SzuGk+hnds4PP0PdrMfA7RTIDPeXKdqFV9ydK/fgWXsfQ9N946Jt+ZHdNa KemaienCjQVeTcfvncLG8H7xM6OEzMGvB82+JN5WFyUpxacAU2Z5C+74IAoxV9BSy1vlZ3jVdJxmR +4yNuk5pw==;
Received: from [31.185.135.221] (port=33832 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <ietf@bobbriscoe.net>) id 1hR3Ap-0000P1-2K; Thu, 16 May 2019 00:18:59 +0100
To: Andrew McGregor <andrewmcgr@gmail.com>
Cc: tsvwg <tsvwg@ietf.org>
References: <CE03DB3D7B45C245BCA0D24327794936303A5167@MX307CL04.corp.emc.com> <CAA_e5Z7P33gbUdaAoT96ZNNJEZ51zOsQ2XuHWwenzLtVnek36g@mail.gmail.com> <CAA_e5Z4=vbs2Zr618htDfTYk5bZxqKeA6YS923dP9rG41926pA@mail.gmail.com> <84005628-9703-c6ab-d27b-b91fce2e396a@bobbriscoe.net> <CAA_e5Z58sM6i1mAhQss-zaCOkpyANW5XdDY4j2GxYSzC=La4Yw@mail.gmail.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <4a3958f9-0b9e-0b9c-8350-480354b9786f@bobbriscoe.net>
Date: Thu, 16 May 2019 00:18:58 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CAA_e5Z58sM6i1mAhQss-zaCOkpyANW5XdDY4j2GxYSzC=La4Yw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------D1720EEF97233E2E8A54C046"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/DsLjUn-9FKYViluoKdo30myNmCI>
Subject: Re: [tsvwg] Fwd: TSVWG: WGLC reviews of ECN encapsulation drafts
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2019 23:19:13 -0000

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 <ietf@bobbriscoe.net 
> <mailto:ietf@bobbriscoe.net>> 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* <andrewmcgr@gmail.com
>>     <mailto:andrewmcgr@gmail.com>>
>>     Date: Fri, May 10, 2019 at 10:32 AM
>>     Subject: Re: TSVWG: WGLC reviews of ECN encapsulation drafts
>>     To: Black, David <David.Black@dell.com
>>     <mailto:David.Black@dell.com>>,
>>     <draft-ietf-tsvwg-ecn-encap-guidelines@ietf.org
>>     <mailto:draft-ietf-tsvwg-ecn-encap-guidelines@ietf.org>>
>>     Cc: gorry@erg.abdn.ac.uk <mailto:gorry@erg.abdn.ac..uk>
>>     <gorry@erg.abdn.ac.uk <mailto:gorry@erg.abdn.ac.uk>>,
>>     Scheffenegger, Richard <Richard.Scheffenegger@netapp.com
>>     <mailto:Richard.Scheffenegger@netapp.com>>, Brian Trammell
>>     (trammell@tik.ee.ethz.ch <mailto:trammell@tik.ee.ethz.ch>)
>>     <trammell@tik.ee..ethz.ch <mailto:trammell@tik.ee.ethz.ch>>,
>>     Black, David <David.Black@dell.com
>>     <mailto:David.Black@dell.com>>, Wesley Eddy <wes@mti-systems.com
>>     <mailto:wes@mti-systems.com>>
>>
>>
>>     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.
[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.
>>
>>     "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
>>     <David.Black@dell.com <mailto:David.Black@dell.com>> 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
>>
>>         David.Black@dell.com <mailto:David.Black@dell.com>
>>
>>         ----------------------------------------------------------------
>>
>
>     -- 
>     ________________________________________________________________
>     Bob Briscoehttp://bobbriscoe.net/
>

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