Re: issue 11 -- window size

Jari Arkko <[email protected]>
Newsgroups gmane.ietf.mobike
Message-ID <[email protected]>
Hi Pasi,

>- Current path (A1,B1) stops working, and the peers switch 
>  to (A2,B2). A is behind a NAT in both cases.
>
>- After a while (A2,B2) still works (and continues working), but
>  the peers really prefer (A1,B1) because it's faster/cheaper/
>  whatever. So, A sends the last request using addresses (A1,B1) 
>  to see if it has become operational again.
>
>- Suppose that direction A1->B1 works, but B1->A1 does not
>  (e.g. because of a malfunctioning middlebox or something; the
>  cause does not really matter). B receives the packet, and if
>  it hasn't seen it yet, processes it, sends reply, and (if it
>  implements the NAT-T "SHOULD" from IKEv2) moves all traffic to 
>  path (A1,B1). Which does not work.
>  
>
OK, I see the problem now. It looks like there are
sevaral subtasks in what we are trying to do:

  (i) test
 (ii) commit to particular set of addresses
(iii) manage unidirectional connectivity (#19)

Tero's model, as I understand it, appears to combine
both (i) and (ii) as well as disallow unidirectional
connectivity. In a sense his model is less flexible, but
at the same time simpler. A good tradeoff? Lets think
about it.

Anyway, presumably you could modify Tero's proposal
to separate (i) and (ii). The drawback in that is that
if there's a change in connectivity between initiating
(ii) and completing it, you have no possibility to send a
test message -- only a commit message. This is because
the model requires sequenced delivery of all messages.

But what exactly is the problem that results from this?
Presumably you wanted to commit to a particular
set of addresses. So the only reason why you might
want to start testing is that you don't get a response.
If you have just one alternative left, then there's no
issue -- switch to it, with commit, if you can. But if there
are multiple alternatives, then you might wish to test
which one to choose. Question: could you do this by
ordering the retransmissions of the commit message
in a proper way? (Or am I now in the area of trying to
fix the special cases that you Pasi were worried about?)

--Jari
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.