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

From: <[email-masked]>
Date: Tue, 10 Nov 2015 07:04:03 +0000

Dear all,

I'm forwarding this review from the DHC working group. The full thread is available at: https://mailarchive.ietf.org/arch/search/?email_list=dhcwg 

Your feedback is more than welcome. 

Cheers,
Med

> -----Message d'origine-----
> 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)
> 
> 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: <[email-masked]>
Date: Thu, 12 Nov 2015 13:00:16 +0000

Hi Simon,

(adding mptcp to the discussion)

Please see inline.

Cheers,
Med

> De : dhcwg [mailto:[email-masked]] De la part de Simon Hobson
> Envoyé : mardi 10 novembre 2015 17:14
> À : [email-masked]
> [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.

[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?

> > ... 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.

[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.
> 
> > 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: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

> De : Niall O'Reilly [mailto:[email-masked]]
> Envoyé : mardi 10 novembre 2015 16:57
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Simon Hobson; [email-masked]
> On Tue, 10 Nov 2015 14:34:02 +0000,
> <[email-masked]> wrote:
> >
> > Although I understand the arguments you raised, I'm not convinced
> > 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: <[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)

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:

_______________________________________________
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: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 Nov 2015 13:13:56 +0000

- Bernie (from iPad)

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)

---

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]
> Objet : RE: [dhcwg] DHCP Options for Network-Assisted Multipath TCP
> (MPTCP)
> 
> 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!