[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


El 31/10/2005, a las 12:31, Paul Jakma escribió:




First, you cannot assume that all hosts support the shim


OK.
this, by itself would be enough to provide multihomed hosts some mechanism to be able to establish new communications after an outage in one of their ISPs i.e. rfc3484 bis, agree?
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..
but in this would the app the one that triggers the shim? or would be the shim that detects when there is a problem?... 
i don't see how this works...
I am not sure if you are considering the case where the app selects the source address (uses bind()) or not... i asume that the source address is not set by the app.
So, the app tries to establish a communication. suppose that there is a failure in one of the isps. the app tries to establish a communication without specifying a source address, and rfc3484 selects the address associated to the isp that is down. Now, the packet with that src address never make it, so who detects that there is a problem? The shim? how is this done? i mean, the shim cannot know if there is an reply packet expected, since it is not aware of the app protocol. The other option would the app, to notify the shim that something is wrong and to try fix it... This would require a modification to the app and would only make sense of the other end supports the shim. As i understand it, this is what we called "shim API on steroids" which would allow an app to tell the shim "i want to connect to hostX, you find a working pair for me" This is good, but it does not work with legacy hosts (that don't support the shim), it imposes a shim negotiation upfront. I like your point that this could be done only when the initial contact fails though (but i am not sure how to detect this failure) 

So, as i see it:
- the API on steroids is a good feature that we want to have
- we need a rfc3484bis at least to support communications with non shim hosts and maybe it would be good to deal with the problem for communications between shim hosts, depending on the result 


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. 



please check draft-ietf-shim6-proto-02
there you will find that the shim6 protocol rqeuires a 4 way exchange to establish the shim context, that needs to be done before the shim translation between locators and ulids can be done
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? 



right. 3 comments:
- this is only for initial contact (so no problem with breaking tcp connection because using a different address, since the communication is being established at this very moment) - this assumes bidirectional working address pairs, (i.e. a single address pair is used in both directions of the communication) - it does not require special support from the peer (it works with non-shim nodes)
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.
shim6 is focused in preserving established communications through outages. in shim6 protocol the main problem is that the address pair that is currently being used for exchanging packets is no longer working, so we need to use a different address pair to route packets, but in order to preserve established connections (TCP for isntance) the address pair presented to the upper layers must remain unchanged. that is why we need this mapping performed by the shim and this is why we need support from both of the peers for this shim
In this other case, we are dealing with a different problem: how to cope with failures during the initial contact? In this case, the failure has occurred before the communication has started. Then what we need is to find a working address pair. This address pair is not fixed, because there is no established connection (yet). So, this problem can be solved without requiring support from both peers i.e. a multihomed host implementing this can successfully communicate with a regular ipv6 hosts that does not implement any specific mechanism 

So, this is a different problem with a different set of restrictions:
- address pair can change
- peer does not support any new mechanism

(as oposed to the shim6 protocol problem where:
- the address pair used by the upper layers is fixed
- the peer needs ti support the shim)


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? 



not exactly...
this only deals with problems during communication establishment phase, as opposed to the shim that deals with problems once established.
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. 

right.
however, it seems that there are apps that select the source address they want to use using bind(). For this it makes sense to provide some guidance of how this needs to be done I am not saying that this is the only mechanism that we need to deal with this, but what i am saying is that IF apps are going to select the source address, we need to provide guidance so that they do it properly taking into account that different source addresses need to be tried in case of a failure
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).
well, rfc3484 state for instance that the app should iterate through all the list of available destination addresses until one that is working is found. This is why it seems that rfc3484bis should be the place to state that in the case that multiple source addresses are available, the app that decides to set the source address using bind() should iterate through all available source addresses until it finds one that is working
- 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. 



I am not sure if i am following you...
for the tcp case, this can done in a fashion that it is transparent to the app 
for the udp case, i am not sure how we can do this...

do you have any idea you could share?
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". 



i hope that with the above comment this is clearer
summarizing:
- we need something that does not involves the shim protocol to support communications with non shim hosts - we could use this also for communications with shim enabled hosts (depending how good is the outcome) - we need also a API on steroids for the shim to benefit from the special case where both peers supports the shim and improved performance can be achieved
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). 



weel this is just another way to put it, right?
whether you call it shim without the shim protocol or rfc3484 bis, they would be local mechanisms for identifying non working source addresses and selecting those that are working, right? 


regards, marcelo