Re: [Ieprep] Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)

On Nov 16, 2006, at 4:02 PM, Curtis Villamizar wrote:
> Preemption in MPLS can be soft preemption (setting aside  
> differences of opinion about how signaling of soft preempt should  
> be done for the moment)...
>
> Even for hard preemption, there is at worst a fall back to IP and  
> reroute...

Those are both options, but IMHO have issues. One can't, for example,  
fall back and reroute to a different path if the bottleneck where  
preemption is occurring is the only path to the destination. Further,  
MPLS is one of many ways we have of building the network. Some of us  
still use IP...

What I have suggested to DoD is simpler. Imagine one defines two  
elastic traffic classes for class 1 and class 2 (whatever DSCP and  
application might be implied). Assign half the capacity to class 1  
and 5% to class 2 (let's presume that the other 45% is taken up with  
other stuff, irrelevant to the present example). In normal use,  
though, presume that one in fact finds 99% class 2 and 1% class 1.

Guess what, class 1 will experience relatively low delay and class 2  
will in fact use the available bandwidth, as our queuing is work- 
conserving. Should suddenly a whole bunch of class 1 show up, it will  
get up to its assigned capacity and class 2 will get squeezed,  
experiencing greater delay and potentially loss momentarily. To class  
2, it will look a lot like a re-route event. Reroute happens.

To my small mind, that has the same characteristics as preemption,  
but does so in a manner that is pretty consistent with elastic  
traffic in the global internet. I can look at the technology, the  
algorithms, and the network, and say what the implications are. So  
define a traffic class (ten if it suits you) for your higher  
precedence traffic.

Other proposals have been offered, like introducing different min- 
thresholds for different preference levels. This has a problem - it's  
not predictable. Let's imagine just for fun that my low precedence  
traffic is already in trouble - I am seeing a 10% drop rate at the  
time the higher precedence traffic shows up [pick your reason]. TCP  
is already, in that case, deep in its back-off behavior, and isn't  
going to back off a whole lot more. What will happen to the higher  
precedence traffic? It will get dropped too. But using two classes,  
fine, I change 10% loss to 80% loss and get the higher precedence  
traffic through with little harm.

Yes, I'm being extreme, but this topic is about the end cases. And  
yes, adding more bandwidth is always helpful. It isn't always an  
option, and under the scenarios in question (in some cases, just say  
"Armageddon") might be pretty difficult to predict in detail.

_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep