[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 13:02, Iljitsch van Beijnum escribió:


On 31-okt-2005, at 11:54, marcelo bagnulo braun wrote:
Is there any good reason why this retry/source-select state can not be kept inside the shim6 layer? The remit of shim6 is after all to handle this stuff transparently. 


Because:
First, you cannot assume that all hosts support the shim
Well, if we can provide unmodified applications on shim-capable hosts with this functionality that would be very good. There are several advantages to using the shim here, including better opportunities for security and traffic engineering,
agree, but this is a different problem imho and different mechanisms can do this.
I mean, because of deployment times and motivations we cannot assume a universal deployment of the shim anytime soon. So, taking this into account, it would be good if we could provide the mechanisms so that a multihomed host that implements them can establish a new communication with a non shim enabled host. The rationale for this is that non-multihomed host has little motivation to implement mechanisms that provide better multihoming support, while, multihomed hosts do have a motivation for adopting mechanisms that allows them to improve their communications. Having a rfc3484bis that allows to establish new communications after an outage that only requires modifications to multihomed hosts make sense from a deployment p.o.v
OTOH, i think that it also makes a lot of sense to have the capability that you are suggesting, that would allow an unmodified application running in a shim capable hosts to establish a communication after an outage. But i see these as two different mechanisms that work under different scenarios, and i think it make sense to work on both of them. (probably we also want to work on the case of a shim aware app running in a shim host too)
although it would of course be nice if we could have the same functionality when one host doesn't support the shim.
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
We don't have to change our current thinking for sessions where the initially chosen ULIDs are reachable: only when those turn out unreachable, we need to do additional work. 



right, this is similar to Paul's comment and i agree
The main problems here are detecting that the initial ULID/locator pair doesn't work
well, if you are using a shim signaling packet exchenge, this probably can be done using the shim context establishment exchenge, depends on whether you want to achieve...
before we have any shim state we can use, and finding additional locators. HBA should allow us to make certain that these locators belong to the initially chosen ULID. However, it's possible that people publish AAAA records for different hosts that provide the same service so the HBA check would presumably not work then. So either we need something independent of AAAA records, or limit ourselves to the case where the AAAA addresses are part of the same HBA set.
Still, I'm not too worried about this, finding locators can be improved later.
BTW, being able to do the shim before communication starts also provides a good path towards something we'll want in the future: disjunct ULID/locator sets. Having a mechanism in place that allows using non-IPv6 ULIDs in the future would also help here.
right. as i said, i think that allowing shim to deal with failures at initial contact and rfc3484bis complement each other, since they are aimed to different scenarios 


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?


Obviously not repair the failure using the shim...
So either use the "second shim" approach or hope that the application does the right thing.
If you don't let X use the shim, then how does it selects the source address? 
If you use current rfc 3484 you are stuck in a single source address,
In my experience hosts try different source addresses in round robin fashion. I don't know if this is in accordance with RFC 3484 or not, 

i have read rfc3484 repeatedly lately and no mention  to this ....
maybe there is a longest match rule in there somewhere. But if so, that's a mistake as this example shows: it would make the host consistently choose a non-working address.
(Note that even with round robin things may not work because the application won't try often enough to arrive at a working address pair. However, when the user makes the application retry eventually it should work.) 



agree
- 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,
You are assuming that an application that does an explicit bind() for outgoing sessions also retries. 

well, not exactly.
i am saying that if the app does a bind() the stack below should honnour this decision and there is not much left to do, but just suggest to the app that it should retry with different source addresses...
I don't think this is generally the case. For instance, the BIND named allows the user to set the source address which is useful because then other nameds know from which addresses they can expect sessions.
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)
Yes, this is useful, but don't expect that application writers will all start doing this. 



agree
the point is that apps should know that if they decide to go through the path of selecting the source address, they need to deal with these issues.
- 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)


Seems reasonable.

But again, I don't think this is a full scale solution to the problem.




agree
this is just what i think it is the best we can do with the constraints imposed to the problem
probably, in order to provide a better support, we can came up with improved mechanisms for the case where both peers support the shim 

thanks for the feedback, marcelo