Subject: (NAT) Transport base for RSIP control protocol

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 4 Nov 1999 17:08:38 -0800 (PST)

Folks,

There has been many arguments made in favor of using TCP as the transport
base for RSIP control protocol. Reliable, sequential delivery with 
built-in algorithms for congestion back-off and packet-retry are some 
of the reasons cited. Given these good reasons, I dont see a problem 
with TCP as the transport base for RSIP control protocol. However, I am 
not convinced about mandating it as the only means. Here's my thinking 
on this. 

There are many resource management/query protocols with payload in the 
form of Tag-Length-Value that exist today. And, surely, there will be 
more in the future. Most of them (such as DHCP), I believe, opted to 
use UDP as the transport base and a few went with TCP. I dont know all
the reasons that went into this.

My point is that when a bunch of these server fucntions are put 
together on a single box (and, by the same token, when a bunch of
client functionalities are put together on a PC), it is awfully 
confusing to have to implement/provision the box when some of the 
services are UDP based and others are TCP based. It would be easy to 
implement/provision these boxes, when all like-services use the
same transport base. If UDP is the most common transport base in use,
why not mandate the use of UDP as a MUST for RSIP control protocol?

Alternately, as Ylian Saint-Hilaire points out, why not give the clients
a choice (implement on top of UDP or TCP) and mandate the use of TCP as 
well as UDP on server boxes?

Any thoughts/opinions would be welcome. Also, if you could provide input 
to the following questions, that would help clear up some issues.

1. What are the known client-server protocols (used in resource mgmt       type
functions) that use UDP vs TCP. What are 3 top reasons for 
   these protocols to select UDP or TCP, as the case may be.

2. What are the parameters/issues that need configuring for TCP vs UDP 
   based protocols - Issues related to fragmentation, MTU sizes, timers,
                     delays, resource overhead, Implementaton overhead etc..

I would like to hear your thoughts. Thanks.

cheers,
suresh  

=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: "Mike Borella" <[email-masked]>
Date: Fri, 5 Nov 1999 07:09:08 -0600

Suresh,

I'm not sure that I understand your case.  What is so difficult about
provisioning for both UDP and TCP? One provisions for applications,
not the transport that they use.

In terms of implementation overhead, try implementing a robust SIP
(session initiation protocol, not RSIP) proxy server with TCP.  Then
try the same thing with UDP and watch your development times shoot
through the roof.  With UDP, behavior when packets are lost or duplicated
must be addressed, whereas with TCP, all that comes for free.

Its clear to me that TCP would be superior for a number of reasons, including
ease of implementation, better support for security, congestion control, etc.
The real question is, are there any compelling cases for UDP?

-Mike

Pyda Srisuresh <[email-masked]> on 11/04/99 07:08:38 PM

Please respond to Pyda Srisuresh <[email-masked]>

Sent by:  Pyda Srisuresh <[email-masked]>

To:   [email-masked]
cc:    (Mike Borella/MW/US/3Com)
Subject:  (NAT) Transport base for RSIP control protocol

Folks,

cheers,
suresh

=====

-

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 5 Nov 1999 08:31:05 -0800 (PST)

> not the transport that they use.

RSIP is not a real user level application, It is a system administrator's
utility. It is fairly common for such a configuration to include tuning 
parameters based on the transport protocol in use. 

> must be addressed, whereas with TCP, all that comes for free.

Sure, switching the transport from TCP to UDP is not trivial. That was
my premise as well. However, the complexity is in the eye of the beholder. 
If someone has all the services based on UDP, adding another service based
on UDP is simpler than having to do that on TCP.

> The real question is, are there any compelling cases for UDP?

How do RSIP clients locate a server? 

cheers,
suresh

=====

---

From: "Mike Borella" <[email-masked]>
Date: Fri, 5 Nov 1999 13:02:50 -0600

Suresh,

I still don't understand why this is an issue.  Can you elaborate?

-Mike

Pyda Srisuresh <[email-masked]> on 11/05/99 10:31:05 AM

To:   Mike Borella/MW/US/3Com
cc:   [email-masked]
Subject:  Re: (NAT) Transport base for RSIP control protocol

cheers,
suresh

=====

-

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 5 Nov 1999 14:37:42 -0800 (PST)

Mike,

While I am not against the use of TCP, I am not convinced that TCP 
should be mandated to be the only transport protocol. Here are some
reasons why. 

    1. The payload format and operation of RSIP is independent of 
       the transport protocol (at least in theory, right). So, 
       why mandate TCP as the transport protocol? 

       Note:  you do need to set some restriction on payload 
       sizes, when carried over UDP. For example, you might want to say
       that UDP datagrams (including all the headers) should not be 
       larger than the path MTU (say 1500 bytes in most cases, 
       or 576 bytes as stipulated for DNS). Else, you could end up 
       with fragment overhead.

    2. It is not reasonable to argue that TCP is uneuivocally the right
       choice in al cases because when you view the complexity of
       implementation/configuration from a systems perspective (i.e., 
       in conjunction with what else is supported in the box), people 
       may opt to go with UDP in preference to TCP.

    3. RSIP is not necessarily a one-time-use protocol. The transactions 
       could be ongoing throughout the operation of the client nodes. So, 
       several RSIP transactions (i.e., a pair of Request and response pkts) 
       could originate from a client with the same RSIP server. If TCP is
       used, these transactions could be conducted over the same TCP 
       connection or over a new connection for each transaction. In either
       case, it is a resource overhead. UDP is light-weight and does not
       have the same kind of resource overhead.

    4. It is not clear how RSIP clients are expected to locate their 
       server. Manual configuration is an approach. Alternately, they 
       could use a multicast/broadcast IP address to locate one. UDP
       can work with multicast/broadcast addresses. TCP cannot. As 
       Mike Richardson pointed out(in a private e-mail to me), DHCP 
       clients use UDP with broadcast IP address to solicit service from 
       a DHCP server. 

    5. If the applications running in conjunction with RSIP are delay/time
       sensitive, UDP may be a better choice because UDP is light weight 
       and does not consume a lot of set-up/processing time.

So, I believe, the transport choice should be left to clients, but both
choices must be mandated on a server.

cheers,
suresh

=====