[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: API for SHIM


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