Subject: RE: My BGP Route Update Pacing Draft

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Tue, 23 Jul 2002 10:43:55 -0400

Manav:

> -----Original Message-----
> From: Manav Bhatia [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2002 12:12 AM
> To: Abarbanel, Benjamin; [email-masked]
> Subject: Re: My BGP Route Update Pacing Draft
> 
> 
> Hi Ben,
> I have some thoughts on the draft.
> 
> The crux of your draft is that if a peer gets so congested 
> that it is not
> able to send any UPDATE/KEEPALIVE message to the remote 
> uncongested peer
> then the session can break down because of the Hold Timer 
> expiring and it
> can be prevented by sending some pacing information which 
> will inform the
> uncongested peer to limit its route advertisement rate. The PACING
> information will too be carried in the TCP packets, so if the TCP is
> implementing flow control and is not sending packets to avoid 
> congestion
> then how will the PACING information be sent? And if  TCP can send the
> PACING information then it can as well send the KEEPALIVE 
> packet which will
> keep the HoldTimer from expiring at the other end.
> 
The assumption is that pacing is keeping the congestion low enough by
throttling the rate at which the source peer is transmitting to the local
peer to be
able to send more pacing messages back to the source router. When the router
is totally congested, its too late and even pacing messages will fail to
reach back to the source router. You would say you can achieve the same
control of the incoming stream by artificially limiting the rate at which
you
read the BGP TCP session socket. The only difference between the two
mechanism is
one is conveyed end to end between the BGP peers (via pacing) the other is
done
indirectly via the TCP end points being controlled via the socket reads. I
think
the Pacing method allows one router to send more detail information about
its 
congestion state then a simple flow on/off condition that is provided via
TCP.
The pacing mechanism is more deterministic than the simple TCP flow control
mechanism
which consumes alot more memory resources when flow control is activated.
 
Maybe now we dont need such fancy capabilities, but tomorrow is another day.

> Secondly, if you are aware that your router is old and might come in a
> situation when it might not be able to handle the full feed 
> of BGP Updates
> from the remote end then it can negotiate a HoldTime of zero 
> and keep the
> session running even when it is in the congested state.
>

If you have a zero hold timer, you would have extended period of time where
routes are not current with topological states. The reason we use the hold 
timer is in the case that the remote peer is not talking without a session
disconnect.
This time period is the most a given timer will tolerate before recomputing
alternate
paths for that router's routes. I dont believe that setting this timer off
will
help an old congested peer. It will make the topology highly unstable and
cause
possible black holes via the unresponsive router.
 
> Thirdly, the very idea of artificially impeding reachability 
> information
> (or sending of BGP UPDATE messages) doesn't really appeal to me. I was
> initially against the idea of using MinRouteAdvertisementInternal etc
> timers in my implementation arguing that a router should pack off any
> reachability information it has as soon as it comes to know 
> of it. But this
> created a problem when i got say some 80K routes. I would 
> then be sending
> 80K packets to my other peers! Finally , better sense 
> prevailed on me and i
> started using the timers for efficiently packing my NLRIs in 
> the UPDATE
> messages. This is one point where i hold my reachability 
> information from
> my peers & I discourage it doing any other time. IMHO i feel 
> we should let
> TCP take care of withholding any data it wants with itself till the
> congestion state rides by rather than us interfering with it.
> 
> What happens say when an uncongested router receives pacing 
> information
> telling it to reduce the advertisement rate by some 70%. In 
> that case there
> will be many UPDATEs lying with it remaining to be yet 
> announced to the
> remote peer which is experiencing congestion. Now what if the 
> uncongested
> network receives withdrawals (both implicit and explicit) for certain
> prefixes which have already been announced or remain yet to 
> be announced?
> You open up a can of worms now !!
> 
> You have to now flush all your output buffers regardless of 
> the congestion
> state your remote peer lies in!
> 
> Thus you end up doing what you always wanted to avoid.
> 
> I think a cleaner and a much simpler approach would be to dynamically
> negotiate the value of the HoldTimer during the session. If 
> you feel you
> are getting congested then increase the value and once the 
> red flags are
> all down you can revert back to your original value or 
> decrease it back
> again.
> 
Changing the hold timer does not reduce the congestion imposed on the
current
router by its peers. It only extends the time it takes for the session to
disconnect.

My draft was not attempting to treat session disconnects as the main issue
but reduce congestion level on a given router.  

Ben

P.S. Since there is no interest in this draft I have withdrawn it from IETF.

> 
> 
> 
> 
> 
> ----- Original Message -----
> From: "Abarbanel, Benjamin" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, July 19, 2002 1:01 AM
> Subject: My BGP Route Update Pacing Draft
> 
> 
> | Hi all:
> |
> |    Our recent discussions on this list and my recent work
> |  experiences have led me to write this draft and offer it
> |  to the IETF community. I would appreciate any comments
> |  anyone has to make.
> |
> |  Thanks in advance,
> |  Ben
> |
> |
> |
> |
>

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 24 Jul 2002 08:42:34 +0530

Ben,

| > I think a cleaner and a much simpler approach would be to dynamically
| > negotiate the value of the HoldTimer during the session. If
| > you feel you
| > are getting congested then increase the value and once the
| > red flags are
| > all down you can revert back to your original value or
| > decrease it back
| > again.
| >
| Changing the hold timer does not reduce the congestion imposed on the
| current
| router by its peers. It only extends the time it takes for the session to
| disconnect.

which is exactly what i wanted to say .. you mentioned that the uncongested
peer is unable to receive KEEPALIVEs and UPDATEs from the remote end and it
brings down the session .. "The mistake is made by the uncongested peer
since it does not see any Keepalive/Update messages before its Hold timer
expires and drops the session thereby dropping all its associated routes."

I was merely suggesting an alternative to avoid this "mistake" by
dynamically suggesting a way to increase the time it takes to disconnect
the session.

Manav