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

David Morris <dwm@xpasc.com> Sat, 07 February 2015 03:38 UTC

Return-Path: <dwm@xpasc.com>
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 37C3A1A040B for <ietf@ietfa.amsl.com>; Fri, 6 Feb 2015 19:38:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.997
X-Spam-Level:
X-Spam-Status: No, score=0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, IP_NOT_FRIENDLY=0.334, MISSING_HEADERS=1.021, 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 4yFAWrhT4Dv5 for <ietf@ietfa.amsl.com>; Fri, 6 Feb 2015 19:38:11 -0800 (PST)
Received: from c2w3p-2.abacamail.com (c2w3p-2.abacamail.com [67.231.154.153]) by ietfa.amsl.com (Postfix) with ESMTP id 6B12A1A0390 for <ietf@ietf.org>; Fri, 6 Feb 2015 19:38:11 -0800 (PST)
Received: from xpasc.com (h-68-164-244-186.snva.ca.megapath.net [68.164.244.186]) by c2w3p-2.abacamail.com (Postfix) with ESMTP id C94A240521 for <ietf@ietf.org>; Sat, 7 Feb 2015 03:38:04 +0000 (UTC)
Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.13.8/8.13.8) with ESMTP id t16JZMmH001112 for <ietf@ietf.org>; Fri, 6 Feb 2015 11:35:22 -0800
Date: Fri, 6 Feb 2015 11:35:22 -0800 (PST)
From: David Morris <dwm@xpasc.com>
cc: IETF Discussion Mailing List <ietf@ietf.org>
Subject: Re: Naive question on multiple TCP/IP channels and please dont start a uS NN debate here unless you really want to.
In-Reply-To: <CAMm+Lwj4QVKQwwMvmypf6Gv8KEThbWzTFL+OR7ytjPT+RtGwRA@mail.gmail.com>
Message-ID: <alpine.LRH.2.01.1502061116080.4284@egate.xpasc.com>
References: <D0F962E2.1E9B2%richard@shockey.us> <CAGhGL2AAda10+YY54GJRN4Af_pGC4ZaMv=97=6aNRzqKfJBqkg@mail.gmail.com> <CAMm+Lwj4QVKQwwMvmypf6Gv8KEThbWzTFL+OR7ytjPT+RtGwRA@mail.gmail.com>
User-Agent: Alpine 2.01 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="17445122-1182535264-1423251322=:4284"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/d8d0PvVcLP9F1sYLKyLElXE7r08>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: ietf@ietf.org
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: Sat, 07 Feb 2015 03:38:12 -0000


On Fri, 6 Feb 2015, Phillip Hallam-Baker wrote:

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

Not a technical fix, but information gathering would help. I run a small
network behind an SDSL connection. A while ago I noticed a performance
issue with my internet connection. When I called the ISP, they came back
and said my link was saturated with traffic.

It would have been really helpful if they'd given me a simple
characterization of the traffic in terms of protocol. I had to gerrymander
the ability to trace the subnet between my SDSL modem and my firewall.
Learned it was the NTP error attack. Configured the firewall to block
unsolicited inbound NTP traffic or perhaps NTP traffic unrelated to the
servers I use.

There was a technical solution to this problem, but my point here is to
illustrate the difficulty of getting data to diagnose the problem.

Every home/small office router/modem should be able to provide
utilization information over time as raw load, by protocol, and ideally,
by inside IP generating the load. Every ISP should be able to provide
something similar on demand.

Having the ability for the ISP to configure traffic filters at their end
to block last mile traffic for common threats. The end customer needs
to control what is filtered. Most small networks don't run HTTP or SMTP
servers as an example. Even fewer run NTP servers.

Dave Morris