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

[Martin Duke <[e-mail]>]

Hi Adrian,

On Wed, Aug 9, 2023 at 3:54 PM Adrian Farrel <[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