Re: [pim] Q on the congestion awareness of routing protocols

[Masataka Ohta <[e-mail]>]

Dear Michael;

> I’m actually fascinated by this idea of the TCP mesh that you keep
> pointing at (I have an interest in doing congestion control
> recursively, where one could automatically attain benefits from
> carrying out control closer to where problems happen, and also
> benefit from aggregation).  Would you have a pointer to some material
> on this? A thesis, a paper, something?

For hierarchical QoS routing, first, we need something like QOSPF
but with real (256 levels, though 20 should be more than enough)
hierarchy, for which we developed HQLIP

	https://www.ietf.org/archive/id/draft-ohta-ric-hqlip-00.txt

avoiding unnecessary complexity of link local reliable multicast
by TCP mesh.

Though the protocol is, academically, just boring, there
is a research paper to use HQLIP for automatic renumbering
of not only hosts but also routers with DNS update.

	https://search.ieice.org/bin/summary.php?id=e99-d_6_1553

Then, QoS/multicast signaling protocol SRSVP, which also use TCP
mesh, was developed, which is briefly explained in:

	https://datatracker.ietf.org/doc/html/draft-fujikawa-ric-srsvp-01

> I have a question. You keep saying that you use a TCP connection for
> every link. That seems odd, because, if that’s all it is, then
> congestion control doesn’t really do much… for CC to do something
> meaningful, it needs MUXing to happen at intermediate systems,

Ethernet switches are such MUXing intermediate systems.

						Masataka Ohta