Re: API for SHIM

[Shinta Sugimoto <shinta@sfc.wide.ad.jp>]

Hi Marcelo and all,

Excuse me for responding lately to the original email, but let me provide
some comments/views on this topic.  I started paying closer look at
API stuff.

On Wed, 8 Mar 2006 16:16:10 +0200
marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:

> Hi,
> 
> I guess that one of the issues that are open for discussion is the API 
> for shim. In order to continue the discussion on this, I have tried to 
> identify the potentials options for an extended API for SHIM that have 
> been brought up in the list
> 
> Here it is an initial version of the list from the stuff that i recall 
> that have been discussed over the years here.
> 
> - 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.

>    - 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.

>    - 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.

> - 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.

> - 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.

> 
> - 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.

> - 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.

> - 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.

> - 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.

> 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.


Regards,
Shinta