Subject: RE: (NAT) RSIP over TCP stream

From: [email-masked]
Date: Mon, 1 Nov 1999 15:51:06 -0600

This speaks to an even larger issue: should RSIP recommend TCP or UDP?
In different environments, their are advantages and disadvantages to each.
In the initial (smaller scale) deployments of RSIP, I suspect that TCP would be
the most
useful, while later (larger scale) deployments may require the low overhead of
UDP.

If we can pick one or the other and just go with it, that would simplify things
greatly.
Discussion?  TCP, UDP, or both....

-Mike

"Saint-Hilaire, Ylian" <[email-masked]> on 11/01/99 03:34:54 PM

Sent by:  "Saint-Hilaire, Ylian" <[email-masked]>

To:   Mike Borella/MW/US/3Com, "Saint-Hilaire, Ylian"
      <[email-masked]>
cc:   "'nat @livingston.com'" <[email-masked]>
Subject:  RE: (NAT) RSIP over TCP stream

TCP is a stream based protocol, with or without fragmentation, we need a way
to break up the RSIP messages inside the stream. If you send small messages
(under path MTU) you never see the problem since a single "socket read" will
get the entire message, but if the message is larger it is not possible to
know where it ends. You should never make a single read off a TCP socket and
expect the same behavior as UDP.

I think we need a size field or a separator of some kind if we want to keep
using RSIP over TCP.

Ylian Saint-Hilaire
Intel - Communication Architecture Labs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 01, 1999 12:22 PM
To: Saint-Hilaire, Ylian
Cc: [email-masked]'
Subject: Re: (NAT) RSIP over TCP stream

I really can't imagine RSIP packets getting fragmented and would
like to avoid any significant (or insiginificant) modifications to the RSIP
protocol at this point.  Is there any WG consensus on this issue?

-Mike

"Saint-Hilaire, Ylian" <[email-masked]> on 10/21/99 04:46:49
PM

Please respond to "Saint-Hilaire, Ylian" <[email-masked]>

Sent by:  "Saint-Hilaire, Ylian" <[email-masked]>

To:   "'nat @livingston.com'" <[email-masked]>
cc:    (Mike Borella/MW/US/3Com)
Subject:  (NAT) RSIP over TCP stream

Comment on the RSIP-PROTO-02 draft:

Since TCP is a streams based protocol, when using RSIP over TCP (control
channel) we need a way to delimit the start and end of each RSIP message.
The new draft supports an arbitrary number of options but there is not
indication on the number of options or the size of the message.
Consequently, an RSIP client could retrieve a message and not get one or
more optional parameters. A fix would be to place a message size field in
front of each RSIP message when using RSIP over TCP. Any feedback?

Ylian Saint-Hilaire
-
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.

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Matt Holdrege <[email-masked]>
Date: Mon, 01 Nov 1999 14:08:30 -0800

TCP is probably the best choice given it's congestion management. TCP has 
been made to work well in very high volume environments
such as popular web sites.

-

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 2 Nov 1999 21:29:58 -0800

>This speaks to an even larger issue: should RSIP recommend TCP or UDP?

Yes. Making a choice will simplify interoperability testing.

One of the things to consider in making the choice is whether you
will need things like RTT estimation, congestion control, or
windowing in your control channel transport. These things tend 
to matter if you believe that the RSIP client and gateway could 
be separated by a WAN (e.g. a Mobile IP scenario), not just 
communicating over a LAN. 

If none of these considerations are worth much, then you might
as well go with UDP with a specified retransmission algorithm
(e.g. exponential backoff). 
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.