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

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.

> 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.

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.

> 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.  

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
> 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.

Ok

> 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.

Ok.

> 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.

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. 

> 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.

<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

_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep