Subject: RE: (NAT) RSIP over TCP stream

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

If the link is slow and undependable, then why not use TCP and
avoid reinventing timeout and retry as well as congestion avoidance?

-Mike

Burak Kevin-LKB026 <[email-masked]> on 11/05/99 08:06:11 AM

Sent by:  Burak Kevin-LKB026 <[email-masked]>

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

I believe it should be an option in both the server and the client. To be a
truly competitive server, then yes it will have both TCP and UDP. Whether
it's TCP or UDP is more than likely to depend upon the link itself. If it is
a highly dependable link such as 10BT then TCP with all its built-in
reliability would simplify the RSIP FSM. But if the link is slow and/or
undependable then UDP would be better served. And yes, that would complicate
the RSIP FSM. In the end, the market will dictate which one will be more
prevalent. If both are an option then I will probably implement TCP first
followed by UDP.

Cheers,

-Kevin

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

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

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

Please respond to [email-masked]

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

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
Intel - Communication Architecture Labs

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

>avoid reinventing timeout and retry as well as congestion avoidance?

Yup. That's exactly when you *do* want TCP!
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.