Re: API for SHIM

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

El 12/04/2006, a las 18:01, Shinta Sugimoto escribió:

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


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.

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

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

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

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.

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

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

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

Regards, marcelo


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