Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt

From: Janet P Gunn <[email-masked]>
Date: Tue, 27 Jan 2004 17:32:32 -0500

I think that, under "normal" circumstances, the QoS mechanisms for
conventional VoIP will be more than adequate to support ETS, and "special
treatment" in Call Admission Control is what will be needed for ETS.

But when  network congestion and/ or damage are severe, the "conventional"
mechanisms may no longer be adequate (especially when network failure
initiates the re-routing of Label Switched Paths, and significantly reduces
the available capacity).

As Fred Baker says in draft-baker-tsvwg-mlpp-that-works.00.txt, if call
admission is working properly, traffic marking is not needed in normal
operations.  It is when there are route changes - typically due to network
failures - that marking is needed.  When there are network failures, the
capacity and route assignments on which call admission was based no longer
apply, the QoS cannot be guaranteed until the new routes are stabilized,
and the call admission process adapts to the new capacity and routes.  This
may be a very local effect, of quite short duration.  But it has a
significant impact on the call quality of the calls that are affected.
While that paper addresses an IP implementation of MLPP, many of the same
concerns apply to ETS.

Network failures, and/or  massive and sustained statistical anomalies
(large, local bursts), and the associated route changes, are the problems
we need to focus on.

It is in this context that ETS calls must be given a high probability of
meeting the QoS criteria, even when network congestion and or damage are
severe.

The requirements in draft-ietf-ieprep-domain-req-00.txt don't seem to
address this, and the framework in draft-ietf-ieprep-domain-frame-00.txt
doesn't seem to solve it.

In draft-gunn-ieprep-ip-telephony-gap-00.txt we address the  need to
support ETS SLAs to provide High Probability Toll-Quality Voice - ETS calls
must be given adequate resources through the network to ensure a high
probability that their packets suffer loss, delay, and jitter consistent
with achieving toll-quality voice even when network congestion and / or
damage are severe.

Of course, one of the conditions for such a service is that the ETS calls
are limited in terms of their relative and/or absolute use of resources.
And if the damage is so severe that there are no available paths, then
obviously they can't be given "adequate resources".  But as long as those
conditions are met,  the ETS calls should get their QoS, even when the
"normal" calls lose theirs, even if for a short time.

In addition, in order for an ETS service to be viable service (i.e., in
order for a provider to be willing to offer it at a "reasonable" cost),
there are several additional requirements.

The impact on non-ETS calls should be minimized, consistent  with providing
the ETS service.  In particular, the impact on non-ETS calls, when there
are no active ETS calls in the network, should be minimal, if any.  So any
solution that requires a lot of additional work on every packet, and/or at
every router, all the time, is not going to be viable.

There needs to be some sort of limit on the volume of ETS traffic- if ALL
the traffic using a particular resource at a particular moment in time is
ETS traffic, it becomes impossible to provide priority treatment.  Limiting
the volume of ETS traffic also reduces its attractiveness as a vehicle for
a DoS attacks (though it might make it more vulnerable to a DoS attack).

The impact on network management and administration should be minimized.
Approaches which require a lot of additional configuration and
administration, just for ETS, during normal network administration, are not
going to be viable.  Such approaches are also unlikely to be sufficiently
reliable, as there is a significant chance that undetected errors will be
made in the ETS specific configuration tasks.

Approaches which build on existing hardware, software, protocols and
procedures are far more likely to be financially viable, and far more
likely to be reliable, than approaches that rely on new or untested
protocols and techniques.

What is the appropriate way to reflect these concerns?

----------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------------------

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 27 Jan 2004 16:35:49 -1000

At 12:32 PM 1/27/2004, Janet P Gunn wrote:
>operations.

lest I be misunderstood, let me restate that. What I wrote was:

    One will ask the value of the multiple DSCPs. They are, in fact, of
    limited to no value in normal operation, as all vice and video
    traffic should have been admitted, and therefore capacity will have
    been assigned to them. The behavior of this service will be
    indistinguishable from the EF PHB regardless of traffic marking.

In retrospect, I wonder what the vice traffic would be :^)

This is not to be understood as saying "no traffic marking is required"; 
one still needs RFC 3246. But if bandwidth admission is operating 
correctly, having N different marks will be operationally indistinguishable 
from having a single EF mark, as the total number of bytes on the wire will 
be the same.

>meeting the QoS criteria, even when network congestion and or damage are 

I wonder if we are communicating here. RFC 3246 is designed to operate in a 
congested network, and to operate in a network in which routing may change. 
The comment in the mlpp-that-works draft - which if it is giving cause for 
confusion I will happily remove - is basically me bending over backwards to 
be intellectually honest and see if I can find a case where CAC may be 
insufficient.

Think about this for a moment: the argument being placed for MLEF is that 
even in the presence of some loss, voice is intelligible. If that is true, 
then just after a route change, during the brief interval between the data 
flow being switched to a new path and the CAC following that and either 
OKing the flow or deciding to shut down the call, when there may be some 
loss, voice should be equally intelligible, no?

Or does the argument that voice is able to work around a modest level of 
loss only work when it comes from the proponents of multiple code points?

---

From: "Ken Carlberg" <[email-masked]>
Date: Wed, 28 Jan 2004 13:40:56 -0500

Janet,

The following response may be a bit picky on some issues/comments, but I
feel it will be helpful to clarify things a bit.
 
> treatment" in Call Admission Control is what will be needed for ETS.

Within the context of what we have written in the past in the IETF, ETS
is an umbrella term that is meant to cover a wide variety of
applications.  Some of these applications (eg, I-Am-Alive) do not
support the concept of CAC. So to say that "special treatment" (whatever
that is) of CAC is what will be needed for ETS is rather too specific a
statement to make.  

I think we can agree that in those applications used to support ETS and
dependent on CAC, an ability to distinguish and perform CAC is of high
interest and needs to be supported.
 
> failures - that marking is needed.  

Keep in mind that Fred's draft is in respect to MLPP.  Arguments from
the draft may be applied to other circumstances, but I would refrain
from treating it as a blanket statement for all applications and
situations.  I've worked on systems in the past where "marking" was used
to separate traffic into either different physical subnets or different
virtuals paths -- neither case where the route changes existed because
of network failures.

> When there are network failures, the
> and the call admission process adapts to the new capacity and routes.
> This may be a very local effect, of quite short duration.  But it has
a
> While that paper addresses an IP implementation of MLPP, many of the
same

Ok

> meeting the QoS criteria, even when network congestion and or damage
are

Ok.

> doesn't seem to solve it.

Actually, that's fine.  The former draft is not aimed at a specific
application or system (this is stated in the draft).  It is admittedly
broad and acts as a foundation for the context of a single domain.  The
latter draft is not meant to offer solutions, but rather to discuss
applicable and related protocols that one *could* encounter within the
specific scope of a single domain.  I will expand this below where you
have a specific question. 

> with achieving toll-quality voice even when network congestion and /
or

<snip>
 
> What is the appropriate way to reflect these concerns?

Through a draft (and I state it with no intention of being obnoxiously
obvious). If your question is, how does one deal with the three
seemingly related drafts?
   1. draft-ietf-ieprep-domain-req-00.txt, 
   2. draft-ietf-ieprep-domain-frame-00.txt, and 
   3. draft-gunn-ieprep-ip-telephony-gap-00.txt, 

then I would follow the position I stated above and have (3) simply be a
more specific continuation of what has been stated in (1) and (2) above.
In my view it may be more constructive to be very specific and identify
specific systems/efforts like GETS or NS/EP or WPS.  If the chairs or AD
feel differently, I'm sure they'll chime in.

Cheers,

-ken