Re: [multipathtcp] Proposed changes to the protocol draft

Hi Georg, All,

I think we need more inputs or opinions for this.
I'm trying to create a simple summary for the proposals from the
previous discussion.
Please correct me if I'm missing or misunderstanding something.

 1) Add a byte to ADD_ADDRESS
     pros: simple change to the current spec. good extensibility
     cons: need one more byte

 2) Use one bit of the address-id
     pros: simple change to the current spec.
     cons: less address-id space, low extensibility

 3) Use more bits of the address-id
     pros: simple change to the current spec, some extensibility
     cons: much less address-id space,

 4) Keep the current format and develop new option to describe the
address (e.g DESC_ADDR)
     pros: great extensibility. no need to change the current spec.
     cons: might need another mechanism to sync 2 options reliably.

Also, I personally think the following can be an another possibility,
although it might not be a good idea.

 5) Keep the current format and develop new option to specify proxy or
other addresses (e. g ADD_ADDR2)
    pros: great extensibility. no need to change the current spec
    cons: having 2 options for mostly the same feature might be a bit
ugly design.

Thanks,
--
Yoshifumi Nishida
nishida@sfc.wide.ad.jp

2011/9/26 Hampel, K Georg (K Georg) <georg.hampel@alcatel-lucent.com>om>:
> Hi Phil, all,
>
> Are we certain that 1 bit is enough to cover all purposes and implications of ADD_ADDRESS?
>
> Based on recent proxy-related drafts and discussions, ADD_ADDRESS would already have to support (1) "Join using this address" and (2) "I'm a proxy". Since both implications are independent from each other and may occur in unison, 1 bit would not be enough.
>
> A more detailed discussion on proxy functions may reveal additional implications of this option.
>
> Adding one byte to the option instead of carving out 1 bit should provide sufficient room for proxy and other extensions.
>
> Thanks.
>
> Regards,
>
> Georg
>
>
>
> -----Original Message-----
> From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
> Sent: Friday, September 23, 2011 11:08 AM
> To: multipathtcp@ietf.org
> Subject: Re: [multipathtcp] Proposed changes to the protocol draft
>
> There seems to be consensus around completing the main spec without trying to solve the proxy issue (since it needs significant more work), but making the spec flexible enough that a 'proxy capability' can be added later.
> Question is how to leave room for this capability. One suggestion was to keep aside one bit of the address-id - does that have consensus? Would any of the spec have to be re-thought?
>
> Thanks
> phil
>
> Philip Eardley
> Research and Technology Strategy
>
> This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.
> British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ
> Registered in England no: 1800000
>
>
> -----Original Message-----
> From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Lars Eggert
> Sent: 12 September 2011 07:28
> To: Olivier.Bonaventure@uclouvain.be
> Cc: multipathtcp@ietf.org List
> Subject: Re: [multipathtcp] Proposed changes to the protocol draft
>
> On 2011-9-10, at 12:43, Olivier Bonaventure wrote:
>> I fear that this would add unnecessary complexity and would prefer to
>> wait for more implementation experience before looking at such
>> optimisations in the main spec
>
> This is my feeling at the moment, too. I think it'd be useful to have this written up in an individual ID so that folks can discuss (and maybe try and implement) it, but I think it's too early to put this into the main spec.
>
> Lars
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>