Re: Thoughts about layering multi-addressing

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

El 19/08/2005, a las 10:30, Pekka Nikander escribió:

> > In any of these approaches, the locator annotated for outgoing 
> > packets are a suggestion of they must be honored? i mean, i guess 
> > this is related with how does the shim informs the ULP that a given 
> > locator is no longer reachable, right?
>
> I don't know what would be the right approach.  Currently I think that 
> the best approach might be to signal the ULP that the shim layer was 
> unable to send the packet due to the suggested locator no more being 
> associated with the ULID.  At that point the ULP could ask the shim 
> for the new set of active locators, and pick a suitable one from 
> there.
>
> The alternative would be the shim layer to pick the locator, in the 
> same way as it would pick if there was none given by the ULP.  The 
> drawback of this approach is that the ULP has no information about the 
> locator having been overwritten...


I think that the distinction of the different types of addresses and 
address pairs defined in draft-ietf-shim6-failure-detection-00.txt 
would be very useful to understand this point.

According to this draft we have

- Available Addresses
- Locally Operational Addresses
- Operational Address Pairs (unidirectional and bidirectional)

Now the question is which type of addresses should the shim inform the 
ULP

I guess this very much depends on what the ULP will do with these 
addresses...

I mean, we can think the case of an app that performs referrals and 
that it wants to find out all the addresses (its own or the remote 
host) so that it can send them in a referral to a third party. In this 
case, since we don't know when the addresses will be used, i guess it 
make sense that the shim inform the ULP about the "available 
addresses". The "locally operational addresses" could be used. I guess 
that address pairs don't fit here.

Now, if the shim wants to inform the ULP about which source and 
destination addresses can be used for communicating, i guess that the 
shim should present the "locally operational addresses" sine not all 
the available addresses can be used for the communication.

Finally, if the shim wants to inform the ULP about a failure in the 
current addresses used, the information provided by the shim should 
involve the "operational address pair" since in the case that the shim 
detects a failure, the information available in the shim is that a 
given address pair is no longer working. I mean, in this situation it 
is more appropriate to consider a failed address pair rather than an 
address

So potentially the shim could inform the ULP about:
- available addresses (local and remote host)
- locally operational address
- changes in the available addresses
- changes in the locally operational addresses
- failure in an address pair (in particular in the currently used one)

> > > Hence, my question is if the transport are likely to need anything 
> > > else than the following:
> > >   - both ULIDs and locators in incoming packets
> > >   - ability to define locators for outgoing packets
> > >     - what happens if the locators are not available any
> > >       more?  Host-internal ICMP-like response?
> >
> > coming back to this point.. by locators you mean locator pair, right? 
> > i mean the shim should inform the ULP that a given locator pair is no 
> > longer reachable, right?
>
> As I indicated above, I am no that far yet in my thinking.  So, the 
> brief answer is that I don't know.
>
> > > Anything else?
> >
> > I wonder if it wouldn't be useful to allow the ULP to inform the shim 
> > about some sort of preferences w.r.t. which alternative locator pair 
> > to try with in case of an outage.
>
> Hmm.  Let's consider the complexity implications.  If the shim just 
> fails and signals the ULP about the failure, the ULP will have all the 
> necessary information about picking a locator to use.  It can easily 
> update its preferences dynamically based on multiple source of input, 
> e.g., based on flows on different locators.  That would keep the shim 
> simple, pushing the complexity to the transport.

in this case, all the path exploration (probing) would be managed by 
the ULP, right?

my concern here is that path exploration is proving to be quite 
complex, especially dealing with unidirectional paths, so probably the 
shim could provide a good support for this

i mean, i am not sure how the ulps would deal with unidirectional 
paths, path exploration and so on...

> On the other hand, if the shim has more information, such as 
> preferences per transport, that brings more complexity to the shim 
> layer.  Conversely, if we accept the architectural principle that I 
> suggested, we shouldn't pick this way, as in this case the shim knows 
> more than is absolutely necessary.
>
> I am currently tempted to try to keep the shim as simple as possible.

right, but as i understand it, the shim already has to deal with 
unidirectional path support, path exploration and failure detection. In 
addition, i guess that the shim will need to provide some form of 
support for expressing policy/preferences.
I guess that the additional complexity in this case, is that these 
preferences are per ULP rather than per ULID... but this brings us to a 
more general problem, which is: how do we handle the case where there 
are two ULPs communicating with a given shim context but they are 
asking to use different locators for the communication?

I mean suppose that two apps are using a single shim context and that 
the different ulps announce different locators for the communication 
(with the same ulids), would this be an issue?

>  Due to having transports that won't know about locators, we clearly 
> need to have some sort of preferred locator at the shim, and 
> associated fail over mechanisms.  However, to me it "smells" better if 
> we would not use them, at least by default, with more intelligent 
> transports that supposedly know better.

agree

> But there is one point here:  As we apparently need to have a 
> preferred locator at the shim, we should allow the transports to learn 
> about that, too.

i am not sure i can see why...

>   Apparently we also need some administrative interface for changing 
> the preferred locator dynamically....

the preferred locator per ULP you mean?


Regards, marcelo
> --Pekka