Subject: Re: [Tsvwg] Admitted Real Time Services

From: "James M. Polk" <[email-masked]>
Date: Mon, 18 Dec 2006 12:20:52 -0600

At 03:58 PM 12/18/2006 +0100, [email-masked] wrote:
>i would like to know how this document that should deal with specific
>DS configuration slips and starts discussing signaling/call issues

Dimitri - signaling, as in SIP or H.323 signaling?

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

---

From: [email-masked]
Date: Mon, 18 Dec 2006 21:22:43 +0100

i should have been more specific - the whole discussion about signaling is 
beyond the scope this document whether performed at at the network (RSVP) 
or the session layer (SIP) or any other signaling technique being 
currently under discussion at IETF - this doc. should not discuss about 
the call-level but stick to packet-level processing and related operations 
(that should translated in a DS configuration profile)

now, what you're looking at is congestion avoidance and preemption 
technique and i fail to see that the solution for implementing congestion 
avoidance is admission control via parameter-based signaling, it is not 
because the doc. introduces UNI's and NNI's (which i think falls also 
beyond scope) that such kind of approach becomes a suitable solution.

hope this clarifies,
- d.

"James M. Polk" <[email-masked]>
18/12/2006 19:20
 
        To:     [email-masked], Lars Eggert 
<[email-masked]>
        cc:     Fred Baker <[email-masked]>, [email-masked]
        Subject:        Re: [Tsvwg] Admitted Real Time Services