Subject: RE: [midcom] defining in-path and out-of-path agents

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 1 Aug 2001 17:41:50 -0600

What about the SIP Proxy/ALG case where you have agent in a box that may
be in the signaling path (physically and/or logically) for SIP but needs
to use midcom to inform a middlebox of RTP traffic that not in path
physically (and not logically unless you count the signaling)?  Would
this type of agent be considered out of path and therefore out of scope?

I'm concerned that so much effort is being placed on defining what is
"in-path" verses what is not. Suppose we leave this completely out of
the conversation for now and allow that:

1. Diversion may happen outside of midcom (since it's clearly not
happening inside our charter and it's not technically difficult), and 

2. While many of us may hold opinions about diversion, midcom as a
protocol ought to be silent on the issue, particularly with respect to
whether an agent is "in-path" or not.

Would this be sufficient to move the current holy war to a new venue and
away from midcom?

--Andy Zmolek
    Technology & Standards Engineer
      CTO Standards
        Avaya Inc.

            [email-masked]
              +1 720 444 4001

-----Original Message-----
From: Mark Duffy [mailto:[email-masked]]
Sent: Wednesday, August 01, 2001 8:49 AM
To: Andrew Molitor; [email-masked]; Cedric Aoun; Bob Penfield;
[email-masked]
Subject: [midcom] defining in-path and out-of-path agents

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

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

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 2 Aug 2001 11:20:37 -0400

>this type of agent be considered out of path and therefore out of scope?

Absolutely not. The SIP examples in the doc work this way. That is why I
suggested that definition of a midcom agent explicitly state that it only
needs to be on the natural path of the signalling/control messages.

>whether an agent is "in-path" or not.

I don't think that it is possible to remain silent on how the agent fits
into the framework, because then you would have holes in the framework with
respect to OOP agents. Since OOP agents require that the middlebox divert
the control packets to the agent, diversion becomes another service provided
by the middlebox. It would natually follow that the agent would want to use
midcom to tell the middlebox to divert the packets to itself. However, the
only services we're allowed to address are firewall and NAT.

>Would this be sufficient to move the current holy war to a new venue and

I think the best we can do now is have an accurate definition of an
"in-scope" agent within the framework we are being restricted to. We have to
leave OOP agent/diversion aside for another holy war later.

I am sensing that there is general consesus that if at least the
control/signalling packets are explicity addressed to an application agent
(end-point, proxy, or whatever) co-resident with the midcom agent, or they
flow to the box containing the midcom agent by normal IP routing (i.e. the
box is on the path), then it qualifies as a valid MIDCOM agent within the
framework defined by the document. Thus case (a) and (b) in Mark Duffy's
original post qualify.

(-:bob

---

From: Scott Brim <[email-masked]>
Date: Thu, 2 Aug 2001 12:12:59 -0400

> needs to be on the natural path of the signalling/control messages.

This might actually work :-).  

> framework defined by the document. Thus case (a) and (b) in Mark Duffy's

Agreed.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 02 Aug 2001 11:40:09 -0400

At 11:20 AM 8/2/01 -0400, Bob Penfield wrote:
>respect to OOP agents.

Yes and no.  If you think about how the inclusion of out-of-path
agents would affect an actual midcom protocol, you might conclude 
"not at all."  Our difficulty is around packet diversion, which in 
addition to being at odds with the spirit of what we're trying to do 
here would additionally require a mechanism for transporting diverted 
packets.  That last bit is deeply, profoundly, and undeniably out-of-
scope.

Melinda

---

From: Mark Duffy <[email-masked]>
Date: Thu, 02 Aug 2001 18:35:20 -0400

>This might actually work :-).  

From an architectural purity point of view, I would suggest that the agent
needs to be in the path of whatever packets it needs to examine/modify, be
they control/data/foobar/whatever.  The midcom framework, the midcom
protocol, and the middlebox should not state nor care whether they are
control/data/foobar/whatever.  However, I will concede that in practice it
is highly likely they will be control packets, and I don't feel a need to
press the issue.

Therefore Bob's definition seems fine to me except I think we need to be
more specific about what it means to be "on the natural path", as we have

>> framework defined by the document. Thus case (a) and (b) in Mark Duffy's

Agreed here also.