Subject: [MULTIMOBSEC-API] feedback from shim-api-00.txt

From: Miika Komu <[email-masked]>
Date: Sat, 13 May 2006 00:08:01 +0300 (EEST)

Shinta, you may want to read sections 3.2.2, 3.2.3 and 4 from my thesis:

http://gaijin.iki.fi/hipl/hip-native-api-final.pdf

It has some relevance to the shim API. Then, some detailed comments on the 
shim api draft:

> Abstract
>
> This document specifies API for multihome shim layer.

C-language based sockets API

> Table of Contents
> 6.  Issues of Handling Multiple Locators with Legacy Socket API

Rename to "Issues of Handling Multiple Locators with shim unware apps"

I'd add a new chapter after this on "Shim aware apps". This section needs 
a lot of work.

> 3.  Terminology
> Identifier (ID) -

End-point identifier (EID)

> Context - A state information...  for to hosts...

s/for to/to/

Btw, on "HIP developer scene" we have been using the term "mapping" 
instead of "context". However, I am also fine with "context" if that is 
what you are using in shim6.

> List of Locators
> ..idetnfied..

s/idetnfied/identified/

In the end of terminology, I'd like to see the following terms:

* Connection latching
* REAP
* HIP
* ED = Endpoint Descriptor
    The representation of endpoints is hidden from the applications.  The
    ED is a "handle" or "pointer" to the actual EID.  A given ED serves as
    a AID [I-D.nordmark-multi6-noid].

Also, I'd like to see ULID and HIT explanations separate from 
Endpoint Identifier (EID). ULID explanation should start like "In the case 
of SHIM6, the EID is called..." and the same goes for HIT.

> 4.  System Overview
> Figure X

You should number the figure.

Anyway, the actual figure should probably have also transport layer 
between socket and IP layer. There should be arrows from socket<->shim and 
also socket<->transport. Please rename the interface layer e.g. to 
"physical layer" etc.

> 5.  Requirements
>
> 5.1 Requirements for shim unaware applications

* add text

> 5.2 Requirements for shim aware applications
>
> Following is a list of requirements from the application perspective.

*shim aware* application perspective

(which it really is)

>   o  Notification from application to shim layer about the outage.

I think it is safe to say here "event based" notification as that is the 
aim anyway. Also, it does not say here what "outage" is in question
(locator outage?)

>   o  Hot-standby.  Application may request shim layer if hot-standby
>      connection is needed.

s/if/that a/ ?

>   o  Providing locator information to application.  Application should
>      be able to obtain information about the locator which was actually
>      used to receive the packet.  With this information, application
>      can verify if its preference on choice of locator is actually
>      applied to its flow or not.

What about sending? Can the application select a specific locator?

>   o  Application should be able to specify if it wants to defer the
>      context setup or it wants context establishment to be started if
>      there is no available context.

I don't really understant this point. Isn't the context set up always 
automatically when the application connects? Or maybe I am missing some 
shim6 specific knowledge here.

> 6.1.  Initial Contact
>
> When application to establish communication with its peer who happens
> to have multiple locators, there are some issues to consider.

application *is going* to establish

> In connection oriented communication, connect() system call is used to 
> make the initial contact to the peer, which requires IP address and port 
> number to specify the endpoint.

which requires an IP address or HIT

> Application needs to resolve IP address of the peer from its FQDN by any 
> available name-to-address conversion method.

Application needs to resolve FQDN of the peer to an IP address by any 
available name-to-address conversion method.

> One option is to issue concurrent connect() with every locator of the 
> peer, which is done in some applications today.

I think for the legacy case it is not "concurrent" but rather 
"consecutive". At least in the most common case, but may be there are some 
advanced applications.

> Another option would be to request shim layer for taking care of initial 
contact.

There is nothing wrong with this sentence, but the paragraph is getting 
too long, so I'd insert a paragraph break after this sentence.

> And behavior of shim layer will depend on the presence of the required 
> context.

s/And//

> However, this approach does not help the case where ID is not in form of 
> IP address (e.g.  HIT in HIP case).

In HIP, a HIP enabled resolver can be used for setting up context prior to 
the actual connection to HIT. Alternatively, DHTs support look-up of 
non-hierarchical identifiers, such as HITs.

> 6.2.  Naming at Socket Layer
> ..
> getsockname() is used when an application wants to obtain the local IP 
> address and port number assigned for given socket instance.

*Traditionally*, getsockname() is used..

Related to section 6.2., I suggested earlier that getsockname() returns 
whatever addresses transport layer is using because it is the closest 
layer. However, at least when HIP is concerned, we have to make a 
trade-off between these two problems:

1. Backwards compatibility: HITs are not routable, and mapping them to
    locators might be difficult - possibly referral related troubles
2. Mobility and multihoming: returning HITs is better than returning
    possibly depracated, unusable addresses

I'd bet that the DHTs are getting more common in the future, and as a 
consequence, the first problem is not so relevant anymore. So, if I have 
to choose, I would return EIDs (HITs or ULIDs) to applications.

For shim aware applications, it does not really matter what those 
functions return. Shim aware applications are new applications that can 
use even a completely new API call to query about EIDs and locators.

Comments?

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

_______________________________________________
MULTIMOBSEC-API mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/multimobsec-api

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 14 May 2006 17:56:32 +0300

a clarification point...

> automatically when the application connects?

no
shim6 supports deferred context setup
this means that the application can start the communication just as a 
non shim6 communication and then the shim6 context establishment is 
triggered by some heuristics located in the peers, like packet count or 
time count

the point being made here is that the app should be able to influence 
the moment when the context is establihsed, up front, or how deffered 
is the context setup

regards, marcelo

---

From: Miika Komu <[email-masked]>
Date: Mon, 15 May 2006 13:02:54 +0300 (EEST)

On Sun, 14 May 2006, marcelo bagnulo braun wrote:

> this means that the application can start the communication just as a non 
> shim6 communication and then the shim6 context establishment is triggered by 
> some heuristics located in the peers, like packet count or time count
>
> the point being made here is that the app should be able to influence the 
> moment when the context is establihsed, up front, or how deffered is the 
> context setup

So, in a way the connection can be "upgraded" to use the shim? If I 
understood correctly, the "upgrade" word could be used also in the text.

---

From: Shinta Sugimoto <[email-masked]>
Date: Mon, 15 May 2006 15:18:18 +0300

Hi Miika,

Thank you for your comments.  Please find my responses/comments inline.

On Sat, 13 May 2006 00:08:01 +0300 (EEST)

> http://gaijin.iki.fi/hipl/hip-native-api-final.pdf

Ok.  I read the sections.  Certainly there are something that I should
learn from your past work.  I will also read other parts as well.  Thanks.

> C-language based sockets API

Mm, I am not sure if I want to be so specific at the beginning of
the document.  Wouldn't it be fine just to say "Socket API" ?

> I'd add a new chapter after this on "Shim aware apps". This section needs 

Ok.

> End-point identifier (EID)

Ok, fine with me.

> what you are using in shim6.

Ok. I hope 'context' fits well with HIP as well.

> s/idetnfied/identified/

Ok.

> In the end of terminology, I'd like to see the following terms:

Ok, but I assume that the definition should be inline with the one
from BTNS.  Let me check BTNS documents first, and will come back with
text defining the words.

> * HIP

Ok.

>     a AID [I-D.nordmark-multi6-noid].

Ok.

> of SHIM6, the EID is called..." and the same goes for HIT.

Ok.

> You should number the figure.

Yes.

> also socket<->transport. Please rename the interface layer e.g. to 

Ok. I came to think that this figure should be re-drawn.
As you pointed out, there should be arrows; one for socket<->shim
and one for socket<->transport so that reader can easily
understand what the API is for.

> aim anyway. Also, it does not say here what "outage" is in question

Ok, I will use 'event based'.  Does following sound better ?

<t>Notification from application to shim layer about outage.
Application should be able to inform shim layer about outage
in its communication.  Note that the notification is made
in event based manner.  The cause of outage could be for instance
a problem of network interface, congestions on the path and so on.
ICMP error messages delievered to the upper layer protocol is
normally clue for application to detect outgae.  REAP module
may be triggered by this indication to invoke procedure of
path exploration.</t>

> >   o  Hot-standby.  Application may request shim layer if hot-standby

Ok.

> What about sending? Can the application select a specific locator?

On email discussion with Marcelo, we identified that this is still
an open issue whether to allow application to select (specify) locator
pair.  Maybe we can have this item on "further discussions" part.

> shim6 specific knowledge here.

see Marcelo's comment.

> application *is going* to establish

Ok.

> available name-to-address conversion method.

Ok.

> "consecutive". At least in the most common case, but may be there are some 

Ok. I'll take your comment into account.

> too long, so I'd insert a paragraph break after this sentence.

That's right.  Will spit in paragraphs.

> > And behavior of shim layer will depend on the presence of the required 

Ok.

> non-hierarchical identifiers, such as HITs.

Yes.  But I think those (HIP enabled resolver and the DHT support) are
still in some HIP implementation or HIP experts' mind, aren't they ?
(I may be wrong, correct me if so)
So I was not sure if we could give conclusive statements about
these problems.

> *Traditionally*, getsockname() is used..

What do you imply with "*Traditionally*" ?  Could you elaborate more ?

>     possibly depracated, unusable addresses

True.

> to choose, I would return EIDs (HITs or ULIDs) to applications.

I see.
As for me, I am not sure if DHT based name resolution service could
be easily done.  In longer run, we may need to re-think naming service
(which might require us to replace DNS with something new) if we want
to have a network where the ID and locator are purely separated.

> use even a completely new API call to query about EIDs and locators.

Ok, agree.

Regards,
Shinta

---

From: Miika Komu <[email-masked]>
Date: Tue, 16 May 2006 00:01:10 +0300 (EEST)

> the document.  Wouldn't it be fine just to say "Socket API" ?

According to the literature, it is "sockets API" with an "s".

Maybe you can say in intro that the draft is illustrated using C language. 
It is not a bad choice because the API bindings for other languages are 
based on C anyway.

> may be triggered by this indication to invoke procedure of

s/outgae/outage/. Again, it is undefined what kind of outage is in 
question. Otherwise it is fine.

> pair.  Maybe we can have this item on "further discussions" part.

Fine.

>> shim6 specific knowledge here.

Please add my comments about "connection upgrade". I believe that it makes 
the idea more understandable for a person who I quite clueless on shim6 
details :)

> So I was not sure if we could give conclusive statements about

I don't understand. HIP enabled resolvers and DHT support are mostly 
supported by all of the three public implementations and they are also 
seriously considered both in the HIP WG and RG. What you can add is a 
deployment statement, that they are not widely used or deployed yet.

>>> 6.2.  Naming at Socket Layer .. getsockname() is used when an 
>>> application wants to obtain the local IP address and port number 
>>> assigned for given socket instance.
>>

We have now identifier / locator split which changes things. We don't 
have anymore just "addresses":

Consider my comment as an "readability enchancement".

> As for me, I am not sure if DHT based name resolution service could be 
> easily done.

It has been already done, but not really deployed in a large scale. And 
also it has not been standardized in the IETF, but neither has been e.g. 
skype :)

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 16 May 2006 09:16:04 +0300

El 16/05/2006, a las 0:01, Miika Komu escribió:

> Maybe you can say in intro that the draft is illustrated using C 
> language. It is not a bad choice because the API bindings for other 
> languages are based on C anyway.
>

i guess that it is any kind of outage that makes that an address pair 
is no longer working.
And an address pair is said to be working is packet containing the 
first address from the pair as source address and the second address 
from the pair as destiantion address can safely travel from the source 
to the destiantion.

> supported by all of the three public implementations

interesting.... which implementations are those?

>  and they are also seriously considered both in the HIP WG and RG. 
> What you can add is a deployment statement, that they are not widely 
> used or deployed yet.
>

>> be easily done.
> It has been already done, but not really deployed in a large scale. 
> And also it has not been standardized in the IETF, but neither has 
> been e.g. skype :)
>

i am not really following what comments you think there should be 
included about DHT?... could you send text so we can understand more 
precisely what you mean?

Regards, marcelo

---

From: Shinta Sugimoto <[email-masked]>
Date: Tue, 16 May 2006 15:25:48 +0300

Hi Miika,

Please find my comments inline.

On Tue, 16 May 2006 00:01:10 +0300 (EEST)

Ok.

Ok.

Ok.

I will add definition of "outage" (and probably "working address pair"
too) in the terminology section.

Yes.

> deployment statement, that they are not widely used or deployed yet.

Ok.  Thanks for the information.

> have anymore just "addresses":

Ok, I see what you mean.

Yes.

Ok.

> also it has not been standardized in the IETF, but neither has been e.g. 

Scalability and security would be the key issues in building system of
mapping HIT and locators, I think.  Anyway, we won't be providing details
of how the solution (for HIT-to-locator resolusion) look like.

Regards
Shinta

---

From: Miika Komu <[email-masked]>
Date: Tue, 16 May 2006 14:14:39 +0300 (EEST)

On Tue, 16 May 2006, marcelo bagnulo braun wrote:

> i guess that it is any kind of outage that makes that an address pair is 
> no longer working. And an address pair is said to be working is packet 
> containing the first address from the pair as source address and the 
> second address from the pair as destiantion address can safely travel 
> from the source to the destiantion.

Something like this should be also in the text.

(Maybe I am getting too detailed already now in the beginning)

> interesting.... which implementations are those?

http://infrahip.hiit.fi/
http://www.hip4inter.net/
http://www.openhip.org/

(I am not sure about the DHT support for Ericsson, you can ask Kristian 
for details)

> i am not really following what comments you think there should be included 
> about DHT?... could you send text so we can understand more precisely what 
> you mean?

I believe I misunderstood the context term. In HIP and BTNS, the context 
really is a pair of IPsec SPs and the associated SAs, not a "mapping" like 
I described earlier. The mapping I was referring to means a HIT-to-IP 
mapping for the host.

So, in section "6.1.  Initial Contact", please remove the last sentence 
about HIP to avoid confusing things. Let's add a separate, new paragraph 
after that:

---text begins

In HIP, resolving HITs to IP addresses using DNS is not feasible because 
HITs do not contain any hierarchical information. To migitate this 
problem, there are few alternatives. First, resolver library on end-host 
can modified to communication HIT-to-IP mappings with HIP software module. 
Second, a distibuted hash table (DHT) service can be used for storing and 
looking up the the mappings because it supports non-hierarchical 
identifiers, such as HITs [*]. Third, it is possible to use IP addresses 
in legacy applications as described in [**].

[*] http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-03.txt
[**] http://www.ietf.org/internet-drafts/draft-henderson-hip-applications-02.txt

---text ends

We should not really argue in the draft what approach is good and what is 
bad, at least when it comes to HITs and DHT. Let's just list the 
alternatives and give references, otherwise the discussion is just getting 
into a sidetrack.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 16 May 2006 15:34:54 +0300

El 16/05/2006, a las 14:14, Miika Komu escribió:

>> is no longer working. And an address pair is said to be working is  
>> packet containing the first address from the pair as source address  
>> and the second address from the pair as destiantion address can  
>> safely travel from the source to the destiantion.
>

ok

> (I am not sure about the DHT support for Ericsson, you can ask  
> Kristian for details)
>
> I believe I misunderstood the context term. In HIP and BTNS, the  
> context really is a pair of IPsec SPs and the associated SAs, not a  
> "mapping" like I described earlier. The mapping I was referring to  
> means a HIT-to-IP mapping for the host.
>
> So, in section "6.1.  Initial Contact", please remove the last  
> sentence about HIP to avoid confusing things. Let's add a separate,  
> new paragraph after that:
>
> ---text begins
>
> In HIP, resolving HITs to IP addresses using DNS is not feasible  
> because HITs do not contain any hierarchical information. To migitate  
> this problem, there are few alternatives. First, resolver library on  
> end-host can modified to communication HIT-to-IP mappings with HIP  
> software module. Second, a distibuted hash table (DHT) service can be  
> used for storing and looking up the the mappings because it supports  
> non-hierarchical identifiers, such as HITs [*]. Third, it is possible  
> to use IP addresses in legacy applications as described in [**].
>
> [**]  
> http://www.ietf.org/internet-drafts/draft-henderson-hip-applications 
> -02.txt
>
> ---text ends
>
> We should not really argue in the draft what approach is good and what  
> is bad, at least when it comes to HITs and DHT. Let's just list the  
> alternatives and give references, otherwise the discussion is just  
> getting into a sidetrack.
>

agree

regards, marcelo