Subject: RE: [midcom] middlebox informs agent?

From: "Cedric Aoun" <[email-masked]>
Date: Mon, 18 Jun 2001 13:29:05 +0100

Folks,
I think we all agreed on both methods and that each has potential
scalability issues
I propose to close that matter off and come back to it when we start looking
at the protocol design
Cedric 
-----Original Message-----
From: Andrew Molitor [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 6:46 PM
To: Aoun, Cedric [QPD:0000:EXCH]
Cc: 'Maciocco, Christian'; 'Scott Brim'; [email-masked]';
[email-masked]; [email-masked]'
Subject: RE: [midcom] middlebox informs agent?

On Tue, 12 Jun 2001, Cedric Aoun wrote:

> sorry to spam again with that one, but we need to get agreement on that
> issue ...
> 
> Christian,
> The Middle Box has already a flow based state machines in 
> which one state consist on a timer that is reset upon reception of a
> packet.

	This is a false assumption. As I have indicated in an
earlier note to the midcom list, there are many ways to handle timers
up to and including not having them.

	In some cases, like SIP, the agent need not have any timer
state since the endpoints will (may?) provide events which can
be used to refresh state. In other cases, the agent may need to
maintain internal timers for its own purposes. It is not safe to
assume that the agent is maintaining timer state.

	It is safe to assume that essentially any model of timers you
can think up will be desireable to someone. It is not safe to assume
ANYTHING about the timer model implemented by a specific middlebox
class device. As I indicated in the aforementioned email, I have
no clear idea of what the right way to deal with these fact in the
to-be-defined MIDCOM protocol is. I eagerly await suggestions.

	I keep seeing these posts which apparently assume some
Platonic Ideal middlebox -- usually subtly different from everyone
else's Platonic Ideal of a middlebox. Let me remind us all, one more
time, MIDCOM needs to deal with existing middlebox class devices. I
am happy to go on all day about one such device, the one I work on.
I have described many of its properties as illustrative examples
already. I am neither so naive, nor so rude, as to assume that MY
device is the canonical middlebox, the only one MIDCOM must deal
with.

		Andrew

---

From: "Fleischman, Eric W" <[email-masked]>
Date: Mon, 18 Jun 2001 11:53:04 -0700

This excellent posting has touched on several ideas which I would appreciate us discussing more fully.

 > can think up will be desirable to someone. It is not safe to assume 
  
This is an excellent point. I think that we can agree that because there 
are many implementations, there are potentially different approaches
to timers in existing products. However, to the degree to which the
midcom protocol addresses timer issues, to that extent we theoretically
have the option to create standardization of approaches which impact 
timers.

Towards that end, I would like to propose that we explicitly seek to
make no assumption as to a midcom agent's use of timers, by explicitly 
making subsequent use of the midcom teardown function be optional. By
so doing, however, we would explicitly be requiring that the middlebox
itself keeps timers (as the text already says) so that it could 
automatically close down any "hole" even if the agent "goes away" for
unforeseen reasons. I think that most of us will readily agree with
this tenet because it makes the protocol more able to weather 
unforeseen events.

Question to Cedric: could you agree with my above two paragraphs? If not,
how would you modify them?

 > device is the canonical middlebox, the only one MIDCOM must deal 

This is a  bit of a problem since unless we are talking about your
implementation, then we're talking about someone else's implementation.
If they object to us using your implementation as our standard or if 
you object to our using their implementation as our standard, then 
we can't really talk about specific implementations after all. That is, 
the only way we can talk about all implementations is to add in 
abstraction, thereby perhaps creating a "Platonic Ideal of a middlebox". 
I believe that this is a almost unavoidable.

On the other hand, any implementation can rightly object to assumptions
contained within this "Platonic Ideal" which war against their particular
implementation. An example is my second paragraph above. However, unless
all implementations are harmonious in the points touched by the midcom
protocol, the unfortunate reality will be that any attempt for 
standardization will be more challenging for some implementations than
for others. Therefore, I HOPE that we can resolve this problem by 
having very good reasons for doing whatever we're doing, which is why
these types of discussions are so important.

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

---

From: "Cedric Aoun" <[email-masked]>
Date: Thu, 21 Jun 2001 09:52:17 +0100

Eric
I thought we agreed to postpone the debates on usage of timers in the state
machines of Middle Boxes and agent until starting to work on the protocol
spec.
I'm always happy to serve our cause but it is best to focus the framework
first and the protocol requirements first (tear down and cleaning of unused
resources); the protocol spec will provide the means to achieve the
previous.

Please see comments below

..Cedric

-----Original Message-----
From: Fleischman, Eric W [mailto:[email-masked]]
Sent: Monday, June 18, 2001 8:53 PM
To: Aoun, Cedric [QPD:0000:EXCH]; 'Andrew Molitor'; 'Maciocco,
Christian'; 'Scott Brim'; [email-masked]'; [email-masked]
Cc: [email-masked]'
Subject: RE: [midcom] middlebox informs agent?

This excellent posting has touched on several ideas which I would appreciate
us discussing more fully.

  

Question to Cedric: could you agree with my above two paragraphs? If not,
how would you modify them?
--------------------------------
CA: As I ( and Suresh, Scott, Christian M and others in the list) previously
mentioned to the list there 
are several options to achieve the same end results. We need to compare the
pros/cons of both.

Having different approaches to achieve the end goal, requires a
negotiating capabilty to be introduced during the registration phase between
the Midcom Agent and the Middle box, to understand who does what.
This will complexify the protocol state machines ( I think that we all agree
on that).

All this will need to be considered when start looking in the details of
the protocol.

I agree with the fact that there are several current implementations of MBs
in the market and if we want MIDCOM to be successful it needs to take into
account all the previously mentioned options to do the tear down/cleaning of
session descriptors
--------------------------------

I agree that form a requirements

-----------------
CA: I also hope that we shall find a way to meet everybody's MBs needs
without requiring to
add negotiating capabilities and hybrid type of behaviors ...