Subject: [shim6] SHIM API and unconnected sockets

From: Miika Komu <[email-masked]>
Date: Sun, 13 Dec 2009 15:21:41 +0200

Hi,

the applicability of unconnected sockets says:

    6.4. Notification from Multihoming Shim Sub-layer to Application

    ..

    There is no restriction in terms of applicability of the notification
    about locator change.  The notification can be delivered to sockets
    regardless of if it is connected or unconnected, stream-oriented or
    datagram-oriented.

However, the shim6 locator API has to have a field for the ULID or 
otherwise an unconnected application cannot distinguish the context:

    7.1. Placeholder for Locator Information

    ...
        struct shim_locator {
                 uint8_t    lc_family;       /* address family */
                 uint8_t    lc_proto;        /* protocol */
                 uint16_t   lc_port;         /* port number */
                 uint16_t   lc_flags;        /* flags */
                 uint16_t   lc_pref;         /* preference value */
                 uint32_t   lc_ifidx;        /* interface index */
                 struct in6_addr lc_addr;    /* address */
         };

So, I think we need a struct in6_addr lc_ulid here and explain it in the 
text.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 28 Dec 2009 22:50:16 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Miika Komu
> Sent: Sunday, December 13, 2009 5:22 AM
> To: [email-masked]
> Cc: Kristian Slavov
> Subject: [shim6] SHIM API and unconnected sockets
>
> Hi,
>

In section 6, under Figure 3, it says:
   In case of non-connected socket, msg_name member stores the socket
   address of the peer which should be considered as an identifier
   rather than a locator.  The locator of the peer node should be
   retrieved by SHIM_LOC_PEER_RECV as specified below.

So, is the additional lc_ulid needed in this case?  Is it storing the socket address of the local host?

It is a bit unclear to me the relationship between an unconnected socket and an underlying shim association (with context)-- perhaps some explanatory text would be helpful to add that describes how the transport-layer connection is related to the shim context, and what it means when one is present but the other is not.

Tom

---

From: Miika Komu <[email-masked]>
Date: Tue, 29 Dec 2009 13:51:28 +0100

Henderson, Thomas R wrote:

Hi,

>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Miika Komu Sent:
>> Sunday, December 13, 2009 5:22 AM To: [email-masked] Cc: Kristian
>> Slavov Subject: [shim6] SHIM API and unconnected sockets
>> 
>> Hi,
>> 
>> There is no restriction in terms of applicability of the 
>> notification about locator change.  The notification can be
>> delivered to sockets regardless of if it is connected or
>> unconnected, stream-oriented or datagram-oriented.
>> 
>> ... struct shim_locator { uint8_t    lc_family;       /* address
>> family */ uint8_t    lc_proto;        /* protocol */ uint16_t
>> lc_port;         /* port number */ uint16_t   lc_flags;        /*
>> flags */ uint16_t   lc_pref;         /* preference value */ 
>> uint32_t   lc_ifidx;        /* interface index */ struct in6_addr
>> lc_addr;    /* address */ };
>> 
>> So, I think we need a struct in6_addr lc_ulid here and explain it
>> in the text.
> 
> 
> In section 6, under Figure 3, it says: In case of non-connected
> socket, msg_name member stores the socket address of the peer which
> should be considered as an identifier rather than a locator.  The
> locator of the peer node should be retrieved by SHIM_LOC_PEER_RECV as
> specified below.
> 

This information is not available in socket options.

> It is a bit unclear to me the relationship between an unconnected
> socket and an underlying shim association (with context)-- perhaps
> some explanatory text would be helpful to add that describes how the
> transport-layer connection is related to the shim context, and what
> it means when one is present but the other is not.

A connected socket is always related zero or one context. An unconnected 
socket is related zero, one or many contexts.

---

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 30 Dec 2009 23:20:52 +0900

Henderson, Thomas R wrote:
>> notification

I see your concern.  The relationship between an unconnected socket and 
shim context(s) is tricky and should be explained in the document, I 
think.  There was a discussion among authors whether to cover 
unconnected sockets or not for notification from the shim sub-layer to 
the application (the feature addressed in Section 6.4), and the outcome 
of the discussion was that we may cover unconnected socket as well 
provided that the shim sub-layer employs a kind of caching mechanism to 
store source and destination EID pair of the IP packet sent over the 
unconnected socket.  The cached information allows the shim sub-layer to 
  identify the target (unconnected) socket when there is an event 
(locator  change) occurs within a shim context.

As Miika pointed out, we need to include the EID in the shim_locator{} 
structure in order to implement the notification mechanism *if* we aim 
at supporting unconnected socket.

All in all, I think we should simply exclude the support for unconnected 
sockets for the notification feature.  The reason is that there are too 
many system requirements posed by this, and I think it makes the system 
too complex.  The caching mechanism required by the support of 
unconnected sockets seems overkill, and the additional member (lc_ulid) 
for the shim_locator{} structure required by the support of unconnected 
sockets seems redundant to me as the data structure is meant to store 
information about a single locator.  I do not think it's worthwhile 
fulfilling these system requirements for the support of unnconnected 
sockets.  So, I'd suggest to specify that the notification from the shim 
sub-layer to the application is supported only for connected sockets.

Miika (and maybe others), would you please hear your opinion on this?

Regards,
Shinta

---

From: Miika Komu <[email-masked]>
Date: Wed, 30 Dec 2009 23:29:45 +0100

Miika Komu wrote:

Hi,

>>> about locator change.  The notification can be

actually, I'm starting to wonder if I started this thread for nothing. I 
think the lc_ulid field is not needed because section 6.4 applies only 
to recvmg(). Right, Shinta?

---

From: Miika Komu <[email-masked]>
Date: Wed, 30 Dec 2009 23:35:50 +0100

Shinta Sugimoto wrote:

Hi,

>> transport-layer connection is related to the shim context, and what it 
>> means when one is present but the other is not.
> 

I think the new field is not needed after all, please check the previous 
email.

> Miika (and maybe others), would you please hear your opinion on this?

I think we want to support unconnected sockets because the whole 
notification feature requires recvmsg() which implies UDP based sockets. 
This means that we're ruling out the majority of the audience which are 
unconnected apps.