Re: issue 11 -- window size

 > 
> Tero Kivinen writes:
> 
> > Yes, I agree that doing probing of previously non-working 
> > addresses, which now have unidirectional connection, can cause 
> > the connection to loose packets in case there is NAT between both 
> > connections we are trying to use. So I suggest we do not try to do 
> > probing on that case, but simply start finding the working path only 
> > after we know there is problem with current path.
> 
> I think it is useful to allow path testing even when the current
> path is working, and the protocol should support doing this 
> without disrupting ongoing communication (which does not seem
> to be possible in your proposal).
> 
Yes, this is a useful feature that MOBIKE should provide.

> (E.g., suppose we have two interfaces, one very fast and cheap, 
> second one very slow and expensive. If the first one has a temporary 
> problem, and we switch to the second one, we want to switch back 
> when possible even if the second interface keeps on working forever.)
> 
I am wondering when the switch will happen. If we assume that the switch
will not happen when the IPsec connection is actively used (e.g. streaming services),
then Tero's proposal would still be okay because temporarily changing to a
non-workable address will not affect much. But i don't understand why having
a separate PATH_TEST message is such a big deal. I don't see additional
complexity. So, what is the issue with having a separate PATH_TEST message ?
Jari said it is simpler. I am not sure i understood that.


-mohan

> Best regards,
> Pasi
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike