Re: API for SHIM

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

Hi Marcelo,

Thanks for your comments, please find my response inline.

On Tue, 11 Apr 2006 15:01:01 +0300
marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:

> Hi Shinta,
> 
> El 11/04/2006, a las 10:15, Shinta Sugimoto escribis:
> >>
> >> - 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)

Yes, I understand your statement above.  connect_by_name() is a kind of
wrapper to connect() system call in a sense that it only requires app
to provide hostname rather than the IP address.  Then the library would
take care of name resolution and session establishment for each
resolved address.  As you pointed out, SHIM6 is not required to make
this work.  What I want to point out is that connect_by_name() might
be able to coordinate with SHIM6 REAP mechanism.

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

Agree.

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

No.  I am not saying that probing by TCP SYNs should be replaced by
SHIM6 probe message.  I am saying that unnecessary attempt of sending
TCP SYNs to the un-working locator pairs *can* be avoided if the
SHIM6 REAP state indicates that the locator pair is supposedly
unreachable.

> (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)

You are right that SHIM6 probe message is associated with a context.

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

Right.  SHIM6 context establishment should be kicked if the
selected ULID of the peer is not reachable/routable as you
mentioned above.

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

Yes.

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

I see.  Different aspect.

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

Ok.

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

Ok, understood.

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

Yes, but what can SHIM6 API provide application then ?
Do you think that app should specify FII via socket API ?

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

Ok, application should refer to specific forked context (how it can/should
be is still open issue though) which also contains preference information
of the locator.

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

Yes, RFC3484 mentions about HoA and CoA.  It recommends to have higher
preference on HoA over CoA.  In plain Mobile IPv6 environment,
behavior following the recommendation would probably fulfill users
desire.  But in some advanced scenarios, app may prefer CoA for
better performance (SHIM6 based RO).  RFC3484 does not help to do this.

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

No.  I am talking about the ancillary data which (extended)
Socket API may provide from SHIM6 perspective.  What I have in mind
is that application may want to know src/dst locators
which were actually used to deliver the packet to the host.
Well, it may sound contradictory to the basic concept of SHIM6
which is to make locator information transparent to the ULP.
But some application may still want to know (for some reason)
what is the decision made by the underlying SHIM6 layer in
locator selection.  In the past discussions on SHIM6 & TE, it
was suggested to allow locator rewriting at the site exit router.
So, in SHIM6 a host may receive an IP packet on the locator
which is not the preferred one.  But I don't have the answer for
a question why would the application need such info ...

My statement above only considers inbound packet processing.

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

see above.


Regards,
Shinta