Re: [Idr] Fwd: New Version Notification for draft-spaghetti-idr-bgp-sendholdtimer-05.txt

[Jeffrey Haas <[e-mail]>]

[Speaking as a BGP implementor.]

On Wed, Aug 03, 2022 at 02:28:26PM +0200, Job Snijders wrote:
> On Wed, Aug 03, 2022 at 11:42:53AM +0200, Robert Raszuk wrote:
> > So I am asking what exactly is the trigger to fire that timer when BGP
> > can not write to a TCP socket ? Is it Error 105: No buffer space
> > available ? Something else ?
> 
> Something else! A POSIX.1 function like send() normally *blocks* if no
> message space is available at the socket to hold the message to be
> transmitted. To prevent blocking the whole process, a developer
> generally will construct async loops using the select(2) or poll(2)
> system calls to determine when it is possible to send more data. As such
> it is fairly straight forward to set up (and reset) a timer event in the
> implementation's BGP FSM that aligns with whether data could be
> transmitted to the peer or not.

The above touches on some of the implementation considerations of this
feature.  It also helps to illustrate that coming up with normative text for
the draft will be challenging.


The underlying conditions we want from my perspective are:
- We have detected we are unable to write further data to the TCP connection
  and have more data to send.  Certainly EWOULDBLOCK would be a common
  example.  How about EAGAIN?  Depends on the stack.  Other conditions such as
  ENOBUFS, EINTR, ENOMEM, ENOSPC lead to questions as to whether this is a
  useful POSIX indication that you can't write vs. you can't write because TCP
  is not progressing.

  Once we figure out we have written and we can't write further (for the
  above vague definition), setting the sendholdtimer would be appropriate.
- That said, if the TCP session starts draining and data starts moving, and
  we become able to write, the timer should be canceled.  
 
  + How does that manifest vs. kevent/select/poll/etc.?

If your stack has the easy ability for the BGP stack to take a peek into the
TCP state and tell that this ties to zero-windowing, great!  It removes an
awful lot of ambiguities for that specific case.

There are a number of other messier edge cases where you're not at a zero
window, but still can't write to the socket.  Basically any case where you
can't write pending data to the socket for the sendholdtimer interval is
probably a Good Enough condition.


-- Jeff