RE: [Tsvwg] multiaddressing

> -----Original Message-----
> From: Randall Stewart [mailto:randall@stewart.chicago.il.us] 
> Sent: Wednesday, November 24, 2004 9:14 AM
> To: weddy@grc.nasa.gov
> Cc: tsvwg@ietf.org
> Subject: Re: [Tsvwg] multiaddressing
> 
> 
> Ok, I will finally comment a bit on this :-0
> 
> Wesley Eddy wrote:
> > On Mon, Nov 15, 2004 at 01:40:47PM -0500, Wesley Eddy wrote:
> > 
> >>In draft-crocker-mast-analysis-01 (now expired), the concept of
> >>"multiaddressing" for solving multihoming and mobility problems is
> >>explained.
> >>
> 
> The crocker draft was just an attempt to take the
> SCTP add-ip draft and duplicate it into a lower level.. I never
> thought it would work since the reason we have been holding
> the add-ip draft is the fact that there are security issues
> with it. These should be solved as soon as we finish the
> work on the auth draft.. but you can't do that without state which
> means a shim layer can't do it.. unless you want to mirror all
> the transport state at a layer below transport.. ughly and far
> from simple... I know that first hand.. I am working on NAT
> and SCTP and let me tell you its tricky when restarts can
> show up .. and thats not even the multi-homing .. just single
> homed SCTP :-0
>
<snip>
>
> I just don't see how you can have anything simple below transport
> doing this.. It just gets more and more complicated.. IMO we should
> leave it where per-connection state can be maintained so one can
> do the necessary things...
> 

When you say "all the transport state", what do you mean?  I do not
see it as being that daunting, perhaps because I don't assume that
a wedge implementation completely virtualizes all of the possible
network paths so that transport is unaware of path changes.

The wedge layer proposals (multi6 and HIP) assume that the wedge works
out the security issues in binding addresses to hosts.  And probably
the NAT issues in the future as well.  That leaves the congestion 
control, which should be tied somehow to distinct paths (distinct 
address pairs?).   

SCTP implementations will support multiple paths, so they probably 
won't not need much change at all in such a scenario.  TCP doesn't
support mobility, failover, or load balancing.  Depending on how 
ambitious one decided to be at the wedge layer, one might try to 
duplicate all of SCTP's capability there (probably not), but at least 
a simple cwnd/ssthresh reset upon path change detection at the wedge 
layer should not be that difficult, and would allow mobility and failover
multihoming to work correctly.

Tom

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg