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