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

Iljitsch van Beijnum wrote:
> John,
> 
> On 11-nov-04, at 13:55, <[email protected]> wrote:
> 
>>>> So what I meant more was that if we use keep-alives at the multi6
>>>> layer, then perhaps this could be something that the upper layer
>>>> could set the keep-alive behavior.
> 
> 
>>> I could just go on disagreeing, but let me ask you this: assuming a
>>> decent multihoming solution, under which circumstances would upper
>>> layers want to do something like that, trying to achieve which
>>> benefits?
> 
> 
>> I'm not wedded to the use of keep-alives; to back it up a level,
>> if there are keep alives at the multi6 level, it would be nice if
>> the use of the keep-alive could be tunable by the ULP.  If we
>> toss out keep-alives at the multi6 level, I won't lose sleep at it.
> 
> 
> Keepalives aren't really the correct name for what the multi6 layer 
> needs. The multi6 layer needs to know which address pairs work and which 
> don't. There are basically two approaches to this: try every combination 
> and pick the one that loooks best, or start trying combinations until 
> you find the first one that works and use that one. (These are extremes, 
> something in the middle is also possible.) This reachability testing 
> MUST happen in the multi6 layer for robustness and security reasons.
> 
> The question that we've been talking about is when this reachability 
> testing should happen. I don't think sending keepalives all the time or 
> when idle is a good idea here. For multihoming purposes, it's enough to 
> do reachability tests when the traffic patterns indiciate a _possible_ 
> loss of connectivity. This would be when there is only traffic in one 
> direction.
> 
> Now if applications or transports feel they need to notice immediately 
> when connectivity goes away, they can always send keepalives when the 
> session is otherwise idle. It doesn't make sense to subcontract this job 
> to the multihoming layer for two reasons:
> 
> 1. There may not be any multihoming so no keepalives happen
> 2. The added complexity of interfacing between layers
> 
>> At the same time, how does the multi6 layer understand what kind of
>> connectivity the application needs?  With wireless links, its really
>> easy to get intermittent connectivity. 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'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 min(x,y)+abs(rand()+0.5)*(max(x,y)-min(x,y)) (ok 
> this means either x or y at random) throughput.

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 (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).

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. We looked into it several times before (webmux, in 
particular), and it ends up creating substantial problems with priority 
inversion, layered multiplexing, etc.

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBnBwdE5f5cImnZrsRArs3AKCVf8QbH/zkpXbPW/I+9DXrdU+WCQCaAniJ
EzYtP5l+rESLyyp8yHpUcC0=
=aqZR
-----END PGP SIGNATURE-----