Re: [Idr] Questions over draft-retana-idr-bgp-quic-01

[Claudio Jeker <[e-mail]>]

On Mon, Mar 20, 2023 at 01:15:55AM -0400, Gyan Mishra wrote:
>  BGP app could also benefit from QUIC transport in dealing with the TCP
> zero window BGP peer stuck state?

No it can't. QUIC has the same issue. Every reliable transport protocol
has this issue. It comes from the fact that there are no infinite
resources and that the receiver can stop consuming data.
In QUIC this is controlled by MAX_DATA and MAX_STREAM_DATA. It is a bit
easier to recover from it since control packets are still able to flow but
the fundamental issue is still around, needs to be detected and handled.

QUIC solves different issues mainly around reduction of roundtrips to
establish a connection (it does TLS handshake and SYN/ACK in one) and
adjustments to congestion control. BGP does not really benefit from either
of the two. I actually argure that the TLS requirement of QUIC is a deal
breaker for a protocol that needs to be cold start capable.

> Good APNIC blog
> https://blog.apnic.net/2022/11/03/comparing-tcp-and-quic/
> 
> The blog talks about the advantages that QUIC has over TCP transport and
> how it overcomes many inherent pitfalls of TCP.  Definitely a massive lift
> for vendors and operators to shift.  A seamless migration strategy would be
> key on how to shift from TCP to QUIC transport.
> 
> As BGP has become the defacto standard in DC space with BGP Only DC RFC
> 7938, I think it makes sense to look at possible future alternatives for a
> transport for BGP which still could be years down the road before any
> transition happens as has been with forklift changes for example with
> transition from IPv4 to IPv6 it’s been over 20 years and we have gone a
> long ways but the IPv6 application traffic across the internet is  pretty
> low adoption rate but has been now been steadily climbing.
> 
> Kind Regards
> 
> Gyan
> 
> 
> On Wed, Mar 15, 2023 at 5:07 PM Robert Raszuk <[e-mail]> wrote:
> 
> > Claudio,
> >
> > To me the fundamental benefit is departure from keeping TCP sessions up
> > for days, months, years and transition to transaction based route
> > exchange model. And getting rid of issues associated with keeping such TCP
> > sessions in UP state.
> >
> > But point taken - maybe we should not call it a BGP-4 new transport but
> > simply fork BGP-4 to BGP-Q and work on it independently. Maybe even outside
> > of IDR ...
> >
> > Multisessions has been tried .. it was even shipping for a while, but a
> > number of issues associated with it triggered removal of it from some code
> > basis.
> >
> > Dynamic capabilities also has been tried .. even in limited critical
> > subset - and it is nowhere.
> >
> > We should learn from the compute world and move to a transactional based
> > database exchange model for Internet and services routing  instead of
> > keeping the circuit switching pipe paradigm in BGP forever.
> >
> > Best,
> > R.
> >
> > PS. Note that sessions do go down when not desired ,,, and instead of
> > triggering route removal some people went and standardized long lived GR to
> > keep it irrespective of TCP session state.
> >
> >
> >
> > On Wed, Mar 15, 2023 at 6:04 PM Claudio Jeker <[e-mail]>
> > wrote:
> >
> >> On Mon, Mar 13, 2023 at 05:01:12PM -0700, Yingzhen Qu wrote:
> >> > As Alvaro mentioned, we're still at the very early stage of this
> >> project,
> >> > and there is still a lot of work to be done. One of the key areas we're
> >> > focusing on is exploring the benefits and challenges of using BGP over
> >> QUIC.
> >> >
> >> > There are several advantages of using QUIC for BGP, including its
> >> ability
> >> > to support multiple streams over a single connection. This allows one
> >> > stream to be reset without impacting other streams. Additionally, the
> >> > stream prioritization feature of QUIC can help us manage traffic more
> >> > effectively, ensuring that high-priority BGP traffic is given the
> >> resources
> >> > it needs to be transmitted quickly and reliably.
> >>
> >> So your reason for QUIC is multi session support but that is not a problem
> >> of the transport layer (TCP vs QUIC) but is a problem of BGP RFC4271 OPEN
> >> handling and would require an extension like
> >> draft-ietf-idr-bgp-multisession.
> >>
> >> Also I doubt that stream priorization is able to improve priorization of
> >> individual BGP messages. It is anyway mostly a non issue since most BGP
> >> sessions run on short-fat pipes so there is little queuing required.
> >>
> >> > However, there are also some challenges to consider when using BGP over
> >> > QUIC. For example, since TLS 1.3 is integrated into QUIC, this improves
> >> > security and also makes it more difficult for network administrators to
> >> > monitor and troubleshoot network traffic. Additionally, the complex
> >> nature
> >> > of the protocol could require more resources to maintain and debug.
> >>
> >> QUIC makes it impossible to cold start a network. Depending on TLS 1.3
> >> requires a working clock, DNS and global network to work properly.
> >> Also admins need to keep all their certificates valid. Looking at RPKI and
> >> the state of RRDP servers it is obvious that many admins are unable to
> >> ensure this.
> >>
> >> > Despite these challenges, we believe that the benefits of using BGP over
> >> > QUIC are significant enough. While we acknowledge that there is still a
> >> lot
> >> > of work to be done, we'd like the community to be aware of this work and
> >> > get interested, and send questions and comments.
> >>
> >> I really see no need for BGP over QUIC. It does not offer any benefits
> >> over TCP since all the features are ready availabe in TCP. The problem is
> >> the BGP protocol on top of those transports.
> >>
> >> I see a lot of challenges and very minimal benefit for the cost required
> >> to implement QUIC as transport solution.
> >>
> >> --
> >> :wq Claudio
> >>
> >> > On Mon, Mar 13, 2023 at 3:19 PM Alvaro Retana <
> >> [e-mail]>
> >> > wrote:
> >> >
> >> > > On March 13, 2023 at 12:56:48 PM, Jared Mauch wrote:
> >> > >
> >> > >
> >> > > Hi!
> >> > >
> >> > >
> >> > > ...
> >> > > > I have my own concerns about the lack of stability within QUIC
> >> standards
> >> > > here
> >> > > > as well. We often see TCP sessions up for several years carrying BGP
> >> > > data,
> >> > > > and most of the QUIC stuff is extremely short lived, while a 7
> >> year+ TCP
> >> > > > (BGP) session isn’t as unusual as one might think.
> >> > >
> >> > > Yes, this is definitely new territory!
> >> > >
> >> > > The QUIC experts tell us they don't see an obvious red flag, but we do
> >> > > need to keep in mind that the initial QUIC use case is HTTP/3 -- as
> >> you
> >> > > mention.  There are some features, like 0-RTT data exchange, that may
> >> not
> >> > > be applicable to a long-lived session like BGP.
> >> > >
> >> > > Any potential transition will not be overnight. ;-)
> >> > >
> >> > >
> >> > > Alvaro.
> >> > > _______________________________________________
> >> > > Idr mailing list
> >> > > [e-mail]
> >> > > https://www.ietf.org/mailman/listinfo/idr
> >> > >
> >>
> >> > _______________________________________________
> >> > Idr mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/idr
> >>
> >> _______________________________________________
> >> Idr mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/idr
> >>
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/idr
> >
> -- 
> 
> <http://www.verizon.com/>
> 
> *Gyan Mishra*
> 
> *Network Solutions A**rchitect *
> 
> *Email [e-mail] <[e-mail]>*
> 
> 
> 
> *M 301 502-1347*

-- 
:wq Claudio