[Csci551-talk] BGP KEEPALIVEs

ramesh sarangarajan sarangar@usc.edu
Mon, 10 Mar 2003 16:47:17 -0800


The following text is from RFC 1122 page 100:
-------------<Quote>----------------

4.2.3.6  TCP Keep-Alives

            Implementors MAY include "keep-alives" in their TCP
            implementations, although this practice is not universally
            accepted.  If keep-alives are included, the application MUST
            be able to turn them on or off for each TCP connection, and
            they MUST default to off.

            Keep-alive packets MUST only be sent when no data or
            acknowledgement packets have been received for the
            connection within an interval.  This interval MUST be
            configurable and MUST default to no less than two hours.

            It is extremely important to remember that ACK segments that
            contain no data are not reliably transmitted by TCP.
            Consequently, if a keep-alive mechanism is implemented it
            MUST NOT interpret failure to respond to any specific probe
            as a dead connection.

            An implementation SHOULD send a keep-alive segment with no
            data; however, it MAY be configurable to send a keep-alive
            segment containing one garbage octet, for compatibility with
            erroneous TCP implementations.

---------------<Unquote>----------------

Seems that TCP specification does not include keep-alives, yet the implementors
chose to have keep-alive timers as an OPTION.

So, it seems that BGP folks chose to have their own keep-alives because they
could not rely on a common yet not standard option in TCP implementations.

-Ramesh

----- Original Message -----
From: Omprakash Gnawali <gnawali@usc.edu>
Date: Monday, March 10, 2003 3:25 pm
Subject: Re: [Csci551-talk] BGP KEEPALIVEs

> 
> I think the TCP socket is implemented such that you might not learn
> about dead flows until you try to read/write from them. This might be
> related to this thread of discussion.
> 
> you wrote:
> > AFAIK, TCP sockets (and hence the flows) are associated one-on-one with
> > processes running on the machines. So, if the BGP process has crashed, 
> how ca
> *n
> > TCP flow remain alive? In other words, without the process feeding the flow,
> > would the flow be any longer alive?
> > 
> > Correct me, if I'm wrong.
> > 
> > -Ramesh
> > 
> > ----- Original Message -----
> > From: Rohit Mordani <mordani@aludra.usc.edu>
> > Date: Monday, March 10, 2003 2:25 pm
> > Subject: Re: [Csci551-talk] BGP KEEPALIVEs
> > 
> > > The BGP has to have KEEPALIVE since only the TCP flow may be alive but the
> > > BGP process that is running may have been terminated or crashed....thus
> > > the end to end problem....The BGP runs above the TCP and it too has to
> > > have KEEPALIVE msgs.
> > > rohit
> > > 
> > > On Mon, 10 Mar 2003, ramesh sarangarajan wrote:
> > > 
> > > > Why don't BGP use the underlying transport layer's KEEPALIVE mechanism?
> > > >
> > > > I remember us agreeing (during the corresponding lecture session) that
> > > > it is an application of E2E argument. But isn't tranport layer too E2E?
> > > >
> > > > If you agree with this, then is the right answer - BGP uses its own
> > > > KEEPALIVE mechanism to avoid depending on a particular transport layer
> > > > (in this case TCP) so that it can also be run on a different transport
> > > > layer which does not have keepalives?
> > > >
> > > > -Ramesh
> > > >
> > > >
> > > 
> > > 	---- R O H I T   M O R D A N I ----
> > >                 rohit.mordani.com
> > >            rohit.mordani.com/photoshop
> > > 
> > > 
>