Re: [v6ops] draft-pauly-v6ops-happy-eyeballs-update-01

Philip Homburg <pch-v6ops-7@u-1.phicoh.com> Thu, 30 March 2017 12:11 UTC

Return-Path: <pch-bF054DD66@u-1.phicoh.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BBC1294BD for <v6ops@ietfa.amsl.com>; Thu, 30 Mar 2017 05:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 yaIOvEqQWRXQ for <v6ops@ietfa.amsl.com>; Thu, 30 Mar 2017 05:11:30 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2CC129489 for <v6ops@ietf.org>; Thu, 30 Mar 2017 05:11:30 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1ctYvJ-0000GSC; Thu, 30 Mar 2017 14:11:29 +0200
Message-Id: <m1ctYvJ-0000GSC@stereo.hq.phicoh.net>
To: v6ops@ietf.org
From: Philip Homburg <pch-v6ops-7@u-1.phicoh.com>
Sender: pch-bF054DD66@u-1.phicoh.com
References: <CAD6AjGSxKftRXGfJ67rYN6Ccr961HMuU69Y=SSwnemvmsqddNQ@mail.gmail.com> <34A0BBC1-E9C9-4856-BBB5-F6A2B9F4C72F@consulintel.es> <alpine.DEB.2.02.1703300845190.30226@uplift.swm.pp.se> <m1ctWOM-0000IOC@stereo.hq.phicoh.net> <alpine.DEB.2.02.1703301211140.30226@uplift.swm.pp.se>
In-reply-to: Your message of "Thu, 30 Mar 2017 12:14:58 +0200 (CEST) ." <alpine.DEB.2.02.1703301211140.30226@uplift.swm.pp.se>
Date: Thu, 30 Mar 2017 14:11:29 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/gsiJxikPlSA5TSPgIvFu2o7yyLw>
Subject: Re: [v6ops] draft-pauly-v6ops-happy-eyeballs-update-01
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 12:11:32 -0000

>On Thu, 30 Mar 2017, Philip Homburg wrote:
>
>> It is hard to quantify, but in IPv4 lots of potential PMTU problems are 
>> masked by MSS clamping.
>
>Yes. I don't have data, but I have commonly talked to people in the 
>business who are of the opinion that MSS clamping solves "all" problems.
>
>When I point out that there are other protocols I typically get back that 
>MSS clamping is good enough and solved all their customer complaints.

It's sad how little some people know about internet protocols. 

>While I don't really like the approach, I think the pragmatic thing to do 
>is to have the devices themselves have the ability to do PMTUD clamping if 
>they have lots of problems that can be attributed to PMTUD, and then have 
>this reported by means of diagnostics report to application/device vendor.

The 'nice' thing about doing MSS clamping in a CPE is that the CPE knows 
what it is using to connect to the internet. 

A host would have to probe every time it connects to a network for local
PMTU limitations. I wonder what the operational impact would be if every
host would start sending maximum sized packets to some well known destination
right after connecting to the network.