[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: API for SHIM
Hi Shinta,
El 11/04/2006, a las 10:15, Shinta Sugimoto escribió:
- The application should be able to tell the shim to
initiate a communication with a given peer and use
the shim for that.
There are several cases for this:
- The connect-by-name case, where the application
indicates that it wants to initiate a communication
with a FQDN and the resolver obtain different IP
addresses for that FQDN and tries to use them to
establish the communication. Not sure if the shim
needs to be involved for this
Yes. I recall there have been some discussions about this topic
on the list. connect_by_name() a substitute for legacy connect()
system call seems to be attractive for application which attempts
to reach its peer with multiple IP addresses. (My understanding
on connect_by_name() suggested by Erik in based on his emails and
hope that I understand it correctly) With regard to the question
if SHIM6 needs to be involved in this or not, I think there would
be some case where SHIM6 may have useful information that could
be taken into account for the peer locator selection to be done
by connect_by_name(). Assuming that REAP mechanism is in place
for verifying reachability of locator pair, that information could
be used to avoid unnecessary attempt of sending TCP SYNs.
Right, but it is also the case that the connect by name functionality
can be used without the shim and it is really useful in that case too.
I mean first of all, it is important to note that in order to make this
work we don't need the shim. This is so, because at the moment that
connect by name is performed , the ulid for that communication is being
determined, and it is possible to select one that is working since the
application has only specified the name of the target.
So, for this communication there is no real need to have a locator that
differ from the ulid used for the communication, it is just enough to
select the ulid/locator in a smart fashion, so that a working address
is selected. So no need to perform the shim translation between ulid
and locators in this case (Which is the main function of the shim)
IMHO this is very good because the connect by shim funtiobality can be
used even when the peer does no supports the shim and it would allow to
establish new communications in the case of a failure in the multihomed
site.
Of course, if we don't use the shim we will need to use other than shim
messages to figure out if the address pair is working. however,
considering that this is connect by name, probing with TCP syns seems
the natural options and i don't see any drawback, do you?
(note that it is not trivial to use REAP messages, since the probe
messages need to be associated to an established shim context, which is
not the case here, since we are trying to establish a context. Probably
I1 packet would be a better option)
- The connect to an ULID case. In this case the
application decides to establish a communication
with a given ULID and the shim may be required
if the ULID is unreachable/unroutable. The shim
will attempt to establish a context using the
ULID selected by the application and using
alternative locators. The question is how does
the shim retrieves the alternative locators?
The options for this may be to cache information
obtained by the DNS (i.e. when the query for a
FQDN returns multiple addresses, these are passed
to the shim as a hint about alternative locators)
The other option would be to use the reverse DNS,
as suggested in draft-nordmark-shim6-esd-00.
I see. In the first alternative solution you mention above,
I feel that we need to look into the relation between resolver,
connect() system call, and SHIM and how see if the interaction
could be done in architecturally clean way.
note that in this case, we need the shim, because as opposed to the
previous case, the ulid for the communication has been selected by the
ulp and cannot be changed
- In addition, the application may want to inform
about locators that are not working, or in
particular that the ULID is not reachable. This
may be useful in the case that the application
is triggering the shim context establishment
because of a failure in an ongoing communication.
Ok. Trigger may be needed for initial contact (the previous
issue) too.
right.
you mean that the application can inform that the initial contact has
failed and that it wants to establish a communication with the peer, so
that the shim6 context needs to be established, right? this would be
like the trigger for the previous point right?
- The application should be able to inform the shim
about the timeout values for detecting a failure,
for sending keepalives, for starting the exploration
procedure. In particular, the application should be
able to suppress the keepalives
Ok. TCP keepalive and reachability/failure detection to be
performed by REAP are semantically identical, which implies
that there could be a chance to better coordinate.
well, i was more thinking about data traffic and tcp acks, which allow
the app to tell that a communication is progressing properly...
- The application should be able to inform the shim
if hot stand-by is desired, so that alternative paths
are being probed when the current locator pair is
working.
Ok. This is also mentioned in the appendix of shim6-proto-04
document, I guess.
- The application should be able to tell how aggressive
the alternative path exploration procedure is desired
i.e. the number of alternative path that are probed
in parallel
This seems to be related issue to the one before (hot stand-by).
I assume that the case would apply for an application which is
more sensitive to the e2e delay, for example.
well, there seem to be somehow different issues, i guess
The previous point is about probing alternative locator pair while the
current locator is still working, in order to have an alternative path
that we know that is working
(Actually this information could be obtained if there are other
contexts with overlapping locator pairs, and that are using another
locator pair as current locator pair)
This point is about how many locator pairs a node tries in parallel,
after a failure.
both of them are related to how fast an alternative path is discovered,
only that the first option implies traffic even if no outage occurs.
- The application should be able to request not using
the shim for this communication
Yes.
- Forking related options. In particular, the
application should be able to request the creation
of a Forked Instance for a context, and should be
able to set the preferences for that forked instance,
the same as a regular context.
This is one of the main issues of API.
I understand that forked context can be specifically used by
each application (process). IMO, the question is how could
application have a reference to specific forked context.
Forked context could be identified by the FII, of course.
But it does not seem to be suitable/easy for application to use
it as a referral of locator. So far, I think it would make
sense to allow application to specify ULID as well as
preferred locator (if any) to send/receive packet to/from
given socket.
but this could identify more than one forked contexts, right?
i mean, there is nothing precluding that two forked contexts of the
same original context use the same locator pair... in this case,
locator pair and ulid pair does not identifies a single forked
context... not sure if this is problem though....
- The application should be able to inform that an outage
has occurred. Also it should be able to inform that the
performance of the current locator pair is not
satisfactory any more and that the shim should launch
exploration and an alternative locator pair that works
better (for some definition of better that may be
included in the request.
Right. This is another need for trigger.
- The application should be able to select a locator pair.
A particular case for this, is that application should
be able to tell the shim that it prefers using the ULID
pair as locator pair as long as they are working.
Ok. I suppose that this is mainly to avoid invoking unnecessary
re-homing event.
i see it as mean to avoid the payload header in data traffic once that
the original path is restored..
- The application should be capable of obtaining the
locator sets, local and remote, available for a shim
context. In addition, the application should be able to
obtain the preferences for that locators as well as other
information, such whether the locator is reachable or not.
I am not sure how much would the system-wide preference make sense.
(see below)
- The application should be able to set the preferences for
the locators, local and remote one and also to the
preferences of the local locators that will be passed to
the peer.
This makes more sense to me (than the one before) as each
application would probably have own preference for locators.
The SHIM6 context is per ULID pair, which means that context
can be allocated per application, but not necessarily per
application. It is basically system-wide. So in this sense,
there is slightly a gap between application's need and what
SHIM6 provides.
well, you have the forked context for that.
As i see it, there will be some system wide preferences that are
applied to all context by default. However, a given application can
override this preferences using the API especially for the forked
contexts... not sure if an application should be allowed to override
the preferences of a context that it has not forked, because in this
case we may end up with different apps trying t change the preferences
and having contradictory requests...
- Interaction between RFC3484 and the shim. In this case,
the information available in the shim could be used to
influence RFC3484 selection procedure, so that
unreachable locators are avoided.
I see. And I tend to think that application may also want to
distinguish locator with its type. In case of running SHIM6
over MIPv6, application may want to distinguish HoA and CoA
for achieving better performance (maybe by taking advantage of
SHIM6 based RO mode), for instance.
but this is already built in the rfc3484 right? i mean, rfc3484 already
preffers HoAs over Coas... besides, the basic SHIM over MIP scenario
does not assumes that CoAs are exposed to the shim, i guess
Others??
In addition, we would probably need a mechanism for providing
application ancillary data that are related to SHIM6 behavior.
For instance, application may want to know which locator was
*actually* used to receive/send given IP datagram.
you mean about packets sent in the past?
I am not sure that the shim needs to keep the historical data of
locators used for any reason.... why would you require that for?
regards, marcelo
Regards,
Shinta