Subject: Re: [Tsvwg] Admitted Real Time Services

From: [email-masked]
Date: Mon, 18 Dec 2006 15:58:12 +0100

i would like to know how this document that should deal with specific
DS configuration slips and starts discussing signaling/call issues 

the point is even not whether one does consider that RSVP is suitable
or not - it is simply outside the scope of the document -

thanks,
- d.

Lars Eggert <[email-masked]>
18/12/2006 10:13
 
        To:     Fred Baker <[email-masked]>
        cc:     [email-masked]
        Subject:        Re: [Tsvwg] Admitted Real Time Services

< Attachment smime.p7s removed >

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