Subject: [Tsvwg] Admitted Real Time Services

From: Fred Baker <[email-masked]>
Date: Wed, 13 Dec 2006 10:54:54 -0800

Per Lars' permission, I have posted a new draft at the IETF Internet  
Drafts site. It is tagged draft-ietf-tsvwg-admitted-realtime- 
dscp-00.txt, and is a working group draft. It is the same draft I had  
in under my name with the dates changed to reflect today. Pending its  
posting, you may review it at

     ftp://ftpeng.cisco.com/fred/tsvwg/draft-ietf-tsvwg-admitted- 
realtime-dscp-00.txt

I have also posted the following for working group discussion. -01 is  
the proposed new draft, and the -00-01 file is a diff between the two.

     ftp://ftpeng.cisco.com/fred/tsvwg/draft-ietf-tsvwg-admitted- 
realtime-dscp-00-01.txt
     ftp://ftpeng.cisco.com/fred/tsvwg/draft-ietf-tsvwg-admitted- 
realtime-dscp-01.html
     ftp://ftpeng.cisco.com/fred/tsvwg/draft-ietf-tsvwg-admitted- 
realtime-dscp-01.txt
     ftp://ftpeng.cisco.com/fred/tsvwg/draft-ietf-tsvwg-admitted- 
realtime-dscp-01.xml

The proposed updates include:

  - proposed changed text for section 2.2.3 submitted by Kwok Ho Chan
  - further changes to that text along the lines of text suggested by  
Georgios Karagiannis
  - updates required by the idnits tool
  - updates to include a video class as requested by Dave McDysan

There has been a fairly extensive discussion in private email among  
the authors and the chairs of the working group, parallel to the  
discusison on the list. Much of it has centered on the need or lack  
of it for a separate Admitted Multimedia Conferencing class. I'd like  
to go over that a little.

The issue prompting this draft is that the use of capacity admission  
in RFC 4594 is optional, reflecting present service characteristics,  
which usually omit capacity admission. The reason they do is that  
they make assumptions about the underlying network - it is entirely  
within a LAN environment, or it has broadband access that is  
uncongested, or that if the broadband access becomes congested the  
user has the ability to disable competing traffic, or in the IMS  
case, there is by definition an engineered path suitable for the  
application in question. With increasing mobility (wireless mesh and  
manet networks being the poster children), this is harder to  
accomplish, and those who have deployed enterprise VoIP networks will  
report that the engineering implied can be painful.

But if emergency services, such as e-911, GETS, and the like are to  
be deployed, the ability to authenticate the caller and request and  
authorize the usage, and if necessary to do more dramatic things to  
enhance the probability of call completion, are critical. And once  
one accepts this, the deployment of normal services that have the  
same capabilities becomes attractive. That is the point of this draft  
- making available a service class that requires and depends on  
authenticated admission.

The question is whether this issue also applies to video. I suspect  
that it does not: while Skype and presumably others support a low- 
rate video conferencing capability in their services and current  
telephone instruments have options for the same thing, the agencies  
requesting support for video services have merely expressed desire,  
not requirement for this type of service. The place where video  
services are most likely to be used for emergency use are more likely  
to be as a replacement for H.321 ISDN service, which often runs at  
384 KBPS or higher and to be useful has to run with little or no  
frame loss, and as such in many deployments already uses RSVP  
admission services. This argues that a better way to deploy this  
class of video service is to REQUIRE rather than RECOMMEND the use of  
authenticated capacity admission in the Multimedia Conferencing Class  
of RFC 4594 rather than building a second and parallel class that  
requires it.

To that end, I personally would favor an update to RFC 4594 making  
that statement. That would involve less edits than I have made to  
this document, and so would back out the paragraph requesting a DSCP  
for admitted video from IANA and the various references to "two  
DSCPs" and the "Multimedia Conferencing Class". I would instead make  
a simple statement somewhere stating that RFC 4594's Multimedia  
Conferencing Class is updated to require capacity admission, and that  
admission should follow essentially the same algorithms proposed here  
for voice.

One question that has arisen in private conversation that I will deal  
with publicly relates to the requirement for separate voice and video  
classes. The issue is explained, I believe, in RFC 4594 and in http:// 
tools.ietf.org/html/draft-ietf-tsvwg-diffserv-class-aggr. Voice and  
video interact poorly on a low speed (5 MBPS and below) link; both  
want to minimize jitter and loss, and video is very adversely  
affected by loss, but video inserts a fair degree of jitter to voice  
if they compete for the same queue due to its large packet size.  
Hence, on low speed links, one wants to separate them - which  
requires a DSCP. Also, admission services often distinguish them,  
wanting to allocate a certain amount of bandwidth to voice and a  
certain amount to video. However, on LAN and other higher speed  
interfaces, the jitter issue falls into the noise. This is the reason  
that RFC 4594 separates them while draft-ietf-tsvwg-diffserv-class- 
aggr combines them into a common service class.

I would appreciate a review of the proposed text as I have posted and  
further recommendations.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 18 Dec 2006 10:13:56 +0100

Folks,

the draft is now available from the repository. As requested by the  
editors, please review the changes that they are proposing for  
discussion for the next version.

We had quite a number of WG members argue in favor of adopting this  
draft as a WG item; I expect especially this group to be interested  
in reviewing and discussing ongoing revisions.

Thanks,
Lars

On Dec 13, 2006, at 19:54, Fred Baker wrote:
> Per Lars' permission, I have posted a new draft at the IETF  
> Internet Drafts site. It is tagged draft-ietf-tsvwg-admitted- 
> realtime-dscp-00.txt, and is a working group draft. It is the same  
> draft I had in under my name with the dates changed to reflect  
> today. Pending its posting, you may review it at
>
> I have also posted the following for working group discussion. -01  
> is the proposed new draft, and the -00-01 file is a diff between  
> the two.
>
>  - further changes to that text along the lines of text suggested  
> by Georgios Karagiannis
> of it for a separate Admitted Multimedia Conferencing class. I'd  
> like to go over that a little.
>
> The issue prompting this draft is that the use of capacity  
> admission in RFC 4594 is optional, reflecting present service  
> characteristics, which usually omit capacity admission. The reason  
> they do is that they make assumptions about the underlying network  
> - it is entirely within a LAN environment, or it has broadband  
> access that is uncongested, or that if the broadband access becomes  
> congested the user has the ability to disable competing traffic, or  
> in the IMS case, there is by definition an engineered path suitable  
> for the application in question. With increasing mobility (wireless  
> mesh and manet networks being the poster children), this is harder  
> to accomplish, and those who have deployed enterprise VoIP networks  
> will report that the engineering implied can be painful.
>
> same capabilities becomes attractive. That is the point of this  
> draft - making available a service class that requires and depends  
> on authenticated admission.
>
> services are most likely to be used for emergency use are more  
> likely to be as a replacement for H.321 ISDN service, which often  
> runs at 384 KBPS or higher and to be useful has to run with little  
> or no frame loss, and as such in many deployments already uses RSVP  
> class of video service is to REQUIRE rather than RECOMMEND the use  
> of authenticated capacity admission in the Multimedia Conferencing  
> Class of RFC 4594 rather than building a second and parallel class  
> that requires it.
>
> this document, and so would back out the paragraph requesting a  
> DSCP for admitted video from IANA and the various references to  
> "two DSCPs" and the "Multimedia Conferencing Class". I would  
> instead make a simple statement somewhere stating that RFC 4594's  
> Multimedia Conferencing Class is updated to require capacity  
> admission, and that admission should follow essentially the same  
> algorithms proposed here for voice.
>
> One question that has arisen in private conversation that I will  
> deal with publicly relates to the requirement for separate voice  
> and video classes. The issue is explained, I believe, in RFC 4594  
> and in http://tools.ietf.org/html/draft-ietf-tsvwg-diffserv-class- 
> aggr. Voice and video interact poorly on a low speed (5 MBPS and  
> below) link; both want to minimize jitter and loss, and video is  
> very adversely affected by loss, but video inserts a fair degree of  
> jitter to voice if they compete for the same queue due to its large  
> packet size. Hence, on low speed links, one wants to separate them  
> - which requires a DSCP. Also, admission services often distinguish  
> them, wanting to allocate a certain amount of bandwidth to voice  
> and a certain amount to video. However, on LAN and other higher  
> speed interfaces, the jitter issue falls into the noise. This is  
> the reason that RFC 4594 separates them while draft-ietf-tsvwg- 
> diffserv-class-aggr combines them into a common service class.
>
> I would appreciate a review of the proposed text as I have posted  
> and further recommendations.