Subject: [midcom] Terms needing definition or replacement

From: Melinda Shore <[email-masked]>
Date: Wed, 05 Sep 2001 10:58:23 -0400

Ruleset
Pinhole
Connection
Pinhole-descriptor (the thing describing the state that's been
  created on the middlebox)
flow/resource

Melinda

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

---

From: Mark Duffy <[email-masked]>
Date: Wed, 05 Sep 2001 19:04:46 -0400

>  created on the middlebox)

Is that an invitation to propose terms/definitions?
I thought someone got sent off from London to do that?
Anyway, here is a proposal for 5 terms to obsolete the above ones.  The
first two describe phenomena that exist (already) in the network; the last
three describe midcom artifacts.

  Microflow    A single instance of an application-to-application flow of
packets which is identified by source address, source port, destination
address, destination port and protocol id.   [[That is the definition from
RFC 2475, Diffserv Arch.]]  In a middlebox connected to multiple address
realms with overlapping address spaces, some additional criterion besides
the above-listed 5-tuple will be needed to uniquely identify a microflow.

  Application Flow   The union of all microflows attributable to a single
application session.  The exact nature of this will vary with the application.

  Filter Spec   Packet classifier information that identifies a set of
packets to be treated a certain way by a middlebox.  Depending on its
value, a filter spec may refer to something as specific as a microflow
originated in a certain direction, or as general as "all packets".   [[Term
adapted from rfc 2205 RSVP.]]

  Flow Spec   Description of the middlebox treatment/service to be applied
to a set of packets.  May also contain auxilliary information such as
timeout values, owning agent, etc.   [[Term taken from rfc 2205 RSVP.
Definition changed to be midcom-relevant.]]

  Flow Descriptor   The combination of a filter spec and one or more flow
specs.  Packets matching the filter spec are to be treated according to the
associated flow spec(s).  [[Term adapted from rfc 2205 RSVP.]]

---

From: Scott Brim <[email-masked]>
Date: Wed, 5 Sep 2001 19:15:59 -0400

> Ruleset

A set of rules which are installed and removed as a unit.  A combination
of a filtering (matching) specification and one or more action
specifications.  How complex these can be is not defined.

(This is the generic I prefer.  It's specific, it's not ambiguous, and
it includes all the functions of all the others, e.g. pinhole).

> Pinhole

A ruleset where the main action specification is either to allow packets
to traverse the middlebox or to allow it through with address and/or
port translation.  

(If you want to keep using this word, I suggest separating out the two
different kinds of pinholes.  "translated" versus "straight-through"
pinholes, maybe.)

> Connection

Rewrite to eliminate all occurrences of this word.  Don't assume any
state maintenance mechanism.

>   created on the middlebox)

Ruleset.

> flow/resource

Eliminate.

> Melinda

..Scott

---

From: Scott Brim <[email-masked]>
Date: Thu, 6 Sep 2001 10:17:16 -0400

On Wed, Sep 05, 2001 07:04:46PM -0400, Mark Duffy allegedly wrote:
> Is that an invitation to propose terms/definitions?  I thought someone
> got sent off from London to do that?  Anyway, here is a proposal for 5
> terms to obsolete the above ones.  The first two describe phenomena
> that exist (already) in the network; the last three describe midcom
> artifacts.

I've found that people generally have trouble getting used to RSVP
terminology.  In particular, it would seem intuitive that a "flow spec"
should describ a flow, as opposed to a scheduling treatment of a flow.
You've gone further and you're defining a flow spec as one or more rules
for modifying/dropping the packets in a flow.  It doesn't feel exactly
intuitive.  The phrase I'm used to is "transform rules".  I made that a
bit more intuitive in my proposal and suggested "action specifications".

> the above-listed 5-tuple will be needed to uniquely identify a microflow.

We've agreed that the midcom protocol will make it possible to define
rules for 5-tuples as you describe them above, but that the protocol
will not limit you to only being able to match 5-tuples.  Even in
diffserv, and in MPLS, classification at the edge is a separate issue
from treatment in the network and can use any criteria it wants.  A
middlebox will act upon a set of packets which match a filter spec -- it
won't (necessarily) work in units of microflows.  So, what use is this
definition for midcom?  The only use I see is when we are presenting
examples, so I suppose this will be useful in a framework document, but
that's all.

> application session.  The exact nature of this will vary with the application.

Same.  Good for examples.

> adapted from rfc 2205 RSVP.]]

OK.

> associated flow spec(s).  [[Term adapted from rfc 2205 RSVP.]] 

As I said above, the problem with these is that the terms suggest
meanings other than the ones you've provided

I assume you've read my suggestions.

..Scott

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 7 Sep 2001 09:29:32 -0700 (PDT)

> it includes all the functions of all the others, e.g. pinhole).

Rules are middlebox function specific. Filters in the case of a firewall
and address maps and BINDs in the case of NAT.

> different kinds of pinholes.  "translated" versus "straight-through"

A pinhole, in my mind, is simply a filtering rule - a specific tuple
to be permitted or denied by a firewall.

> state maintenance mechanism.
Agreed. I suggest replacing with "MIDCOM session" to be defined 
as follows.

   MIDCOM session is defined to be a lasting association between
   a MIDCOM agent and a middlebox. The MIDCOM session is not 
   assumed to imply any specific transport layer protocol. 
   Specifically, this should not be construed as refering to a 
   connection-oriented TCP protocol.

> >   created on the middlebox)

See my comment above.
 
> Eliminate.
Are you saying, eliminate the definition of a middlebox resource
(or) eliminate the discussion on middlebox resource?
 
> ..Scott

cheers,
suresh

=====

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

---

From: Scott Brim <[email-masked]>
Date: Fri, 7 Sep 2001 13:06:20 -0400

> and address maps and BINDs in the case of NAT.

I think you're agreeing that "rule" is an appropriate generic term, but
disagreeing on "filter".  Tell me if that's not true.  Would "matching"
be better than "filtering"?

> to be permitted or denied by a firewall.

Exactly.  A pinhole is the reification of a rule.

>    connection-oriented TCP protocol.

This looks good to me.  With this definition we can keep 'session'.

> > >   created on the middlebox)

and my response.  I'm not sure if you're saying 

> (or) eliminate the discussion on middlebox resource?

Eliminate the use of the term.  I believe the way "resource" has been
used it's synonymous with "ruleset".  That is, a bit of state which can
be installed or removed through the midcom protocol.

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 7 Sep 2001 20:27:12 -0700 (PDT)

> disagreeing on "filter".  Tell me if that's not true.  Would "matching"
Right.

> be better than "filtering"?

I do not like force-fitting all middlebox functions into the box of
firewall-like ACL(or filter) based action devices. Why cant rules 
exist as address maps or port maps or in whatever form that is 
appropriate for the middlebix function?

> Exactly.  A pinhole is the reification of a rule.

The point I was trying to make is that the connotation of pinhole is
limited to firewall-only, or at most to policy-based middlebox functions.
I dont believe, this is a generic middlebox function term.

OK. 
> and my response.  I'm not sure if you're saying 
Right. This was a repeat term. Defined earlier.

> be installed or removed through the midcom protocol.
Disagree. The term resource can be an ACL, an address BIND, a port BIND
or a NAT session descriptor etc.

regards,
suresh

---

From: Scott Brim <[email-masked]>
Date: Sun, 9 Sep 2001 18:11:32 -0400

> appropriate for the middlebix function?

But ... address and port maps (in the NAT sense, right?) are not
matching rules, they're action rules.  A ruleset contains both.

> or a NAT session descriptor etc.

I see.  Then, could we use the more specific terms when we can?

..Scott