Subject: RE: [midcom] London meeting time

From: "Christian Huitema" <[email-masked]>
Date: Thu, 12 Jul 2001 09:39:32 -0700

> On Thu, 12 Jul 2001, Melinda Shore wrote:
> 
> > At 08:30 PM 7/11/01 -0500, Andrew Molitor wrote:
> > >        My personal feelings are that UDP is the way to go, since
> > >TCP's backoff behavior is just not what you want in a real-time
> > >environment.
> >
> > I believe that all IETF protocols are now expected to employ
> > TCP-compatible congestion response mechanisms.  That's not an
> > argument against using UDP, but it is something to be aware of.
> 
> 	If I put on my standard hat, I arrive pretty quickly at
> the 'should run over UDP or TCP' exactly for these reasons. Obviously
> a TCP implementation would do that vis a vis congestion, and
> a UDP implementation would let you play games. This seems to be
> pretty common, and I'd be surprised if we DON'T get there.

The classic "sweet spot" of UDP is the handling of multiple short
transactions with a large number of parties -- by and large the traffic
profile of the DNS. Using TCP in such applications is
counter-productive, since you have to wrap a simple exchange between a
three way handshake and a final disconnect -- there is extra traffic,
and there is basically no congestion control gain, since the TCP
connections are too short to move out of slow start.

I am not sure that Midcom fits under that profile. In fact, we have a
performance requirement that was outlined in the list discussion, and
that I would summarize as follow:

	The SIP and H.323 scenarios mention the control of the 
	midcom server by a single midcom agent collocated with a SIP
proxy 
	or an H.323 gatekeeper. In these situations, we may
	expect a heavy amount of traffic between the midcom agent and
the
	midcom server, and it is important to design the protocol in a
way 
	that supports high performance. The typical impediments to high 
	performance are high transaction cost and windowing effect.

	A large fraction of the transaction cost will derive from the 
	security requirements, which will result in a conjunction of
	cryptographic applications and database look-up, e.g. using 
	Radius; both encryption and look-up can be slow and costly. A
	specific requirement is to distinguish between the operations
that 
	are common to many transactions, such as the authentication of
the 
	midcom server to the midcom agent and the midcom agent to the 
	midcom server, and the actions that are specific to a single 
	transaction.

	The windowing effects occur when a specific transaction has to 
	wait for the completion of a previous transaction. From a 
	performance point of view, it may be acceptable to wait for the 
	confirmation of the opening of a pin-hole before closing the
same 
	pin-hole. (This may not be acceptable from a security point of 
	view.) But it would not be acceptable to wait for the completion
of one pin-hole opening before allowing the opening of another 
	pin-hole.

 	In summary, the following must be true:

	*	It should be possible to exchange authentication
information 
		once, and use the result for a series of transactions 
		between a client and a midcom server,

	*	It should be possible for a client to send multiple 
		transactions without waiting for the results of previous
		transactions.

I believe that this text provides a better "requirement" than merely
stating "run over UDP" versus "run over TCP". In particular, the
performance requirement combined with the security requirement may well
lead us towards an "authenticated session" model, e.g. running over TLS.

-- Christian Huitema

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

---

From: Andrew Molitor <[email-masked]>
Date: Thu, 12 Jul 2001 16:27:41 -0500 (CDT)

> lead us towards an "authenticated session" model, e.g. running over TLS.

	I am in violent agreement with you. On or around Mar 28 I wrote:

-----------------------
*	- must support low-latency, high-throughput operation, with
*	  best effort to maintain low latency in the face of a lossy network.
*	  This is necessary for telecom grade operations -- backoff
*	  policies in retransmit timers are not necessarily a good idea
*	  on controlled channels controlling equipment. (This boils
*	  down to: TCP Considered Harmful -- in rather specific
*	  environments.)
*
*	- must also support more ordinary network traffic models for
*	  use on standard networks where backoff policies for retransmit
*	  timers, and the like, are a good ideas. (This boils down to:
*	  TCP is a hell of a good idea most of the time.)
*
*	[ I think the first bullet above pretty much requires UDP
*	  transport with wicked timers, but if there's anothe option
*	  I'd be pleased to hear about it. The situation I am thinking
*	  of is: some goober in a POP unplugs the wrong cable for
*	  a moment, or there is some other glitch in connectivity.
*	  It would Be Bad if this glitch made TCP back off and make
*	  the POP unable to complete calls for, say, 2 or 3 seconds
*	  AFTER connectivity is restored. This could readily create
*	  irritating post-dial delays for several hundred customers
*	  over the next 10 seconds while the queue clears. This is the
*	  sort of thing that gives telecom geeks nightmares. ]

	- should be transport independent, a la SIP.

	- must support high transaction throughput over highish
	  latency networks (read: must support message streaming.)

-------------------

	I then spent far more effort than it was worth explaining
why this is a) a requirement and b) why one cannot safely assume
that "it's a transport problem" and not take at least a little care
in the protocol itself.

	Now I can at least imagine it was not all in vain ;)

		Andrew