Re: [shim6] WG Last Call for draft-ietf-shim6-multihome-shim-api

[Shinta Sugimoto <[e-mail]>]

Hi Michael,

Thank you very much for reviewing the draft. This is very helpful. Please find my responses inline:

(Just FYI, Michael is working on API for multi-path TCP: http://www.ietf.org/id/draft-scharf-mptcp-api-00.txt which high relevance to our work. So, I asked Michael to review our ID)

> -----Original Message-----
> From: SCHARF, Michael [mailto:[e-mail]] 
> Sent: Friday, December 18, 2009 9:20 PM
> To: [e-mail]
> Cc: Shinta Sugimoto
> Subject: RE: [shim6] WG Last Call for 
> draft-ietf-shim6-multihome-shim-api
> 
> Dear all,
> 
> I had a look at draft-ietf-shim6-multihome-shim-api-11. 
> Unfortunately, I have not followed the discussion before, and 
> I am not an expert in SHIM6 and HIP. But I hope that my 
> comments are still useful.
> 
> 
> Summary:
> --------
> 
> In general, I think that the document is already in a good 
> shape, but some small modifications and clarifications are 
> needed, as explained below.
> 
> 
> Comments:
> ---------
> 
> > 1.  Introduction
> >
> >  HIP and SHIM6 have a commonality in their protocol design in the  
> > sense that the semantic roles of an IP address, i.e., an 
> identifier  
> > and a locator, are distinguished.
> 
> It could maybe help to better understand the API if there 
> there was an overview paragraph that explains which parts of 
> the API can indeed be applied to HIP or SHIM6, respectively. 
> While the slight differences are addressed various times in 
> the API specification, an additional overall statement would 
> make sense, e. g., in Section 5.

Basically, all the socket API extensions defined in this document are applicable to both HIP and SHIM6 as we set the scope of this document is to define socket API extensions that are *commonly* needed for both HIP and SHIM6.  This means that anything specific HIP or SHIM6 must be outside the scope of this draft.  Let us set the scope clearly in Section 1.

> Also, the system model in Figure 2 seems to apply more to HIP 
> than to SHIM6.

Why do you think so?  In my understanding, the system model depicted in Figure 2 can be applied to both HIP and SHIM6.

> >   The distinction between "connected" sockets and "unconnected"
> sockets
> >   is important when discussing the applicability of the socket API
> >   defined in this document.  A connected socket is bound to a given
> >   peer, whereas an unconnected socket is not bound to any specific
> >   peers.  That is, the destination of the user data is not 
> known until
> >   the application writes data to an unconnected socket.  TCP sockets
> >   are connected, by definition.  UDP sockets are unconnected, unless
> >   the application uses the connect() system call.
> 
> I would classify a TCP socket as "unconnected" before the TCP 
> connection is established, i. e., before the 
> connect()/accept() system call. Some of the socket API 
> functions could indeed be called before the TCP connection is 
> established (e. g., SHIM_DONTSHIM, SHIM_DEFERRED_CONTEXT_SETUP).

Ok, you are right.  We will revise the text.

> 
> The document should more explicitly describe which of the 
> socket options can be set for an "unconnected" TCP socket.

Basically, applicability statement 

> > 3.  System Overview
> >
> >   It may also be possible that the shim sub-layer interacts with the
> >   transport layer, however, such an interaction is outside the scope
> of
> >   this document.
> 
> In addition to interactions, there could also be API 
> conflicts with a multi-homing capable transport, which are 
> probably outside of the scope of this document, too.

True.  This was pointed out by Brian and we agree to mention that:

- it is not recommended to apply SHIM6 (or HIP) and any other multihoming mechanism to the IP flow by referring to draft-ietf-shim6-applicability
- we recommend SCTP and multipath TCP to have API to turn on/off the multihoming feature (so that the TCP/IP stack can avoid conflicting use of multihoming mechanisms)

> > 4.  Requirements
> >   o  Turn on/off shim.  An application should be able to request to
> >      turn on or turn off the multihoming support by the shim layer:
> >      *  Apply shim.  The application should be able to explicitly
> >         request the shim sub-layer to apply multihoming support.
> >      *  Don't apply shim.  The application should be able to request
> >         the shim sub-layer not to apply the multihoming 
> support but to
> >         apply normal IP processing at the IP layer.
> 
> I think that this is a quite important requirement and could 
> be put first in the list.

Ok. Well, I am not sure if this is the most important one, but will move this upward (as I agree it's an important one).

> > 5.11.  SHIM_LOCLIST_LOCAL
> >
> >   An application can get the locator list by getsockopt().  
> Note that
> >   the size of the buffer pointed by optval argument should be large
> >   enough to store an array of locator information.  The 
> number of the
> >   locator information is not known beforehand.
> 
> This leaves open what happens if the buffer size is not large 
> enough to store all locators. I think there should be some 
> comment what would happen in this corner case.

You are right.  We will define the maximum size of the locator list and error code when the list reaches the limit.

> 
> > 5.15.  Applicability
> >
> >   All the socket options for the multihoming shim sub-layer 
> except for
> >   SHIM_HOT_STANDBY are applicable for both connected and unconnected
> >   sockets.
> 
> As already mentioned, this section should IMHO discuss in 
> which state of a TCP connection the different socket options 
> can be used.

Ok.

> > 6.4.  Notification from Multihoming Shim Sub-layer to Application
> 
> Based on the description, I am not sure if I really 
> understand how this notification mechanism would actually 
> work, and what it would imply.

This is to notify the application about the locator change within a multihome shim context.  Suppose if applications that run on host 1 (H1) and host 2 (H2) are communicating each other.  Let's assume H1 is multihomed and has two locators, L1_H1 and L2_H1, and H2 is a single homed host which comes with a single locator L2_H2.  Suppose if the applications use L1_H1 and L2_H2 to send user data.  Now, reachability between L1_H1 and L2_H2 is lost for some reason and the multihoming shim sub-layer decides to re-home the application session.  The H1 changes its locator from L1_H1 to L2_H1.  The notification defined in this section is sent to the application in this kind of circumstance, i.e., whenever the locator change happens within a multihomed shim context.  The reaction of the application upon receiving this notification is outside the scope of this ID, but we believe such notification is useful, e.g., for application that are sensitive to characteristics of the communication channel.  Does this make sense?

> > 11.1.  Naming at Socket Layer
> 
> This subsection could IMHO be moved to Section 9. Maybe there 
> should also be a comment on potential implications of 
> returning the EID in case of legacy applications.

I agree. We will move the texts to Section 9.

> > 11.2.  Additional Requirements from Applications
> 
> I am not sure why this subsection is needed.

You are right. This is obsolete and should be removed (the requirement mentioned is already covered in the document).
 
> > 11.3.  Issues of Header Conversion among Different Address Family 
> > 11.4.  Handling of Unknown Locator Provided by Application
> 
> These two subsection should IMHO more clearly state what the 
> open issue is.

Ok, thanks. Let us revise the texts. With regard to 11.4, we are now discussing what to do (see email threads titled "Unknown Locator").

> 
> 
> Some editorial comments:
> ------------------------
> 
> * In general, I think that the use of articles ("a", "the") 
> should be reviewed in some paragraphs. But I am not a native speaker.

Ok, thanks.  We will try to improve the grammatical correctness.

> * Page 8: Typo: [RFC5534]]

Ok, thanks.

> 
> * Page 21: "An error EINVALIDLOCATOR is returned when an 
> invalid locator is specified."

Ok, thanks.

Thanks again for your thorough review!

Regards,
Shinta