traffic engineering (or lack of thereof)

Thu Oct 30 17:11:19 UTC 2003

> And how many people here operate non-oversubscribed networks?

The right question here should be "How many people here operate non-super
oversubscribed networks?" Oversubscribed by a a few percents is one thing,
oversubscribed the way certain cable company in NEPA does it is another.[1]

> So having 3 Gb of DoS traffic coming across a half dozen
> peering OC48s isn't that bad; but having it try to fit onto
> a pair of OC48s into the backbone that are already running
> at 40% capacity means you're SOL unless you filter some of
> that traffic out.

Why does your backbone have only two OC48s that are 40% utilized if you have
half a dozen peering OC48s that can easily take those 3Gb/sec?

> And I've been in that situation more times than I'd like to remember,
> because you can't justify increasing capacity internally from a remote
> peering point into the backbone simply to be able to handle a possible DoS
> attack.

This means that the PNIs of such network are full already. So we are back to
the super-oversubscribed issue.

> Even if you _do_ upgrade capacity there, and you carry the extra 3Gb of
> traffic from your peering links through your core backbone, and off to
> your access device, you suddenly realize that the gig port on your access
> device is now hosed.  You can then filter the attack traffic out on the
> device just upstream of the access box, but then you're carrying it
> through your core only to throw it away after using up backbone capacity;
> why not discard it sooner rather than later, if you're going to have to
> discard it anyhow?

Because you do not know what is the "evil" traffic and what is the "good"
traffic. 

> And under those circumstances, there is a strong preference to discard
> "bad" traffic rather than "good" traffic if at all possible. One technique
> we currently use for making those decisions is looking at the type of
> packets; are they 92 byte ICMP packets, are they TCP packets destined for
> port 1434, etc.

And this technique presumes that the backbone routers know what are the
packets that their customers are want to go through and which ones they do
not. Again, this is not a job of backbone routers. It is a kluge that should
be accepted as a kludge.

> I'd be curious to see what networks you know of where the IS component
> does *no* statistical aggregation of traffic whatsoever.  :)

The example that you are using is not based on statistical traffic
aggregation. Rather it is based on an arbitrary decision of what is good and
what is bad traffic (just like certain operators that claimed that DHS
ordered them to block certain ports).

> Matt

Alex

[1] Bring three T1s of IP. Sell service to serveral hundred cable
customers. 