Subject: Re: [multipathtcp] Proposed changes to the protocol draft

From: Alan Ford <[email-masked]>
Date: Tue, 4 Oct 2011 19:15:27 +0100

Hi all,

Sorry for the delay in replying, this is a general reply to a number of
points...

Firstly, I agree with Costin's proposal 1 - fallback should drop into a mode
identical to regular TCP.

As regards the proxy issue, I agree with Georg that it's not sensible to
rush into defining something.

Yes, ADD_ADDR does have two meanings - the ID/address mapping, and the
request to initiate join. However, as I see it, there is little reason to do
the former without desiring the latter.

So, the question is, quite rightly - if we did have a 'proxy' flag, what
does it actually mean? And could it have wider uses than just proxies?

Ultimately, I would agree with the sentiment that this should be an
additional option, defined later, once requirements are clearer. We have the
extensibility to support this in terms of MPTCP option subtypes. In other
words, Yoshifumi's Option 5.

Regards,
Alan

On 27 September 2011 15:36, Hampel, K Georg (K Georg) <
[email-masked]> wrote:

> Hi Yoshifumi, all,
>
> I think you summarized the various options and their respective tradeoffs
> very well.
>
> I'm not completely certain, however, on what we are trying to accomplish.
> While the transparent proxy proposed in our I-D demands one additional bit
> in ADD_ADDRESS, I'm not sure that one bit is enough to cover *all* (present
> and/or future) meanings of the ADD_ADDRESS option.
>
> The WG further seems to have agreed that the proxy concept requires more
> work. I'm not sure we can anticipate the associated signaling changes
> without having gone through this work. Why should the present WG draft try
> to preempt this work?
>
> The proxy discussions may have created the feeling that ADD_ADDRESS
> *principally* lacks sufficient space to cover future
> implications/actions/descriptions associated with an address. Such space
> extension should indeed be captured within the present WG draft. However, I
> think it should not be guided by preemptive guesses on what a proxy may
> need.
>
>
> -Georg
>
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Yoshifumi Nishida
> Sent: Tuesday, September 27, 2011 5:06 AM
> To: Hampel, K Georg (K Georg)
> Cc: [email-masked]
> Subject: 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
> [email-masked]
>
> 2011/9/26 Hampel, K Georg (K Georg) <[email-masked]>:
> > 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: [email-masked] [mailto:
> [email-masked]] On Behalf Of [email-masked]
> > Sent: Friday, September 23, 2011 11:08 AM
> > To: [email-masked]
> > 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: [email-masked] [mailto:
> [email-masked]] On Behalf Of Lars Eggert
> > Sent: 12 September 2011 07:28
> > To: [email-masked]
> > Cc: [email-masked] 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/multipathtcp
> > _______________________________________________
> > multipathtcp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/multipathtcp
> >
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

---

From: <[email-masked]>
Date: Wed, 5 Oct 2011 11:50:44 +0100

Another possibility is to go for a combination of Option 2 & 4 /5. This might be worthwhile if it is clear that the Option 2 (use one bit) is significantly useful in an important proxy scenario, whilst Option 4/5 would be for other proxy scenarios.

Georg's email with the long list of "proxy issues" would suggest to me that Yoshifumi's option 4 or 5 are better. Ie we don't currently have a very good understanding of what is needed

I'm not sure I understand the difference between 4 & 5. Is 4 saying that DESC_ADDR is not valid on its own but always associated with an ADD_ADDRESS which it supplements? Whilst 5 is a standalone option? If I got this right, then I favour 5, as I'd have thought there are some nasty error cases with 4.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Ford
Sent: 04 October 2011 19:15
To: Hampel, K Georg (K Georg)
Cc: [email-masked]
Subject: Re: [multipathtcp] Proposed changes to the protocol draft

Hi all,

Sorry for the delay in replying, this is a general reply to a number of points...

Firstly, I agree with Costin's proposal 1 - fallback should drop into a mode identical to regular TCP.

As regards the proxy issue, I agree with Georg that it's not sensible to rush into defining something.

Yes, ADD_ADDR does have two meanings - the ID/address mapping, and the request to initiate join. However, as I see it, there is little reason to do the former without desiring the latter.

So, the question is, quite rightly - if we did have a 'proxy' flag, what does it actually mean? And could it have wider uses than just proxies?

Ultimately, I would agree with the sentiment that this should be an additional option, defined later, once requirements are clearer. We have the extensibility to support this in terms of MPTCP option subtypes. In other words, Yoshifumi's Option 5.

Regards,
Alan

On 27 September 2011 15:36, Hampel, K Georg (K Georg) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yoshifumi, all,

I think you summarized the various options and their respective tradeoffs very well.

I'm not completely certain, however, on what we are trying to accomplish. While the transparent proxy proposed in our I-D demands one additional bit in ADD_ADDRESS, I'm not sure that one bit is enough to cover *all* (present and/or future) meanings of the ADD_ADDRESS option.

The WG further seems to have agreed that the proxy concept requires more work. I'm not sure we can anticipate the associated signaling changes without having gone through this work. Why should the present WG draft try to preempt this work?

The proxy discussions may have created the feeling that ADD_ADDRESS *principally* lacks sufficient space to cover future implications/actions/descriptions associated with an address. Such space extension should indeed be captured within the present WG draft. However, I think it should not be guided by preemptive guesses on what a proxy may need.

-Georg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Yoshifumi Nishida
Sent: Tuesday, September 27, 2011 5:06 AM
To: Hampel, K Georg (K Georg)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [multipathtcp] Proposed changes to the protocol draft

Hi Georg, All,

Thanks,
--
Yoshifumi Nishida
[email-masked]<mailto:[email-masked]>

2011/9/26 Hampel, K Georg (K Georg) <[email-masked]<mailto:[email-masked]>>:
> 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
>
>
>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> 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
> 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.
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Lars Eggert
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]> List
> 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
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
multipathtcp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Alan Ford <[email-masked]>
Date: Wed, 5 Oct 2011 15:28:38 +0100

As I understood it, Option 4 is about defining a split DESC_ADDR and join
initiation messages today, decoupling the two functions of ADD_ADDR that
Georg identified.

This does not in itself solve the proxy issue, however. Since we do not yet
understand fully what we want to achieve from proxy signalling
functionality, we also do not know whether we want to split ADD_ADDR or not.
I therefore strongly favour Option 5 as it is simpler - it does not
(potentially unnecessarily) define an additional message, it keeps the
functionality as we know it today (i.e. tailored for non-proxy scenarios),
and still permits new signals to be developed once the requirements are
better defined.

On 5 October 2011 11:50, <[email-masked]> wrote:

> Another possibility is to go for a combination of Option 2 & 4 /5. This
> might be worthwhile if it is clear that the Option 2 (use one bit) is
> significantly useful in an important proxy scenario, whilst Option 4/5 would
> be for other proxy scenarios. ****
>
> ** **
>
> Georg’s email with the long list of “proxy issues” would suggest to me that
> Yoshifumi’s option 4 or 5 are better. Ie we don’t currently have a very good
> understanding of what is needed ****
>
> ** **
>
> I’m not sure I understand the difference between 4 & 5. Is 4 saying that
> DESC_ADDR is not valid on its own but always associated with an ADD_ADDRESS
> which it supplements? Whilst 5 is a standalone option? If I got this right,
> then I favour 5, as I’d have thought there are some nasty error cases with
> 4. ****
>
> ** **
>
> *From:* [email-masked] [mailto:
> [email-masked]] *On Behalf Of *Alan Ford
> *Sent:* 04 October 2011 19:15
>
> *To:* Hampel, K Georg (K Georg)
> *Cc:* [email-masked]
> *Subject:* Re: [multipathtcp] Proposed changes to the protocol draft****
>
> ** **
>
> Hi all,****
>
> ** **
>
> points...****
> ** **
> Firstly, I agree with Costin's proposal 1 - fallback should drop into a
> mode identical to regular TCP.****
>
> ** **
>
> rush into defining something.****
>
> ** **
>
> the former without desiring the latter.****
>
> ** **
>
> does it actually mean? And could it have wider uses than just proxies?****
>
> ** **
>
> words, Yoshifumi's Option 5.****
>
> ** **
>
> Regards,****
>
> Alan****
>
> ** **
>
> [email-masked]> wrote:****
>
> Hi Yoshifumi, all,
>
> -Georg****
> https://www.ietf.org/mailman/listinfo/multipathtcp****
>
> ** **
>

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Wed, 5 Oct 2011 10:07:22 -0500

Philip, Alan, Yoshifumi, all,

It's not easy to accommodate room on present messages for future proxy functionality without actually discussing the future proxy functionality. We have to realize that the discussion on "how to create room on ADD_ADDR" is already based on such proxy discussions.

How much room do we think the proxy will need?

Steeling 1 or 2 bits from an existing ADD_ADDR field (option 2 & 3) may satisfy what we presently think the proxy needs, but it may turn out to be too meager and we may face the whole space discussion in a few months again.

Blindly adding bytes for "future purposes, e.g. proxy" (option 1) seems overly preemptive, especially since option space is scarce and the reserved bytes may never be used.

Options 4 and 5 keep the existing signaling, and they demand for new messages to cover future functionality. This seems to be a reasonable approach since we don't have to preempt anything. We should further postpone decisions on the specific nature and name of these messages (e.g. ADD_ADDR2, DESC_ADDR, etc) until we do the actual proxy discussion. Option 4) and 5) are therefore identical.

Thanks,

Georg

________________________________
From: Alan Ford [mailto:[email-masked]]
Sent: Wednesday, October 05, 2011 10:29 AM
To: [email-masked]
Cc: Hampel, K Georg (K Georg); [email-masked]
Subject: Re: [multipathtcp] Proposed changes to the protocol draft

As I understood it, Option 4 is about defining a split DESC_ADDR and join initiation messages today, decoupling the two functions of ADD_ADDR that Georg identified.

This does not in itself solve the proxy issue, however. Since we do not yet understand fully what we want to achieve from proxy signalling functionality, we also do not know whether we want to split ADD_ADDR or not. I therefore strongly favour Option 5 as it is simpler - it does not (potentially unnecessarily) define an additional message, it keeps the functionality as we know it today (i.e. tailored for non-proxy scenarios), and still permits new signals to be developed once the requirements are better defined.

On 5 October 2011 11:50, <[email-masked]<mailto:[email-masked]>> wrote:
Another possibility is to go for a combination of Option 2 & 4 /5. This might be worthwhile if it is clear that the Option 2 (use one bit) is significantly useful in an important proxy scenario, whilst Option 4/5 would be for other proxy scenarios.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alan Ford
Sent: 04 October 2011 19:15

Hi all,

Regards,
Alan

-Georg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Yoshifumi Nishida
Sent: Tuesday, September 27, 2011 5:06 AM
To: Hampel, K Georg (K Georg)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [multipathtcp] Proposed changes to the protocol draft

Hi Georg, All,

Thanks,