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

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

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