Subject: [midcom] Time for a Time-Out?

From: "Eric Burger" <[email-masked]>
Date: Fri, 6 Dec 2002 10:47:58 -0500

I'm taking off my IETF hat for a moment and putting on my corporate hat (you know, the one that pays the bills).

H.248 would be the easiest protocol for me to implement.  For a midcom-like box, it should scale well.  Unfortunately (see my posting on H.248), I don't see how it can meet the midcom requirements.

SNMPv3 requires a lot of CPU processing.  I can put lots of CPUs into my box.  That means choosing SNMPv3 would put me at a competitive advantage.  It just seems to be the wrong thing to do.

I don't know about COPS et. al.  I'm sure everything has a fatal flaw.

Last time I looked, the IETF is the organization that does protocols.  Why do we have this aversion to creating a protocol?  Because of marketplace realities, I have to build a proprietary protocol to make something that works and scales.

Now let's look at midcom and progress to date.  It has been over a year, and the work group really hasn't produced anything of substance.  There is still discussion on the list about the requirements.  At the rate we're going, I don't expect that we will produce anything in the coming year, either.

My modest proposal: let's bounce the whole problem to the IRTF, where we can probe the theory, get some working implementations, and do some bake-offs.  Then we can come back to the IETF to polish it off.
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 06 Dec 2002 11:23:47 -0500

I've personally been silent on all of this stuff for quite some time. To 
  be honest, that is primarily due to my frustration at the general lack 
of progress and amazing circuitousness (is that a word) of the path we 
have taken to completion of this work.

Some responses inline.

Eric Burger wrote:

 > Last time I looked, the IETF is the organization that does protocols.
 > Why do we have this aversion to creating a protocol?  Because of
 > marketplace realities, I have to build a proprietary protocol to make
 > something that works and scales.
 >
 > Now let's look at midcom and progress to date.  It has been over a
 > year,

Oh, much longer than that. I recall the foglamps bof meeting in Adelaide 
in March 2000, which is almost three years ago. Most groups produce real 
protocols in faster than three years after their bof.

 > and the work group really hasn't produced anything of
 > substance.  There is still discussion on the list about the
 > requirements.  At the rate we're going, I don't expect that we will
 > produce anything in the coming year, either.

I agree.

I think it is time for a change in direction. Right now, we are on a 
path to fail. There are folks in each protocol camp who will clearly not 
budge. There is also, I think, a good contingent (myself included) who 
would rather build a new, simple-as-possible protocol for the task at 
hand. There is also a large contingent that is tired and no longer 
cares. Indeed, the participation in list discussion has dropped 
tremendously since this evaluation process began. Where is everyone?

I would like to propose that the group consider some radical actions at 
this point. Short of that, we will probbaly fail to produce anything at all.

I do not know what the right thing is, but here are some ideas:

1. Parallelism, ala IMPP: Let the COPS people, SNMP people, and new 
protocol people all develop their own protocols. Make the semantics doc 
a mandatory thing, so that each protocol must provide the semantics 
described there, and show a mapping. THis is akin to the CPIM approach. 
THen, let the market pick a winner. Three is better than zero, I guess.

2. Shut down: Just give up. Close the group. This interface remains 
proprietary. We have things like TURN, ALGs and eventually nsis, which 
is (I think) the right answer. Of course nsis is probably 5 years away 
from useful deployment.

3. Move to IRTF: As Eric suggests.

4. Dictatorial Fiat: The IESG tells the group to "use protocol X" and we 
do that (seems unlikely but I throw it out for consideration).

5. New protocol: do a new one from scratch.

Other ideas? I would favor approach 5 first, then 1, then 4, then 2, 
then 3.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Melinda Shore <[email-masked]>
Date: Fri, 06 Dec 2002 11:31:04 -0500

> My modest proposal: let's bounce the whole problem to the
> IRTF, where we can probe the theory, get some working
> implementations, and do some bake-offs.  Then we can come
> back to the IETF to polish it off.

I think there's a broader context here and that's that this
is an instance of off-path signaling, which is getting more
attention these days for better or worse (mostly the
latter).  There's been some agitation from a subset of
people interested in QoS for the IETF to take on off-path
QoS signaling, and it may be worthwhile to kick all of it
out to the IRTF to develop a better understanding of some of
the issues (and I think there's a tendency for off-path
signaling advocates, including us, to be glib about some
problems that are actually extremely difficult, like routing
and topology).

That said, there's a real problem to be solved here, and
there's some real-world implementation experience in the
form of Aravox's (RIP) product and UPnP.  Although I do
believe there are better ways to solve this problem I also
recognize that there are environments in which this *is* the
right answer, and I think the only really hard part is the
process of selecting a protocol.  It is my fondest but
likely fruitless hope that people will *not* see this as an
opportunity to try to rally some additional support for their
otherwise largely unpopular protocols, but rather understand
that we have a problem to solve and that we need to choose
the most suitable tools to do so.

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Fri, 06 Dec 2002 11:37:04 -0500

> Other ideas? I would favor approach 5 first, then 1, then 4, then 2, 

I can think of at least four existing "from scratch" midcom
protcols, and I don't see the process of sorting through
them as being any easier than sorting through COPS, SNMP,
megaco, and Diameter.

Melinda

---

From: Ted Hardie <[email-masked]>
Date: Fri, 6 Dec 2002 13:27:54 -0800 (PST)

> problems that are actually extremely difficult, like routing

I agree that there is a broader context here, and that this work
forces us to think about some problems in routing and topology which
are very difficult.  I'm not sure that kicking the larger question to
the IRTF helps that, though, as it tends to make a bounded problem
unbounded.  As it is, the group has a difficult, bounded problem;
making it a difficult, unbounded problem seems unlikely to help us
make progress.

> process of selecting a protocol.  

If narrowing the focus of the solution to those environments where
this is the right answer is possible, it seems like a good idea.  It
may also help us when making the decision on which protocol fits the
environment best.  Note that I really do mean "environment" here, not
just problem statement.  If there is a clear match between the tools
used in the environments where this is applicable and one of the
protocols under consideration, likely success in deployment seems like
a strong factor to consider.  To put it another way, if the candidate
protocols have about the same number of positives and negatives, pick
the one which the operations community seems most likely to be able to
use.  

>It is my fondest but

And it is my fond (and hopefully not fruitless) hope that you do
not give up.  We have some scary short term hacks out there
which should be superseded by a more considered approach.  Giving
up on the considered approach dooms us to live with those hacks
far longer than we would like.
				best regards,
					Ted Hardie
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 09 Dec 2002 10:20:58 +0100

> I can think of at least four existing "from scratch" midcom

Take SIMCO ;-). It does fit the semantics to 100%.

Cheers
Martin

-- 
************************************************
NEW ADDRESS EFFECTIVE DECEMBER 23RD
Kurfuersten-Anlage 34, 69115 Heidelberg, Germany
phone, fax and email remain unchanged
************************************************

Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 09 Dec 2002 11:11:23 +0100

> have taken to completion of this work.

Jonathan,

there has been some progress on this stuff in the last few months, take 
a look into the semantics. But since a lot of people are staying quiet 
instead of saying their opinion, we do not have any big progress. Some 
people take care about driving the evaluation process and the semantics, 
and they would be happy about even more comments!

Out of the favorite list I don't like 2, 3 and 4.

With 5 I'm fine (lets go with an XML-encoded SIMCO), but we have to face 
the reality that we have first to evaluate extisting protocols (I think 
this is mandatory by the ADs?).

Martin

Martin Stiemerling

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 9 Dec 2002 18:00:58 -0800

Jonathan,

I agree 100% with your proposed order.  If a new protocol fits the 
requirements....  The original justification for reusing an existing 
protocol was simplicity and speed. I don't think anyone, even the 
critics, thought that reusing an existing protocol would be so hard.

thanks,
-rohan

On Friday, December 6, 2002, at 08:23 AM, Jonathan Rosenberg wrote:
> I've personally been silent on all of this stuff for quite some time. 
> To  be honest, that is primarily due to my frustration at the general 
> lack of progress and amazing circuitousness (is that a word) of the 
> path we have taken to completion of this work.
>
> Some responses inline.
>
> Eric Burger wrote:
>
> Oh, much longer than that. I recall the foglamps bof meeting in 
> Adelaide in March 2000, which is almost three years ago. Most groups 
> produce real protocols in faster than three years after their bof.
>
> path to fail. There are folks in each protocol camp who will clearly 
> not budge. There is also, I think, a good contingent (myself included) 
> who would rather build a new, simple-as-possible protocol for the task 
> at hand. There is also a large contingent that is tired and no longer 
> I would like to propose that the group consider some radical actions 
> at this point. Short of that, we will probbaly fail to produce 
> anything at all.
>
> protocol people all develop their own protocols. Make the semantics 
> doc a mandatory thing, so that each protocol must provide the 
> semantics described there, and show a mapping. THis is akin to the 
> CPIM approach. THen, let the market pick a winner. Three is better 
> than zero, I guess.
>
> 4. Dictatorial Fiat: The IESG tells the group to "use protocol X" and 
> we do that (seems unlikely but I throw it out for consideration).
>