Subject: Re: (NAT) Changes for RSIP protocol -04

From: "Mike Borella" <[email-masked]>
Date: Fri, 19 Nov 1999 13:37:03 -0600

We had a rough consensus of about 2:1 in favor of
using TCP for now with the future open to UDP.

I didn't see any messages from you regarding this on
the list or in the archives.

Matt's email was not responded to, which in itself makes a
case for consensus.

-Mike

Eliot Lear <[email-masked]> on 11/19/99 01:10:49 PM

Please respond to [email-masked]

Sent by:  Eliot Lear <[email-masked]>

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

As I wrote, I do not believe we had a real consensus on the control
protocol.  So please be prepared for my objection should you try to
advance the protocol.
--
Eliot Lear
[email-masked]

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

---

From: Vern Paxson <[email-masked]>
Date: Sun, 21 Nov 1999 23:49:53 PST

> Really I don't believe the
> people in the room had the opportunity to digest the issue.

I agree with this, and that further discussion on the list is worth while.

> I believe valid reasons for TCP are the following
> (and Vern can correct me if I'm wrong or missing something in this
> list):
> 
>      [1]  congestion control,
>      [2]  fair share of bandwidth,
>      [3]  Order-enforced reliable delivery of a data stream,(*)
>      [4]  Reliable frag/defrag.

A couple more come to mind, though I don't think they're particularly
germane for RSIP:

       [5]  high performance over a wide range of network
	    properties / conditions

       [6]  strong protection against packets delivered late or
	    multiple times

I agree that the key issue is traffic volume: if a solid argument can be
made that the volume will be low and that the packet sizes will be small
(so no fragmentation needed), then congestion control can be dealt with
using exponential backoff on a stop-and-go retransmit timer, and UDP is
appealing.

		Vern
-

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 22 Nov 1999 07:11:39 -0800 (PST)

--- Mike Borella <[email-masked]> wrote:
<... snip>
> 
> The RSIP protocol was always meant as an application, from the
> -00 draft on.
> 

Mike,

RSIP is not an application protocol. As you will note from the 
minutes (posted just a few minutes ago :-), host level applications 
are expected to run unchanged with RSIP installed on the system. 
Essentially, "RSIP-enabled IP stack" replaces the "IP stack". 
I view RSIP as an administrative function that needs to be 
configured one time for the host.

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.

---

From: "Mike Borella" <[email-masked]>
Date: Mon, 22 Nov 1999 09:13:55 -0600

No, the RSIP protocol, for control and signalling, *is* an application.
However, RSIP "data flow" is not application-specific.  It is highly
analogous to IKE and IPSEC: IKE runs as an app, passes info to
the IPSEC module in the stack, but said IPSEC module is not tied
to the particular apps that use it.

-Mike

Pyda Srisuresh <[email-masked]> on 11/22/99 09:11:39 AM

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

To:   Mike Borella/MW/US/3Com, Eliot Lear <[email-masked]>
cc:   [email-masked]
Subject:  Re: (NAT) Changes for RSIP protocol -04

Mike,

cheers,
suresh

-

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 22 Nov 1999 07:29:31 -0800 (PST)

Agree with the analogy. 
My point is that the RSIP control client should only be viewed as 
an administrative utility that is used infrequently.

cheers,
suresh

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 22 Nov 1999 13:41:13 -0500

In message <[email-masked]>, Pyda Srisu
> an administrative utility that is used infrequently.

Precisely.  The whole philosophy of RSIP is that most hosts don't need public 
addresses most of the time; if they did, you'd just assign them permanently 
and not bother with RSIP or NAT.  That means that there almost certainly will 
not be much traffic between clients and the RSIP server.

		--Steve Bellovin

-

---

From: "Mike Borella" <[email-masked]>
Date: Mon, 22 Nov 1999 12:49:31 -0600

Not exactly.  The hosts may need public addresses all of the time.
RSIP allows multiple hosts to share the same address w/o permanent
assignment.  If addresses weren't a presumed scarcity, we'd just use
DHCP.

Nonetheless, one would hope that this doesn't mean that RSIP requires
a lot of traffic between clietns and servers, but we won't know until we have
real-world experience.

-Mike

"Steven M. Bellovin" <[email-masked]> on 11/22/99 12:41:13 PM

Sent by:  "Steven M. Bellovin" <[email-masked]>

To:   Pyda Srisuresh <[email-masked]>
cc:   Mike Borella/MW/US/3Com, Eliot Lear <[email-masked]>, [email-masked]
Subject:  Re: (NAT) Changes for RSIP protocol -04

          --Steve Bellovin

-

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 22 Nov 1999 13:59:20 -0500

> assignment.  If addresses weren't a presumed scarcity, we'd just use

This is exactly my point.  Yes, hosts can share addresses, but that only works 
when most don't need outside addresses most of the time.  

		--Steve Bellovin

-

---

From: "Mike Borella" <[email-masked]>
Date: Mon, 22 Nov 1999 12:57:47 -0600

Addendum:

If micro-flow policy is used, there probably will be a fair amount of traffic
between
client and server, especially if the client is "surfing".  In fact, there will
probably
be as much as with SOCKS when similar policy is used.

-Mike

---------------------- Forwarded by Mike Borella/MW/US/3Com on 03/22/2000 12:51
PM ---------------------------

"Mike Borella" <[email-masked]> on 11/22/99 12:49:31 PM

Please respond to "Mike Borella" <[email-masked]>

Sent by:  "Mike Borella" <[email-masked]>

To:   "Steven M. Bellovin" <[email-masked]>
cc:   Pyda Srisuresh <[email-masked]>, Eliot Lear <[email-masked]>,
      [email-masked] (Mike Borella/MW/US/3Com)
Subject:  Re: (NAT) Changes for RSIP protocol -04

-Mike

          --Steve Bellovin

-

-

---

From: "Iyer, Prakash" <[email-masked]>
Date: Mon, 22 Nov 1999 11:01:32 -0800

Except that in small business / consumer networks, multiple IP addresses may
not be an option (cost could be a factor). We also assume than in such
(eventually multi-segment, multi-subnet) networks, a few (order of 10s) of
these IP addressable entities will access the Internet and will be accessed
from the Internet. So in a sense, there will be a fair amount of traffic to
the RSIP server, which will most likely be co-located on a consumer gateway
type device.

-Prakash Iyer
Intel Arch. Labs

-----Original Message-----
From: Steven M. Bellovin [mailto:[email-masked]]
Sent: Monday, November 22, 1999 10:41 AM
To: Pyda Srisuresh
Cc: Mike Borella; Eliot Lear; [email-masked]
Subject: Re: (NAT) Changes for RSIP protocol -04 

In message <[email-masked]>, Pyda
Srisu
> an administrative utility that is used infrequently.

Precisely.  The whole philosophy of RSIP is that most hosts don't need
public 
addresses most of the time; if they did, you'd just assign them permanently 
and not bother with RSIP or NAT.  That means that there almost certainly
will 
not be much traffic between clients and the RSIP server.

		--Steve Bellovin

-

-

---

From: Gabriel Montenegro <[email-masked]>
Date: Mon, 22 Nov 1999 11:06:27 -0800 (PST)

> Gabriel,
> 
> Both your reasons are potentially valid.

thanks

> I'm not a mobileip expert.  

whoa! who ever mentioned mobileip? i don't follow this thread. perhaps
you misunderstood me, i certainly never mentioned or was even thinking
of mobileip in this thread.

you asked for one reason to use tcp, that's what i tried to give.
for example for extranet applications or for wireless rsip clients,
the rsip server will have a huge fanout of connections of widely varying
characteristics. tcp with auto-tuning and others provides a
better way to handle this, i believe.

whether all this stuff can be implemented in udp or not (as portions
have been in dhcp and dns), well, of course. but do we want to?

-gabriel

-

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 22 Nov 1999 11:32:19 -0800 (PST)

Clearly, you can design clients to cause a lot of traffic in the
network. But, a good design should focus on minimizing the traffic.
If a host is likely to use a set of ports, the client ahould reuse the 
same ports without releasing and reclaiming frequently (i.e., port 
thrashing). The TLV options(such as lease time) are in the protocol so 
one could optimize the use of ports and minimize control traffic.

cheers,
suresh

---

From: "Mike Borella" <[email-masked]>
Date: Mon, 22 Nov 1999 14:14:02 -0600

This isn't the point.  Of course, a poor design would cause more
traffic than necessary.

A good design focuses on solving a problem with the least overhead
possible.  If the network admins want to support fined-grained control,
they can, but this will increase the amount of traffic.  If they don't then
much less traffic will be necessary.

-Mike

Pyda Srisuresh <[email-masked]> on 11/22/99 01:32:19 PM

To:   Mike Borella/MW/US/3Com, [email-masked]
cc:
Subject:  Re: (NAT) Changes for RSIP protocol -04

cheers,
suresh

-

---

From: "Mike Borella" <[email-masked]>
Date: Mon, 22 Nov 1999 14:19:28 -0600

Ok, I think I understand now...

I think you're considering N IP addresses with M clients, where M >> N and
the clients de-allocate resource as soon as they are done using them.

The other situation is that M clients share N addresses and we don't "thrash"
the port space - a client keeps its ports as long as it needs to, throughout
multiple sessions, etc.  I think that in the "little RSIP" case, this makes more
sense.

It would really help if we scope this problem more clearly.  There's a
difference
between "little RSIP" with a small number of clients (say, < 100) on a SOHO LAN
versus "big RSIP" with 1000's of clients behind multiple gateways.  I'm not
even sure that RSIP is the best solution for the latter environment and there
may not be as much demand.

-Mike

"Steven M. Bellovin" <[email-masked]> on 11/22/99 01:43:25 PM

To:   "Iyer, Prakash" <[email-masked]>
cc:   Pyda Srisuresh <[email-masked]>, Mike Borella/MW/US/3Com, Eliot Lear
      <[email-masked]>, [email-masked]
Subject:  Re: (NAT) Changes for RSIP protocol -04

In message <[email-masked]>, "Iye
> the RSIP server, which will most likely be co-located on a consumer gateway

I'm still not making myself clear.  RSIP (and NAT) are like virtual
memory, if you will.  Virtual memory works if and only if the average demand
is below some limit corresponding to the amount of real memory available.  If
you exceed that limit, the system thrashes and no work gets done.

Sure, public addresses are limited, or we wouldn't need concepts like RSIP and
NAT.  But if there's ever too much demand -- which in turn means too many
messages -- the whole scheme falls apart.  The only way there can be a lot of
traffic to a reasonably-sized RSIP server is if very many hosts on the inside
need public addresses.  That in turn implies very short lifetimes,
starvatation, and all the other bad things that happen when you can't meet
your average load.

You say a "few (order of 10s)" will need to talk to the Internet at any one
time.  How long is each "session"?  It's hard to see how it can be less than a
minute, which in turn implies a request to the RSIP server every few seconds.
That isn't very much traffic...

          --Steve Bellovin

-

---

From: "Mike Borella" <[email-masked]>
Date: Wed, 24 Nov 1999 07:32:22 -0600

So far, we haven't considered differentiating between TCP and UDP ports.

So there would have to be a check in the RSIP driver that looks for ports
that it already has open.  I don't think that this will be an issue.

-Mike

"Bernard Aboba" <[email-masked]> on 11/24/99 01:51:01 AM

Please respond to "Bernard Aboba" <[email-masked]>

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

To:   Mike Borella/MW/US/3Com, "'Steven M. Bellovin'" <[email-masked]>
cc:   "'Pyda Srisuresh'" <[email-masked]>, "'Eliot Lear'" <[email-masked]>,
      [email-masked]
Subject:  RE: (NAT) Changes for RSIP protocol -04

If RSIP leases are set to long times then
connections will remain up but most of the
time they won't be sending very much. This has the
result of adding lots of state to the gateway
but not much in the way of traffic. On the other
hand if the lease times are set lower then many
of those connections will age out. You'll have more
control traffic but less gateway state.

BTW, I am curious about the implications of not
differentiating between allocation of TCP and UDP
ports in RSIP. The case I have in mind is a DNS
server behind an RSIP gateway (strange, I know). It will forward
DNS queries to another server, and so will ask for a source port to
send to dest port UDP 53. If it then attempts to do a zone transfer
from that same dest, and again makes a request for a source
port to send to dest port 53 (TCP this time) what happens? Does
RSIP allocate another port? Does it return an error saying
"sorry, gave you one already?"

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Mike Borella
Sent: Monday, November 22, 1999 12:11 PM
To: Steven M. Bellovin
Cc: Pyda Srisuresh; Eliot Lear; [email-masked]
Subject: Re: (NAT) Changes for RSIP protocol -04

Not necessarily.  Depends on the size of the network.  Theoretically,
RSIP can support 10's of thousands of client all sharing 1 IP address.

Realistically, far fewer, but hundreds of clients per address is still
reasonable.
You're more likely to run into congestion on the router before RSIP itself
is the bottleneck.

-Mike

"Steven M. Bellovin" <[email-masked]> on 11/22/99 12:59:20 PM

      [email-masked]

In message <[email-masked]>, "Mike Borella"
> assignment.  If addresses weren't a presumed scarcity, we'd just use

This is exactly my point.  Yes, hosts can share addresses, but that only
works
when most don't need outside addresses most of the time.

          --Steve Bellovin

-

-

-