Re: successful termination?

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

(catching up)

On 2009-04-08 02:40, marcelo bagnulo braun wrote:
> Hi Brian,
> 
> a couple of comments.
> 
> Brian E Carpenter escribió:
>> Jari,
>>
>> If I look at both Geoff's and Olivier's (relayed) comments,
>> it's clear to me that there is work to be done.
>>
>> I agree that the address-pair selection issue is broader
>> than just shim6 (and is related to other things, such as
>> egress router selection).
> note that shim6 need to do both ULID pair selection and locator pair
> selection (after a failure) and maybe the selection is different for
> these cases (the typical example is that when used in conjunction with
> MIPv6, probably the CoA is better as a locator  while the HoA is better
> as a ULID. OTOH, maybe in general the option is not so different.
> 
> In the scope of 6man, they select an address pair that will play both
> roles, so the criteria for selection maybe potentially different.
> 
>>  But there may still be some work
>> do here, on 'SHIM6 Requirements for Address Pair Selection',
>> even if the actual specification belongs in 6MAN.
>>
>> I agree that there is commonality of interest with multipath
>> transport, but it's far from clear to me that there is
>> actual overlap in the mechanisms; SHIM6 is a layer 3 shim,
>> and multipath transport sure seems like a layer 4 shim,
>> which was a direction that MULTI6 explicitly choose not to
>> follow up.
>>   
> I think the story here is something like this.
> Suppose we want to do multipath TCP.
> One option is to do it a la SCTP, where the MPTCP exchanges all the
> alternative addresses and includes different source dest address pairs
> to select the different paths.
> Now, the point that can be made is that shim6 already handles the
> locator pair management which is far from trivial, espcially when
> considering the security issues. So, why not let MPTCP to leverage on
> shim6 do do the locator pair management and let the MPTCP to actually
> decide which segments to send through each locator pair?
> 
> I mean, we can use a comibation of the shim6 API plus the forking
> capabiltiies and maybe some new extension so that the MPTCP is not aware
> of the actual address pairs, but knows that the underlying shim6 layer
> has path diversity. So MPTCP simply will add some tags to state that
> some segments should fly over one path and some other segments though an
> alternative path.
> So, in this case, each layer does what i does best. Shim6 handles the
> multiple locator pairs, while MPTCP distribute the segments through the
> different pahts based on congestion.
> 
> Makes sense?
> 
> If so, then we may need to do some work so that both mechanisms interact
> reasonably.

Yes. It sounds like a more developed API is needed, so that MPTCP can
use what shim6 and LEAP have already discovered. That's different from
SCTP, where we just want to switch shim6 off.

    Brian
> 
> 
>> That said, it's clear that the union of Geoff's and Olivier's
>> messages add up to a program of work, basically to find out if
>> SHIM6 is deployable and useful. I think it would be a shame
>> to pause before doing that.
>>
>>   
> agree
> 
> Regards, marcelo
> 
> 
>>   Brian