[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC3484bis (was Re: Design decisions made at the interim SHIM6 WG meeting

On Mon, 31 Oct 2005, marcelo bagnulo braun wrote:


El 31/10/2005, a las 2:28, Paul Jakma escribi�> thanks


Sorry ;).


Because:



First, you cannot assume that all hosts support the shim


OK.
Second, even if they do, such approach would imply that the shim negotiation is made upfront i.e. that the shim session is established before the communication starts, which is completelly opposed to current deferred context approach that is being followed throughout the shim6 design
OK. I'm not sure why that's implied though. The shim could start off with a NULL mapping (whatever the default source is, as decided by plain old SAS, probably routing policy). Given shim is to be able to interject later on if required.. Also, if the application hasn't bound to any specific address, then the shim can very easily put in whatever address it wants to..
I.e. If the default source doesn't work, shim6 kicks in and /then/ *shim* can do source-address probing.
Handy side-effect of only introducing these complications when there's actually a problem, hence the 99% of connections which get setup when things are working normally don't have to be encumbered with source-probing by all applications.. 


So, we need to deal with the following situation:



            /-- ( A ) ---(      )
  X (site X)             ( IPv6 ) ---(C)---(site Y)Y
            \-- ( B ) ---(      )
Where, host X supports multihoming features, something like an rfc3484 bis and event the shim if you want, but host Y does NOT support the shim. Suppose now that ISPA fails, what do you do?
If you base your solution in the shim, then if hostX can not communicate with host Y using the shim.
If you don't let X use the shim, then how does it selects the source address?
I must have missed a lot of developments in the direction shim in the last month or two. I don't understand at all now. I had thought the intention was that shim could 'kick in', e.g. by opportunistically sending the first packet on without any shim6 setup (or minimal setup), was the impression I had from some other discussions.
You seem to be exploring a way to get some of the benefits of shim without ever having a shim involved at all, is that right?
If you use current rfc 3484 you are stuck in a single source address, so in case host X selects ISPA address as source address, he won't be able to communicate. How do you solve this problem?
I'm confused now. I thought the whole point was for shim6 to solve that problem. 


What i can think of is:
- For those apps that want to select the source address (i.e. they use bind()) you let them take care of the problem, since it seems they know what they are doing, since they are in fact already taking an explicit decision to set the source address. In this case, the app is the one performing the retrial, so the modification needed for rfc3484bis is just to guide the apps on how to retry. This basically means two thing: 1. rfc3484bis should state that apps need to retry using different source addresses when they are available. 2. the available source addresses associated to a destiantion address can be provided by rfc3484bis to the app in the form of an ordered list, so that the app has some guidance of which addresses to try first (similar to what is done with destination address by current rfc3484)
IOW, achieve the goals of shim but in the applications rather than in a shim IP<->output layer in the IP implementation?
I'd agree that's the most sensible way to implement this, in a perfect world. But of course has pretty big deployment barrier, the entire reason for this WG in the first place. It could be done with some standardised APIs (which are not the remit of the IETF to specify, but some nice API work has been documented in informational RFCs). 

Or have I completely missed the point? (again ;) ).
- For those apps that do not select the source address, there are two options: 


 - In the case of TCP, we can allow the rfc3484bis to tell the socket to
   retry when a connect() is made. This means that the 3-way handshake
   is retried with different source addresses until it is completed



 - In the UDP case, the situation is more difficult, because we don't
   have signaling packets to try with. In this case, i would suggest
   that rfc3484bis only keep some track of which source addresses
   seems not to be working with a given destiantion address, so that
   if the app retries, a different source address is tried( and we
   are not stuck with the same source address, as it is the current
   situation)
This is what i can think as possible solutions to this problem. It implies modifications to the apps in the case that is the app the one in charge of retrial,
I would suggest doing it in the application (preferably in a nice widely available library) would be best.
but this seems to be in line with the fact that it is the app the one that is selecting the source address i.e. the app is involved to a certain degree in this selection. 

Right, and it has the best view of its state.


Now do this still make no sense to you?


It makes sense.
I'm wondering about the motivation though, i.e. wrt the shim6 IP-intermediary-layer approach, which I /thought/ was what ye were going with. ;) I'm confused on that point. The point that started this sub-thread was Geoff's summary of the design decisions, where this SAS by way of RFC3484 is to be the way for initial location: 

"1.  The specification for initial contact will use RFC3484, as modified by
     this draft in terms of source address ordering."
I still don't get why, if the intention is for this to be used /with/ shim6, this responsibility has to be punted to either the application or to some algorithm which currently is stateless.
Ie, why not let the modifications to SAS be specified as part of Shim6, in a context of "acting on behalf of the application" rather than "affecting the protocol".
Shim can simply act as the "agent" and implement the required SAS. It needn't imply anything else of Shim, particularly the protocol side. (ie, whether it must set things up in advance).
If so, could you suggest approaches to deal with the problem and the imposed constraints?
I'm afraid not, just suggesting that keeping the problem confined within shim6 (and any cousins, MIP, whatever) will be /less/ of a problem than the proposal of complicating SAS a lot for /all/ cases. 

regards,
--
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
It's been a business doing pleasure with you.