Re: Naive question on multiple TCP/IP channels and please dont start a uS NN debate here unless you really want to.

Richard Shockey <richard@shockey.us> Fri, 06 February 2015 18:11 UTC

Return-Path: <richard@shockey.us>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61311A870C for <ietf@ietfa.amsl.com>; Fri, 6 Feb 2015 10:11:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.035
X-Spam-Level: *
X-Spam-Status: No, score=1.035 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 QOymwGiBaWAr for <ietf@ietfa.amsl.com>; Fri, 6 Feb 2015 10:11:27 -0800 (PST)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id A3F071A1A67 for <ietf@ietf.org>; Fri, 6 Feb 2015 10:11:27 -0800 (PST)
Received: (qmail 29125 invoked by uid 0); 6 Feb 2015 18:11:24 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy4.mail.unifiedlayer.com with SMTP; 6 Feb 2015 18:11:24 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id p6A91p00C1MNPNq016ACqA; Fri, 06 Feb 2015 11:10:16 -0700
X-Authority-Analysis: v=2.1 cv=J8Y5smXS c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Fm5PWBbyStgA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=0HtSIViG9nkA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=zYwl4YgTW5TfpyaPdygA:9 a=KxD8Ke8STAD-uUmi:21 a=oQapNetoPl36fGrU:21 a=wPNLvfGTeEIA:10 a=UmGHw2-3JSnxHvEHmCEA:9 a=h265M47IrvtVGtEe:21 a=rd2mONJE8uic2305:21 a=sUnj2UzeaEDlGJov:21 a=_W_S_7VecoQA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=l7EmYtU62HI4MEJKqknP5BIu02q44QrX2ALYcJYZ7hk=; b=RxVOe8QnHS7p4YhrsTTq2oiT4qShQ/tMH2QacSYPbg29UgVSwerXNRtaZOzh2shJkbLX86Hp1iKBfUosxp4OBd7sS1hKR3IU/2/TU5vgqpAwpfb89mGRDuFqDdFN/x/N;
Received: from [108.56.131.201] (port=51433 helo=[192.168.1.4]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from <richard@shockey.us>) id 1YJnM1-0006Ag-Tz; Fri, 06 Feb 2015 11:10:10 -0700
User-Agent: Microsoft-MacOutlook/14.4.7.141117
Date: Fri, 06 Feb 2015 13:10:05 -0500
Subject: Re: Naive question on multiple TCP/IP channels and please dont start a uS NN debate here unless you really want to.
From: Richard Shockey <richard@shockey.us>
To: Phillip Hallam-Baker <phill@hallambaker.com>, Jim Gettys <jg@freedesktop.org>
Message-ID: <D0FA6196.1EB9C%richard@shockey.us>
Thread-Topic: Naive question on multiple TCP/IP channels and please dont start a uS NN debate here unless you really want to.
References: <D0F962E2.1E9B2%richard@shockey.us> <CAGhGL2AAda10+YY54GJRN4Af_pGC4ZaMv=97=6aNRzqKfJBqkg@mail.gmail.com> <CAMm+Lwj4QVKQwwMvmypf6Gv8KEThbWzTFL+OR7ytjPT+RtGwRA@mail.gmail.com>
In-Reply-To: <CAMm+Lwj4QVKQwwMvmypf6Gv8KEThbWzTFL+OR7ytjPT+RtGwRA@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3506073009_689558"
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us}
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/qhf6xHWgM-U1cMG04x68oLjRqNs>
Cc: IETF Discussion Mailing List <ietf@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2015 18:11:31 -0000


So people see their Netflix or their Vonage suddenly sputter and the first
explanation that comes into their heads is 'my ISP is trying to kill them to
sell me their stuff instead'.

RS> Of course didn¹t you get the memo?   ISP's are evil. Even more evil than
the evil airlines.  :-)


We have the potential here for a really bitter dispute. Instead of picking
up the phone to complain to their ISP, people have been picking up the phone
to complain to their Senator or the guy in the White House.

RS> Potential!  Potential dispute! We¹re already there. The missiles are in
the air.! They call it Obamanet around this town.  The cynics are already
calling it the Federal Internet Commission and or the Bureau of Transit and
Peering. It just leaked that the proposed FCC Open Internet order that will
drop Feb 26 is over 332 pages long. ( That is not the record BTW)  There's
³light touch² regulation for you.

And it is going to be really difficult to explain to a lot of people who
have taken up arms on either side of this dispute that this might be the
cause of the slowdowns. One side is going to accuse us of being shills for
the corporate interests. And on the other side there are a lot of lobbyists
licking their chops at the thought of fat billable hours for as long as they
can make the fight worse.


RS> Welcome to Washington DC, Ottawa, Brussels depending.


So how do we de-escalate the situation?

One part is that we need more than a technical fix for this problem. We need
to be able to tell Joe or Jane Consumer how often these slowdowns occur and
what the cause is. The problem being that the cause of the problem might be
on the broadband provider side or the home user side of the network.

So maybe have the residential gateway collect some data and expose it to the
consumer in some fashion. This could also help debug other connection
issues. I was having unexplained network slowdowns for a month that were
eventually found to have been caused by a falling tree snapping the fiber
but not the sheath round it. So the result was a flaky connection that had
the peculiar property of working for some frequencies but not others.

Another is to point out that just as the fact that you can't print from your
computer is because you have the wrong printer port assignment rather than a
virus does not mean viruses do not exist, the fact that buffer bloat
explains some network slowdowns does not mean it explains every slowdown.
Nor does it mean that malice is never a cause.

RS>  Speaking from personal experience the easiest way to put some internet
policy wonk to sleep is say the word bufferbloat.  I've tried.  A lot of
people have been proposing this idea of more consumer control of packet
labeling at the edge or more consumer information.  I¹m deeply skeptical of
any of these ideas.  Life is simply too complicated as it is.  99.8% of
consumers just want their cat videos or House of Cards and they want them
now.  Having some White Paper on the causes of network congestion for
consumers, legislators, regulators etc is a fine idea and could be useful.
That is something IMHO ISOC could and should commission. Actually MIT SAIL
and CAIDA  have filed a number of papers with the USG on this. However the
counter argument I often point out  are smart meters in the power industry.
Sure they gather lots of interesting data but the evidence is consumers
never use it.  Historically we went through this congestion issue  in the
late 1990¹s with dial up 9600/56k modems etc.  Eventually we all worked
through it though there was a lot of pain network engineers had to endure.