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

[Brian E Carpenter <[e-mail]>]

Agreed.

Regards
   Brian Carpenter

On 2009-12-14 17:41, Shinta Sugimoto wrote:
> Hi again,
> 
> With regard to the compability issue with SHIM6 and SCTP (and potentially multi-path TCP), I agree that we may need to put small note in the API spec.  I checked the applicability document (draft-ietf-shim6-applicability) and I think what is stated in Section 7.3 (Shim6 and SCTP) is reasonable.
> 
> So, I think we should notes in the document stating 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)
> 
> Regards,
> Shinta
> 
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:[e-mail]] 
>> Sent: Sunday, December 13, 2009 8:43 PM
>> To: [e-mail]
>> Cc: [e-mail]; Kristian Slavov; [e-mail]; Shinta Sugimoto
>> Subject: Re: [shim6] WG Last Call for 
>> draft-ietf-shim6-multihome-shim-api
>>
>> Hi Miika,
>>
>>
>> On 2009-12-14 01:41, Miika Komu wrote:
>>> Brian E Carpenter wrote:
>>>
>>> Hi,
>>>
>>> thanks for your comments! I basically I agree with the rest of your 
>>> comments, but I think the comments on SCTP and multipath TCP needs 
>>> more discussion.
>>>
>>>> ...
>>>> Also in the Introduction
>>>>
>>>>>    This document recommends that the switching of 
>> identifier and locator
>>>>>    is done only once inside the TCP/IP stack of an 
>> endhost.  That is, if
>>>>>    multiple shim sub-layers exist at the IP layer, any one of them
>>>>>    should be applied exclusively for a given flow.
>>>> I agree with this, but does it really belong in the API spec? It 
>>>> seems more like something for an applicability statement. 
>> However, if 
>>>> this stays, I think it should be very explicit, adding 
>> something like:
>>>>   Specifically, only one of SHIM6 and HIP should be in 
>> use, and neither
>>>>   of them are compatible with SCTP or multipath TCP.
>>> this interesting grey area at least for me. Why SHIM6 and 
>> HIP are not 
>>> compatible with SCTP and mTCP? Both SHIM6 and HIP are low layer 
>>> mechanisms where as SCTP and mTCP are operating at the 
>> transport layer.
>>> I'm not sure if the SHIM protocols are incompatible with 
>> the transport 
>>> layer ones, but they do offer somewhat overlapping functionality.
>>>
>>>> (see
>>>>
>> http://www.ietf.org/mail-archive/web/multipathtcp/current/msg00178.ht
>>>> ml
>>>> for example)
>>> Are you familiar with this work:
>>>
>>> http://tools.ietf.org/html/draft-pierrel-hip-sima-00
>>> http://www.cs.helsinki.fi/u/gurtov/papers/broadnets09.pdf
>> No, those are new to me. But they do help to show exactly why 
>> this is a grey area. I believe that in shim6 we've always 
>> assumed an incompatibility between shim6 and SCTP (two 
>> different algorithms for changing locators). MPTCP is a bit 
>> too new to be sure, but since it assumes using several 
>> locators simultaneously and shim6 assumes using one locator 
>> at a time, again it seems incompatible.
>>
>> But really, that's why I think the whole discussion doesn't 
>> belong in the API spec, except perhaps as an open issue. See below.
>>
>>>>> 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.
>>>> We might add a note that this function is also required by any 
>>>> multipath transport layer such as SCTP or MPTCP, with the details 
>>>> being operating system dependent.
>>> Just based on your earlier incompatibility statement, I 
>> don't really 
>>> see why we should drag SCTP and mTCP all the way here, but 
>> I'll wait 
>>> for your comments on the incompatibility first.
>> Yes, it isn't part of the socket API. I was only suggesting a 
>> small note.
>>
>> There is some discussion of this topic in 
>> draft-ietf-shim6-applicability.
>> My feeling is that probably we should remove it all from the 
>> API spec, and add any missing points to 
>> draft-ietf-shim6-applicability, which can then be an 
>> Informative reference.
>>
>>     Brian
>>