Re: [tsvwg] Improvements to figures of draft-ietf-tsvwg-ecn-encap-guidelines-20

Bob Briscoe <in@bobbriscoe.net> Tue, 07 November 2023 22:25 UTC

Return-Path: <in@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 88BE4C18770A; Tue, 7 Nov 2023 14:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdoRDwq1oLxT; Tue, 7 Nov 2023 14:25:15 -0800 (PST)
Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (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 24AEAC18FCB7; Tue, 7 Nov 2023 14:25:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:To:Subject:MIME-Version:Date:Message-ID:Sender: Reply-To:Cc: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=A/eJ5J3yS61e+v+4h97T8xT6dR8/p/mPzDudFjHvImo=; b=VbYRDTJfyFROMk4FcfOPH/A9o+ I2xPJGTUJgTa8lwMS/1j9AssIFA9LJvWgj+8/YDTlNwBeqZtkrnnh9YLBk4c+m4FLJw1hi2CgJ2Ul PIW+tdUbkH+wOpU/dQFQamNeWUIfUIhXq9raR4RzdzB7uEDYQVi61NAE07vRr2XrPZZuOuPsSXvi1 gYKUjitP4zq4pGopWzMJKAzpvgf++i/ixm+jsFH4L13/TRHMDl3rQTOWvqnlz+eH/25I4K9iiAwT+ 8zRG7g9JY9uR+s9zrcD+Ev37PGFgMK9KLjevwCDfsLqjwMeIMDf/y3Bz4p1IYxwhO+/5ADeqQ2kSO GU/z65nQ==;
Received: from 109-81-83-20.rct.o2.cz ([109.81.83.20]:55811 helo=[192.168.1.33]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96.2) (envelope-from <in@bobbriscoe.net>) id 1r0UVY-0004xI-2x; Tue, 07 Nov 2023 22:25:13 +0000
Message-ID: <4f905193-f6aa-42ee-8fbf-b0fcdc72f951@bobbriscoe.net>
Date: Tue, 07 Nov 2023 22:25:03 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-GB
To: "Dale R. Worley" <worley@ariadne.com>, draft-ietf-tsvwg-ecn-encap-guidelines.all@ietf.org, tsvwg@ietf.org, Gorry Fairhurst <gorry@erg.abdn.ac.uk>
References: <87lebipsl2.fsf@hobgoblin.ariadne.com>
From: Bob Briscoe <in@bobbriscoe.net>
In-Reply-To: <87lebipsl2.fsf@hobgoblin.ariadne.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-MagicSpam-TUUID: c8fe8dbf-bbf9-4765-a90c-911b3f6e2060
X-MagicSpam-SUUID: f2f9e2f7-2ada-495c-99e7-6df3ee9a6c4c
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu
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: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ei8DROG5BWInzJ-B2JB-GbzpXa4>
Subject: Re: [tsvwg] Improvements to figures of draft-ietf-tsvwg-ecn-encap-guidelines-20
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 07 Nov 2023 22:25:20 -0000

@Gorry, as doc shepherd and @John as co-author. Pls advise whether you 
agree with my proposed approach.

@Dale, see [BB]

On 31/10/2023 18:14, Dale R. Worley wrote:
> Looking at draft-ietf-tsvwg-ecn-encap-guidelines-20, it seems to me
> that the figures should be improved.  In particular, the following is
> an improvement to Figure 1.  The guide line at the top shows that I've
> out-dented the figure by 1 space, so it has a left margin of 3 like
> the body of the text.  The final "X" on the line shows the 72nd
> character of the line, which is the last allowed by RFC 7994 sec 4.3.
>
> 123....................................................................X
>
>                         _ _ _
>              /_______  | | |C|  ACK Packet (V)
>              \         |_|_|_|
>     +---+        layer: 2 3 4 header                              +---+
>     |  <|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Packet V <<<<<<<<<<<<<|<< |L4
>     |   |                         +-----+                         | ^ |
>     |   | . . . . . . Packet U. . | >>v>|>>> Packet U >>>>>>>>>>>>|>^ |L3
>     |   |     +---+     +---+     | ^ v |     +---+     +---+     | ^ |
>     |   |     |  *|>>>>>|>>>|>>>>>|>^ >>|>>>>>|>>>|>>>>>|>>>|>>>>>|>^ |L2
>     |___|_____|___|_____|___|_____|_____|_____|___|_____|___|_____|___|
>     source  ^       subnet A   ^  router     ^   subnet B         dest
>         __ _^_ _       __ _ _ _^   __^_ _    ^__ _ _ _
>        |  | | | |     |  | | |C|  |  | |C|   |  | |C|C|  Data________\
>        |__|_|_|_|     |__|_|_|_|  |__|_|_|   |__|_|_|_|  Packet (U)  /
>     layer: 4 3 2A         4 3 2A      4 3        4 3 2B
>     header
>
>                      Figure 1: Feed-Forward-and-Up Mode
>
> The changes are:  (1) It shows how "router" has set the C bit of the
> second L2 encapsulation, as specified by section 3.1:
>
>     The
>     router forwards the marked L3 header into subnet 2, and when it adds
>     a new L2 header it copies the L3 marking into the L2 header as well,
>     as shown by the 'C's in both layers (assuming the technology of
>     subnet 2 also supports explicit congestion marking).

[BB] You're right. But I've been in two minds about this. In both Figs 1 
& 2, I think showing the copying down to L2 in the RH subnet distracts 
from the main message of each Fig, by shifting the focus from the LH 
subnet. But you're right that just showing the signal at both layers in 
the packet diagram begs the question of why it's not shown by chevrons 
in the RH subnet as well.

As well as your suggestion, 2 other remedies are open to us:
1) illustrate cases where the subnet to the right uses a L2 protocol 
that does not support ECN (which is the common case anyway).
2) leave the figures as they are, but say in the text that chevrons 
showing the middle router copying signal down to and across L2 of subnet 
B (or F) are omitted for clarity - to focus on the essential path taken 
by the congestion signal.

Option 1 loses the benefit of pointing out that signals arriving at 
encap /can/ be copied to the outer (without making it the centre of 
attention). So I think I'll go for option 2.

But, first, I'll ask my co-author and the doc shepherd (Gorry) for 
second opinions.

more...

>
> (2) I've added marks to show where the four packets illustrated in the
> bottom row are taken from the packet flow.
>
> The parallel changes to figure 2 are:
>
>                         _ _ _
>              /_______  | | |C|  ACK packet (V)
>              \         |_|_|_|
>     +---+        layer: 2 3 4 header                              +---+
>     |  <|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Packet V <<<<<<<<<<<<<|<< |L4
>     |   |                         +-----+                         | ^ |
>     |   | . . .  >>>> Packet U >>>|>>>v>|>>> Packet U >>>>>>>>>>>>|>^ |L3
>     |   |     +--^+     +---+     |   v |     +---+     +---+     | ^ |
>     |   |     |  *|     |   |     |   >>|>>>>>|>>>|>>>>>|>>>|>>>>>|>^ |L2
>     |___|_____|___|_____|___|_____|_____|_____|___|_____|___|_____|___|
>     source  ^       subnet E   ^  router     ^   subnet F         dest
>         __ _^_ _       __ _ _ _^   __^_ _    ^__ _ _ _
>        |  | | | |     |  | |C| |  |  | |C|   |  | |C|C|  data________\
>        |__|_|_|_|     |__|_|_|_|  |__|_|_|   |__|_|_|_|  packet (U)  /
>     layer: 4 3 2E         4 3 2E      4 3        4 3 2F
>     header
>
> I've also changed the "layer header" labels from "2" to "2E" and "2F"
> corresponding to the subnet.

[BB] This is unequivocally an error on my part.

Thank you for pointing these issues out.


Bob

>
> Dale

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