Subject: Re: (NAT) Transport base for RSIP control protocol

From: "Mike Borella" <[email-masked]>
Date: Fri, 5 Nov 1999 17:55:05 -0600

Rebuttal:

1) So we do UDP just because we can? I think we should examine the
     pros and cons of both and determine if one makes for a significantly
     better solution than another.
2) I still don't see why people would want RSIP to use UDP just because
     other apps use UDP.
3) I agree with Gabriel - TCP resource overhead is not the limiting factor
4) Good point, but see my previous email.
5) Perhaps, but other transaction oriented protocols, such as NFS, originally
     used UDP but now support TCP.  The pros outweighed the cons.

I'm not religiously bound to TCP.  I'm playing devil's advocate to get
the WG to present a convincing argument for UDP.  If we can't do so
(and IMHO we so far have not) then we need to draw the line by saying
"TCP is good enough for now" so that we can get on with things.  If
we need to reopen the protocol for UDP at a later date then that's OK too.

-Mike

Pyda Srisuresh <[email-masked]> on 11/05/99 04:37:42 PM

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

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

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

--- Mike Borella <[email-masked]> wrote:
>
>
> 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
>
> Sent by:  Pyda Srisuresh <[email-masked]>
>
>
> To:   Mike Borella/MW/US/3Com
> cc:   [email-masked]
> Subject:  Re: (NAT) Transport base for RSIP control protocol
>
>
>
>
>
>
> --- Mike Borella <[email-masked]> wrote:
> >
> >
> > 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.
> >
>
> 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.
>
> > 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.
> >
>
> 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.
>
> > 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?
> >
>
> How do RSIP clients locate a server?
>
> > -Mike
>
> cheers,
> suresh
> >
> >
> >
> >
> >
> > 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,
> >
> > 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.
> >
> >
> >
> >
> > -
> > To unsubscribe, email [email-masked]' with
> > 'unsubscribe nat' in the body of the message.
> >
>
>
> =====
>
> __________________________________________________
> Do You Yahoo!?
> Bid and sell for free at http://auctions.yahoo.com
>
>
>
>
>

=====

__________________________________________________
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: "Bernard Aboba" <[email-masked]>
Date: Fri, 5 Nov 1999 22:46:58 -0800

>If we can't do so then we need to draw the line by saying
>"TCP is good enough for now" 

Well, part of the reason this isn't resolving quickly is
that without some requirements, it's not clear how you judge
when something is "good enough."

If you are talking about a home or SOHO scenario, then
certainly TCP is good enough. If you are talking about
a bazillion user firewall, maybe not. Personally, I
only care about use of RSIP in the former scenario and 
not the latter. But others in the WG might have
different scenarios in mind. 

Having a requirements doc would be helpful in 
delimiting what we're trying to achieve. That
makes it easier to know when we're done.
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.