Subject: [Tsvwg] Paradox in draft-baker-tsvwg-mlpp-that-works-01

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 22 Mar 2004 16:19:23 -0800

We have studied possible QoS configurations for some time. One of our conclusions is that reservation-based IP QoS systems (including also the EF PHB (RFC 3246), if my memory serves) significantly wasted available capacity and should therefore be avoided in all situations where explicit over provisioning was not possible -- unless one was willing to have the reservation-based traffic deprecate everything else.

Two IETFs ago I asked many of the luminaries who had led the IETF's various Int-Serv and Diff-Serv efforts over the years concerning what major lessons they believed that we as a community learned from implementing QoS. The unanimous answer (of those I queried) was that "the only guaranteed effective QoS is over provisioning."

The recent ID published by Fred Baker and James Polk (both of Cisco) , identified in the subject line above, acknowledges these lessons learned to the extent of dividing the world's networks into those that can be over provisioned ("10:1 over provisioning is often the cheapest and surest solution" they wrote) and those operating within tight bandwidth constraints. This ID, when combined with draft-baker-tsvwg-mlef-concerns-01, jointly describe a very interesting problem apparently confronting military networks of how to ensure that only the more important communications are preferentially delivered in times of crisis and/or congestion.
While sympathizing with the military's problem, I am skeptical about Fred and James' plan to use RSVP. While acknowledging that four years ago the IETF's recommendation was "Int-Serv at the edge and Diff-Serv in the core", which is exactly what Fred and James are now proposing, I want to point out that other than NSIS (see http://www.ietf.org/html.charters/nsis-charter.html) and some remaining Telecom (SS7-like) and governmental (e.g., DISA) enthusiasts, I am not aware of anybody anywhere else wanting to use RSVP, such that I have considered the protocol to be essentially "dead". [Does anybody know of ANY actual deployment actually using RSVP in any production network anywhere in the world?  (I certainly don't.) If so, please educate me about that deployment.] There are many reasons for this, including (1) RSVP security is a real mess, lacking interoperable "standards" (e.g., no defined key management -- see Section 5 of RFC 2747) such that there is no guarantee that different vendor's products can interoperate if "secured". (2) RSVP increases "state" in the middle of the network (rather than at its edges), with the well-known problems associated with doing so. (Introducing state in the middle is hard to do right, forcing developers to make difficult (tragic?) choices.) My point being that if RSVP has not previously worked in the past, why do the author's believe that it could work now, especially for life-and-death military traffic?
Yet I am wandering off-target. A paradox of Fred's and James' I-D posting is that capacity constrained networks are singularly poorly equipped to use capacity-wasting technologies such as reservations, since doing so further reduces the available capacity of that network, thereby further reducing the available capacity over what it would have been had no reservations been used at all. Of course, James and Fred may simply argue that this is for their customers to decide, and their customer have stated a requirement to have a small very high priority subset be delivered rather than risk the non-delivery of those critical items. OK, I admit that this is a winning argument -- it is indeed the customer who determines these types of things.
However, this issue becomes more significant once one considers that many of these capacity constrained networks may well be wireless networks operating in MANET (mobile ad hoc network) environments. One of the facts of life for fielded MANET devices is their network availability performance is constrained due to signal interference by foliage, landforms, and other causes. Many current suggests that 80% network availability for MANET deployments is towards the high end of the scale. 
Because of this, one must question the use of a real-time signaling protocol such as RSVP within such low availability networks, especially if the reservation is to occur over multiple hops (i.e., assuming 80% local availability, then two hops would be .8 * .8 = .64 local availability for that circuit). I don't know what network diameter Fred and James are envisioning, but I suggest that this approach is poorly suited to MANET networks. Rather, a latency-friendly approach (e.g., EF PHB) would be a much better design choice for such low availability environments.
And this brings up a second paradox of Fred's and James' I-D: their design for the resource constrained networks is primarily suited to the high-availability characteristics of networks that can be overprovisioned, and which therefore do not need to benefit from their approach. Rather, for the class of networks needing the MLPP services they are addressing, they need an approach that would cleanly work within low availability environments.
--Eric

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

---

From: "Ken Carlberg" <[email-masked]>
Date: Mon, 22 Mar 2004 21:59:48 -0500

> Yet I am wandering off-target. A paradox of Fred's and James' I-D
posting is
> that capacity constrained networks are singularly poorly equipped to
use
> capacity-wasting technologies such as reservations, since doing so
further
> reduces the available capacity of that network, thereby further
reducing the
> available capacity over what it would have been had no reservations
been
> used at all.

Your comment carries a lot of weight when the goal is fairness among all
users and optimal use of resources in a work conserving manner.
However, the underlying aspect of MLPP, which both drafts of Fred and
James are targeted at, pretty much runs contrary to that and explicitly
accepts that some users are more important that others.  Hence, reducing
available capacity/resources of others is an acceptable position to take
for those set of users that participate in the MLPP network/domain.
(note, I'm constraining my comment to a specific user group as opposed
to the Internet as a whole -- I'm choosing my words carefully because I
have a preference not to trigger a religious war)

> However, this issue becomes more significant once one considers that
many of
> these capacity constrained networks may well be wireless networks
operating
> in MANET (mobile ad hoc network) environments. One of the facts of
life for
> fielded MANET devices is their network availability performance is
> constrained due to signal interference by foliage, landforms, and
other
> causes.

Citing MANET is a good educated guess, but a bit off the mark.  Existing
MLPP systems (in both military and commercial arenas) that are targets
for migration from non-IP to IP based technology are not based on MANET
characteristics -- ie, networks of nodes (hosts/routers) moving in
relation to each other.  I also feel that discussions on anticipated
network technologies and characteristics runs the risk of turning into a
rat hole, so I'll stop here.  

The focus of the discussion on these drafts (I feel) should be the
technical strengths or weaknesses of protocols proposed as opposed to
tangent topics of discussion such as market acceptance or network
technologies/characteristics.  While I share your philosophical concerns
(for lack of a better term) about reliance of RSVP due to lack of
deployment across autonomous domains, I don't have *technical* concerns
about RSVP as it is presented in these drafts.

Cheers,

-ken

---

From: Fred Baker <[email-masked]>
Date: Wed, 24 Mar 2004 04:17:45 -0500

At 07:19 PM 03/22/04 -0800, Fleischman, Eric wrote:
>One of our conclusions is that reservation-based IP QoS systems (including 
>also the EF PHB (RFC 3246), if my memory serves) significantly wasted 
>available capacity and should therefore be avoided in all situations where 
>explicit over provisioning was not possible -- unless one was willing to 
>have the reservation-based traffic deprecate everything else.

Although I asked for that to be true, RFC 3246 does not call for admission.

I guess I would like to understand your concerns here; could you spell them 
out?

An over-provisioned system by definition provides more capacity than the 
offered load is able to use. If the definition of "neither over nor under 
provisioned" is 100% utilization with no loss, an over-provisioned system 
is by definition under-utilized. A system that has finite bandwidth and 
location-based CAC (such as the H.323 gatekeeper or a SIP proxy uses) also 
results in under-utilization; such systems know the number of calls between 
two gatekeepers/proxies, but know nothing of the underlying routing or 
utilization, and as a result must make conservative estimates. Yes, simple 
bandwidth reservation with no measurement results in under-utilization. 
That seems to be a common theme.

Section 2.3.5.1 of our document addresses variable rate codecs and codecs 
of any description with Voice Activity Detection. It says:

     One can also approximate to average load, which is perhaps a
     more reliable procedure. In this case, one maintains a variable
     which measures actual traffic through the admitted data's queue,
     approximating it using an exponentially weighted moving average.
     When a new reservation request arrives, if the requested rate is
     less than the difference between the configured upper bound and
     the current value of the moving average, the reservation is
     accepted and the moving average is immediately increased by the
     amount of the reservation to ensure that the bandwidth is not
     promised out to several users simultaneously. In time, the
     moving average will decay from this guard position to an
     estimate of true load, which may offer a chance to another
     session to be reserved that would otherwise have been refused.

     Statistical reservation schemes such as these are overwhelmingly
     dependent on the correctness of their configuration and its
     appropriateness for the codecs in use. But they offer the
     opportunity to take advantage of statistical multiplexing gains
     that might otherwise be missed.

This is a double-edged sword; it in fact works in a large number of cases, 
at least for voice traffic with VAD. However, it depends on past 
performance being a guide to future behavior, and as your stock broker will 
tell you, past performance is not necessarily such a guide. With MPEG-4 
encoding (to me, voice and video are different applications with similar 
real-time requirements; the absolute numbers change, but the big picture 
doesn't change quite so much), it is very possible for a data stream to 
jump an order of magnitude in volume after a very long period of stability. 
So this kind of algorithm needs to be used with some thought.

I don't think anyone in this forum or any other is going to argue against 
over-provisioning as an approach. The only problem is that it is not 
universally available or cost-effective; many civilian access networks, 
such as the one that serves my home or the hotel room I am sitting in at 
this instant, and many military networks, are in fact not massively 
over-provisioned and will not become so in the foreseeable future. The 
military MLPP and civilian GETS services (both US, but with counterparts in 
other parts of the world) presuppose that the system has sufficient 
capacity for normal cases but may bump during peaks, and deal with that 
reality.

You mentioned NSIS. From my perspective, NSIS is a perfectly reasonable 
signaling protocol, or will be when it is finished being specified and 
proven out. At this point, it is not a protocol that I can turn on in any 
production router that I am aware of, and doesn't (yet) cover a number of 
the use cases that we discussed in the draft. I think we have to table that 
discussion pending further work on NSIS.