On 11-nov-04, at 13:55, <firstname.lastname@example.org> 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.
Description: OpenPGP digital signature