Subject: Re: [dhcwg] DHCP Options for Network-Assisted Multipath TCP (MPTCP)

From: Dan Seibel <[email-masked]>
Date: Mon, 9 Nov 2015 08:50:38 -0700

I think your document gives a good overall impression of how this will
work (having no experience with MPTCP implementations I found this fairly
easy to follow).

A few questions:

- in sections 4.2 you mention a client requests this option, but does it
have to?  I.e could a server send this option without the client
requesting it, and the client would still accept it? (should there be a
MUST or SHOULD statement in there?)

- similarly, in section 5 I don¹t see any mention of if the server needs
to see a request for this option to hand it out.

On 2015-11-05, 8:19 AM, "dhcwg on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>Dear all,
>
>Comments are more than welcome.
>
>Cheers,
>Med
>
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]]
>> Envoyé : jeudi 5 novembre 2015 16:19
>> À : BOUCADAIR Mohamed IMT/OLN; Tirumaleswar Reddy; JACQUENET Christian
>> IMT/OLN
>> Objet : New Version Notification for draft-boucadair-mptcp-dhc-02.txt
>> 
>> 
>> A new version of I-D, draft-boucadair-mptcp-dhc-02.txt
>> has been successfully submitted by Mohamed Boucadair and posted to the
>> IETF repository.
>> 
>> Name:		draft-boucadair-mptcp-dhc
>> Revision:	02
>> Title:		DHCP Options for Network-Assisted Multipath TCP (MPTCP)
>> Document date:	2015-11-05
>> Group:		Individual Submission
>> Pages:		11
>> URL:            https://www.ietf.org/internet-drafts/draft-boucadair-
>> mptcp-dhc-02.txt
>> Status:         https://datatracker.ietf.org/doc/draft-boucadair-mptcp-
>> dhc/
>> Htmlized:       https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-02
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-boucadair-mptcp-
>> dhc-02
>> 
>> Abstract:
>>    One of the promising deployment scenarios for Multipath TCP (MPTCP)
>>    is to enable a Customer Premises Equipment (CPE) that is connected to
>>    multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of its
>>    network attachments.  Because of the lack of MPTCP support at the
>>    server side, some service providers consider a network-assisted model
>>    that relies upon the activation of a dedicated function called: MPTCP
>>    Concentrator.
>> 
>>    This document focuses on the explicit deployment scheme where the
>>    identity of the MPTCP Concentrator(s) is explicitly configured on
>>    connected hosts.  This document specifies DHCP (IPv4 and IPv6)
>>    options to configure hosts with Multipath TCP (MPTCP) parameters.
>> 
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 10 Nov 2015 02:57:32 +0000

Dan:

Yes, the client should request this option. That is the normal behavior of clients.

And, yes, servers should only return the option if requested by the client.

Please see RFC 7227 and also my email regarding the ORO handling (Ticket #81 for the RFC3315 bis work).

And, Med ... a quick check of the options seems they are formatted correctly (as per the option guidelines and common practice).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Dan Seibel
Sent: Monday, November 09, 2015 10:51 AM
To: [email-masked]; [email-masked]
Subject: Re: [dhcwg] DHCP Options for Network-Assisted Multipath TCP (MPTCP)

I think your document gives a good overall impression of how this will work (having no experience with MPTCP implementations I found this fairly easy to follow).

A few questions:

- in sections 4.2 you mention a client requests this option, but does it have to?  I.e could a server send this option without the client requesting it, and the client would still accept it? (should there be a MUST or SHOULD statement in there?)

- similarly, in section 5 I don¹t see any mention of if the server needs to see a request for this option to hand it out.

On 2015-11-05, 8:19 AM, "dhcwg on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>> Envoyé : jeudi 5 novembre 2015 16:19 À : BOUCADAIR Mohamed IMT/OLN; 
>> Tirumaleswar Reddy; JACQUENET Christian IMT/OLN Objet : New Version 
>> Notification for draft-boucadair-mptcp-dhc-02.txt
>> 
>> 
>> A new version of I-D, draft-boucadair-mptcp-dhc-02.txt has been 
>> successfully submitted by Mohamed Boucadair and posted to the IETF 
>> repository.
>> 
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>> 
>> The IETF Secretariat
>

---

From: <[email-masked]>
Date: Tue, 10 Nov 2015 06:56:50 +0000

Hi Dan,

Thank you for the feedback. 

Please see inline. 

Cheers,
Med

> De : Dan Seibel [mailto:[email-masked]]
> Envoyé : lundi 9 novembre 2015 16:51
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Objet : Re: [dhcwg] DHCP Options for Network-Assisted Multipath TCP
> (MPTCP)
> 
[Med] The client has to indicate the option if it needs to be provisioned with a concentrator. I changed the wording to make it clearer: 

"To discover one or more MPTCP Concentrators, the DHCPv4 client MUST include OPTION_V4_MPTCP in a Parameter Request List Option [RFC2132]."

> to see a request for this option to hand it out.
[Med] We assumed that as being the default behavior of the server. In order to make it cleared, I added this sentence in section 5:

"The DHCP server MUST NOT reply with the DHCP MPTCP Concentrator option unless the client has explicitly requested for it."

---

From: <[email-masked]>
Date: Tue, 10 Nov 2015 06:57:19 +0000

Hi Bernie,

Thank you for checking the document. Much appreciated!

Cheers,
Med

> De : Bernie Volz (volz) [mailto:[email-masked]]
> Envoyé : mardi 10 novembre 2015 03:58
> À : Dan Seibel; BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Objet : RE: [dhcwg] DHCP Options for Network-Assisted Multipath TCP
> (MPTCP)
> 
> Dan:
> 
> And, Med ... a quick check of the options seems they are formatted
> correctly (as per the option guidelines and common practice).
> 
> - Bernie
>

---

From: "Niall O'Reilly" <[email-masked]>
Date: Tue, 10 Nov 2015 08:55:52 +0000

On Tue, 10 Nov 2015 06:56:50 +0000,
<[email-masked]> wrote:
> 
> 
> "The DHCP server MUST NOT reply with the DHCP MPTCP Concentrator
> option unless the client has explicitly requested for it."

  Writing this as "SHOULD NOT" would allow scope for supporting
  broken clients.  For some other option, which I can't recall
  just now, I've sometimes needed to "adjust" the Parameter
  Request List on receipt at the server, so as to include an
  option which the client needed but hadn't included.

  Best regards,
  Niall O'Reilly

---

From: <[email-masked]>
Date: Tue, 10 Nov 2015 09:13:18 +0000

Hi Niall,

Wouldn't be better to fix the broken client implementation?  

Relaxing the behavior at the server side leads to another question: how to ensure that a broken client will correctly interpreted an option it didn't ask for? 

Thank you.

Cheers,
Med

> De : Niall O'Reilly [mailto:[email-masked]]
> Envoyé : mardi 10 novembre 2015 09:56
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Dan Seibel; [email-masked]

---

From: Simon Hobson <[email-masked]>
Date: Tue, 10 Nov 2015 09:59:11 +0000

> Wouldn't be better to fix the broken client implementation?  

Yes, in the general case that would be the correct response. But I think few of us have never found themselves in a situation where something is "not quite right" but the vendor shrugs their shoulders and takes the attitude "it works for us".
It's one thing for an open source client where even if the original authors/maintainers don't care, it's possible for someone else to pick it up and deal with it. It's a different matter if it's some proprietary piece of junk someone's just put on the network and expects the admin to make it work.

> Relaxing the behavior at the server side leads to another question: how to ensure that a broken client will correctly interpreted an option it didn't ask for? 

It may be a simple issue of the client author just not having configured the client to ask for it - perhaps being one of those that only ever tests with their own server that they've configured to always send it. That's the other situation I've seen - "client" devices built on the assumption that the only network they'll ever be connected to is managed by the same vendor's "server" device. Any suggestion to the vendor that there's a problem is met with a "it works with our ${box of tricks}" so it must be your server that's at fault - so the only way to work round it is to "misconfigure" your own server to match the broken vendor server.

---

From: <[email-masked]>
Date: Tue, 10 Nov 2015 14:34:02 +0000

Hi Simon,

I hear you...

But, in addition to updating the client's behavior so that it must be prepared to receive the option even if it didn't requested for it, the server must support a logic to decide which clients should be supplied with the mptcp option. If such logic is not implemented, ** all ** clients will be configured with an MPTCP concentrator ... which is not desired!

Although I understand the arguments you raised, I'm not convinced the text should be relaxed. 

Cheers,
Med

> De : dhcwg [mailto:[email-masked]] De la part de Simon Hobson
> Envoyé : mardi 10 novembre 2015 10:59
> À : [email-masked]
> Yes, in the general case that would be the correct response. But I think
> few of us have never found themselves in a situation where something is
> "not quite right" but the vendor shrugs their shoulders and takes the
> attitude "it works for us".
> It's one thing for an open source client where even if the original
> authors/maintainers don't care, it's possible for someone else to pick it
> up and deal with it. It's a different matter if it's some proprietary
> piece of junk someone's just put on the network and expects the admin to
> make it work.
> 
> > Relaxing the behavior at the server side leads to another question: how
> to ensure that a broken client will correctly interpreted an option it
> didn't ask for?
> 
> It may be a simple issue of the client author just not having configured
> the client to ask for it - perhaps being one of those that only ever tests
> with their own server that they've configured to always send it. That's
> the other situation I've seen - "client" devices built on the assumption
> that the only network they'll ever be connected to is managed by the same
> vendor's "server" device. Any suggestion to the vendor that there's a
> problem is met with a "it works with our ${box of tricks}" so it must be
> your server that's at fault - so the only way to work round it is to
> "misconfigure" your own server to match the broken vendor server.
>

---

From: "Niall O'Reilly" <[email-masked]>
Date: Tue, 10 Nov 2015 15:56:51 +0000

> the text should be relaxed.

  I believe that, as it stands, the text constrains unduly the
  discretion of the operator to configure the server to accommodate
  a broken client whose repair cannot practically be effected.

  Operationally, this is likely to cause a pain in the proverbials.
  Please see https://fr.wikisource.org/wiki/La_B%C3%A9gueule

  Best regards,
  Niall O'Reilly

---

From: Simon Hobson <[email-masked]>
Date: Tue, 10 Nov 2015 16:14:23 +0000

[email-masked] wrote:

> But, in addition to updating the client's behavior so that it must be prepared to receive the option even if it didn't requested for it

I think the specific use case was that the client is expecting it, but just doesn't ask for it. I'm no expert user, but I have come across stuff where a vendor has built server and client, and makes the two work together - but not in a standards compliant way. Since in some cases the vendor has zero interest in working with anything but an "all mine and nothing else" network environment, they may have no interest in fixing a client that is broken according to the standards, but which is working with their server which is also non-standards compliant in a way that makes the pair work together.

> ... the server must support a logic to decide which clients should be supplied with the mptcp option.

Typically that would be done by the admin, classifying the clients by some means, and then overriding the requested parameter list. This is certainly possible with the ISC server.

I can't remember what it was for (it was a good few years ago with a different hat on), but I know I've had to provide an option list override for a problematic client in the past - it was most likely a done by adding it to a "host" declaration with the ISC server.

> Although I understand the arguments you raised, I'm not convinced the text should be relaxed. 

As Niall points out, it prohibits an admin faced with a broken client from working around the issue.

---

From: <[email-masked]>
Date: Thu, 12 Nov 2015 13:00:16 +0000

Hi Simon,

(adding mptcp to the discussion)

Please see inline.

Cheers,
Med

> Envoyé : mardi 10 novembre 2015 17:14
> À : [email-masked]
> > But, in addition to updating the client's behavior so that it must be
> prepared to receive the option even if it didn't requested for it
> 
> I think the specific use case was that the client is expecting it, but
> just doesn't ask for it.

[Med] Agree on the use case. BTW, this is governed by the following: 

https://tools.ietf.org/html/rfc7227#section-19: 

"  For some options, such as the options required for the functioning of
   DHCPv6 itself, it doesn't make sense to require that they be
   explicitly requested using the Option Request Option.  In all other
   cases, it is prudent to assume that any new option must be present on
   the relevant option request list if the client desires to receive it."

and https://tools.ietf.org/html/rfc7227#section-21:  

"As a convenience to the reader, we
   mention here that the server will send option foo only if configured
   with specific values for foo and if the client requested it."

My initial comment was: if we allow the server to return an option a client didn't asked for, we need to add a sentence like this one in the client's behavior section:

"The DHCP client MUST be prepared to receive the DHCP MPTCP Concentrator
   Option even if it didn't include it in the request."

(I do personally think this adds extra complexity without any guarantee that a broken implementation will make use of an option it didn't asked for).

 I'm no expert user, but I have come across stuff
> where a vendor has built server and client, and makes the two work
> together - but not in a standards compliant way. Since in some cases the
> vendor has zero interest in working with anything but an "all mine and
> nothing else" network environment, they may have no interest in fixing a
> client that is broken according to the standards, but which is working
> with their server which is also non-standards compliant in a way that
> makes the pair work together.
> 

[Med] That's the point. Does it really matter to have a "SHOULD NOT" instead of "MUST NOT" if the standard behavior will be broken anyway?

> Typically that would be done by the admin, classifying the clients by some
> means, and then overriding the requested parameter list. This is certainly
> possible with the ISC server.

[Med] Yes; that's implementation-specific. My point is not about "how" but that the sever should be able to do that using "some means". 

> 
> I can't remember what it was for (it was a good few years ago with a
> different hat on), but I know I've had to provide an option list override
> for a problematic client in the past - it was most likely a done by adding
> it to a "host" declaration with the ISC server.
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 Nov 2015 13:13:56 +0000

Please don't over specify this.

If client wants option it MUST request it in the ORO / PRL. End of story.

Note that clients may receive options they didn't ask for (perhaps ones they don't even know) and proper action is to ignore those.

It also makes little sense for a client not to ask for something it supports (except in cases where it is being asked (by an application?) to get something (via Information-Request/Inform) that it didn't request in the past).

What does a statement like the following mean?

What is "prepared"? Again, client should always be "prepared" to receive any option - that may just mean ignoring it.

We are working to update RFC3315bis text to clarify that clients and servers must be capable of receiving any option - but will ignore those that they do not care about or know about.

We really want "other configuration" options documents to say very little about option processing. State that client MUST include in ORO/PRL to have any chance to receive it.

- Bernie (from iPad)

On Nov 12, 2015, at 8:00 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Simon,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : dhcwg [mailto:[email-masked]] De la part de Simon Hobson
Envoyé : mardi 10 novembre 2015 17:14
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [dhcwg] DHCP Options for Network-Assisted Multipath TCP
(MPTCP)

[email-masked]<mailto:[email-masked]> wrote:

... the server must support a logic to decide which clients should be
supplied with the mptcp option.

Although I understand the arguments you raised, I'm not convinced the
text should be relaxed.

As Niall points out, it prohibits an admin faced with a broken client from
working around the issue.

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: <[email-masked]>
Date: Thu, 12 Nov 2015 13:24:04 +0000

Hi Niall,

We are not trying to make the specification "perfect"...we are doing our best to follow dhc guidelines (rfc7227, in particular). 

Cheers,
Med

> Envoyé : mardi 10 novembre 2015 16:57
> Cc : Simon Hobson; [email-masked]

---

From: <[email-masked]>
Date: Thu, 12 Nov 2015 13:28:08 +0000

Hi Bernie,

I'm on the same page as you.

The proposed text was to explicitly show to Simon the complexity induced by the request to handle broken implementations.

FWIW, the latest version of the draft is available at: https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-03

Cheers,
Med

De : Bernie Volz (volz) [mailto:[email-masked]]
Envoyé : jeudi 12 novembre 2015 14:14
À : BOUCADAIR Mohamed IMT/OLN
Cc : Simon Hobson; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [dhcwg] DHCP Options for Network-Assisted Multipath TCP (MPTCP)

- Bernie (from iPad)

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : dhcwg [mailto:[email-masked]] De la part de Simon Hobson
Envoyé : mardi 10 novembre 2015 17:14
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [dhcwg] DHCP Options for Network-Assisted Multipath TCP
(MPTCP)

---

From: Simon Hobson <[email-masked]>
Date: Thu, 12 Nov 2015 14:23:53 +0000

> The proposed text was to explicitly show to Simon the complexity induced by the request to handle broken implementations.

Which IMO you failed to do.

If a client receives an option that it doesn't know what to do with - it is already required to ignore it. As Bernie points out, you do not need to specify that as that's already "standard requirement" for all options.
You also don't need to specify that the client must request it - that too is standard requirement.

The suggestion was simply that you change one instance of "must not" to "should not".
In the ideal world, no client would ever want an option but not request it - "should not" is sufficient instruction for a normal server, serving a normal client, with nothing broken, to not send the option if not requested.

But in the non-ideal world, sometimes the admin needs to override the strictly correct operation so as to deal with something that isn't completely ideal. Stating "must not" precludes the admin from working around a problem, and technically means an implementation must prevent him from trying*. In the real world there are broken things we can't fix - only work around the broken bits.

You don't need to specify any mechanism for that, you don't even need to reference the possibility - just don't prohibit it. So the sole change required is to change "must" to "should" in one place.

* If the server "must not" send an option the client didn't ask for, then strictly speaking, an implementation "must not" have a means for the admin to override that parameter list.

---

From: <[email-masked]>
Date: Thu, 12 Nov 2015 15:09:38 +0000

Re-,

The change you asked for is as follows: 

==============
OLD:
   The DHCP server MUST NOT reply with the DHCP MPTCP Concentrator
   option unless the client has explicitly requested for it.

NEW:
   The DHCP server SHOULD NOT reply with the DHCP MPTCP Concentrator
   option unless the client has explicitly requested for it.
==============

Comments from the wg about this change is welcome. 

Cheers,
Med

> Envoyé : jeudi 12 novembre 2015 15:24
> À : [email-masked]; [email-masked]
> > The proposed text was to explicitly show to Simon the complexity induced
> by the request to handle broken implementations.
> 
> If a client receives an option that it doesn't know what to do with - it
> is already required to ignore it. As Bernie points out, you do not need to
> specify that as that's already "standard requirement" for all options.
> In the ideal world, no client would ever want an option but not request it
> - "should not" is sufficient instruction for a normal server, serving a
> normal client, with nothing broken, to not send the option if not
> requested.
> 
> But in the non-ideal world, sometimes the admin needs to override the
> strictly correct operation so as to deal with something that isn't
> completely ideal. Stating "must not" precludes the admin from working
> around a problem, and technically means an implementation must prevent him
> from trying*. In the real world there are broken things we can't fix -
> only work around the broken bits.
> 
> You don't need to specify any mechanism for that, you don't even need to
> reference the possibility - just don't prohibit it. So the sole change
> required is to change "must" to "should" in one place.
> 
> * If the server "must not" send an option the client didn't ask for, then
> strictly speaking, an implementation "must not" have a means for the admin
> to override that parameter list.
>

---

From: "Niall O'Reilly" <[email-masked]>
Date: Fri, 13 Nov 2015 16:48:42 +0000

> The change you asked for is as follows: 

  Yes, please!  I think Simon has explained the need already.

  Best regards,
  Niall O'Reilly

---

From: <[email-masked]>
Date: Tue, 17 Nov 2015 08:56:04 +0000

Hi Niall,

Ok, noted. 

Hope to hear more voices.

Cheers,
Med

> Envoyé : vendredi 13 novembre 2015 17:49
> Cc : Simon Hobson; [email-masked]; [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Nov 2015 15:28:44 +0000

Neither text is correct.   If you are going to specify DHCP server behavior with normative language, you are updating RFC 3315, which you almost certainly do not want to do.   RFC 3315 already specifies the correct behavior.   Please remove this text.   RFC 7227 section 21.2 touches on this issue.
________________________________________
From: dhcwg [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Tuesday, November 17, 2015 03:56
To: Niall O'Reilly
Cc: [email-masked]; [email-masked]
Subject: Re: [dhcwg] DHCP Options for Network-Assisted Multipath TCP (MPTCP)

Hi Niall,

Ok, noted.

Cheers,
Med

---

From: <[email-masked]>
Date: Wed, 18 Nov 2015 06:31:55 +0000

Hi Ted,

Thank you for feedback. I see you are asking we revert back to what we had in -02.

I do confirm we don't want to update RFC3315. This is exactly why the title of the section we are discussing is "DHCP Server Configuration Guidelines", not "server behavior". 

Cheers,
Med

> De : Ted Lemon [mailto:[email-masked]]
> Envoyé : mardi 17 novembre 2015 16:29
> À : BOUCADAIR Mohamed IMT/OLN; Niall O'Reilly
> Cc : [email-masked]; [email-masked]
> Neither text is correct.   If you are going to specify DHCP server
> behavior with normative language, you are updating RFC 3315, which you
> almost certainly do not want to do.   RFC 3315 already specifies the
> correct behavior.   Please remove this text.   RFC 7227 section 21.2
> touches on this issue.
> From: dhcwg [[email-masked]] on behalf of
> [email-masked] [[email-masked]]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Nov 2015 15:07:59 +0000

Thanks, Med.   The new text (or lack thereof!) is fine!