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

[Miika Komu <[e-mail]>]

Shinta Sugimoto wrote:

Hi,

based on some internal discussions between the authors, the out-of-band 
stuff (locator notifications from SHIM to the application) should be 
actually removed from the draft. It's not supported at all by UDP-based 
sockets (at least in Linux). TCP-based apps don't really use recvmsg() 
and sendmsg() interface. This part of the API has to be realized in some 
other way.

> Let me forward another email as well.
> 
> Regards,
> Shinta 
> 
> -----Original Message-----
> From: SCHARF, Michael [mailto:[e-mail]] 
> Sent: Friday, January 15, 2010 12:23 AM
> To: Shinta Sugimoto
> Subject: RE: [shim6] WG Last Call for draft-ietf-shim6-multihome-shim-api
> 
> Dear Shinta, 
> 
> I briefly scanned through -12. All in all, it seems to be OK for me.
> 
> Concerning the out-of-band stuff, it could be convenient to have the reference to one of the Stevens books in the draft; maybe other readers may find a reference helpful, too. But that's a comment of the category "would be nice to have".
> 
> Feel free to forward the mail to the list.
> 
> Michael 
>  
> 
>> -----Original Message-----
>> From: Shinta Sugimoto [mailto:[e-mail]]
>> Sent: Wednesday, January 13, 2010 3:03 AM
>> To: SCHARF, Michael
>> Subject: RE: [shim6] WG Last Call for 
>> draft-ietf-shim6-multihome-shim-api
>>
>> Dear Michael,
>>
>> Thank you for the comments. Please find my answers inline.  
>> BTW, I hope you do not mind if I forward this email to the
>> SHIM6 WG mailing list.  We (the WG) need to confirm that all the 
>> comments/issues raised during the WGLC are addressed in the revision 
>> of the document.
>>
>>> -----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.
>> Ok, I see.  Yes, SHIM6 is basically only for IPv6.  
>> Identifiers must be IPv6 as SHIM6 as the security mechanism to prove 
>> identity ownership is based on cryptographically generated addresses 
>> (CGA/HBA).  On the other hand, it is possible (in theory) to use IPv4 
>> locators although it is not specified in the protocol specification.  
>> The possibility of using IPv4 locators was discussed several times on 
>> the SHIM6 WG mailing list in the past.
>>
>>>>> 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?
>> Yes.
>>
>>>>>> 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.
>> Ok.
>>
>>> 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.
>> I see.  To be honest, I am also not so familiar of the use of 
>> out-of-band data handling.  For instance, the out-of-band data is used 
>> in Telnet to send interrupt signalg (e.g., Ctrl-C).  Yes, detailed 
>> explanations are given in Steven's book.  Besides, Section 24 of the 
>> book titled "UNIX Network Programming" (by Stevens, Fenner, and 
>> Rudoff) also gives detailed explanation about out-of-band data 
>> handling.
>>
>> We've submitted revision (version 12) of the document which reflects 
>> all of your comments. I'd appreciate if you could check the document 
>> to see if changes made are fine from your p.o.v.  Thanks!
>> http://tools.ietf.org/id/draft-ietf-shim6-multihome-shim-api-12.txt
>>
>> Regards,
>> Shinta
>>
> _______________________________________________
> shim6 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/shim6