Subject: RE: [midcom] Re: draft-ietf-midcom-requirements-01.txt

From: "Cedric Aoun" <[email-masked]>
Date: Mon, 2 Jul 2001 13:04:08 +0100

Bob,
I agree that setting dynamically certain flow's priorities might be
required:
-This could be done through the application's signaling and marked at the
endpoint (IP telephony is one of these applications)
-It could also be done at the Middle Box covering the endpoint, this is done
through MIDCOM

So we found an agreement on that. 
This will require that the Middle Box has the mapping of the Midcom Agent
Service Class priorities
to DSCP marking, this is required because there is no "uniform" PHBs between
networks.
Thanks

Cedric

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Friday, June 29, 2001 4:52 PM
To: Aoun, Cedric [QPD:0000:EXCH]
Subject: Re: [midcom] Re: draft-ietf-midcom-requirements-01.txt

----- Original Message -----
From: "Cedric Aoun" <[email-masked]>
To: "'Bob Penfield'" <[email-masked]>
Sent: Friday, June 29, 2001 9:57 AM
Subject: RE: [midcom] Re: draft-ietf-midcom-requirements-01.txt

>
>
> > John,
> > We all agree that the Middle Box is a policy enforcement point, but
> > there is no need to define a PHB on per call, the main purpose of
Diffserv
> > is to do traffic prioritization and assign a behavior for certain type
of
> > traffic classified
> > by the flow priority (the DSCP in our case).
> > These PHBs are on the MB either by manual config or
> > by propping down policies from a Policy Decision Point.
> > I don't see the need to discuss that in the context of MIDCOM.
>
> I disagree. The idea is that a midcom agent be able to "assign" one of
these
> established PHBs to a flow it is enabling thru the middlebox. I don't
think
> anybody wants to use MIDCOM to define PHBs. We just need to be able set
the
> priority for a flow that would otherwise get ordinary best-efforts
> treatment.
>
> <CA> The application server can also request the application end point
> to put the appropriate DSCP setting for the packet. This is already done
in
> most
> IP telephony products.
> But the point is valid for applications that have not developed this
> capability,
> this is required to ensure that the flows are assigned proper
> classification.
> ...Cedric
>
In a multi-domain scenario, QOS treatment needs to be applied within each
domain. An application endpoint in a different network cannot do MPLS
insertion or DSCP setting for PHBs defined in my network. These need to be
applied as the packets enter my network.

(-:bob

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 02 Jul 2001 09:44:03 -0500

> Cedric Aoun wrote:
> 
> Bob,
> I agree that setting dynamically certain flow's priorities might be required:
> -This could be done through the application's signaling and marked at the endpoint (IP telephony is one of these applications)
> 
> -It could also be done at the Middle Box covering the endpoint, this is done through MIDCOM
> 
> This will require that the Middle Box has the mapping of the Midcom Agent Service Class priorities
> to DSCP marking, this is required because there is no "uniform" PHBs between networks.

DSCPs are not priorities. I think the true statement is that it is entirely
appropriate for a middlebox to *also* act as a diffserv node, getting its
diffserv configuration from ... somewhere, not necessarily the midcom agent.
I still object to QOS being shown as a fundamental part of the midcom model,
although I agree that we should not close the door in the design.

   Brian

> applied as the packets enter my network.

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

---

From: "Scott Brim" <[email-masked]>
Date: Fri, 6 Jul 2001 20:38:13 -0400

> although I agree that we should not close the door in the design.

Right, exactly.  There is no reason for midcom to mention QoS, as long
as the requirements draft clearly says the midcom protocol must be
extensible.  Bundling in instructions on diffserv markings would be a
simple extension, just as it is for COPS or RSVP.