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

[Bob Briscoe <[e-mail]>]

Dale, Gorry, John, See [BB2]

On 07/11/2023 22:25, Bob Briscoe wrote:
> @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.

[BB2] In the absence of any immediate response, I've decided to take a 
middle line and use your illustration in Figure 2, but in Figure 1, I've 
changed the scenario so that the L2 protocol in the RH subnet does not 
support ECN. Then the reader is not distracted into the copying down the 
layers aspect until after they've got the main messages about the 
difference between feed-forward-and-up vs feed-up-and-forward. It also 
doesn't require the figure to be wider.

Also, rather than adding more carets to show where the little 
illustrations of packets apply to, I've used vertical bars and shifted 
the row of illustrations so that they are all at the front of the frame. 
This was preferable to adding pointing arrows to a diagram where (lots 
of) arrows are used already, but only to express motion.

You can find the diff in the updated draft:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-tsvwg-ecn-encap-guidelines-20&url2=draft-ietf-tsvwg-ecn-encap-guidelines-21&difftype=--html
There's no implication that this is a fait accomplis - I can always 
update it if we agree.

The diffs for each Area review are in the commit history:
https://github.com/bbriscoe/ecn-encap/commits/master/draft-ietf-tsvwg-ecn-encap-guidelines.xml


Bob


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