[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-multi6-v4-multihoming-02
John,
On 11-nov-04, at 13:55, <john.loughney@nokia.com> 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.