Subject: RE: [midcom] middlebox informs agent?

From: "Fleischman, Eric W" <[email-masked]>
Date: Thu, 21 Jun 2001 08:29:04 -0700

From: Cedric Aoun [mailto:[email-masked]]
> 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 wasn't aware of this agreement -- perhaps it occurred during the weeks the Midcom archives 
weren't functioning because I did not notice any mention of it in the archived materials.
  
It is my perception that the framework document should provide the specs for the 
midcom protocol. If one adopts such a viewpoint, state machines and timers are 
central for the framework document to address. More importantly, I want a protocol that 
is transactional during setup and transactional during teardown, but which has no state 
during the initial negotiation stage to protect against DoS attacks. I also want to have
no state kept within the protocol between setup and teardown. This requires the middlebox 
itself to keep the timers so that it could know when a teardown should occur should the 
Midcom Agent "disappear" -- as well they might for a variety of reasons. I am very 
surprised that adding these concepts to the framework document is controversial.

>Having different approaches to achieve the end goal, requires a 
>negotiating capability 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). 

The type of protocol I seek is one that is as simple as possible. I do not think that the 
current "state of the art" is mature enough -- particularly understanding the security 
implications -- to design an "all things for all people"-type of protocol which the 
framework authors are targeting. People with gray hair such as myself who were active
participants in the TCP/IP vs. OSI wars re-learned several lessons from history (e.g., 
the Merrimack versus the Monitor during the US Civil War). Younger people may not yet 
have learned that the efficient way to build complex systems is to hypothesize an 
architecture and then build a small system to verify it. Once the small system works 
as hoped, then incrementally build upon it. Put another way: I've designed some really 
complex systems over the years. I've come to realize that building a "full-blown" 
system from the get-go is doomed to cost overruns, re-designs, and massive schedule 
slips. The proper way to design such systems is to build the core and then incrementally 
enhance it, learning the needed lessons at each stage. I had hoped that younger people 
would have been familiar with these types of concepts from Extreme Programming, but I 
fear that the allure of creating massive systems from scratch is a powerful one. It's also
very easy to underestimate the difficulty of a task.

As I earlier stated in an email to the group, it is my perception that we are operating on 
different assumptions as to what the framework document is or should be. I also see the 
group as currently being very polarized and the timeframes we are marching to increase 
the pressure. I don't necessarily view polarization as bad. What I object to
is the scarcity of technical discussion that occurs on this group. For example, 
I respect that people can disagree with me about the importance of OOP Agents (who knows, 
maybe they are right?), but I am frustrated that nobody has addressed my specific 
technical objections to their position. Why aren't they taking the next step to show me 
how their approach could be done in a secure manner, for example? Also, I either do not 
understand or do not approve (I'm not sure at this time which is the case) of the 
current direction of this group. The net result is that I feel very insecure about the probability of this WG producing useful results.

--Eric

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

---

From: Andrew Molitor <[email-masked]>
Date: Thu, 21 Jun 2001 11:41:43 -0500 (CDT)

On Thu, 21 Jun 2001, Fleischman, Eric W wrote:

> >negotiating capability to be introduced during the registration phase
> >between the Midcom Agent and the Middle box, to understand who does what. 
> The type of protocol I seek is one that is as simple as possible. I do
> not think that the current "state of the art" is mature enough --
> particularly understanding the security implications -- to design an
> "all things for all people"-type of protocol which the framework
> authors are targeting.

	I'm not targeting any such thing! I want this thing to be as
simple as possible -- but no simpler!

	My personal feeling (though we're getting ahead of the game
into protocol design) is that if MIDCOM does not include a capabilities
advertisement/query scheme, then it'll be a useless toy. This does
not imply a 7 step iterative exchange that provably converges on
the optimal interoperability gloop snork gack. Something along the
lines of 'Hey, can you <this>?' and '407 No' is just fine.

> People with gray hair such as myself who were
> active participants in the TCP/IP vs. OSI wars re-learned several
> lessons from history (e.g., the Merrimack versus the Monitor during
> the US Civil War).

	I am FASCINATED by this! What is the parallel between IP vs. OSI
and the battle of the ironclads? Indeed, what is the lesson inherent
in the latter, other than 'playing chicken with cannons in cramped
floating tanks is insane and dangerous?'

> Younger people may not yet have learned that the
> efficient way to build complex systems is to hypothesize an
> architecture and then build a small system to verify it. Once the
> small system works as hoped, then incrementally build upon it. Put
> another way: I've designed some really complex systems over the years.
> I've come to realize that building a "full-blown"  system from the
> get-go is doomed to cost overruns, re-designs, and massive schedule
> slips. The proper way to design such systems is to build the core and
> then incrementally enhance it, learning the needed lessons at each
> stage. I had hoped that younger people would have been familiar with
> these types of concepts from Extreme Programming

	'Kludge and Conquer'

>, but I fear that the
> allure of creating massive systems from scratch is a powerful one.
> It's also very easy to underestimate the difficulty of a task.

	Perhaps you don't realize how snotty this paragraph sounds?
I wan't there for the Monitor vs. Merrimack battle, I haven't got a
nanonsecond of patience for EP, but I'm actually not an idiot, I swear.

	The 'build a small one and expand' model is fine. What you don't
want to do is start out by designing a small one from specifications that
are demonstrably wrong. Then the little demo you wrote will, surprise,
NOT pass that all important 'verify it' stage. Sometimes there is a
minimal level of complexity required from the beginning. It is
exceedingly difficult to get to the moon by building a turtle shaped
mock-up of your vehicle out of concrete (because that's easy, plus
which it looks COOL!) and then incrementally improving your
implementation.

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 21 Jun 2001 10:28:35 -0700 (PDT)

--- "Fleischman, Eric W" <[email-masked]> wrote:
> midcom protocol. 

Eric - The framework draft is not a functional spec for the MIDCOM
protocol. 

The FW document specifies an architecture and framework in
which trusted third parties can be delegated to assist the middleboxes
to perform their operation without resorting to embedding application
intelligence. The objective of the MIDCOM architecture is to create
a unified, standard way to exercise this functionality, currently 
existing in an ad-hoc fashion in some of the middleboxes.

>                 If one adopts such a viewpoint, state machines and timers
> are 
> central for the framework document to address. 

Sounds like, you are on a different track than the rest of us on what is
expected of the framework. The draft shall not include discussions on 
state machines and timers and how they ought to be implemented for MIDCOM.
 
>                                                  More importantly, I want a
> protocol that 

Your discussion is perhaps very pertinent at the time of protocol design.
We are not there yet. You are jumping the gun.

<... stuff deleted>

> different assumptions as to what the framework document is or should be. I

You are right about that.

<... stuff deleted>

cheers,
suresh

=====

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

---

From: "Scott Brim" <[email-masked]>
Date: Fri, 22 Jun 2001 08:12:34 -0400

On 21 Jun 2001 at 08:29 -0700, Fleischman, Eric W apparently wrote:
> From: Cedric Aoun [mailto:[email-masked]] > 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 wasn't aware of this agreement -- perhaps it occurred during the
> weeks the Midcom archives weren't functioning because I did not notice
> any mention of it in the archived materials.

Cedric made the suggestion and people subsided, so there was a tacit
consensus.  The issue is still open because it hasn't been documented.

> It is my perception that the framework document should provide the
> specs for the midcom protocol.

We want to provide *requirements* for the midcom protocol, and we do
that in the requirements draft.

Your text below should be addressed at requirements, with
justification.  The latest draft came out Thursday.

OK, having said that, let's assume the rest of this thread is about the
requirements draft ...

> More importantly, I want a protocol that is transactional
> during setup and transactional during teardown, but which has no state
> during the initial negotiation stage to protect against DoS attacks. I
> also want to have no state kept within the protocol between setup and
> teardown.

So far so good -- except I'm confused about state "within the protocol",
since protocols are communication, the endpoints keep the state.  Do you
mean the protocol shouldn't require either end to keep state?  And yet,
you're requiring timers.  But anyway ...

> This requires the middlebox itself to keep the timers so
> that it could know when a teardown should occur should the Midcom
> Agent "disappear" -- as well they might for a variety of reasons.

The original issue was that Suresh wanted the middlebox to keep a timer
and be responsible for pinging the agent periodically to see if the
installed state was still wanted.  That was highly debated.  There was
general agreement that if the agent disappeared the middlebox should
clean up, except ...

> I am
> very surprised that adding these concepts to the framework document is
> controversial.

It wouldn't be controversial except that someone said he really didn't
want middleboxes to be required to delete state if an agent disappeared,
that pinholes should be left open for some time.  At that point we
started talking about general rules which could be installed -- for
example allowing the agent to specify exactly what to do with left-over
state.  Then we kind of petered out, because you get into soft issues
like how much complexity is worth it when you don't know how important a
particular need is.  We can't make this decision right now.

I'd like to see this revisited.  Could the person who claimed he wanted
pinholes left open after the agent disappeared please stand up?

> "all things for all people"-type of protocol which the framework

I'd like to distinguish here between the protocol being simple and what
the protocol carries being simple.  Clearly we want a lean and mean
transaction-like idempotent protocol.  The question we stopped on is how
much complexity do we allow in the instructions an agent can pass.  In
most protocols we handle that by suffering a slight overhead to make it
extensible, but not using the extensibility in version 1.0.  We need to
agree on the midcom protocol requirements.  Once we do, I'm looking
forward to a succinct summary of requirements, in a nice little table
with very little text, so I can have an opinion about how much
extensibility to bother with.

(Passing over the concerns about youth in the group.  At my first IETF
there were 14 people.)

---

From: "Melinda Shore" <[email-masked]>
Date: Fri, 22 Jun 2001 08:32:44 -0400

> that pinholes should be left open for some time.

That "he" would be me.

That's a sort of a rough paraphrase, Scott.  I'm concerned
that tearing down state as soon as an agent fails works 
against fault tolerance.

Melinda

---

From: "Scott Brim" <[email-masked]>
Date: Fri, 22 Jun 2001 08:45:40 -0400

> that tearing down state as soon as an agent fails works 

Sorry about "rough".  OK, can we work toward consensus on requirements?
What specifically is the minimum that is required?  Do you want to
require, say, the agent to state (in the midcom protocol) the minimum
time that installed state should be retained if agent<->middlebox
communication is lost (default to 0)?  Note that this would be after
communication was declared "lost", an interval that hasn't been set
yet.  

I think maybe we should talk about fault tolerance requirements in
general first?

...Scott

---

From: "Melinda Shore" <[email-masked]>
Date: Fri, 22 Jun 2001 11:00:39 -0400

> communication was declared "lost", an interval that hasn't been set

I dunno - something like a teardown/don't teardown flag.
I'd kind of like to see an timer element in general, and
it seems to me that that can remain independent of a
what-to-do-when-the-agent-disappears hint.

Melinda