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