Subject: [sidr] Beacons in a separate TCP

From: Jakob Heitz <[email-masked]>
Date: Wed, 9 Nov 2011 17:11:00 -0500

The beacons will be unlikely to come like the slow constant
drizzle of Seattle weather, but more like the quick cloudbursts
of Miami weather. Just guessing.

Such beacons will cause head-of-line blocking for more
urgent updates behind them. Beacons can be delayed for
hours without consequence. Not so for other updates.

I think beacons should be transmitted in a TCP session
separate from the normal BGP traffic, so as not to delay
that.

--
Jakob Heitz.

> -----Original Message-----
> From: Eric Osterweil [mailto:[email-masked]]
> Sent: Wednesday, November 09, 2011 12:37 PM
> To: Sriram, Kotikalapudi
> Cc: Jakob Heitz; sidr wg list
> Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs
> 
> Hey Sriram, Russ, and Jakob,
> 
> Thanks for the #s.  I think I get the general notion that adding n
> updates per day per prefix equals (n * #prefixes)/1. :)  I guess my
> question was kinda vague, sorry.  Upon reexamination, I see that I
> said "overhead" without being specific.  Since we can use the
> updates that are generated today to measure how much (for example)
> bandwidth is already needed, can we calculate how much extra
> bandwidth universal deployment would mean?  Also, perhaps this would
> be most informative in the form of a ratio (i.e. a factor of $x$
> increase).  That way, when people look at events like the one that
> the "General Internet Instability" thread that just happened on
> NANOG refer to, they can gauge the update amplification that was
> seen against what _would_ be seen given bgpsec.  I think this
> actually kind of came up on nanog, so it seems like maybe it would
> be a relevant thing to look at here?
> 
> Anyway, I guess I was mostly just curious about what kinds of
> evaluations have been done, thanks. :)
> 
> Eric
> 
> On Nov 8, 2011, at 12:19 PM, Sriram, Kotikalapudi wrote:
> 
> > Now the ops doc has much longer beaconing interval recommendations
> for
> > what you may consider a normal prefix.
> >
> > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-01#section-7
> >
> > 	Normal Prefix:  Most prefixes SHOULD announce with a
> signature
> > 	validity of a week and beacon every three days.
> >
> > Sriram
> >
> > -----Original Message-----
> > From: Jakob Heitz [mailto:[email-masked]]
> > Sent: Tuesday, November 08, 2011 12:09 PM
> > To: Sriram, Kotikalapudi
> > Cc: Christopher Morrow; Eric Osterweil; sidr wg list
> > Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs
> >
> > Proposal was 24 hour beacon timeout and 3 beacons per timeout.
> That makes 3 beacons per day.
> >
> > --
> > Jakob Heitz.
> >
> >

---

From: "George, Wes" <[email-masked]>
Date: Fri, 11 Nov 2011 20:02:59 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jakob Heitz
>
> The beacons will be unlikely to come like the slow constant drizzle of
> Seattle weather, but more like the quick cloudbursts of Miami weather.
> Just guessing.
>
> Such beacons will cause head-of-line blocking for more urgent updates
> behind them. Beacons can be delayed for hours without consequence. Not
> so for other updates.
>
> I think beacons should be transmitted in a TCP session separate from
> the normal BGP traffic, so as not to delay that.

[WEG] I'm not certain I understand how a separate TCP session would make a significant difference. When the update arrives, the router has to do something to it, either process it or slap it into a buffer (RAM or hard drive) for processing when it's less busy.
You could accomplish the same thing by flagging it with different QOS values, instructing the beacon sender to send the updates at pseudo-random intervals, and instructing the receiving router to always process update/withdraw messages before beacons, right? But really, this just ends up being part of the overall base CPU load of the BGPSec implementation. Either the routing system hardware has the scale to run it or it doesn't. If we're down to having to use separate TCP sessions to segregate important updates from less important ones, we have a larger problem IMO.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 11 Nov 2011 20:25:02 -0500

If the router has other work, it can simply stop reading the tcp socket. That would put the tcp into persist state and the sender will stop sending. This is only possible if the beacons are in a separate tcp session.

--
Jakob Heitz.