Subject: RE: [Ieprep] new individual draft submission

From: "Nguyen, An" <[email-masked]>
Date: Fri, 21 Jun 2002 11:33:21 -0400

Ken,

Because this contribution is about the elastic service for emergency
communications, do you think we should have a sentence or a paragraph that
talks about going from high speed codecs (e.g., G.711) to low codecs (e.g.,
G.723.1)in times of traffic congestion for authorized emergency workers
instead of dropping the calls completely? Of course, this will affect the
QoS of the calls. I don't know if it is in the scope of this document.

An

-----Original Message-----
From: Ken Carlberg [mailto:[email-masked]]
Sent: Thursday, June 20, 2002 6:50 AM
To: [email-masked]
Subject: [Ieprep] new individual draft submission

Hello,

An individual contribution titled "Requirements for Authorized Emergency
Communications Using Elastic Service" has been submitted to the I-D
editor.  Its an attempt to come up with some requirements that can be
applied to elastic traffic/applications.

and BEFORE anyone hits the panic button :-)....please read the following
abstract for the portion of you that don't have the time to read all the 
drafts that get produced.

The draft itself has some incomplete sections that can be either expanded
or taken out.  It would be great to have area experts/implementors 
participate -- we did this with the SMTP section and took a lessons-learned
approach from an attempt last year to consider adding a priority field
in SMTP.

for those that do have time to read, and while waiting for the draft
to perculate through the repositories, one can obtain a version from:

http://www.cs.ucl.ac.uk/staff/k.carlberg/tmp/draft-carlberg-ieprep-elastic-
requirements-00.txt

-ken

-----------------------------------------------------

Abstract

   The objective of this draft is to present a set of requirements to
   address requests by users of authorized emergency communications for
   better than best effort service for elastic service.  We stress the
   word "request" versus guarantee, and we do NOT advocate broad
   sweeping changes to elastic applications.  This document provides
   background information on emergency communications and presents
   suggested do's and don'ts in addressing the issue of requirements
   for elastic services.  Finally, examples of requirements for specific
   applications are presented.

_______________________________________________
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: Fri, 21 Jun 2002 13:26:18 -0400

> QoS of the calls. I don't know if it is in the scope of this document.

That kind of thinking makes sense, at least as an example of one
way some operators or users might deal with congestion, etc...

I'm not a fan of levying any implementation-specific requirements
onto operators, figuring that different operators have different networks
and might choose different mechanisms/implementations to meet whatever
high-level requirements might exist.  But examples seem fine...

Ran

---

From: Ken Carlberg <[email-masked]>
Date: Sat, 22 Jun 2002 16:48:53 +0100

Hello An,

> QoS of the calls. I don't know if it is in the scope of this document.

a nice head scratcher.  I'm probably being picky, but my feeling is that 
the specific example above is out of scope of the document because there 
isn't an automated means in your description of going from something like 
G.711 to G.723.  Lacking something in the application or a server/gateway 
middlebox to accomplish the downgrade, it relies on a person-in-the-loop 
action.

however, a generalization of your example IS something I can put in the 
issues portion of the draft to convey that the placement of a label 
doesn't automatically mean better service in the form of additional 
resources.  instead, it can simply be a trigger for achieving a different
type of service -- e.g., a lower form of end-to-end QoS in order to achieve
communication.

-ken

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 23 Jun 2002 14:01:53 -0500

>middlebox to accomplish the downgrade, it relies on a person-in-the-loop 

The interface in the middle (that has the active session in question) where
congestion is occurring must notify (the UAs directly) or something else to
notify the UAs of the congestion situation and to ask/request/mandate that
session downgrade to use less BW. 

Hmmmm.....

SIP already has the capability to alter an existing session through
reINVITE with different SDP parameters (such as using a lower BW codec).
Currently the UAS can either accept this request or reject it, or propose
an again different SDP (parameters).

The issue you described above lacks the ability of the network to
inform/notify a UA (or both) that an RTP session it has active needs to be
adjusted, because the network isn't a stateful component in SIP
architectures, nor will it know (possibly ever under any circumstances) the
particulars of a (any) session traversing it.

This should be easy with a Call Agent Architecture, and perhaps the comment
in the ID can state something to that affect (i.e. "... in the case where
the network is statefully aware of the endpoints communicating via this x
congested interface, to notify them that a codec downgrade is (about to or
going to) occur (provided the auditcapabilities of each endpoint or
termination) *can* perform this function)...")

>type of service -- e.g., a lower form of end-to-end QoS in order to achieve

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Senior Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com