Subject: RE: My BGP Route Update Pacing Draft

From: "Tsillas, Jim" <[email-masked]>
Date: Wed, 24 Jul 2002 10:37:03 -0400

Manav,

the real challenge for an implementation is to be both efficient
in terms of building updates and policy processing but at the same
time to be accomodating of slow peers. If all peers ran at the
same speed, an implementation could theoretically build a single
update and retransmit this update to all the peers (I'm ignoring
alot of detail here). With the above (efficient approach) when a
single peer slows down enough to make TCP flow control, all update
sending must wait on that slow peer. The alternative approach is
to independently update all peers at their given rate: this has
the drawback that potentially for every peer the update must be
rebuilt for sending. A hybrid approach could use some local buffering
(above the TCP buffering) to accomodate slow peers to some extent
and (most of the time) allowing reuse of that update buffer.
Another complicating aspect is that peers can often be grouped
so that their out-policy is reused - it is beneficial to reuse
updates for these groups.

Seems like a topic ripe for some modelling.

-Jim.

-----Original Message-----
From: Dennis Ferguson [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 6:36 PM
To: Manav Bhatia
Cc: Mareline Sheldon; [email-masked]
Subject: Re: My BGP Route Update Pacing Draft 

Hello,

> If you have some UPDATEs to announce and if you are holding them back
> because of the congestion you perceive in the network and then if you
> recieve a WITHDRAW for one of those same prefixes then you have to first
> advertise the UPDATEs because it is invalid to announce the same address
> prefix in the WITHDRAWN routes and the NLRI field of an UPDATE message.
You
> thus end up flushing all the BGP UPDATEs you had piled up waiting for the
> congestion to clear out at your remote end.

Why would you do this?  If you receive a withdrawal for a route for which
you haven't sent an UPDATE yet, why wouldn't you forget about the UPDATE
and just send the withdrawal (or, if you've never advertised the route
to the peer, just send nothing at all)?  If a route is flapping and
goes up and down 62 times while your peer has you flow controlled, would
you really send the 62 flaps when the peer allows you to send again?  Why
wouldn't you just send the final result?

You need to do routing protocol implementations in a way which avoids
unbounded state, and doing this means that you shouldn't be recording
all route transitions to play back to a peer which isn't listening at
the moment.  If the only state you keep is what you advertised to the
peer before and what the state of the route is now, then the amount
of state you need to keep remains proportional to the number of routes
you have and you only need to advertise the current state (if it doesn't
match what the peer already knows, otherwise you send nothing) when
the peer starts taking updates again.

> The better solution is to let
> TCP take care of the congestion internally as it has always been

I don't think this has much to do with TCP, TCP flow control works
the same way.

Dennis Ferguson

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 24 Jul 2002 20:13:30 +0530

Jim,
All that i'm trying to say is that we don't need to put in any extra
features into BGP (atleast not as of now!) to achieve what all you
mentioned down below. Encompassing a slow peer will be automatically taken
care of by TCP.

- Manav
|
| the real challenge for an implementation is to be both efficient
| in terms of building updates and policy processing but at the same
| time to be accomodating of slow peers. If all peers ran at the
| same speed, an implementation could theoretically build a single
| update and retransmit this update to all the peers (I'm ignoring
| alot of detail here). With the above (efficient approach) when a
| single peer slows down enough to make TCP flow control, all update
| sending must wait on that slow peer. The alternative approach is
| to independently update all peers at their given rate: this has
| the drawback that potentially for every peer the update must be
| rebuilt for sending. A hybrid approach could use some local buffering
| (above the TCP buffering) to accomodate slow peers to some extent
| and (most of the time) allowing reuse of that update buffer.
| Another complicating aspect is that peers can often be grouped
| so that their out-policy is reused - it is beneficial to reuse
| updates for these groups.
|
| Seems like a topic ripe for some modelling.
|
| -Jim.
|
| -----Original Message-----
| From: Dennis Ferguson [mailto:[email-masked]]
| Sent: Tuesday, July 23, 2002 6:36 PM
| To: Manav Bhatia
| Cc: Mareline Sheldon; [email-masked]
| Subject: Re: My BGP Route Update Pacing Draft
|
|
| Hello,
|
| > If you have some UPDATEs to announce and if you are holding them back
| > because of the congestion you perceive in the network and then if you
| > recieve a WITHDRAW for one of those same prefixes then you have to
first
| > advertise the UPDATEs because it is invalid to announce the same
address
| > prefix in the WITHDRAWN routes and the NLRI field of an UPDATE message.
| You
| > thus end up flushing all the BGP UPDATEs you had piled up waiting for
the
| > congestion to clear out at your remote end.
|
| Why would you do this?  If you receive a withdrawal for a route for which
| you haven't sent an UPDATE yet, why wouldn't you forget about the UPDATE
| and just send the withdrawal (or, if you've never advertised the route
| to the peer, just send nothing at all)?  If a route is flapping and
| goes up and down 62 times while your peer has you flow controlled, would
| you really send the 62 flaps when the peer allows you to send again?  Why
| wouldn't you just send the final result?
|
| You need to do routing protocol implementations in a way which avoids
| unbounded state, and doing this means that you shouldn't be recording
| all route transitions to play back to a peer which isn't listening at
| the moment.  If the only state you keep is what you advertised to the
| peer before and what the state of the route is now, then the amount
| of state you need to keep remains proportional to the number of routes
| you have and you only need to advertise the current state (if it doesn't
| match what the peer already knows, otherwise you send nothing) when
| the peer starts taking updates again.
|
| > The better solution is to let
| > TCP take care of the congestion internally as it has always been
|
| I don't think this has much to do with TCP, TCP flow control works
| the same way.
|
| Dennis Ferguson
|