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

[Shinta Sugimoto <[e-mail]>]

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
>