Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt

From: "Sanjoy Sen" <[email-masked]>
Date: Mon, 2 Jul 2001 10:02:59 -0500

> -----Original Message-----
> From: Bob Penfield [mailto:[email-masked]]
> Sent: Friday, June 29, 2001 6:37 AM
> To: Brian E Carpenter; midcom
> Subject: Re: [midcom] Re: I-D 
> ACTION:draft-ietf-midcom-framework-02.txt
> 
>
> Being able to set the DS code point is definitely something that
> applications are going to want to do. For example, a SIP 
> proxy acting as a
> midcom agent talking to a middlebox at the border between 
> networks will need
> to instruct the middlebox to set the DSCP in the RTP packets 
> that will flow
> thru the middlebox. The RTP packets will not flow thru the 
> SIP proxy/midcom
> agent. The middlebox is the only place the application will be able to
> affect QoS for the data flows.
> 

Or, the SIP Proxy (MA) may be able to engage a PDP to set the DS filters in
the Middlebox. Does this mean that we may also need to define, in future, an
interface between the MA and the PDP?

Sanjoy

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 02 Jul 2001 12:23:56 -0500

> Sanjoy Sen wrote:
> Or, the SIP Proxy (MA) may be able to engage a PDP to set the DS filters in the Middlebox. Does this mean that we may also
> need to define, in future, an interface between the MA and the PDP?

We won't be changing QOS policy on a per-call basis, so I don't see
why that would be needed.

   Brian

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: Andrew Molitor <[email-masked]>
Date: Mon, 2 Jul 2001 16:21:21 -0500 (CDT)

> why that would be needed.

	I'm not entirely sure what this means, but I do have a comment.
It is certainly desireable to be able to set things QoS and bandwidth
parameters on a call by call (actually on a media-stream-by-media-stream)
basis. Obviously things like video have different bandwidth requirements,
and may have different QoS requirements than, say, an audio stream. It is
not at all clear to me that it's useful to:

	- change QoS/bandwidth parameters on a given stream after
	  it's set up.
	- support fine grained control (probably sufficient to allow
	  a handful of "grades" of service with guidelines, and map
	  a requested service grade into whatever works underneath.
	  E.G an Agent could ask for 'DATA', 'PHONE', 'CD', or 'VIDEO'
	  or something.

	Also, something the IP Telephony chaps will soon want to offer
is 'premium' audio service as well as perhaps 'cheaper' audio service.
Not that I have heard anyone talking about it, but it seems a no-brainer
(and relatively simple) to build equipment capable of delivering
phone/FM/CD quality audio. Then a service provider can turn the ability
to deliver various audio grades into a differentiators and revenue
streams.

	It is clearly desirable to allow something like a SIP Proxy
server to actively provision network elements with QoS/bandwidth
parameters. My personal opinion is that MIDCOM is the right place
to do this -- but I am also happy to concur that MIDCOM should table
that issue in favor of, say, getting something done now.

		Andrew

---

From: Andrew Molitor <[email-masked]>
Date: Mon, 2 Jul 2001 17:20:07 -0500 (CDT)

At risk of being boring and repetitive, let me quote myself:

On Mon, 2 Jul 2001, Andrew Molitor wrote:
> My personal opinion is that MIDCOM is the right place

	Did this part get clipped off of the copy everyone else saw,
or is it simply not clear that this means:

	'I know QoS is out of scope and I agree that it doesn't
	 go in the documents'

	That's what it does mean, for the record.

		Andrew