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

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.