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
