Subject: Re: [midcom] Framework comments & suggestions

From: "Bob Penfield" <[email-masked]>
Date: Wed, 1 Aug 2001 07:41:17 -0400

----- Original Message -----
From: "Mark Duffy" <[email-masked]>
To: "Andrew Molitor" <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 31, 2001 11:53 PM
Subject: Re: [midcom] Framework comments & suggestions

> At 10:40 AM 7/31/01 -0500, Andrew Molitor wrote:
> ...
> > In the second place, the distinction is, as I understand it,
> >this:
> >
> > In-path agents use information from IP packets IP
> > addressed to the agent host.
> > Out-of-path agents use information from IP packets
> > IP addressed to some other host.
>
> This was not my understanding.  I am surprised in fact not to see any
> responses to the above post (so far).  Does the silence mean everyone
> agrees with the above statement?  I guess we can at least conclude that
the
> definition of in-path agent "...devices that are naturally within the
> message path of the application" is too vague!
>
> Andrew's definition strikes me as unnecessarily restrictive of what can be
> an in-path agent (and therefore an in-scope agent :-)
>
> Consider the pre-midcom case where a middlebox, say a firewall, embeds
> application intelligence in order to do its job.  None of the application
> packets would be IP-addressed to the firewall.  Now consider the
> midcom-ized evolution of that picture.  We can shift the application
> intelligence out of that firewall and into a midcom agent that is within
> the path traversed by the packets.  Why should it be a precondition to
> doing so that the application now address its packets to the agent?  All
> this serves to do is to prevent (as a side effect) the use of midcom for
> any application that is not using some sort of proxy.

An "invisible" agent that was in-path would have to be another middlebox on
the path/pipe as the firewal/NAT middlebox. I suppose that is not illegal,
but then you would have all the packets traversing (data & control) two
middleboxes introducing potential latency and performance problems. With the
midcom agent co-resident with an application agent, only the
signalling/control messages must traverse the box with the midcom agent. The
data/media flows only go through one middlebox.

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

---

From: Mark Duffy <[email-masked]>
Date: Wed, 01 Aug 2001 10:48:36 -0400

I think a lot of the confusion here is because we have coined two terms
(in-path and out-of-path agents) but in fact there are at least three cases:

a.) agents in boxes to whom the packets to be inspected/modified by the
agent are specifically addressed at the IP layer.  Perhaps called
"logically and physically in-path".

b.) agents in boxes through which the packets in question are flowing, but
to which the packets are not specifically IP-addressed.  Perhaps called
"physically in-path".

c.) agents in boxes through which the packets in question do not flow
(unless diverted for that specific purpose)

I think we would probably all agree that a. are "in-path" agents and
therefore in-scope.
I think we would probably all agree that c. are "out-of-path" agents and
therefore out of scope.

I had understood b. to be in-path and in-scope, because I interpret this as
falling within the definition "... within the message path of the
application...".

I do not see why b. should be out of scope.  What does it matter to midcom
how the agent gets hold of the relevant application packets (as long as
midcom does not have to do anything about it such as diversion)?  I think
the difference between a. and b. would be transparent to midcom.

Regardless, we should improve our terminology.  I suggest some terms above
to differentiate a. and b.

Regards, Mark