RE: Some thoughts about "path failover"

Well, Spencer,
 
It is not me or you, but the customers of our product who should decide
ultimately.
I think either approach has merits & drawbacks. With sending packets
sequentially & retry multiple times,
you could end up in a scenario that the recovery just takes too long & and
it's simply not acceptable
for certain applications. On the other hand sending packets simultaneously
might not end up having more 
packets out in transit because as soon as a reply is returned then no more
retries are sent out assuming 
a small number in the address list. Again I don't think all customers will
want the same thing. So if we support both
ways, we'll end up something more in the middle than we go with just one.
 
Regards!
/Jing
 

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf
Of Spencer Dawkins
Sent: Friday, April 23, 2004 10:51 PM
To: [email protected]
Subject: Re: [Mobike] Some thoughts about "path failover"


Dear Jing,
 
See, this is exactly the problem. If YOU want to send path testing packets
out simultaneously, that's great, but if (insert the name of a major ISP
here) craters and ALL their customers decide to simultaneously test ALL
their alternative paths, that's not something I'm looking forward to.
 
We're really spoiled by overprovisioned network paths. Sometimes we're
spoiled enough to forget that when we lose path connectivity, we may not be
the only ones affected, and the exact moment when everybody is selecting new
paths that are now carrying more traffic, because the new paths still work,
is exactly the wrong time to start throwing more traffic into the network.
 
Synchronization is good in swimming and not good in path failover.
 
Spencer

----- Original Message ----- 
From: Jing Xiang <mailto:[email protected]>  
To: [email protected] <mailto:[email protected]>  ;
[email protected] <mailto:[email protected]>  ; [email protected]
<mailto:[email protected]>  
Sent: Friday, April 23, 2004 9:18 AM
Subject: RE: [Mobike] Some thoughts about "path failover"



Spencer/Pasi, 

I think sending packets over all paths simultaneously or sequentially can be
useful 
depending on circumstances. e.g. some customers might want to recover the
connection 
ASAP at any cost, in this case sending path testing packets out
simultaneously might 
make sense. In other cases, some customer might prefer certain paths because
of cost and 
not care much about recovering speed, then sending path testing packets
sequentially 
(subject to retry interval & retries) might make sense. 
It should not be that hard to have the protocol accormodate both cases. I
don't see 
any reasons we need to exclude either case in our considerations. 

Regards! 
/Jing 

-----Original Message----- 
From: [email protected] [ mailto:[email protected]
<mailto:[email protected]> ]On 
Behalf Of [email protected] 
Sent: Wednesday, April 21, 2004 9:55 AM 
To: [email protected]; [email protected] 
Subject: RE: [Mobike] Some thoughts about "path failover" 


Hi Spencer, 

I think we should consider this somehow. At least we should not 
send the path testing packets over all paths simultaneously, but 
instead separated by a short interval (since the paths could 
share links). 

My guess is that this is closer to RTO, but then again, window 
size in IKEv2 is not really related to congestion control (though 
in some sense, "path failover" is trying to detect if the missing 
packets were due to congestion, a broken link, or a dead peer). 

(I created new issue #14 about this so we don't forget this.) 

Best regards, 
Pasi 

> -----Original Message----- 
> From: [email protected] on behalf Of Spencer Dawkins 
> Sent: Friday, April 16, 2004 2:20 PM 
> To: [email protected] 
> Subject: Re: [Mobike] Some thoughts about "path failover" 
> 
> 
> 
> > >    - Initiator sends the previous IKEv2 request (not a new one, 
> > >      to avoid problems with window size) over all the paths. 
> 
> I know the Internet has changed a bit since Slow Start was introduced 
> :-} 
> 
> but my impression was that if you think you have a problem, sending 
> multiple packets into the network is not the right thing to so. You're 
> talking about sending single packets over multiple paths, but we don't 
> know how disjoint the paths are (so they may all traverse one link 
> somewhere on the way). Should we ignore this, or think about it? 
> 
> Pasi, do you have a sense that we're talking about a recovery 
> mechanism that we use during Fast Recovery, or during RTO (to put 
> things in TCP-speak)? 
> 
> Spencer 
_______________________________________________ 
Mobike mailing list 
[email protected] 
https://www.machshav.com/mailman/listinfo/mobike
<https://www.machshav.com/mailman/listinfo/mobike>