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

[Janet P Gunn <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ieprep