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

[Adrian Farrel <[e-mail]>]

Thanks Martin,

> COMMENT:
>
> Thanks for this clear and well-written document.
>
> Thanks to Bob Briscoe for an especially thorough TSVART review!
>
> I have a few minor points from the Transport perspective:
>
> (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.

> (S1.4) "Egress node: The device (router) at with traffic" s/with/which?

Ack

> (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 last paragraph of (S5.1.1.4) is a sentence fragment.

Ack

> (S5.1.3.6) IPPM also designs measurement techniques and protocols to obtain
> those metrics. Probably worth mentioning?

Yes. Sure.

> (S5.1.3.8) As a transport AD, I had never heard of RFC3124. Perhaps I'm not
> working in the right cases, or maybe that's an indication that RFC3124 is no
> longer relevant. If the latter, I'd observe that the main lessons of that work
> ended up in HTTP/2 and later, directly in the transport in QUIC, in the way
> that they consolidate streams under a single connection and congestion control
> context.
>
> RFC3124 also references TCP control block interdependence (RFC2140, since
> replaced by RFC9040), which IIUC is very much alive. So maybe the right
> references for this concept are 9000, 9040, and 9113?

Happy to be educated on this.
The reference to 3124 comes from 3272, and no one knew any better to update it.
It sounds as those the concepts of 3124 are not obsolete (even if some of the referenced material has moved on). 
Indeed, saying that the lessons ended up in HTTP/2 and QUIC sounds like it is actually a good base reference, but that more attention needs to be given to HTTP/2 and QUIC.
I'll rework this short section to use those newer references.

> (S7) "Layer 4 multipath transport protocols are designed to move traffic
> between domains and to allow control of the selection of the paths."
>
> Pedantically, it only allows control of the source and destination IP
> addresses. It cannot force any path through the network.

I'm strongly in agreement with you, although we might not get full agreement everywhere (for example, in PANRG).
But I think the point is that by selecting the entry and exit points to a domain, you do have *some* influence on the selection of paths. I meant, it is called multi-path because there are multiple paths and you are fiddling around with which one will be used.
So, I'll soften "control" to "some influence".

Many thanks for the review and any further hints you can offer.

Cheers,
Adrian