Re: Comments on draft-ietf-multi6-v4-multihoming-02

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 18-nov-04, at 4:50, Joe Touch wrote:

> > > How do we classify when the
> > > connectivity is too poor to be useful - the application should be 
> > > able
> > > to determine this and ask for using a different address pair.

> > This is an unsolved problem. I think at some point we need an 
> > interface for this, so that multi6-aware applications can influence 
> > certain aspects of multihoming operation.

I'm assuming you're not disagreeing with this part?

> > I've always assumed that once basic multihoming is in the can the 
> > next step would be to make TCP multihoming-aware so that it can load 
> > balance over more than one address pair at a time in order to achieve 
> > x+y throughput rather than max(x,y) throughput, or worse

> IMO, this is a very bad idea, despite its prevalence in certain 
> communities. If this is where you're going, you need TCP to know the 
> AGGREGATE of its window, and behave accordingly, but as to 
> load-balancing, that's building IP into TCP, and assumes that address 
> pairs are meaningful in this context

I don't see the problem...?

> (if there are 8 pairs on each end, are there 8 end-to-end pairs, or 
> 64? - there could be 64 unique routes, depending on what IP does).

Obviously a pair can't be on one end. If one host has 4 addresses and 
the other 3, then there are 12 pairs. Communication can happen over one 
pair in both directions (12 possibilities) or different pairs in 
different directions (132 possibilities) for a total of 144 different 
ways to communicate between these hosts.

> If you want to make a set of links look like one link, build a tunnel 
> with a loadbalancing demux in it, but don't go to TCP for that 
> functionality, IMO.

So you propose an additional layer of functionality that massages the 
different properties of the different links such that TCP's assumptions 
about the link it runs over (reasonably stable RTT, packet loss = 
congestion) work? This is exactly how we always get into trouble: add 
protocols that break the assumptions of previous protocols. It would be 
much better to change TCP so it has all the information and can make 
the right decisions. Basically this would be like running several TCP 
sessions in parallel, except that we have to ensure in-order delivery. 
Unless this aspect turns out unexpectedly difficult, I see no problems.

> We looked into it several times before (webmux, in particular), and it 
> ends up creating substantial problems with priority inversion, layered 
> multiplexing, etc.

Do you have links to stuff I can look at in this area?