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

[Miika Komu <[e-mail]>]

Brian E Carpenter wrote:

Hi,

I think adding a reference to the SHIM6 applicability document is a good 
idea.

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