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

From: "King, Kimberly S." <[email-masked]>
Date: Wed, 26 Feb 2003 17:56:52 -0500

Ken said:

>comments/thoughts?

I find that abstractions are wonderful but examples really make things
clear.  

You propose: "Application-layer mechanisms specifically targeted to
recognize ETS type 
  labels MUST be ABLE to support better than best effort service.  This 
  support SHOULD focus on probability of forwarding packets used for call 
  completion.  Probability MAY reach 100% depending on the local policy 
  associated with the label.  Local policy MUST also be used to determine 
  IF better than best effort is to be applied to a specific label (or 
  related set of labels)."

Do you have an example, albeit hypothetical, of an application-layer
mechanism that might be targeted to recognize ETS type labels meeting the
above criteria?  How about one that fails?   The intent of my questions is
to make the proposed requirement more lucid.  

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

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 26 Feb 2003 21:21:06 -0800 (PST)

> Application-layer mechanisms specifically targeted
    > to recognize ETS type labels MUST be ABLE to support
    > better than best effort service.

There can be, by definition, no such thing.  Since so many of you prefer
semantics to reality, I'd like to point out that QoS provides services
which is, by definition, worse than Best Effort.

                                -Bill

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 27 Feb 2003 11:10:21 +0000

> which is, by definition, worse than Best Effort.

QoS is a term that really gets tossed around very freely and at times
hap-hazardly on this list, so lets put some perspective into the
discussion. QoS does not *provide* a service.  Mechanisms provide QoS.
These mechanisms can exist at various levels and forms.  We can add
classifiers and schedulers in routers to support a measure of quality to
the flow.  We already know your position on QoS support in the network
(routers), so lets not bother rehashing that thread.  And please keep
in mind that the word "network" was not used in the above excerpt, bt
rather "application-layer mechanisms" was specifically stated.

One can also use schemas like FEC to provide a measure of end-to-end
QoS either at the transport layer (see work from Luigi Rizzo on this)
or at the application layer -- such as your demonstration at the last
IETF where each respective SIP phone added FEC packets to compensate
for the loss in order to retain a measure of QoS experienced by the end
user.

Outside of FEC, there are other approaches in use today to try and
achieve better than best effort service.  Re-read an excerpt from
Kimberly's email describing the service offered by Worldcom.

-ken

 From: King, Kimberly S. [mailto:[email-masked]] 
 Sent: Friday, December 06, 2002 6:12 PM
 Subject: [Ieprep] commercial SIP service

 Worldcom offers IP Communications, a converged voice/data service using
 SIP mainly targeted at small to medium businesses.  I contacted them on
 behalf of ieprep as a result of last week's discussions and Henry
 Sinnreich was kind enough to provide some answers.

 They will:

 Provision CPE to support a fixed maximum number of voice calls over a
 customer access link.  This is based upon policy of UDP to TCP ratios
 and also maximum data burst sizes.  What this means is that the
 customers may choose more or fewer maximum voice connections (as a
 function of the link speed) with the tradeoff of how fast they can send
 data during times when all those virtual voice channels are in use.

 They use a QoS appliance at the customer premise to track the number of
 calls.
 <snip>....<snip>

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 27 Feb 2003 11:34:06 +0000

hi Kimberly,

> mechanism that might be targeted to recognize ETS type labels meeting
> the above criteria?  How about one that fails?  The intent of my
> questions is to make the proposed requirement more lucid.

for the sake of discussion, we could use the system in place at Worldcom
(mentioned in the previous email) that takes a count of the SIP calls.
If we added support recognizing ETS labeled traffic (via the
hypothetical SIP R-P header :-), then those labeled packets that are
recognized could be placed in a separate queue and thus bypass the
queue threshold used for all other non-labeled SIP packets.  It would be
a crude but simplistic way of providing better than best effort service
for certain SIP messages.

An example of one that fails is simply the same mechanism without
the spport to recognize that R-P header -- ie, what we have today.

-ken

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 27 Feb 2003 06:55:24 -0800 (PST)

On Thu, 27 Feb 2003, Ken Carlberg wrote:
    > Please keep in mind that the word "network" was not used in the
    > above excerpt, but rather "application-layer mechanisms" was
    > specifically stated.

Ah, quite true, my apologies.  I just blanched at the thought of a
technical specification containing a requirement for "better than best".
I would hope that some more felicitous phrase might be found prior to
any potential publication.

                                -Bill