Re: [Idr] BGP Message level ACKs

[Alejandro Acosta <[e-mail]>]

Hello, it can be also added as a new BGP Capability


On 9/3/23 11:58 AM, Robert Raszuk wrote:
>
> Well it can not be put in KEEPALIVE thread as by definition it would 
> be event triggered not periodic. So hardly would fit that thread.
>
> Cheers,
> R.
>
> On Thu, Mar 9, 2023 at 4:54 PM Tony Przygienda <[e-mail]> 
> wrote:
>
>     aha, ok, yeah, and that problem is real as we know ... you should
>     have mentioned it.
>
>     yes, anything that reflects a token will do fine here ... unless
>     developers optimize and put that processing into the same bgp
>     keepalive thread. Then we are where we started  ;-)
>
>     -- tony
>
>
>     On Thu, Mar 9, 2023 at 4:48 PM Robert Raszuk <[e-mail]>
>     wrote:
>
>         Tony,
>
>         > But I lost track frankly WHAT we're solving here with this
>         ACK you suggest ...
>
>         The reported problem is:
>
>         "The remote peer is not reading my BGP messages while TCP
>         works fine."
>
>         So if a remote peer can ACK that it got messages I send to it
>         (last 10 or last 100 etc ..) it solves the problem as defined.
>         In fact it solves it better then current proposal of using
>         single side socket buffer full timer.
>
>         I should have not thrown into this UDP as it changes the
>         objective - from informational nice to have ACK to something
>         much more complicated to provide transport reliability. That
>         was not the original aim.
>
>         Best,
>         R.
>
>         PS. If you like lets talk more about it face to face :)
>
>
>
>
>
>
>         On Thu, Mar 9, 2023 at 4:36 PM Tony Przygienda
>         <[e-mail]> wrote:
>
>             simple update message "counter" does not change much of
>             anything really since the sender has to keep this
>             "counter" on the NLRI at which an update was sent to
>             understand which prefixes have been processed by the peer.
>             and all very amusing if you start to overlap with newer
>             updates containing the newer version of the same prefix.
>             Unless you think of "keeping all the updates stored on the
>             outbound until they 'acked" which would be a fantastic
>             attack vector by intentional or unintentional slow peers +
>             double with the TCP buffering already. With the
>             interesting stuff on top of when you give up on the peer
>             if it doesn't ACK in timely manner/at all ...
>
>             So, if you want to know what the peer on the other side
>             "processed" you will have no other choice but keep per
>             NLRI _something_ and possibly per peer (as I explained
>             with lots cleverness you can get away without per peer
>             possibly). Unless we're talking unreliable transport under
>             BGP which as I said seems to be solving wrong problems in
>             wrong layers. But I lost track frankly WHAT we're solving
>             here with this ACK you suggest ...
>
>             I still don't understand what "application consuymed the
>             data" _really_ means in terms of assurances the remote
>             system is giving you in terms of forwarding
>             behavior/convergence with other peers/whatever and hence
>             this "assurance" seems to be to have no semantics.
>
>             So, I chime out. Either this all has no real semantics and
>             possibly conflates multiple issues together or I don't
>             grok what it's all about.
>
>             motivation for having seq# on enhanced GR draft I get. we
>             do mark/sweeping kind of thingies on session re-establish
>             (which GR really is) and we have to sync up on versions of
>             state held (as optimization vs. re-sending e'thing). And
>             having the other side "confirming" really means
>             somethjing, namely FIB/RIB is programmed to this version
>             so no updates are needed. It's kind of simplified version
>             of the refresh-options (since it basically assumes there
>             is no GR-over-GR or endless updating on sender that makes
>             the process never stop?) but it burns basically 8 bits per
>             NLRI as well (assuming most likely there is never more
>             than one peer GR'ing either or maybe just one version for
>             all peers work, I didn't think that through yet). But
>             yeah, no free lunch ...
>
>             --- tony
>
>             On Thu, Mar 9, 2023 at 9:48 AM Robert Raszuk
>             <[e-mail]> wrote:
>
>                 Tony,
>
>                 I think you are looking at this in a different way.
>
>                 So what you are likely considering is a very fine and
>                 detailed sequence number like approach. That's a lot
>                 of work indeed to accommodate it into current BGP
>                 outbound code - with tons of optimizations.
>
>                 I on the other hand was just thinking of reusing
>                 simple UPDATE message counter per peer. Some (I would
>                 say most) implementations I think have it already.
>
>                 The only sort of open issue is to synchronize the
>                 counters or at least clocks. Alternative would be to
>                 inject periodically a sequenced BGP MARKER message to
>                 tag local counter with remote counter and have the
>                 ACKs being MARKER triggered. Quite popular solution in
>                 completely asynchronous systems :)
>
>                 So to spec this out should be pretty straightforward.
>                 But again this email is to just probe the topic not
>                 volunteer to do it.
>
>                 Many thx,
>                 Robert.
>
>
>                 On Thu, Mar 9, 2023 at 8:45 AM Tony Przygienda
>                 <[e-mail]> wrote:
>
>                     The problem is on the sender side. it has to keep
>                     track of whether an update has been ack'ed by a
>                     peer and that's in simple terms per peer per NLRI
>                     (modulo group discussion as usual). It can be
>                     tricked into per NLRI only but since NLRIs get
>                     packed differently, in different sequence towards
>                     different peers a high scale implementation will
>                     end up with at least per prefix. This is _very_
>                     expensive, particularly memory wise. Tricks can be
>                     played with rollovers like in
>                     https://datatracker.ietf.org/doc/draft-idr-bgp-route-refresh-options/
>                     but the logic isn't simple by any means and
>                     ultimately any solution may force implementations
>                     into structures to support this that are very
>                     inefficient for other parts of the implementation.
>
>                     Generally, shoving reliability of the transport
>                     into BGP is basically solving the wrong problem at
>                     the wrong layer just like shortcutting BGP to run
>                     on a user transport protocol brought nothing but
>                     lots of technical debt grief over the years.  Real
>                     problem is lack of control session layer that
>                     realizes underneath that transport went away and
>                     notifies up and/or allows transport for the
>                     session to come up again. It's only when a new
>                     session needs be established AFAIS that we need
>                     state sync which lands us in possibly GR corners
>                     or refresh corners again rather than trying to
>                     reinvent TCP on top of UDP in BGP by ACKs (I
>                     wonder when the first window size proposal starts
>                     to come in ;-)
>
>                     -- tony
>
>                     On Wed, Mar 8, 2023 at 11:52 PM Robert Raszuk
>                     <[e-mail]> wrote:
>
>                         Hi Jeff,
>
>                             A fundamental challenge for bgp
>                             implementations is efficiently keeping
>                             versioning across peer-groups.*  Some
>                             implementations are friendlier to that
>                             idea than others, but the inconsistency in
>                             the ability to do that is one of the
>                             things that prevented this idea from
>                             progressing.
>
>
>                         I did not mean that it should touch update
>                         generation and replication. The ACKs which I
>                         had in mind would be operating way above this
>                         and simply periodically indicate to the sender
>                         that last N number of UPDATE messages got
>                         received by remote BGP process.
>
>                         N-being configured and possibly negotiated on
>                         the session bootstrap.
>
>                         Critical part of this is the time scale. If we
>                         are talking about the last 10 min or last 20
>                         min this would not be sufficient for helping
>                         to achieve reliable transport, but could be
>                         IMO more than sufficient to make sure UPDATE
>                         got to remote BGP I/O.
>
>                         So I am not sure if this is real distraction
>                         to the topic. I would rather call it
>                         exploration of alternative approaches. Just
>                         like punting the "issue" to telemetry ...
>                         avoiding need for any BGP code or FSM state
>                         machine change needed.
>
>                         Many thx,
>                         R.
>
>                         _______________________________________________
>                         Idr mailing list
>                         [e-mail]
>                         https://www.ietf.org/mailman/listinfo/idr
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr