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

[Masataka Ohta <[e-mail]>]

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