Re: API for SHIM

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

Hi Marcelo,

please find my replies inline.

On Tue, 18 Apr 2006 13:33:34 +0300
marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:

> 
> El 12/04/2006, a las 18:01, Shinta Sugimoto escribis:
> 
> ...
> >> 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.
> >
> I am not sure if i am following you here, but i would think it this way:
> 
> suppose that the app performs a connect-by-name call to www.foo.com
> the resolver returns 3 addresses
> 
> Now, i guess the first interaction with the shim6 may be to find out if  
> there is an established context with one of these target addresses with  
> any of the local addresses available. If there is, it may be worthy to  
> preffer this address and initiate the communication using it, rather  
> than the other addresses for which there is no establihsed shim6  
> context. (this would be a first inter

Yes, this makes sense.

> 
> If none of them has an established context, then i guess we could have  
> two options:
> - one would be to use multiple TCP SYNs packets in parallel (this  
> option is nice because does not require shim support from the other  
> end)
> - the other one would be to  use the shim6 protocol to establish a  
> context and once the context is up, then initiate the communication.

Ok.

> >>
> >> 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.
> 
> were you thinking about something in the lines that i described above  
> or something else?

Yes, mostly similar to the one you described above (the first bullet about
simultaneous TCP SYNs).  In a case there is already established ULID-pair
context with the peer (and associated REAP status with locator pairs),
that can be taken into account for establishing the TCP connection.

> 
> >
> ....
> >>>> - 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 ?
> >
> 
> i am not sure.... perhaps a good way forward with this would be to  
> figure out how would an application that need this interact with the  
> shim in a reasonable way and then provide the interface to support such  
> interaction... but not sure...

Ok.

> ...
> >>>> - 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.
> >
> 
> but not as a ulid but as a locator right?

Right.

> from previous discussion with Erik, seemed that we may need a locator  
> selection algorithm that is shim6 specific, i.e. in order to select  
> locators withinh a context (as oposed to having to select initial  
> addresses which will be the ulids of the context and that are selected  
> by RFC3484 and possible extensions.)
> In the case of locator selection, i agree that we may need to change  
> the priorities.
> 
> The result is that a locator selection mechanisms different from  
> rfc3484 may be needed, because there are different priorities when  
> selecting locator pairs than when selecting ulid pairs.

Agree.
 
> I have wrote a proposal for this locator pair selection algorithm (but  
> i still haven't submitted it to the wg)
> 
> You can find it at:
> 
> http://www.it.uc3m.es/marcelo/draft-bagnulo-shim6-locator-pair- 
> selection-00.txt
> 
> in case anyone cares to comment...

Thanks, I will take a look at it.

> 
> >>>> 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)
> >
> 
> yes, this is the question, what would be the motivations for this  
> feature?

Hmm, I don't persuasive answer for the question at the moment...

> I mean i am all for doing a richer api but i guess we need at least one  
> use case per feature :-)

Yes.  Let me come back if I find any good usecase.


Regards,
Shinta