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

From: [email-masked]
Date: Thu, 14 Jun 2001 07:08:21 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Middlebox Communication Working Group of the IETF.

	Title		: Middlebox Communication Architecture and framework
	Author(s)	: P. Srisuresh, J. Kuthan, J. Rosenberg,
                          A. Molitor, A. Rayhan
	Filename	: draft-ietf-midcom-framework-02.txt
	Pages		: 42
	Date		: 13-Jun-01
	
There are a variety of intermediate devices in the Internet today
that require application intelligence for their operation. 
Datagrams pertaining to real-time streaming applications such
as SIP and H.323 and peer-to-peer applications such as Napster 
and NetMeeting cannot be identified by merely examining packet
headers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-midcom-framework-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-midcom-framework-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Jun 2001 16:59:05 -0500

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.

   Brian

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

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 29 Jun 2001 07:37:01 -0400

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 28, 2001 5:59 PM
Subject: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt

> 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.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Jun 2001 09:04:36 -0500

> 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

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 29 Jun 2001 11:07:40 -0400

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "Bob Penfield" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, June 29, 2001 10:04 AM
Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt

> model; there is no need for the SIP proxy to enter the picture.
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?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Jun 2001 10:45:54 -0500

> border device know which flows get marked and which don't if it is not aware

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
}

in other words source and destination address ranges, DSCP, protocol #, 
port ranges, any of which can be wild-carded. You might set a classifier
up for a few hours, but I would expect them to be essentially
permament and certainly they don't change on a flow-by-flow basis.
If you want that, use Integrated Services.

All this is orthogonal to midcom.

   Brian

---

From: Mark Duffy <[email-masked]>
Date: Fri, 29 Jun 2001 15:59:27 -0400

>    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.  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).

-Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Jun 2001 16:16:07 -0500

Mark Duffy wrote:
> 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

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.

All this goes to show that it's a complex topic, beyond what I thought midcom
was intended for.

   Brian

---

From: "Melinda Shore" <[email-masked]>
Date: Fri, 29 Jun 2001 17:35:11 -0400

> 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

> All this goes to show that it's a complex topic, beyond what I thought midcom

Indeed, and I think we received a pretty clear message to take
the scope outlined in the charter very seriously.

If someone wants to write a draft on the use of midcom for pushing
packet markings out to routers they're certainly free to do that,
but it is out of scope for midcom deliverables and the material
would not be incorporated into the framework or requirements 
document.

Melinda

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 29 Jun 2001 17:42:32 -0400

----- 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

> 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.

---

From: Mark Duffy <[email-masked]>
Date: Fri, 29 Jun 2001 17:38:01 -0400

>some other n-tuple that does identify media traffic.

What n-tuple would that be?  In some cases local knowledge might allow the
source or dest addresses to be used but in other scenarios it wouldn't.

>That is in fact the simplest realisation of diffserv.

I certainly agree with that.
However, in cases where the source does not so mark, a carrier might like
to identify the traffic and appropriately mark it on their subscriber's
behalf, as a value-added service.  This of course requires the carrier to
somehow identify the appropriate flows.

>All this goes to show that it's a complex topic, beyond what I thought midcom

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).

-Mark

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 29 Jun 2001 17:41:56 -0500 (CDT)

On Fri, 29 Jun 2001, Brian E Carpenter wrote:
> [ re: diffserv Stuff ] 

	I could be wrong on this, but I am pretty sure that it
is impossible to identify a UDP packet as RTP, if all you have is the
packet. There are probably some heuristics you could apply ("pretty
small, big port numbers, destination even, a couple of magic numbers
at this offset and that") which might be enough, but isn't certain.

	I personally am happy to allow QoS features to fall under the
aegis of "future extensions of the extensible MIDCOM protocol" and
worry about them later. Of course, if MIDCOM is accidentally designed
to make THAT extension impossible, that would be bad. I think we have
enough eyes on the ball to prevent that.

		Andrew