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

From: "Christian Huitema" <[email-masked]>
Date: Fri, 29 Jun 2001 09:21:16 -0700

> Given that the flows that need preferred treatment are being
dynamically
> created and destroyed in the SIP network, how would that work? How
will
> the
> border device know which flows get marked and which don't if it is not
> aware
> of the dynamic flows?

SIP is by no means the only way to initiate transmission of real-time
A/V flows between internet hosts. Other ways include SAP, RTSP,
documentation of SDP streams in web pages, etc. Then, A/V is by no means
the only application that has delay constraints; video games come to
mind, and they definitely don't use SIP. There are at least three
solutions to the marking problem:

* one possibility is to just let the sender do the marking. This works
well in a controlled environment, and is in fact enabled by MGCP for
VoIP solutions.

* another possibility is have a router analyze the traffic, recognize
some applications, and "promote" them. This is in fact the modus
operandi in most corporate networks today, with priorities based on IP
addresses and port ranges.

* yet another possibility is to use explicit signaling, such as RSVP, to
negotiate the right to use this or that marking.

Brian is right when it comes to charter creep. The primary task of this
group is to enable the crossing of firewalls and NATs. The IETF already
has defined standards for managing quality of service. There is no
reason to sneak quality of service work into MIDCOM.

-- Christian Huitema

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

---

From: John LaCour <[email-masked]>
Date: Fri, 29 Jun 2001 11:08:48 -0700

> From: Christian Huitema [mailto:[email-masked]]

> * another possibility is have a router analyze the traffic, recognize

s/router/middlebox

> reason to sneak quality of service work into MIDCOM.

I agree about charter creep, but lets not paint ourselves into a
corner that excludes it for future consideration.

> -- Christian Huitema

-John

---

From: "Fernando Cuervo" <[email-masked]>
Date: Fri, 29 Jun 2001 15:07:01 -0400

I agree with you, an agent may benefit from the Midcom protocol being able
to explicitly signal QoS service requirements, in addition to f/w and NAT.
Therefore, we must balance this against the undesirability of
"charter-creep".

Fernando Cuervo

> -----Original Message-----
> From:	John LaCour [SMTP:[email-masked]]
> Sent:	Friday, June 29, 2001 2:09 PM
> To:	'Christian Huitema'; [email-masked]'
> Subject:	RE: [midcom] Re: I-D
> ACTION:draft-ietf-midcom-framework-02.txt
> 
> 
>

---

From: Randy Turner <[email-masked]>
Date: Fri, 29 Jun 2001 15:09:57 -0700

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.

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

---

From: Mark Duffy <[email-masked]>
Date: Fri, 29 Jun 2001 18:37:09 -0400

At 02:49 PM 6/29/01 -0700, Christian Huitema wrote:
>> I don't really have the perspective to comment on what midcom was
>> "intended
>> for".   Obviously, the charter is focused on firewall and NAT
>middleboxes.
>> However the promise of midcom seems to be to allow middleboxes of many
>> sorts to do whatever their particular purpose in life is, while
>offloading
>> from them the need to understand every application in order to be
>aware of
>> which flows are for which apps.  This is certainly attractive from the
>> perspective of classifying packets by *application* (and not just by
>> protocol and port numbers).
>
>Please register a violent disagreement. Many of us see allowing
>"middleboxes of any sort" as a license to break the Internet in whatever
>ways may fit someone's business model. While the IETF has no business
>validating business models, its goal is certainly to develop a better
>Internet, not to break it. If the group had proposed a charter to
>"develop any kind of transparency breaking box in the middle of the
>network", then the charter would most probably not have been approved.
>
>-- Christian Huitema

Christian,

Although you have placed the words in quotes, you will notice above that I
didn't say middleboxes of *any* sort but rather middleboxes of *many* sorts.

And the larger context of my message was about a middlebox function that
would be entirely transparent except to the Diffserv codepoint, which it
might mark.  In fact, it is a central principle of Diffserv for DSCPs to be
remarked in the network, not passed transparently end to end.

If you'd like to disagree with that, fine.  But please do not manufacture
positions I have not expressed and then disagree with them.  :-)

Regards, Mark

---

From: "Fernando Cuervo" <[email-masked]>
Date: Fri, 29 Jun 2001 11:41:46 -0400

What is important to keep in mind is that it is possible that a border 
device may provide QoS marking, NAT and pin-hole "services" and
that this combination is actually a useful one. Therefore, if a single
protocol
can realise this service behaviour between the agent and the middlebox 
then that would simplify the interface. The protocol would then be COPS or 
something like RSVP where a service requirement is specified in conjunction
with  policy objects.

Fernando Cuervo

> From:	Brian E Carpenter [SMTP:[email-masked]]
> Sent:	Friday, June 29, 2001 10:05 AM
> To:	Bob Penfield
> Cc:	[email-masked]
> Subject:	Re: [midcom] Re: I-D
> Bob Penfield wrote:
> > To: <[email-masked]>
> > Sent: Thursday, June 28, 2001 5:59 PM
> > Subject: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt
> > 
> > > I'm a bit puzzled by the isolated reference to Diffserv
> > > sitting in the middle of Figure 1, and the very brief mention
> > > at the beginning of the Introduction. While it is true that
> > > one possible location for diffserv classification and shaping
> > > is in a border router which is also a NAT and/or firewall,
> > > it can be done in any router or in hosts. And it has its
> > > own policy distribution mechanisms (COPS, SNMPCONF).
> > > So I would recommend removing the two brief references.
> > > I don't see why diffserv would be a midcom issue.
> > 
> > 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.
> 
> No, wrong model. The border device (whether it is the midcom version of
> a middlebox, or any old router) will apply diffserv classification and
> marking according to policy delivered from the diffserv policy server
> (a.k.a. PDP) by COPS or SNMPCONF. That is the diffserv management
> model; there is no need for the SIP proxy to enter the picture.
> 
>   Brian
>