Hi Toerless, Some late comments - first specifically on the PIM topic and then extend to the general point of congestion aware routing protocols.
The TCP-based PIM protocol RFC6559 was designed to handle the congestion-on-scale problem. However, most PIM deployments have not come to the point where scaling become a acute problem where RFC6559 solution must be used, so its deployment has been limited. The congestion-on-scale point was also taken when BGP-MVPN (RFC 6514) was developed. The Rosen/PIM-MVPN was very popular and there was a big debate when BGP-MVPN was proposed. Good that it eventually got standardized and became mainstream (at least for new deployments). Someone already brought up a point of BGP updates being potentially slow. I've also heard about that many times (sometimes from known BGP experts), including when I work on BGP based multicast (beyond RFC 6559). However, there are also protocols that rely on fast convergence even though they use BGP. EVPN is one example. Then mobile network's control plane relies on UDP-based GTP-C. I wonder why they're not concerned with congestion in scaled situations. For some 5G use cases I was proposing to use BGP to propagate routing information in place of some mobile user session information, and I often get asked "can you do that very fast"? So, I am struggling with these two things: - TCP-based solutions reduce protocol messages, but BGP may be deemed slow (or should I say with uncontrolled delay), though BGP-based EVPN actually relies on fast exchange of (at least some) BGP routes (e.g., for DF election). - Other solutions may lead to lots of protocol messages including refreshes, but the mobile operators seem to have been fine with UDP-based control plane. As for the "a totally non-congestion aware sending of protocol packets should not be permitted anymore for new RFC IMHO and i am just baffled how this is permitted anymore by the IETF. Where is adult supervision by TSV when we need it" comment below, I have the following view: - I am not sure if this involves TSV. A protocol sending lots of protocol packets is no different from an application sending lots of application traffic as far as transport is concerned. It is ultimately an issue with protocol design itself. - There are situations where a non-TCP based solution is needed even when a parallel TCP-based option is also present, so we can not simply disallow the former. We can discuss examples separately (one example is actually PIM as BIER overlay vs mLDP/BGP as BIER overlay). Thanks. Jeffrey Juniper Business Use Only -----Original Message----- From: pim <[email protected]> On Behalf Of Toerless Eckert Sent: Friday, December 9, 2022 8:47 AM To: Jon Crowcroft <[email protected]> Cc: BIER WG <[email protected]>; [email protected]; Matt Mathis <[email protected]>; [email protected]; Stewart Bryant <[email protected]>; pim <[email protected]> Subject: Re: [pim] Q on the congestion awareness of routing protocols [External Email. Be cautious of content] On Tue, Dec 06, 2022 at 07:15:31AM +0000, Jon Crowcroft wrote: > path exploration? but consider the shadow pricing... > > the tradeoff between convergence rate and congestion control seems to > be something that ought to be put on a more systematic grounding You folks are all thinking way beyond the point i was making and looking for support: In PIM, we have potentially gigantic burst of datagrams without any specification of pacing sent to routers across a network core (with easily likelyhood of path congestion). Such a totally non-congestion aware sending of protocol packets should not be permitted anymore for new RFC IMHO and i am just baffled how this is permitted anymore by the IETF. Where is adult supervision by TSV when we need it ;-) Yes, the incast issue is an interesting aspect, but i have not seen good simulations whether / to-what-extend it would happen in the PIM/BGP cases, but i would bet any sum, that a TCP solution, as bad as it may be will outperform the no-congestion-control periodic burst solution of (datagram) PIM. Cheers Toerless _______________________________________________ pim mailing list [email protected] https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!ASlubqGLmV8O43aB2Lcffy5JQ7FN49DnrotemtmPtVIat4Zubv-4DnJEjmh7o_4QoUn9BRIsoiEJuQ$
