Subject: RE: [Ieprep] WG last call for General Requirements for ETS

From: "Dvorak, Charles A (Chuck), ALABS" <[email-masked]>
Date: Sun, 16 Feb 2003 00:50:56 -0500

Some comments intended to improve the draft:

In the circuit world, we know that ETS means increasing (not guaranteeing) the probability of completion of labeled calls. Since IP knows nothing about calls, it knows nothing about call completion. All it can do is give some type of reduced probability regarding packet loss, jitter and delay--right? So far so good.

But the requirements here are in terms of doing "better than best effort," which I accept is all that can be done within the scope, but just what does this mean in terms of the applications?

Possibly everything, and maybe nothing--there is some reduction of IP loss, jitter and/or delay, but the result (even if achieved) may not be visible to the user. For example, if you decrease the end-to-end delay from 150 to 100 msec through special treatment...a voice call doesn't much care. (And that same resource could instead have been used to get more "calls" through.)

If the intent is to do exactly what I am describing, namely say that the "requirement" is ONLY to do "better than best effort," well OK, but it really doesn't mean much--maybe we should be clearer about this. 

Hope this helps,

Chuck Dvorak
AT&T Labs

> -----Original Message-----
> From: King, Kimberly S. [mailto:[email-masked]]
> Sent: Monday, February 10, 2003 11:39 AM
> To: Ieprep (E-mail)
> Cc: 'Scott Bradner ' (E-mail)
> Subject: [Ieprep] WG last call for General Requirements for ETS
> 
> 
> This message announces WG last call for 
> General Requirements for Emergency Telecommunication Service
> (draft-ietf-ieprep-ets-general-01.txt).  
> The intension is for this draft to
> have informational RFC status.
> 
> The cut-off date for WG last call is Feb 24, 2003.
> _______________________________________________
> Ieprep mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ieprep
> _______________________________________________
> Ieprep mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ieprep
> 
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Sun, 16 Feb 2003 10:49:27 -0500

On Sunday, Feb 16, 2003, at 00:50 America/Montreal, Dvorak, Charles A 
(Chuck), ALABS wrote:
> Possibly everything, and maybe nothing--there is some reduction of IP 
> loss, jitter and/or delay, but the result (even if achieved) may not 
> be visible to the user. For example, if you decrease the end-to-end 
> delay from 150 to 100 msec through special treatment...a voice call 
> doesn't much care. (And that same resource could instead have been 
> used to get more "calls" through.)

The above analysis has some implicit assumptions about which codecs 
(and so forth)
are being used.  For at least some codecs, reducing end-to-end delay or 
jitter
can improve the "perceived quality" of a voice call.  It also assumes 
that voice
is the primary/only application of interest, whereas the Japanese 
deployment
shows that this is not necessarily the case.

> If the intent is to do exactly what I am describing, namely say that 
> the "requirement"
> is ONLY to do "better than best effort," well OK, but it really 
> doesn't mean much
> --maybe we should be clearer about this.

Also important to keep in mind that the "general" document is quite 
explicitly
NOT focused on voice applications.  Instead, it covers all kinds of 
applications,
including a whole range of things that are not voice/voice-related.

Depending on which of those applications is being considered, the 
degree of
benefit will necessarily vary.  Voice-specific discussion is intended to
be in the "Telephony Requirements" document rather than the "General 
Requirements"
document -- as a matter of document scope.

Ran

---

From: Ken Carlberg <[email-masked]>
Date: Mon, 17 Feb 2003 13:45:51 +0000

the points you make are good ones.  beyond what I would add to what Ran
said is that the context of the requirement is the use of better than best
effort as opposed to a guarantee with hard bounds.  and more importantly,
we use the word "should" in this respect. 

also, an underlying aspect in my response to Janet's earlier email on
the topic is that I'd prefer to stay away from identifying exactly how
things are to be done in this document.  this in addition to my desire
to avoid getting caught into a series of IF/THEN/ELSE type statements.

the subject of your comment is well suited for the Telephony Framework
document, and I'll make sure that it is discussed there.

-ken