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

From: [email-masked]
Date: Tue, 3 Jul 2001 13:31:23 +0100

Brian,

> > >
> > > 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?
> 
> We won't be changing QOS policy on a per-call basis, so I don't see
> why that would be needed.
> 
>    Brian
> 

The settings of DS bits, or TOS bits _may_ have different meanings on either
side of a Middlebox (i.e. where it is firewalling between two networks). In
such cases it may be necessary for a MIDCOM Agent to request a Middlebox to
apply a specific mapping to a specific flow traversing the Middlebox. This
is a definite requirement and is IMHO certainly within the scope of MIDCOM
to allow. End-end signalling for QoS is a different matter altogether and so
clearly out of scope.

regards

Richard

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

---

From: "Melinda Shore" <[email-masked]>
Date: Tue, 3 Jul 2001 09:06:08 -0400

> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Tuesday, July 03, 2001 8:31 AM
> Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt

> End-end signalling for QoS is a different matter altogether and so
> clearly out of scope.

Any QoS signaling is out of scope.

Melinda

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Jul 2001 09:55:49 -0500

Richard (and Andrew Molitor, to clarify what I meant),

Indeed a midcom middlebox can apply diffserv traffic conditioning,
and the diffserv regime can be different downstream from upstream
(in which case the midcom middlebox is at a diffserv domain boundary).
But this applies to diffserv traffic aggregates, not to individual
flows, as does everything in diffserv. We can't be changing the
parameters of a traffic aggregate each time a flow starts & stops.

Now, if you mean that when a new flow starts (and stops), the diffserv
classifier in the midcom middlebox needs to be told the relevant 5-tuple
so that it can create (and destroy) a classifier for that flow, that
I can see, but it's the only scaleable flow-specific change I can imagine.

Regards
   Brian