Subject: [Tsvwg] comments on draft-baker-mlef-concerns-00.txt

From: "Eagan, Christopher" <[email-masked]>
Date: Wed, 03 Dec 2003 13:46:47 -0500

Comments on draft-baker-tsvwg-mlef-concerns-00

Thanks for putting out this draft.  Although I don't agree with it, it is easier to criticize your work than write a whole new draft :)

The major problems with this draft are:

1.  A mechanism implementing PHB "MUST include some means to limit the damage EF traffic could inflict on other traffic (e.g., a token bucket rate limiter)" [RFC 2598, Section 2].  This means EF packets will be dropped if the aggregate EF traffic exceeds a policy driven rate limit - right?  So, in some situations, EF packets will be dropped, whether one is using EF or MLEF or something else.  The only thing MLEF adds to this picture is to provide a mechanism to choose *which* packets will be dropped.  The fact that packets will be dropped in some situations does not change by including or excluding MLEF.

2.  This draft implicitly assumes MLEF being implemented without other mechanisms also being implemented (e.g. without call admission control).  Merits of other mechanisms aside, what is the basis for this assumption?  Does an implementation of MLEF exclude other QoS mechanisms or vice versa?  Not that I have seen.  Maybe if you added interoperability concerns between MLEF and other existing mechanisms this would bolster your argument.

The major issue that MLEF solves is network resource priority at a lower and more fundamental level than CAC.  Specifically, MLEF allows higher priority traffic to survive without any prior state variables being set in the router.  I can see the merits of CAC with respect to managing the problem you describe as "congestive collapse" in section 2.5.  But does CAC work in all situations?  Does it work in mobile ad hoc environments? Does it recover fast enough when an router routing voice traffic gets blown up or smashed?  It makes a lot of sense to me that even using a great CAC mechanism, one would want a backup mechanism to assure important communications.  MLEF provides this backup in a simple, easy to implement manner.

3.  With regards to the last sentence in the last paragraph,  no one has to be reminded of the seriousness of emergencies and how good or bad lines of communications can translate into people's lives.

My comments are based on our own discussions within Lockheed Martin and comments previously posted to the IEPREP working group by participants there such as Mike Pierce and Steve Silverman.  Having said that, these comments also represent my personal opinions.

Christopher Eagan
Software Engineer
Lockheed Martin
(301) 240 - 6328
[email-masked]

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Fred Baker <[email-masked]>
Date: Mon, 08 Dec 2003 13:46:49 -0800

At 02:46 AM 12/3/2003, Eagan, Christopher wrote:
>1.  A mechanism implementing PHB "MUST include some means to limit the 
>damage EF traffic could inflict on other traffic (e.g., a token bucket 
>rate limiter)" [RFC 2598, Section 2].  This means EF packets will be 
>dropped if the aggregate EF traffic exceeds a policy driven rate limit - right?

You are correct that the problem I raise with MLEF is also a problem with 
EF; it needs effective CAC.

The difference between EF and MLEF is that EF considers that one engineers 
capacity in such a way that one rarely actually crosses the policing 
thresholds, and I assure you that VoIP as deployed today does that. MLEF 
presumes that discard of excess traffic is normal. These are two very 
different scenarios.

However, if you have heard much from me in the past decade, you have heard 
the line of reasoning outlined in 
http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlpp-that-works-00.txt 
mentioned as appropriate for EF as well.

>2.  This draft implicitly assumes MLEF being implemented without other 
>mechanisms also being implemented (e.g. without call admission 
>control).  Merits of other mechanisms aside, what is the basis for this 
>assumption?  Does an implementation of MLEF exclude other QoS mechanisms 
>or vice versa?  Not that I have seen.  Maybe if you added interoperability 
>concerns between MLEF and other existing mechanisms this would bolster 
>your argument.

The MLEF PHB states that packet loss is the means of call admission 
control. The simulations that Mike Pierce has sent me use packet loss to 
perform call admission control at the source - if a source is seeing a 
certain level of loss, it asks itself some policy-related questions and 
then potentially drops the call. Steve Silverman says the same thing:

At 04:53 PM 11/19/2003, Steve Silverman wrote:
>One possible solution for the lower priority calls would be a terminal 
>behaviour such that if a certain percentage (or number) of packets are 
>lost in a certain amount of time, the terminal issues a congestion notice 
>to the other party and either the call is suspended for a short period of 
>time or terminated.

My draft addresses those directly, in section 2.6.

    A measurement-based counterpart to the MLPP procedure has been
    proposed, in which calls experiencing significant loss treat this as
    a signal from the network and drop the call. But if all calls at a
    precedence level are experiencing loss, many and perhaps all calls at
    the precedence level would be dropped by this heuristic; if many
    calls are vying for service, the effect would be rolling call
    disruption - a set of calls would be established, additional calls
    would be established disrupting that class of calls, many of the
    disrupted calls would drop, and then more of the competing calls
    would be established - only to be disrupted when the first set
    redialed.

>I can see the merits of CAC with respect to managing the problem you 
>describe as "congestive collapse" in section 2.5.  But does CAC work in 
>all situations?

If, by policy, you want to decide that when faced with a choice you will 
choose among packets in a graded fashion, I'm OK with that, and say as much 
in section 2.2 of 
http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlpp-that-works-00.txt. 
Remember, I wrote another PHB that does exactly that. However, depending on 
that as your primary CAC mechanism doesn't fly, for reasons outlined above 
and in the mlef-concerns document.

And yes, bandwidth CAC actually does work. You don't, as mentioned in RFC 
2210, want to be doing it in every router in the world, but you do in fact 
want to be doing it in the routers that have bottleneck interfaces. If you 
do it in the places it needs done, it does in fact limit the total offered 
load to be less than or equal to the capacity available to that load.

>3.  With regards to the last sentence in the last paragraph,  no one has 
>to be reminded of the seriousness of emergencies and how good or bad lines 
>of communications can translate into people's lives.

To be very honest, I'm not sure what sentence you're commenting on. The 
last sentence of the last paragraph in the document reads:

    Funding for the RFC Editor function is currently provided by the
    Internet Society.

I'm pretty sure you're not referring to that one. But you may be referring 
to our recommendation:

3. Recommendation

    Considering the nature of real-time traffic and the effect of packet
    loss on known codecs, it is clear that degradation of voice quality
    in an MLEF environment for lower precedence calls will be severe.
    Even the advances in codec technology do not fix the problem.

    With all due respect to the engineers who have worked on designing
    and developing the DISA Assured Service and MLEF, the authors cannot
    in good conscience recommend its deployment as it stands. It will
    protect the calls placed by senior officers and constitutional
    officials, but it does not provide the same service that MLPP
    provides to those who respond to their orders, and therefore
    seriously impinges on the likelihood that those orders will be
    correctly disseminated and carried out. Considering the environment
    this proposed mechanism is for, the potential attractiveness for
    other environments, and that the effects could and should compound
    upon themselves, the worst case scenario includes loss of life due to
    communications failure. Nothing done here should enhance this
    possibility.

Yes, I would hope that nobody has to be reminded that - unlike the 
difference between TCP with this congestion avoidance algorithm vs that one 
- lives depend on this PHB working. What I'm trying to do here is move this 
out of the ivory tower. I care deeply about this issue not because I have a 
pet solution I would prefer you use, although yes I do of course have an 
alternate proposal. I care about this because my son's life may be placed 
at risk because you haven't done your math. This is not ivory tower. This 
is "rubber, meet road; road, meet rubber."

My concern is simply this. MLPP-preempted calls, and the attempted 
placement of more calls than available bandwidth will support, are the norm 
in military environments. I have a fairly long string of emails from 
present and former service personnel telling stories of real MLPP in 
action, and they are *frequent*. What I read as the VoIP solution for that 
level of problem is laden with assumptions that I can't make play as I do 
the math. My key concern is that

    The problem with MLEF, in a nutshell, is that it implements a
    different service than MLPP, and that service has a very different
    effect. The basic function of MLPP is to cause some number of lower
    precedence calls to be dropped, or not started, so that

    o  higher precedence calls get placed, and
    o  the remaining lower precedence calls stay at good quality.

    MLEF fails to achieve the second function. Instead, MLEF can create a
    situation where all lower precedence calls become unintelligible,
    thus destroying most of the usefulness of the communications system.

OK, consider this. Here is a war story from a colleague:
>...preempting  my way to an Italian airbase during Desert Storm to prevent 
>a possible aircraft incident (running a flight of 6 OV-10's out of fuel 
>with no place to land) and as a lower ranking caller, preempting a call 
>between then Brig Gen Jones in Aviano and Gen Al Gray, then CMC, with a 
>priority call when they were using a routine circuit.

So he used a "priority" call, which only preempts "routine" calls. But with 
MLEF, if the bandwidth is exactly 100% used and he has a typical unit 
configuration, what he has just done is impose upwards of 5% random loss on 
*every*single*one* of the competing routine calls. Pick your MOS score 
report; 5% loss drops their MOS well below 3.5 and in many I have read (and 
referenced in the draft), well below 3.0. That can just as easily result in 
fairly dire things happening in a military environment.

We said we can't recommend depending on MLEF in an environment where lives 
depend on it because, well, we can't recommend it. We are in fact very 
deeply concerned about this.

>My comments are based on our own discussions within Lockheed Martin and 
>comments previously posted to the IEPREP working group by participants 
>there such as Mike Pierce and Steve Silverman.  Having said that, these 
>comments also represent my personal opinions.

I have also discussed these things in ieprep, with Mike and Steve, and by 
the way they are my personal opinions. But this is not about opinion, 
whomsoever's it may be.

My concerns derive fairly directly from mathematics. If a system is 
designed to carry 20 calls (T-1 line and using G.711 encoding as proposed 
in current DISA documents), adding a 21st call results in 5% loss roughly 
uniformly distributed among the calls at any lower precedence than the call 
added. 5% loss drops the MOS/PESQ score into the danger zone; 10% loss is 
so bad that the reports don't even attempt to characterize it. If ILBC is 
used as the codec, per the Miami University report I cited, you get a 
little better loss performance. That still has a limit, though, and when 
you go beyond that limit, the result is still horrendous. And, as described 
in section 2.2, any protection-based codec, ILBC being but one example, has 
a ballooning effect - when RCP starts reporting loss, the codec sends more 
traffic. Thus, if a link is capable of carrying 20 calls, adding a 21st 
call doesn't make it lose the traffic equivalent of a single call. It 
actually balloons the traffic to 150% of its former size, and as a result 
drops roughly 1/3 of the traffic - well beyond the limits of even ILBC.

Mathematics is bedrock. You're building a system to operate in a storm. It 
can be a house built on bedrock, or it can be the ship that founders on the 
same bedrock. What you need to show is that the math is wrong, that 21/20 
of a link does not result in 5% loss, or that 5% loss does not result in a 
low MOS score, or ...