Re: [Idr] BGP Message level ACKs

[Robert Raszuk <[e-mail]>]

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
>>>>
>>>