IETF Logo Mail Archive

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

<mohamed.boucadair@orange.com> Tue, 10 November 2015 14:34 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168AF1B2B99 for <dhcwg@ietfa.amsl.com>; Tue, 10 Nov 2015 06:34:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1pMZjd_i5P3 for <dhcwg@ietfa.amsl.com>; Tue, 10 Nov 2015 06:34:06 -0800 (PST)
Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328E51B2B95 for <dhcwg@ietf.org>; Tue, 10 Nov 2015 06:34:05 -0800 (PST)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 71AE840673; Tue, 10 Nov 2015 15:34:03 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 667EB120055; Tue, 10 Nov 2015 15:34:03 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0248.002; Tue, 10 Nov 2015 15:34:03 +0100
From: mohamed.boucadair@orange.com
To: Simon Hobson <linux@thehobsons.co.uk>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: [dhcwg] DHCP Options for Network-Assisted Multipath TCP (MPTCP)
Thread-Index: AQHRG557lq0xhCdf9UGaBhkdp02WE56VB2AA
Date: Tue, 10 Nov 2015 14:34:02 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008C9AEFD@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <D2660C4C.7A833%dan.seibel@telus.com> <787AE7BB302AE849A7480A190F8B933008C9AC74@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <m2pozifd2f.wl-Niall.oReilly@ucd.ie> <787AE7BB302AE849A7480A190F8B933008C9AD6A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <D8E99AD3-A93A-4C43-9E6D-9E3015EF4670@thehobsons.co.uk>
In-Reply-To: <D8E99AD3-A93A-4C43-9E6D-9E3015EF4670@thehobsons.co.uk>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/F52bHjBl3TjTBl-6-jwWELcKYyI>
Subject: Re: [dhcwg] DHCP Options for Network-Assisted Multipath TCP (MPTCP)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2015 14:34:08 -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

> -----Message d'origine-----
> De : dhcwg [mailto:dhcwg-bounces@ietf.org] De la part de Simon Hobson
> Envoyé : mardi 10 novembre 2015 10:59
> À : dhcwg@ietf.org
> Objet : Re: [dhcwg] DHCP Options for Network-Assisted Multipath TCP
> (MPTCP)
> 
> mohamed.boucadair@orange.com wrote:
> 
> > 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.
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

v2.23.0 | Report a Bug | By Email