Re: API for SHIM

[marcelo bagnulo braun <[e-mail]>]

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
>