Re: API for SHIM
Shinta Sugimoto <shinta@sfc.wide.ad.jp> Tue, 18 April 2006 12:38 UTC
Envelope-to: shim6-data@psg.com
Delivery-date: Tue, 18 Apr 2006 12:39:10 +0000
Date: Tue, 18 Apr 2006 15:38:02 +0300
From: Shinta Sugimoto <shinta@sfc.wide.ad.jp>
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
Subject: Re: API for SHIM
Cc: shim6-wg <shim6@psg.com>
Message-Id: <20060418140153.C250.SHINTA@sfc.wide.ad.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
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
- Re: API for SHIM marcelo bagnulo braun
- Re: API for SHIM Wesley Eddy
- API for SHIM marcelo bagnulo braun
- Re: API for SHIM Shinta Sugimoto
- Re: API for SHIM Brian E Carpenter
- Re: API for SHIM Shinta Sugimoto
- Re: API for SHIM marcelo bagnulo braun
- Re: API for SHIM marcelo bagnulo braun
- Re: API for SHIM Shinta Sugimoto