Subject: Re: [Tsvwg] multiaddressing

From: Randall Stewart <[email-masked]>
Date: Wed, 01 Dec 2004 08:44:32 -0500

Ted/All:

First I am removing all the "cc's and to's" I think we are
all on the list and I don't want to cause multiple copies to
be recieved...:-D

Now, I have kept silent on this for a while now trying to
contemplate my reply so that it might be consistent  and
grokable if thats possible :-D

I am not going to touch the mobility aspect of this since
I have never been a supporter of the use of the SCTP-ADDIP
document as a mobility crutch. The idea is interesting.. don't
get me wrong.. but the document was NOT intended for that purpose.
(Note also that if I remember right from my last peruseal of the
  IPR page both Siemens and Cisco have IPR in for use of
  transport protocols in mobility.. DCCP and SCTP.. might
  want to check that page if you are a fan of this concept).

So I will exclude mobility from my discussion of multi-addressing.
Maybe in the future we can do something for mobility.. but I thought
we did that with mobile IP, maybe working at the lower layers does
not always work.. I don't know  :-/

Now, why does SCTP have multiple addresses... (in
priority order)

1) Fault-tolerance - When the design team for SCTP worked
    on SCTP we wanted to be able to get a message from sender
    to receiver with as much fault tolerance as we could. This is
    why we had all transmissions going to alternates, which work
    by Armando Caro at the U-D has shown is ok, but for performance
    you are better to fast-retransmit to the same destination and
    only move timeout's to the alternates... which makes sense
    if you think about it :-D

2) Load-balancing - Yep, sigtran wanted that.. but we were told
    that we would need to take it out since not enough research
    had been done on it. And what they wanted it for is exactly
    what most apps I have ever worked on have wanted it for, throughput
    plain and simple.

Now, why did we get ADD-IP in the picture then? And why has
it been floating around since October of 2000??

Well the third item on the list for sigtran was to dynamically
add and delete the addresses. Why, because a sigtran association
was envisioned to be up for months and maybe even years without
coming down. So I have this wonderful fault tolerant server
and I plug in a new NIC card and do "ifconfig new-card some-address"
and I DON'T want to take down the association, instead I want it
to silently add to the existing association. And for IPV6 you have
the re-number case to deal with.. yeah I know they keep the
old address for a while.. but eventually it is un-useable .. so
having add-ip helps here too.. (remember the association is up
for a year or more...hopefully).. Thats the why, and
the agreement that was made is to spin it into a seperate draft
along with the PR-SCTP draft as well and work on them so that
we could at least get the base protocol out. Scott also arranged
for these drafts to move to TSV since sigtran was 'closing' :-> and
besides transport extensions are to be done in tsv.... at least
at the time (tcpm did not exist yet).

Now why has ADD-IP "treaded water"? Because we (the authors) realized
that there is a security issue with it. Its not that it has not been
implemented.. most every SCTP stack at the last inter-op supported
BOTH PR-SCTP(RFC3758) and ADD-IP.. and in fact,
more supported ADD-IP then PR-SCTP (and its been that way all along).

So whats the hold up? Security plain and simple...
how do I reasonably know that the  guy I started talking to is
the guy that sent me this add/delete IP address thingy?
We are now about throught that problem in that
the auth draft for SCTP (modeled after the pbk draft) adds the
needed security and ADD-IP will require the implementation
and use of the auth draft (of course users will probably
be able to turn it off.. but it will be on by default).

That being done, sigtran will finally get the ADD-IP draft
finished.. gee.. only 4 years :-D

But what about all this other cruft... load balancing
for one?

Well, Jana's work has shown that doing load balancing
in the transport is most efficient for throughput. Does
this handle every case.. I don't think so.. I know
folks have mentioned doing prioritization and other
funky things.. but IMO the reality is throughput
is the major reason folks want loadbalancing... not
the other side issues. IMO we optimize for the majority
and provide a turn-off knob so that the few apps that
want to do some special thingy can... Of course there
is still some more work that needs to be completed
until CMT can be made available in a draft form.. so
we are not there yet IMO but we are getting closer
(research first, engineering later) :-D

So, how do we proceed? It seems to me a Shim layer
will not work very well unless you so intergrate
it with the transport that it becomes part of the transport.
Is the shim going to have to start tracking its own PCB, it
would if it wants to do something like the AUTH draft, that
was a fundamental problem of the old crocker draft IMO. So
you end up having this shim either have a pcb per transport
connection or it gets its hooks deeper and deeper into
the transport's and merges in sort of...

In that case .. sure I can call a section of the
SCTP stack the "shim" but I just don't see it
working very well seperated out.. not without opening
up major interfaces between the new shim and transport and
that does not even account for the state thats needed.

Look how well congestion manager has worked.. its the
same issue.. its concept was to tease out the congestion
managment into a sub-layer.. as yet I see no deployment
of CM and I, for one, will not hold my breath waiting
for it :-D Good idea its just not making its way
out into the world (sorta like mobile IP I guess)...

So where does that leave things?

I think that DCCP and SCTP handle the multi-homing for
now. Lets use these for those app's that need multi-homing
(including in the future load balancing if that work
  pans out) and let those that don't need it continue
to use TCP or UDP. If an app is over TCP that needs the feature its
quite easy to migrate to SCTP.. usually only a couple
of lines of code. Hopefully DCCP will have a similar
API that makes UDP easy to migrate to DCPP..

DCCP and SCTP have solved these
problems lets use these solutions as an encouragment
to use the new protocols... If you need the features
use the existing tools... If you don't stick with TCP
and UDP

R

Ted Faber wrote:
> 
> Despite my testy reply, I think we agree a bunch more than we disagree.
> I understand what you're saying and I apologize for snapping.
> 
> As I'm sure you know, there's quite a bit to worry about beyond naming
> when you consider endpoints that move often and need to maintain
> communications when they do so.  You can constrain yourself into an
> unsolvable problem pretty quickly.  IMHO, one should grab at tradeoffs
> when they appear.  For example, the scale of most of the proposed MANETs
> I've seen (other than sensor networks) means you can trade scope for
> consistency in the naming system.  A small (by Internet standards)
> network of endpoints that change their name-to-address mappings
> frequently is a lousy fit for DNS, and there's no good reason to use it
> there.  (Though having a name system tuned for that environment repsond
> to DNS queries might be of practical use.)
> 
> The more of these sorts of discussions I have, the less I think that the
> various uses of multi-homing (e.g., mobility, availability, load balancing)
> are all that closely related.  I'm less optimisitic that there is a
> single "multi-homing" solution that will scratch all those itches.  In
> any case I think that it's an area in which people should tread
> carefully and precisely.
> 
> I'm also concerned about making transport level changes without a clear
> need or at least a clear indication of the tradeoffs.  I've yet to see a
> case where a system is impossible without moving multihoming into the
> transport or where all the hard parts are solved and the extra
> kernel/layer crossings are the only think keeping the system from being
> efficient.  I'm not saying that they don't exist, just that I haven't
> seen clear demonstrations.
> 
> Finally endpoint to endpoint transport where both endpoints have static
> single identifiers is tricky.  Building on that rather than complicating
> it seems like the way to go.  I recognize that's an opinion, but it's
> one that I hold pretty strongly.
> 

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg