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

Picky is fine.  I have been known to be picky!

Remaining comments in line.

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

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

                      "Ken Carlberg"                                                                                             
                      <carlberg                To:      "'Janet P Gunn'" <jgunn6@csc.com>                                        
                      @g11.org.uk>             cc:      <ieprep@ietf.org>                                                        
                                               Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt              
                      01/28/2004 01:40                                                                                           
                      PM                                                                                                         

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.

[jpg] you are right,  I should have said voice (and video) ETS
applications. Which prompts me to ask if there will be a single domain IP
telephony ETS requirements document.

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

[jpg] Agree, not a blanket statement. But my point is that when something
happens to/in the network, that is the time when "extraordinary" treatment
may make sense (recognizing that even without extraordinary treatment, this
is still vastly superior to the PSTN situation, where ANY disruption to the
network (on the particular call path) makes the call go away).  This is
particularly true for voice and video applications.  Less so, I agree, for
elastic applications.

 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.

[jpg] I guess my unwritten question here is "Are you planning to have a
document which DOES address this."  I agree that it is somewhat
out-of-scpoe for the two new documents.

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

[jpg] Thanks, that is encouraging.

Janet

Cheers,

-ken

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