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

[Michael Welzl <[e-mail]>]

Dear Masataka,

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?

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, in between the sender and receiver. Else, all one gets from TCP is reliability (is this a benefit here?) and flow control - and then, when too many packets arrive at a node at the same time, the app-layer - TCP buffer will become very large. This means that one would need congestion control again - now operating over TCP input buffers instead of network layer buffers. Hence, recursive  ;-)

IMHO, if that “TCP mesh" would use a TCP endpoint (hm, perhaps without reliability: rather, something like DCCP… and yes maybe MP too… MP-DCCP now exists   :)  ) at *every other* router, or some such deployment scheme, things could get quite interesting… one might still need some form of congestion control on the top though…

Cheers,
Michael



> On 6 Dec 2022, at 08:50, Masataka Ohta <[e-mail]> wrote:
> 
> Dino Farinacci wrote:
> 
>>> I would use multipath quic rather than tcp. And for bier CTL, we
>>> want a fine hoppy protocol like PGMcc
> 
>> Just one point about TCP vs multicast. You *can* get more paralellism
> > from multicast where TCP from one central point (like a iBGP route
> > reflector) will cause serialization delays.
> 
> TCP, here, means TCP mesh within a link with full parallelism
> without central point, which shouldn't cause scalability
> problems as long as CATENET model is followed.
> 
> Even for iBGP, the amount of received data by multicast is
> no different from TCP mesh, unless intermediate routers
> merge data using application layer knowledge, which is
> layer violation causing various problems.
> 
> As such, if iBGP by TCP mesh without reflectors
> is not acceptable, iBGP by multicast without merger
> is not acceptable.
> 
> Worse,
> 
>> One could argue you get
>> this with multicast by just moving the problem to the router that is
>> replicating packets across an internal-crossbar switch or fabric. But
>> you can imagine this is done by orders of magnitude less serializtion
>> time.
> 
> merging by routers needs orders of magnitude more time.
> 
> 						Masataka Ohta
>