Subject: RE: [midcom] London meeting time

From: "Fernando Cuervo" <[email-masked]>
Date: Thu, 12 Jul 2001 14:28:39 -0400

There are two separate issues around the choice of transport: 
1-security implications: If TCP and UDP are to be allowed then a security
element in the protocol or use IPSec are needed
2-transaction capabilities: given that the issue is reliability the use of
UDP requires that timers and retransmissions to be handled by the protocol.
However, regardless of TCP or UDP things such as transaction in progress or
even an abort command (to handle the open/close pin-hole scenario) may be
useful, therefore it would be wise to leave all transaction control to the
protocol, which is compatible with the dual use of TCP and UDP.
> -----Original Message-----
> From:	Christian Huitema [SMTP:[email-masked]]
> Sent:	Thursday, July 12, 2001 12:40 PM
> To:	Andrew Molitor; midcom
> Subject:	RE: [midcom] London meeting time
> 
> 
> > 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: "Scott Brim" <[email-masked]>
Date: Thu, 12 Jul 2001 15:24:32 -0400

What about SCTP?