Subject: RE: [Tsvwg] multiaddressing

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 1 Dec 2004 22:57:57 -0800

Randall, I agree with you on many points of your argument,
but I think the problem is more general than you stated and
will require multiple solutions.  In particular,

> Now, why does SCTP have multiple addresses... (in
> priority order)
> 
> 1) Fault-tolerance - 
> 2) Load-balancing - 

Fault tolerance is an interesting case, because (as it is defined
in SCTP) it means that certain transport PDUs have different
priority or delivery semantics than others.  In particular, 
you want to force timeout retransmissions onto a different path. 
I agree here that if you put this kind of function in a multihoming
shim layer, it makes the interface more complicated to transport--
in this case, you want transport to be able to specify which TPDU
goes where, and to know where TPDUs came from, etc.  So I would
agree that SCTP, being oriented towards signaling transport, has
particular signaling fault tolerance requirements in mind (the
requirements may extend beyond signaling and be generally 
applicable), and it makes sense to try to solve it in SCTP.

For load-balancing, it is not as clear to me-- it could be in
a shim, it could be in transport, it could be in session layer.  
It seems to make sense to integrate it with congestion control,
which might lean it towards transport again, but if it is not
in transport, then I don't believe that the interface is necessarily
that complex.

But there are also the site multihoming requirements in RFC3582
for multi6.  I do not think there is a general consensus in multi6
that migration of all apps to DCCP and SCTP is the answer.

In the future, wireless systems with multiple radios will become
more prevalent.  These radios may connect to different providers.
Additional considerations that may arise are energy consumption,
link or network layer indicators of path performance, and relative
monetary costs that may favor one path over another. It is not clear
to me that transport is where the path selection decisions over those
kinds of disparate paths must reside.

I'd like to keep more options open for the future, including
considering whether shims might make congestion manager
more deployable, and multihoming more widely applicable, and even
handle mobility.  In the near term, it seems like the multi6 work
will pick up in another (to be chartered) working group, and if so,
it will probably be a good time for tsvwg to start thinking about
how transport will be affected by such a solution.

Tom 

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

---

From: Randall Stewart <[email-masked]>
Date: Thu, 02 Dec 2004 06:42:39 -0500

> applicable), and it makes sense to try to solve it in SCTP.

Two comments to the above point. A) SCTP has a broader
scope then its initial signalling world. and B) I am a bit
unclear on how one gets differetn priority's. If you do the
currently recommend approach, retransmissons at timeout goes
to the alternate. Then all data in queue, unack'd, when the
timeout happens moves to the alternate. These will arrive
in the same order ... so I don't think I see your point...

> in transport, then I don't believe that the interface is necessarily

You can in theory do load-balancing with SCTP in an upper
layer today. However there are issues with it... i.e. see
Jana's papers on CMT and his previous ones. I agree that
for the upper layers the interface is NOT complex.. I was
thinking more lower layers.. i.e. moving it to a shim....

> that migration of all apps to DCCP and SCTP is the answer.

The goals set forth in RFC3582 may or may-not be reachable...note
the word goals.. they are not requirements IMO if they are then
the RFC should state they are requirements instead of goals :-0

> kinds of disparate paths must reside.

And there is where having switches in the transport to turn
those decisions off is a good thing. That way the application
or layer that is aware of the costs etc can take these into
account. I agree wireless and future radio systems will become
available.. but I don't see them as pre-dominant. While driving
in my car I am not going to do a lot of web-browsing.. its
cheaper for me to do it at home.. and until the radio world
realizes that I will not pay X$ per minute.. when I can have
unlimited use at home.. thats going to stay I think... When
I worked at Mot I always heard how radio IP would sweep the
world ... and that was quite a few years ago.. I agree it
will have its place.. but i dont see it as predominant until
major changes in pricing and policy happen.. and that is blocked
by all the govt's that like to get rich on spectrum and of
course the cost and recovery that the company's want..

But I digress and go down a rat hole :->

Lets just say, yep I agree, but it won't be the primary method
of attachment for quite some time... :-D

> how transport will be affected by such a solution.

Maybe... I have my doubts on the sucess of a shim. It just seems
to me that all this multi-homing/mobility glock is just trying
to take the things done in DCCP and SCTP and re-do them
in another layer to keep us all busy working on things... and
at the same time (like nat) gut some of the incentives to go
to the next newer technology... Until the IETF stops this type
of stuff (which won't happen) it will get harder and harder
to roll out any technology... just wait a new one will come
out...

R

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