Subject: RE: (NAT) RSIP over TCP stream

From: "Iyer, Prakash" <[email-masked]>
Date: Thu, 4 Nov 1999 08:41:08 -0800

We wanted to keep UDP as an option because this issue has come up in the
past: some folks do not prefer TCP in large Enterprise networks due to
perceived scalability issues; especially if the RSIP server is implemented
in an edge gateway/router/gateway etc.

And if we decide to support both, it probably means that RSIP servers must
support both TCP and UDP and RSIP clients could support either. I am in
favor of prohibiting some of the combinations that Bernard proposes in his
email.

Maybe we can have an informal vote on this at the NAT WG meeting and unless
we see pushback, we could drop UDP altogether.

-Prakash

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

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

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: Gabriel Montenegro <[email-masked]>
Date: Thu, 4 Nov 1999 11:11:27 -0800 (PST)

> in an edge gateway/router/gateway etc.

you may run into other scalability issues at the rsip server much before
the number of tcp control blocks becomes an issue: things like running out
of addresses to lend, or if re-using a single address, running out of 
port numbers to hand out, plus the state associated with all of these
rsip bindings. i think the overhead of tcp over udp is a red herring 
here.

> we see pushback, we could drop UDP altogether.
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
                    sure, that would be my vote

it also simplifies your security story on the rsip protocol itself, as there's
ssl/tls  to re-use, for example, instead of defining something for use over udp.

-gabriel

-