Re: As if you don't have enough to read..

Miles Fidelman <mfidelman@meetinghouse.net> Fri, 13 March 2015 17:11 UTC

Return-Path: <mfidelman@meetinghouse.net>
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 726C81A9004 for <ietf@ietfa.amsl.com>; Fri, 13 Mar 2015 10:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.281
X-Spam-Level:
X-Spam-Status: No, score=-0.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, 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 CZaPjGz5gXob for <ietf@ietfa.amsl.com>; Fri, 13 Mar 2015 10:11:14 -0700 (PDT)
Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 33ACA1A8900 for <ietf@ietf.org>; Fri, 13 Mar 2015 10:11:14 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 5AB10CC0FA for <ietf@ietf.org>; Fri, 13 Mar 2015 13:11:13 -0400 (EDT)
X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net
Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WPYUllxUbj0s for <ietf@ietf.org>; Fri, 13 Mar 2015 13:11:11 -0400 (EDT)
Received: from new-host.home (pool-96-230-114-112.bstnma.fios.verizon.net [96.230.114.112]) by server1.neighborhoods.net (Postfix) with ESMTPSA id EA208CC0DD for <ietf@ietf.org>; Fri, 13 Mar 2015 13:11:10 -0400 (EDT)
Message-ID: <55031A2E.70006@meetinghouse.net>
Date: Fri, 13 Mar 2015 13:11:10 -0400
From: Miles Fidelman <mfidelman@meetinghouse.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33
MIME-Version: 1.0
CC: IETF discussion list <ietf@ietf.org>
Subject: Re: As if you don't have enough to read..
References: <D127AF15.21B5B%richard@shockey.us> <20150313130824.GM39886@verdi> <5502E96A.6010801@meetinghouse.net> <20150313141702.GN39886@verdi> <5502FB9F.8090607@meetinghouse.net> <20150313155407.GP39886@verdi>
In-Reply-To: <20150313155407.GP39886@verdi>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/9sxsJRkwB38gLqZwmPUgQTz62mA>
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, 13 Mar 2015 17:11:16 -0000

John Leslie wrote:
> Miles Fidelman <mfidelman@meetinghouse.net> wrote:
>> John Leslie wrote:
>>> Miles Fidelman <mfidelman@meetinghouse.net> wrote:
>>>> Wait a minute... isn't the Internet "capital I" defined precisely by the
>>>> collection of IP addresses that are reachable from each other?
>>> I'm not aware of any definition which says that...
>> It's kind of implicit.
>     (Isn't "kind of implicit" the opposite of "a definition"?)
>
>> It's a mutually interconnected address space.
>     No, it isn't...

I think we have to disagree on this.


>
>> Just like any telephone connected to the PSTN.
>     It's not remotely similar to a telephone connected to the PSTN.
>
>     It's connected to a network connected to another network connected
> to yet another network (et cetera), none of which have any fixed
> contractual interconnections. Paths through the network of networks
> come and go (mostly) without any human intervention or even awareness.

Have you actually looked at the internals of the PSTN, particularly 
packetized underlying infrastructure, VoIP and all that?  Any long 
distance phone call, particularly an international one, gets packetized, 
and goes through lots of different networks.

As to contractual relationships - what do you call backbone peering?

The analogy is very direct.

>
>>>> (Yes, NAT confuses things a bit - but arguably it's the public address
>>>> of a NAT device that's the "Internet endpoint").
>>> That is a reasonable interpretation. But, I must disagree that there
>>> is any generally-accepted definition of the term "Internet endpoint".
>> I've certainly seen the term used interchangeably with IP address in
>> multiple contexts - mostly around DDoS attack on a particular "internet
>> endpoint" or another, and I seem to recall a draft MIB for "internet
>> endpoints" that essentially treated the term interchangeably with IP
>> addresses,
>     Can you give an example?

Google is your friend:
https://tools.ietf.org/html/draft-ops-endpoint-mib-00
and no less than Doug Comer uses the term in his classic 
"Internetworking w/ TCP/IP"
https://books.google.com/books?id=yhwfAQAAIAAJ&q=%22internet+endpoint%22+%22IP+address%22&dq=%22internet+endpoint%22+%22IP+address%22&hl=en&sa=X&ei=OhgDVaarH4qlNoKggfAH&ved=0CDUQ6AEwAQ
(though he uses it in the context of a specific socket)

>
>> or a physical port with an IP address. If NOT an IP address, is there
>> really any other viable interpretation?
>     "Internet endpoint" generally refers to a node with an interface
> connected to one of the networks of "the Internet". "IP address" is
> a transitory characteristic of the interface. These concepts seem
> different to me...
>
>> (And yes, it would be nice if the FCC order defined its terms
>     It's not a question of "nice" -- the FCC _must_ define its terms.
> Judges are not permitted to guess.

Hah.

>
>> - though at one point the order says this "?Fixed? broadband Internet
>>    access service refers to a broadband Internet access service that
>>    serves end users primarily at fixed endpoints using stationary
>>    equipment, such as the modem that connects an end user?s home router,
>>    computer, or other Internet access device to the network).
>     Yeah, they screwed that definition up, too...
>
>>> Please understand what ISPs actually do:
>>>
>>> 1. We receive packets and _try_ to route them to another node which we
>>>     have reason to be "closer" to the destination address;
>>>
>>> 2. We advertise our "closeness" to particular ranges of IP addresses.
>>>
>>> That's it, folks. Whatever else we do in support of these cannot
>>> change the fact that we cannot deliver packets "to" most IP addresses;
>>> and we cannot even know whether a packet we may deliver to a customer
>>> is actually "from" a particular IP address (least of all whether it
>>> is in response to a packet our customer asked us to forward).
>>>
>>> It's all "best effort" -- which means we make no representation
>>> whether any packet will reach the nominal destination.
>> One expects a bit more than that.
>     Regardless of "expects", that's what we do.
>   
>> One expects an ISP to actually have connectivity,
>     I suppose, but "connectivity" typically coveres multiple paths with
> differing characteristics.
>
>> peering agreements,
>     Not all ISPs do "peering agreements" -- though probably most if not
> all of the ISPs the FCC seems to intend to regulate under Title II
> probably do. In any case, peering agreements are mostly secret, and
> ISPs have good and valid reasons to keep them that way.
>
>> and routing tables
>     Yes, we all have routing tables.
>
>> set up that let a customer exchange packets with addresses across
>> the Internet as a whole.
>     No, we don't. Routing tables are one-way things: where do we forward
> a packet hoping the node we forward to is closer? The routing tables
> that affect a return packet contain wildly different data.
>
>> At least, I've never come across an ISP that advertises connectivity
>> only to a limited set of ASNs,
>     That's a meaningless concept: no ISP has control over what happens
> to a packet after it is forwarded to a different autonomous system.
>
>> or a limited set of IP addresses
>     Again, no ISP can control what happens to a packet after it is
> forwarded. ISPs _do_ filter traffic to particular IP ranges, but not
> because they advertise that, rather to mitigate denial-of-service or
> possibly inhibit spammers.
>
>> (well, there are enterprise networks and VPNs, but those are not
>> generally viewed as ISPs).
>> And things are generally considered broken when a polluted routing
>> table leads some part of the net to become unreachable.
>     When such "brokenness" persists, most ISPs will "route around it."
>
>> And it's generally considered a "bad thing" that governments, like
>> the Chinese, put up big firewalls that block traffic to large chunks
>> of the net.
>     Obviously, that is beyond the control of ISPs -- but it's really
> a tiny slice of what is beyond their control...
>
>> The same argument applies to phone service.  I may get my local phone
>> service from Verizon, but I expect to be able to place a call to any
>> phone, anywhere in the world, that's connected to the PSTN. Verizon is
>> providing the "capability" to dial and reach all those numbers, but it's
>> not providing the end-to-end connectivity.  If they started saying "you
>> can't call numbers in Cincinatti, or Italy" I think we'd all agree that
>> something was wrong.
>     No comment -- different topic entirely.

Disagree completely.  Package delivery is not phone service, but they 
are both common carriers; and now so are ISPs.  Not a different topic at 
all.


>
> ====
>     I understand you _want_ Internet Service to fit the FCC definition.
> But wishing doesn't make it so. The FCC definition here calls for things
> that ISPs are completely unable to do.
>
>

By your reading.  Not by mine.

Miles Fidelman






-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra