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

From: "Mike Borella" <[email-masked]>
Date: Sun, 21 Nov 1999 14:26:18 -0600

You are always welcome to express your opinion on the list.
However, given that we discussed the issue on the list for
some time before the meeting, that would suggest that people
had time to think about it.

We're not using TCP for the sake of keeping state - review the
arguments in the archives.

The RSIP protocol was always meant as an application, from the
-00 draft on.

As per discussion in the meeting, I think that the multiple redundant
server RSIP requires a lot of additional complexity, and addressing
all of the possible scenarios in one protocol will require overloading.
Like PIM, where there's a dense mode and a sparse mode based on
our best assumptions of deployment, so it should be with RSIP.

-Mike

PS: TCP vs. UDP is a complicated issue but it need not be solved
     here.

Eliot Lear <[email-masked]> on 11/20/99 04:35:25 PM

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

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

I did send an earlier note out on the subject (I'll pull it and send it
under separate cover).  I didn't restate my opinion on the list since it
was not clear to me I was welcome to do so at this point.  Here it is,
for the record.

The discussion for use of TCP was improperly directed; and consensus at
the IETF isn't just a count by numbers vote.  Really I don't believe the
people in the room had the opportunity to digest the issue.  I apologize
for not objecting at the meeting.  I don't believe I'm alone in my
opinion, however.

To use TCP one should have a reason for doing so. Otherwise you're
keeping state for state's sake, and this impacts scalability and service
migration complexity.  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 data stream to me should be of sufficient duration to require
sequencing.

Recalling that we pretty much envisioned this protocol being a host
level -not application level- mechanism, so far as I can tell, the
protocol will not be sufficiently chatty to require congestion control
or fair share of bandwidth (2 packets in either direction does not a
long data stream make).  The protocol is lock step, so I don't see why
order should be an issue. I don't see the expected use of frag/defrag.
Please show me the case for any one of these four before we proceed
further.  I don't think I'm asking too much.  Again, an expanded theory
of operation in the draft would clarify this point.

I also believe that this does need to be reviewed in the context of an
overall security model, where there are more than one redundant RSIP
servers.  And there may be corner cases there as well which we need to
review.

By the way, I *do* agree with you that we should choose ONE.  I just
think we're choosing the wrong one.  And remember, we can always go back
and add TCP later ;-)
--
Eliot Lear
[email-masked]

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

---

From: Matt Holdrege <[email-masked]>
Date: Sun, 21 Nov 1999 18:15:09 -0800

Eliot,

First of all, some of your posts are not making it to the list.
You can check the archives to make sure. I can see this one
since Mike forwarded it to the list.

Secondly, you make some valid points as to why TCP isn't required.
But you missed some points as to why it would be required and you
didn't really state (AFAICS) why UDP should be the only choice.

As we said in the meeting, RSIP control packets may be sharing
the same data channel as various other TCP streams. So congestion
control is a necessary feature.

-

---

From: Eliot Lear <[email-masked]>
Date: Sun, 21 Nov 1999 20:59:43 -0800

Matt,

> since Mike forwarded it to the list.

Thanks.  Let's take that one offline and work on it.  In case this
doesn't get to the list would you do me the favor of forwarding it as
well?

> didn't really state (AFAICS) why UDP should be the only choice.

Well, my point is that TCP is overhead, and one shouldn't add it unless
it is necessary.  As such I don't see the need to justify UDP until such
time as there is even a single valid argument for TCP.  In other words,
Show Me Yours, first ;-)  

I don't think this the case, but if you're asking me why There Can Be
Only One, in keeping with the IETF model choices within protocols are
discouraged unless there is an identified legitimate reason for either
choice (the Don't-Option-Me-to-Death notion).  Reduces implementation
complexity.

> control is a necessary feature.

Your statement can be taken two ways- to protect the other streams
against this one, or to protect the control channel from the other
streams.   The former scenario presumes that there will be sufficient
volume of traffic that the other streams need protecting.  The latter
requires that the other streams back off due to dropped packets.  That
too requires volume for TCP to matter.  So, where's the volume?

By the way, someone pointed out that code reuse is a good thing, and
that you get keepalives and anti-spoofing for free.  Fair enough, but
that raises the question of whether keepalives are necessary, given the
lease model and the fact that you'll have a separate tunnel up and
running (unless you're fiddling with the routing system, as presented at
IETF).  In other words, how does this differ from DHCP?  Is the expected
churn sufficiently high? (That would answer my volume question.)

Thanks,

---

From: Matt Holdrege <[email-masked]>
Date: Sun, 21 Nov 1999 23:15:02 -0800

>too requires volume for TCP to matter.  So, where's the volume?

I'm going under the assumption that a burst of TCP (e.g. HTTP) traffic 
mixed with some RSIP control traffic would behave better if RSIP used TCP.

As for the potential RSIP control volume, it's just theory for now. Clearly 
there will be a range between moderate usage and high-volume. But we can 
only guess now how high the volume could be. I think it's safer to make the 
assumption now that the volume could be high enough to matter rather than 
choose UDP now and regret the choice when we find out much later that we 
should have chosen TCP. We probably won't find that out til after RSIP has 
been significantly deployed. In other words post-lab.

As for UDP, if there are any overriding reasons for using it, we should 
hopefully discover that in the lab.

>churn sufficiently high? (That would answer my volume question.)

I don't think it would be wise to make the assumption that everyone's 
internets use such a simple architecture. Keepalives have proven quite 
valuable in certain situations.

-