[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thoughts about layering multi-addressing
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
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
I guess this very much depends on what the ULP will do with these
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
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.
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.
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?