Subject: Re: (NAT) RSIP over TCP stream

From: [email-masked]
Date: Mon, 1 Nov 1999 14:22:20 -0600

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.

---

From: "Saint-Hilaire, Ylian" <[email-masked]>
Date: Mon, 1 Nov 1999 14:21:55 -0800

We have agreed to run RSIP over TCP and UDP, I suggest we keep both and add
a message size field to the header of each RSIP message. The new header
would look like this:

    1 byte  1 byte    2 bytes
   +-------+-------+----------------
   |  Ver  |  Msg  | Msg Length | ...
   +-------+-------+----------------

This way both UDP and TCP can be used correctly.

Ylian Saint-Hilaire
Intel - Communication Architecture Labs

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

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

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

-Mike

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

Ylian Saint-Hilaire
-

-

-

---

From: "Mike Borella" <[email-masked]>
Date: Wed, 3 Nov 1999 10:25:06 -0600

This is more or less what we have, though we don't have enough
practical experience with the protocol to say for sure that it is sufficient.
The advantage of TCP is not necessarily flow control or congestion control, just
reliability.  That simplifies the protocol greatly by reducing the number of
failure
states.    On the other hand, UDP is more conducive for light clients.

-Mike

"Bernard Aboba" <[email-masked]> on 11/02/99 11:29:58 PM

Please respond to [email-masked]

Sent by:  "Bernard Aboba" <[email-masked]>

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

>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).

-

---

From: "Saint-Hilaire, Ylian" <[email-masked]>
Date: Wed, 3 Nov 1999 08:57:45 -0800

The message size in the header simply solves the problem of identifying the
end of a the message in a stream based protocol (like TCP). The message size
is sufficient to solve this. As to using TCP or UDP, I would favor keeping
the document as-is.

Ylian Saint-Hilaire

-----Original Message-----
From: Mike Borella [mailto:[email-masked]]
Sent: Wednesday, November 03, 1999 8:25 AM
To: [email-masked]
Cc: 'Saint-Hilaire, Ylian'; [email-masked]
Subject: RE: (NAT) RSIP over TCP stream

This is more or less what we have, though we don't have enough
practical experience with the protocol to say for sure that it is
sufficient.
The advantage of TCP is not necessarily flow control or congestion control,
just
reliability.  That simplifies the protocol greatly by reducing the number of
failure
states.    On the other hand, UDP is more conducive for light clients.

-Mike

-

---

From: "Mike Borella" <[email-masked]>
Date: Wed, 3 Nov 1999 12:53:56 -0600

Keep in mind the separation of coverage between the framework and
protocols drafts.  Just because there is a need to explore RSIP interaction
with other layer-3 protocols does not mean that we have to change
the protocols itself.  The protocols is extensible and, as in the IPSEC case,
we can continue to update it.

My point is that I would like to converge on a basic set of protocol primitives
that do "RSIP" sufficiently well.  Then we can implement to those primitives
with confidence that there will not be significant changes. THat is not to say
that we'll
never add new features to the protocol.

-Mike

"Tang, Tom J" <[email-masked]> on 11/01/99 04:40:25 PM

Please respond to "Tang, Tom J" <[email-masked]>

Sent by:  "Tang, Tom J" <[email-masked]>

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

  Mike :

    I do not think that the protocol should remain
  unchanged at this point.  There are still issues
  that need to be addressed, like multicast traffic.
  In a home network, the RSIP server would need to
  be multicast aware, unless I am totally mistaken.
  This was mentioned in the RSIP framework as an issue
  also (Page 22, To Do).

Tom J. Tang                      Telephone : (503) 712-1791
Network Software Engineer        Office Fax : (503) 264-3843
Intel Architecture Labs          Email : [email-masked]

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

-Mike

Ylian Saint-Hilaire

-----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

-Mike

Ylian Saint-Hilaire
-

-

-

-

---

From: "Mike Borella" <[email-masked]>
Date: Wed, 3 Nov 1999 12:56:26 -0600

Is there any particular reason that you feel this way?

-Mike

"Saint-Hilaire, Ylian" <[email-masked]> on 11/03/99 10:57:45 AM

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

Ylian Saint-Hilaire

-----Original Message-----
From: Mike Borella [mailto:[email-masked]]
Sent: Wednesday, November 03, 1999 8:25 AM
To: [email-masked]
Cc: 'Saint-Hilaire, Ylian'; [email-masked]
Subject: RE: (NAT) RSIP over TCP stream

-Mike

-

-

---

From: "Mike Borella" <[email-masked]>
Date: Thu, 4 Nov 1999 10:20:01 -0600

Approaching this from a different angle:

If we decide to support TCP, what is the major advantage of supporting
UDP as well? The only advantage that I can think of is support of thin
clients that do not have TCP stacks.  However, I believe that the industry
is moving away from UDP-only boxes.

-Mike

"Bernard Aboba" <[email-masked]> on 11/04/99 10:07:26 AM

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

Well, it avoids a flamewar, but when the time comes to do
your bakeoffs and interoperability testing, you can have
lots of complications. Some things to think about:

1. Is both UDP and TCP support required on both client
and gateway? Or is one a MUST and the other a SHOULD or MAY?
If the latter, how does a client determine which the
server will support?

2. Should a client choose UDP or TCP and use the same transport
for *all* control channel traffic to the gateway? For all
communication to the gateway with respect to a given
destination?

3. If the client can use UDP for some traffic, and TCP for
other traffic, how should it make the decision?

4. Are there some messages that SHOULD be sent using
TCP? (I'm thinking about route payloads in excess of
the MTU size).

5. Are certain behaviors prohibited, such as:
     a. Getting a lease over UDP and renewing it over TCP?
     b. Having a client send UDP to the gateway and receiving
          a response over TCP?
     c. Sending the same request on both UDP and TCP?

-----Original Message-----
From: Saint-Hilaire, Ylian [mailto:[email-masked]]
Sent: Wednesday, November 03, 1999 12:52 PM
To: 'Mike Borella'
Cc: [email-masked]; [email-masked]
Subject: RE: (NAT) RSIP over TCP stream

Unless we find consenses on the transport, as it stands RSIP servers will
most likely be implemented to allow  both TCP and UDP (but not required to).
This way clients have a choice, home and corporate products will be ok with
the standard and we don't risk getting into a "doing IKE over TCP" like
discussion. It may be a drag on developpers, but will keep everyone happy.

Ylian Saint-Hilaire

-

---

From: "Mike Borella" <[email-masked]>
Date: Thu, 4 Nov 1999 19:04:24 -0600

I think the issue here is whether the delay to allocate RSIP
resource and complete negotiations will be noticeable in
delay sensitive applications.  I don't think that this would be
a problem in a well provisioned network, especially since
the clients and server should be at most a couple of hops away.
If the delay from start to finish doing RSIP is more than 20-30 ms
then an application's "startup" is delayed but then it should flow
smoothly.

-Mike

Matt Holdrege <[email-masked]> on 11/04/99 06:03:38 PM

Please respond to Matt Holdrege <[email-masked]>

Sent by:  Matt Holdrege <[email-masked]>

To:   [email-masked]
cc:   [email-masked] (Mike Borella/MW/US/3Com)
Subject:  Re: (NAT) RSIP over TCP stream

At 03:44 PM 11/4/99 -0800, Eliot Lear wrote:
>Has anyone considered the implications of delay sensitive applications
>over RSIP?

Sure, but in absence of congestion, TCP should work fine. If there is
congestion, you're going to have problems in any case and at least TCP will
back off.

Or are you referring to TCP setup time? That would depend on the
application.

-

-

---

From: Vern Paxson <[email-masked]>
Date: Thu, 04 Nov 1999 23:25:22 PST

> I use ppp-over-tcp for tunnelling from time to time.  the performance
> is really lousy when packet loss is noticeable, because there are two
> layers of TCP retransmissions, and packets which the receiver thinks
> are lost end up getting delivered eventually..
> 
> The short answer is that TCP is a poor network layer for TCP; TCP
> would much rather run over a link layer where packets either show up on
> time, or not at all..
> 
> rsip-over-tcp will likely have similar performance characteristics;
> for that reason, I'd argue that rsip-over-udp should be the preferred
> mode of operation.

I don't get it - why will RSIP-over-TCP look like TCP-over-TCP?
Clearly RSIP-over-TCP won't have its own retransmission timers, etc.

		Vern
-

---

From: "Mike Borella" <[email-masked]>
Date: Fri, 5 Nov 1999 06:58:36 -0600

In the multiprotocol case, if we were to adopt it, it would
make the most sense to support both protocols at the server
and make the client pick one and stick with it.

-Mike

-----Original Message-----
From: Saint-Hilaire, Ylian [mailto:[email-masked]]
Sent: Wednesday, November 03, 1999 12:52 PM
To: 'Mike Borella'
Cc: [email-masked]; [email-masked]
Subject: RE: (NAT) RSIP over TCP stream

Ylian Saint-Hilaire

-

---

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

---------------------- Forwarded by Mike Borella/MW/US/3Com on 11/05/99 07:18 AM
---------------------------

RSIP doesn't tunnel over TCP - it would just use TCP on layer 4.
Since RSIP is designed for use within a single administrative
domain, packet loss should not be a major issue, and if it is,
using TCP will guarantee that it backs off properly.

-Mike

Bill Sommerfeld <[email-masked]> on 11/05/99 01:07:27 AM

Sent by:  Bill Sommerfeld <[email-masked]>

To:   Matt Holdrege <[email-masked]>
cc:   "Iyer, Prakash" <[email-masked]>, Mike Borella/MW/US/3Com,
      [email-masked], "Saint-Hilaire, Ylian"
      <[email-masked]>, [email-masked]
Subject:  Re: (NAT) RSIP over TCP stream

                         - Bill

-

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 05 Nov 1999 09:12:26 -0500

Sorry, I was half-asleep at the switch when i saw one of my "hot
button" issues and thought you were talking about shovelling user
packets around.  TCP as the only option for tunneling is bad, but
that's not what's being discussed.

sorry for the confusion.

Anyhow, IMHO, TCP-only for control channel seems like a reasonable
simplification, though you should consider how well it will work if
theres a ~200ms RTT between the RSIP box and the end system (e.g., if
there's an analog modem in the way).

Also, depending on exactly how the protocol over the control channel
works, you may get nailed by slow start and/or nagle if you want to
have multiple outstanding transactions at once..

					- Bill
-

---

From: "Saint-Hilaire, Ylian" <[email-masked]>
Date: Fri, 5 Nov 1999 06:56:20 -0800

Seems it would be safe to require TCP for the RSIP control channel to
guaranty Interop. UDP may be supported. This is much like crypto algorithms
where a set is required for Interop and other may be implemented. Over time,
implementations any discover stability issues that could favor UDP, if that
is the case, RSIP would not have to be re-opened.

Ylian Saint-Hilaire

-----Original Message-----
From: Mike Borella [mailto:[email-masked]]
Sent: Friday, November 05, 1999 4:59 AM
To: [email-masked]
Cc: 'Saint-Hilaire, Ylian'; [email-masked]
Subject: RE: (NAT) RSIP over TCP stream

-Mike

-----Original Message-----
From: Saint-Hilaire, Ylian [mailto:[email-masked]]
Sent: Wednesday, November 03, 1999 12:52 PM
To: 'Mike Borella'
Cc: [email-masked]; [email-masked]
Subject: RE: (NAT) RSIP over TCP stream

Ylian Saint-Hilaire

-

---

From: Matt Holdrege <[email-masked]>
Date: Fri, 05 Nov 1999 10:44:59 -0800

>is the case, RSIP would not have to be re-opened.

That sounds good on the surface, but I don't think it will really work. We 
aren't the protocol police so we can't tell people that one protocol is 
required for interop and other is an option. If a given vendor wanted to 
implement UDP, they would go ahead and do it and claim compliance with the 
RFC.

To really achieve interoperability we should have only one choice. Only if 
it is demonstrated that UDP is a better choice would we put it in the spec. 
If we later discover a reason for UDP, it shouldn't be a problem to update 
the spec. In that case, the market would determine a de facto standard 
anyway. That the protocol MUST work is the most important requirement.

-