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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]