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

[Shinta Sugimoto <[e-mail]>]

Hi,

Let me forward an email from Michael Scharf.

Regards,
Shinta 

-----Original Message-----
From: SCHARF, Michael [mailto:[e-mail]] 
Sent: Friday, January 08, 2010 9:25 PM
To: Shinta Sugimoto
Subject: RE: [shim6] WG Last Call for draft-ietf-shim6-multihome-shim-api

Dear Shinta, 

some small clearifications inline.

> > 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.

I was a little bit confused by the IPv4 boxes in that figure. I thought that SHIM6 is IPv6-only.
 
> > 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)

Fine for me.

For MPTCP, this essentially means that the API must turn off the multipath transport, right?

> > > 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?

Yes, this is indeed a relevant use case.

But I struggled with the description of the realization the out-of-band notification, which is AFAIK a rather unusual sockets API mechanism. It would help if there was a reference to a description/tutorial of this out-of-band mechanism (Steven's book?). I have not found many examples for the usage of the forth argument of select() so far, but maybe I have searched in the wrong places. 

Michael