Re: [Teas] Martin Duke's No Objection on draft-ietf-teas-rfc3272bis-26: (with COMMENT)

[Adrian Farrel <[e-mail]>]

OK. I get it. Thanks.

I can finesse some words around both of these.

 

Cheers,

Adrian

 

From: Martin Duke <[e-mail]> 
Sent: 10 August 2023 00:13
To: [e-mail]
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Martin Duke's No Objection on draft-ietf-teas-rfc3272bis-26: (with COMMENT)

 

Hi Adrian,

 

On Wed, Aug 9, 2023 at 3:54 PM Adrian Farrel <[e-mail] <mailto:[e-mail]> > wrote:

Thanks Martin,

 

<snip>

 

>
> (S1.4) Unless this is a well-understood alternate meaning of the term in the TE
> community, might I suggest "congestion response" instead of "congestion
> control"? It is both more descriptive and does not overload a very important
> concept in Layer 4.

I need to be guided by you on this (I don't have enough layer 4 clue).
We took the terminology from RFC 3272 and from [YARE95] (http://www.cs.uccs.edu/~xzhou/teaching/CS522/Projects/Taxonomy_Network1995.pdf) and I think, on re-reading that reference, you are right.
That is, "congestion control" is everything from cautionary, through predictive, to reactive. But the definition you have pointed to in the I-D is only responsive.
That said, it looks to me that the usage in the document (easy to find by searching for "congestion control") is a bit sloppy. Sometimes it seems to be scoped to "congestion response" and sometimes to "congestion control" in the wider sense.
It seems to me that the full congestion control should be an objective of TE. That is, it should place traffic to avoid congestion, and it should move traffic around in response to congestion.
If this seems reasonable, my suggestion would be:
- to define both terms
- to sort out the document to say "congestion response" when that is what it is talking about, but to leave "congestion control" when the broader scope is meant.

 

I think we agree on "congestion avoidance" and "congestion response" and that this other thing (congestion control?) is more or less the union of the two.

 

If it were me, I'd just say "congestion avoidance and response" when I meant both, because "congestion control" is an overloaded term with a bunch of baggage. But I'm not going to micromanage your editorial process, and if you define your terms you can pretty much do whatever you want.

 

<snip>

 

> (S2.4.1) s/if the router supports ECN/if the router and end host support ECN

The full quote is:
          On the
          other hand, if the router supports ECN, it can set the ECN
          field in the packet header.

So, clearly this would be not a lot of help unless the end host also supports ECN. But isn't it the case that the router doesn't know/care about this when it flags ECN in the packet?
So perhaps,
          On the
          other hand, if the router supports ECN, it can set the ECN
          field in the packet header, and the end host can act on this
          information if it support ECN.
?

 

The way this works is, an ECN-compliant host marks the two ECN bits with either ECT(0) (0b10) or (experimentally) ECT(1) (0b01), which tells the router to use one of two techniques to decide when to "mark" the packet with CE (0b11). If the field is Not-ECT (0b00), the host is saying it's not ECN-compliant and the router definitely should not mark. So the router does know and definitely needs to care -- if the host isn't going to do anything with the signal, the packet needs to be dropped instead of marked.

 

Martin