Subject: [midcom] MIDCOM Protocol Performace Requirements -

From: Andrew Molitor <[email-masked]>
Date: Thu, 17 May 2001 12:52:55 -0500 (CDT)

Some of you may recall me beating a drum about explictly
requiring that MIDCOM be, if not inherently high performance, at
least admitting of high-performance implementations. There were
many dissenting responses, including the admirable point that the
SIP spec makes no mention of performance.

	I think I promised to put together my thoughts on this
quite a while ago, and now I am finally delivering.

	SIP is a class 'slow protocol' it turns out. You send
a message and wait for a response, no sliding windows, no nothing.
The horror! Luckily, SIP doesn't NEED to be fast in this sense,
and in fact I cannot think of any use things like sliding windows
would have in SIP. SIP can be used to build high-performing
networks successfully, basically because you can run arbitrarily
many 'slow' transactions in parallel. Since each transaction is
between (in general) a different pair of endpoints, they are
uncorrelated, and things like authentication and whatnot need
to be done on an endpoint-pair basis anyways, if you choose to
do that sort of thing.

	MIDCOM is quite different. In a high-performance situation,
you have (in the simple case) only two endpoints: an agent, and
a middlebox. These two probably do NOT want to re-authenticate
for every transaction. In the case of, say, a NAT-enabled high
performance SIP network, all the many parallel 'slow' SIP transactions
can get bottlenecked by a single Agent<->middlebox session gating
transaction completion.

	One can do hacks like 'open a whole bunch of sessions
between the Agent and the middlebox' but this really is a hack.
It's even a hack I have considered, but it was just too darn ugly.

	I'm not trying to require that the protocol BE high
performance, simply that it admit high-performance implementations.
For example, a protocol that included an authentication phase,
and then sequence numbered transactions within an authenticated
session would (I think) be sufficient to permit windowed
implementations and still allow easy slower ones.

	What I want to avoid is things like:

	- authenticate for every transaction.
or:
	- authenticate once, send requests one at a time and
	  wait for the response before you send another because
	  you can't send two since there's no way to tell the
	  replies apart.

	It is tempting to try to sell:

	- must have an authentication phase followed by
	- a series of transactions each uniquely identified by
	  a sequence number at least 32 bits in size

	but that rather clearly falls OUT of the realm of requirements
into the realm of solutions. I am happy with anything that lets me
allow a single Agent to talk to a single middlebox and get at least
a few hundred transations done per second on the middlebox even assuming
a few milliseconds of latency between the Agent and the middlebox. If
MIDCOM cannot be implemented in such a way as to allow that, it is
useless to me.

		Andrew

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