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

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

Randy Turner wrote:
> 
> 
> DiffServ *can* be end-to-end if endpoints and intermediaries follow the
> guidelines for the standard set of codepoints, as the relate to EF or AF
> forwarding.

But we cannot rely on it. It requires all ISPs on the path to have
interlocking SLAs and that is not a safe assumption.

   Brian

> 
> Randy
> 
> -----Original Message-----
> From: Bob Penfield
> To: Brian E Carpenter; Mark Duffy
> Cc: [email-masked]
> Sent: 6/29/01 2:42 PM
> Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt
> 
> ----- Original Message -----
> From: "Brian E Carpenter" <[email-masked]>
> To: "Mark Duffy" <[email-masked]>
> Cc: "Bob Penfield" <[email-masked]>; <[email-masked]>
> Sent: Friday, June 29, 2001 5:16 PM
> Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt
> 
> > Mark Duffy wrote:
> > >
> > > >Diffserv doesn't have per-flow classifiers, so there is nothing a
> SIP
> > > >proxy can say for a single new flow. The policy system has to
> define a
> > > >classifier for each *type* of traffic, not for individual flows.
> This
> is
> > > >done globally per diffserv domain and is relatively static.
> > > >
> > > >The classifier will be given the appropriate classifier
> specifications
> > > >by the diffserv policy system. These are n-tuple specifications
> just
> > > >like any other. If you grok MIB they look like:
> > > >
> > > >DiffServSixTupleClfrEntry ::= SEQUENCE {
> > > >    diffServSixTupleClfrId           INTEGER,
> > > >    diffServSixTupleClfrDstAddrType  InetAddressType,
> > > >    diffServSixTupleClfrDstAddr      InetAddress,
> > > >    diffServSixTupleClfrDstPrefixLength InetAddressPrefixLength,
> > > >    diffServSixTupleClfrSrcAddrType  InetAddressType,
> > > >    diffServSixTupleClfrSrcAddr      InetAddress,
> > > >    diffServSixTupleClfrSrcPrefixLength InetAddressPrefixLength,
> > > >    diffServSixTupleClfrDscp         DscpOrAny,
> > > >    diffServSixTupleClfrProtocol     Unsigned32,
> > > >    diffServSixTupleClfrDstL4PortMin InetPortNumber,
> > > >    diffServSixTupleClfrDstL4PortMax InetPortNumber,
> > > >    diffServSixTupleClfrSrcL4PortMin InetPortNumber,
> > > >    diffServSixTupleClfrSrcL4PortMax InetPortNumber,
> > > >    diffServSixTupleClfrStatus       RowStatus
> > > >}
> > >
> > > Yes, but since the flows of type 'SIP' come on dynamic ports, you
> can't
> > > readily match them using a classifier like that.
> >
> > There's nothing to prevent you defining a classifier that uses
> > some other n-tuple that does identify media traffic.
> >
> > > However, a middlebox aka
> > > diffserv-domain-edge-traffic-conditioning-box that is aware of which
> flows
> > > are SIP could apply a *static* policy that says mark SIP packets (or
> > > perhaps, SIP packets to/from certain addresses) with a certain DSCP.
> And
> > > in the spirit of midcom, one would want the midcom agent to tell the
> > > middlebox about this flow (perhaps not what DSCP to use, but that it
> is
> SIP).
> >
> > It would all be much simpler if the source of the media stream marked
> its
> > own packets; then neither the proxy nor the middlebox need to worry
> about
> it.
> > That is in fact the simplest realisation of diffserv.
> 
> But diffserv is not end-to-end, right? If the flow is traversing several
> Autonomous Systems, won't each AS apply different QOS measures? The
> combination of a SIP proxy and a middlebox can constitute an ALG which
> is
> often implemented as what SIP calls a back-to-back user agent which
> terminates and re-generates the flow. In this case, the middlebox
> becomes
> the source of the media flow within the local AS.
> 
> >
> > All this goes to show that it's a complex topic, beyond what I thought
> midcom
> > was intended for.
> >
> >    Brian
> >
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/midcom

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

---

From: "Fleischman, Eric W" <[email-masked]>
Date: Mon, 2 Jul 2001 14:31:09 -0700

>From: Andrew Molitor [mailto:[email-masked]]
>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:

When our peers wrote that QoS is outside of Midcom's scope, they weren't
meaning that Midcom Agents -- or any other appropriate device -- can't do
QoS. They were intending, rather, that there is NOTHING SPECIAL QoS-wise
about Midcom -- that Midcom has no special QoS requirements nor any special
"binding" to QoS that needs to be documented in our specs -- and that QoS 
issues are therefore out of our scope. 

When you make your implementation, therefore, you can do anything appropriate 
regarding QoS. However, you are doing this for standard QoS-related reasons, 
not because of the midcom protocol.

---

From: "Cedric Aoun" <[email-masked]>
Date: Wed, 4 Jul 2001 07:57:53 +0100

Sorry if I'm repeating things that other WG members already mentioned ...

"It is clearly desirable to allow something like a SIP Proxy
server to actively provision network elements with QoS/bandwidth
parameters.."

Andrew I totally agree with you, but we need to stick with delivering the
framework 
and protocol requirements for a protocol that allows negotiation and control
of
Packet filtering and NAT Middle Box functions. Within these 2 documents (we
should express that the protocol could be easily extended to control other
Middle
Box functions(Qos and others, this is already mentioned in the documents).

In case we fail to deliver our current expected work items, we won't be 
re-chartered to start going into the protocol spec work and try to find an
existing protocol
(with probably some extensions) that will meet the MIDCOM protocol
requirements.
After being re-charted we need to see how we could get Qos and other
functions to be 
handled by MIDCOM.
Thanks
Cedric