[Ecommerce] Jay Sulzberger's Tutorial for the FTC

Fri Mar 16 11:55:19 2007

(Jay Sulzberger's submitted tutorial carries the FTC through some
illuminating commentary and richly rewards an attentive reading.  As
he defines and illustrates the Internet and net neutrality for the
FTC's "Broadband Connectivity" workshop, he presents a lesson in
ports, nmap, http daemons and browsers, mail transport agents, ssh,
qotd, tinyP2P, and mentions a myriad of applications and protocols,
inserting along the way the entire RFC for the qotd protocol and
attaching the full IANA port numbers document [thereby extending his
submission to 280 pages].  Note that for the following text extract I
did not spend time formatting the various listings embedded within his
presentation.  -- Seth)

> http://www.ftc.gov/os/comments/broadbandwrkshop/527031-00056.htm
> http://www.ftc.gov/os/comments/broadbandwrkshop/527031-00056.pdf

Comment in response to the FTC's workshop on "Broadband Connectivity
Competition Policy":
> http://www.ftc.gov/opp/workshops/broadband/index.html

Comments on the definition of the Internet and the importance of
distinguishing the Net from cable TV, and from lower level signal
transport systems, after the FTC Workshop of 13 and 14 February 2007
on Network Neutrality

I am Jay Sulzberger. I am a working member of New Yorkers for Fair
Use, and I attended the 13-14 February 2007 FTC Workshop on Network
Neutrality. This comment is not an official statement of New Yorkers
for Fair Use.

The full name of the FTC workshop on 13 and 14 February 2007 included
the phrase "broadband competition". At the workshop, most of the
discussions failed to address the real issue of Network Neutrality
because no correct definition of the Net was presented.

Internet packets may be carried over slow communications links or over
fast links. Most week days I use several different connections to the
Net. Some days I use a dialup connection, which is much slower than
the connection over lines owned by the Cable Company, or by the City
of New York. But no matter whether I use slow lines or fast lines, I
use the Net for private, for tribal, for business, and for public
communications. And I use the Net in freedom. And some days I watch
cable TV.

Now cable TV is not the Internet, but most speakers at the FTC's
workshop spoke of the Net in ways that treated it as if it were just a
form of interactive TV, with some extra special services bundled with
interactive TV, "web viewing", email, and doubtfully, voice over IP.

Questions around building another, perhaps several other, cable TV
networks, are not part of the issue of Network Neutrality, because the
Net is not TV of any kind.

Use of the word "broadband" to mean both the Net and cable TV helps
perpetuate the fundamental confusion.

We now state explicitly the main implicit error which underlies the
FTC's present failure to engage with the issue of Network Neutrality:

Main Implicit Error: The Internet is not some bundle of services
delivered by the Telephone Company and/or the Cable Company.

The Net is difficult to understand unless you work with it
productively to develop applications and therefore already know what
it is; and in that case, it is still difficult to convey what the Net
is, because some history and background information, is needed to
grasp how different the Net is from cable TV.

I admit that many people who today visit web sites and do email do not
clearly understand what the Net is. But certainly the FTC should
clearly understand what the Net is.

When ranting on the topic of the Net in years past, I have often
claimed that one can explain the Net without knowing anything of
matters denominated in the popular press as "technical". After the
workshop, I now think that complete ignorance can impede understanding
of the Net. One speaker at the workshop who spoke against Net
Neutrality had never heard of a port. It is likely that part of his,
and others, opposition to Net Neutrality is due to simple ignorance.

We distinguish several faces of the Net.

First let us define what the Net is for a user of the Net. This face
of the Net is simple to explain. But the explanation may, at first,
be hard to understand, not because of subtleties, but rather just the
opposite, because of the simplicity and the extremity of the defining
principles.

If you do not know what a port is, then likely you implicitly assume
that the Duopoly invented the Net and gave us the World Wide Web,
email, videos over the Net, massive virtual worlds/games, etc.. So,
what is a port? For a good introduction to ports, see

http://en.wikipedia.org/wiki/TCP_and_UDP_port
http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

Consider me sitting in front of my computer. My computer is connected
to the Net. My computer has an Internet address, say 192.0.34.166.
Every computer connected to the Net has such an address. (For now,
the question of how long the hardware keeps the same address, and who
decides the address, how other computers figure out the address,
etc. are all irrelevant.)

Important point: We assume in this explanation that I am in full
control of my computer.

Now I issue, as root, this command to my computer

 nmap -sT -O localhost

and I get back:

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2007-02-26
19:25 EST
Interesting ports on localhost.localdomain (127.0.0.1):
 Not shown: 1656 closed ports
 PORT STATE SERVICE
 1/tcp open tcpmux
 11/tcp open systat
 15/tcp open netstat
 25/tcp open smtp
 79/tcp open finger
 111/tcp open rpcbind
 119/tcp open nntp
 143/tcp open imap
 540/tcp open uucp
 635/tcp open unknown
 993/tcp open imaps
 1080/tcp open socks
 1524/tcp open ingreslock
 2000/tcp open callbook
 6667/tcp open irc
 12345/tcp open NetBus
 12346/tcp open NetBus
 27665/tcp open Trinoo_Master
 31337/tcp open Elite
 32771/tcp open sometimes-rpc5
 32772/tcp open sometimes-rpc7
 32773/tcp open sometimes-rpc9
 32774/tcp open sometimes-rpc11
 54320/tcp open bo2k
 Device type: general purpose
 Running: Linux 2.4.X|2.5.X|2.6.X
 OS details: Linux 2.5.25 - 2.6.8 or Gentoo 1.2 Linux 2.4.19 rc1-rc7,
Linux
2.6.3 - 2.6.10
 Uptime 8.412 days (since Sun Feb 18 09:32:55 2007)

Nmap finished: 1 IP address (1 host up) scanned in 2.184 seconds

Ports, in the jargon of Internet engineers, are entrances and/or exits
of my computer. They are entrances/exits for data. nmap is a program
which knocks on every port of the specified computer. The knocks are
delivered over the Net, that is, nmap is an Internet application. I
specified in my command that nmap knock on the ports of my computer,
here called "localhost". (Irrelevant detail: from the vantage of my
computer itself, my computer has by convention, sometimes, the
Internet address 127.0.0.1.) nmap reports back which ports are open
to incoming connections, that is, which ports will accept data coming
in. nmap may be used to knock on the ports of any computer on the
Net, even though in this example, I instructed nmap to only check my
own computer.

The three columns of the first part of the data returned by nmap are:

1. the port, given by a number and what sort of data packets the port
sends/receives

2. the state of the port

3. what service the people who built and run the Net have agreed
should usually be listening at the port

The next part of the information returned by nmap, that is,

 Device type: general purpose
 Running: Linux 2.4.X|2.5.X|2.6.X
 OS details: Linux 2.5.25 - 2.6.8 or Gentoo 1.2 Linux 2.4.19 rc1-rc7,
Linux
2.6.3 - 2.6.10
 Uptime 8.412 days (since Sun Feb 18 09:32:55 2007)

is nmap's guess as to what sort of computer system nmap knocked on.
The guess is that my computer is a general purpose computer running
some version of the GNU/Linux operating system, and that it has been
up "8.412 days". (The uptime is not correct. nmap is not infallible.)
Finally nmap tells what it did:

 Nmap finished: 1 IP address (1 host up) scanned in 2.184 seconds

The information returned by nmap helps to show us what the Net is. My
machine is connected to the Net. My machine has an address which
allows other machines on the Net to send data to my machine in order,
perhaps, to start two streams of data flowing between the two
machines. Suppose that you also have before you a computer connected
to the Net. Again, we assume that you have full control of your box.

We now present a well known, popular, and paradigmatic, use of the
Internet:

You might have opened port 80 on your box, and placed a program called
an "http daemon", say Apache, to listen for incoming requests on port
80. I might start a Web browser, say Firefox, on my machine and tell
my browser to ask for a web page on your machine. Firefox would now
knock on port 80 on your machine, and request the page.

This is the mechanism by which web pages are delivered. Between your
machine and mine lies the Net. Today, within the Net, there is no
third party wiretapping our communication. There is no third party
attempting to determine the value of our conversation to us, in order
to charge us extra for valuable conversations. There is no third
party examining our conversation in order to silence us if we say
things the wiretapper's boss finds unpleasant.

I should have said "In the best circumstances, there is no ..."
because, if your machine were in the United States, and mine in China,
and if our conversation were to include mention of movements not
favored by the government of China, then China might act to stop our
conversation. And if your machine were in the United States and your
"Internet Service Provider" refused to pass that first packet to port
80 on your machine, then our conversation could not even get started.
The policy of refusing that first packet to port 80 is often called
the "no servers allowed" rule. Both interferences result in something
that is not the full and true Internet.

Let us list two other uses of the Net:

1. You might want to send me some email. By convention, usually port
25 is used for email. If I choose to get email by the usual means, I
must open port 25, and place a "mail transport agent", say exim,
listening on the port. But we both might want to send email back and
forth by other means. In that case, you and I might have agreed
before hand to use another port, or set of ports, and we might have
agreed on some other protocol for delivery of email. We are free to
make our own arrangements, without asking permission of any third
party.

2. Assume you are a master sysadmin and an old friend. I might be
having trouble with my computer, and I might ask you, by telephone
say, to come into my box and have a look around in order to help me.
We might have agreed that you would come in via "secure shell", that
is, ssh. By convention, the usual port for ssh is port 22, and when I
have opened up port 22, and set the ssh daemon listening, and granted
you certain privileges on my system, you may run ssh on your box, ssh
will open a connection to my box and you may now log in to my box.
But we might, for some reason, choose not to use ssh and port 22. In
that case, you and I might have agreed before hand to use another
port, or set of ports, and we might have agreed on some other protocol
by which you can log into my machine. We are free to make our own
arrangements, without asking permission of any third party.

Here is the definition of the Internet. The definition comes in three
parts.

1. My machine and yours stand equal as peers, in the sense that my or
your machine can initiate, or attempt to initiate a conversation,
without interference by third parties. And my machine or yours can
accept such an invitation to converse, without interference by third
parties. Naturally if your machine attempts to make a connection and
my machine refuses, this is still the Net. But, up to bugs,
communication occurs, or fails, by agreement, or disagreement, between
you and me, as long as we have paid our ISPs.

2. If you and I agree on a protocol, and agree on a port, or ports,
for our data streams to travel over, and we write, or otherwise
obtain, two programs that use the protocol, we may set our programs
running on our boxes, and we may communicate using the protocol we
have together freely chosen, without interference by third parties.
In particular, we are free to invent new protocols, and to write
programs using the new protocols, and to set these programs running
over the Net.

3. About one billion machines are connected and use the freely agreed
on protocols that enable our conversations to be transported by the
wires, fibers, through the routers, over the air, via satellites,
carrier pigeons. And it all works because many people and companies
and governments have built the pieces and connected them so that it
does work to make possible the extraordinarily flexible and free
communication specified in 1 and 2. The main underlying protocol of
the Net is TCP/IP. Note that there are other networks which use the
TCP/IP protocol, but are not the Net, because they do not allow on the
order of one billion people to freely connect with each other with
complete flexibility in their manner of communication, that is, in the
protocols running atop TCP/IP. For example, various variants of
cable TV may be delivered using the TCP/IP protocol. But such a cable
TV network is not part of the Net.

Now we come face to face with the Main Error. If the Net were some
bundle of services provided by the Duopoly, and perhaps, in future, by
some other companies, then none of these defining conditions of the
Net could be met. In order to be brief, we shall only explain why
condition 2 would fail, if the Duopoly ran the Net:

ad 2. If the Duopoly provided the Net, then surely you and I could not
design and deploy and use a new protocol without either working for
the Duopoly, or negotiating with the Duopoly some arrangement by which
the Duopoly would support the protocol. But this is exactly not how
the Net was built. We adduce here a wonderful document, called the
"port numbers", which may be found at the website of the IANA, the
Internet Assigned Numbers Authority:

http://www.iana.org/assignments/port-numbers

We append one version of this list, it is on occasion updated, as
Document IANA-port-numbers below.

Let us look at some lines from the list of ports:

Keyword Decimal Description References
------- ------- ----------- ----------
0/tcp Reserved
0/udp Reserved
# Jon Postel <postel@isi.edu>
tcpmux 1/tcp TCP Port Service Multiplexer
tcpmux 1/udp TCP Port Service Multiplexer
# Mark Lottor <MKL@nisc.sri.com>
compressnet 2/tcp Management Utility
compressnet 2/udp Management Utility
compressnet 3/tcp Compression Process
compressnet 3/udp Compression Process
# Bernie Volz <volz@cisco.com>
# 4/tcp Unassigned
# 4/udp Unassigned
rje 5/tcp Remote Job Entry
rje 5/udp Remote Job Entry
# Jon Postel <postel@isi.edu>
# 6/tcp Unassigned
# 6/udp Unassigned
echo 7/tcp Echo
echo 7/udp Echo
# Jon Postel <postel@isi.edu>
# 8/tcp Unassigned
# 8/udp Unassigned
discard 9/tcp Discard
discard 9/udp Discard
# Jon Postel <postel@isi.edu>
discard 9/dccp Discard SC:DISC
# IETF dccp WG, Eddie Kohler <kohler@cs.ucla.edu>,
[RFC4340]
# 10/tcp Unassigned
# 10/udp Unassigned
systat 11/tcp Active Users
systat 11/udp Active Users
# Jon Postel <postel@isi.edu>
# 12/tcp Unassigned
# 12/udp Unassigned
daytime 13/tcp Daytime (RFC 867)
daytime 13/udp Daytime (RFC 867)
# Jon Postel <postel@isi.edu>
# 14/tcp Unassigned
# 14/udp Unassigned
# 15/tcp Unassigned [was netstat]
# 15/udp Unassigned
# 16/tcp Unassigned
# 16/udp Unassigned
qotd 17/tcp Quote of the Day
qotd 17/udp Quote of the Day
# Jon Postel <postel@isi.edu>
msp 18/tcp Message Send Protocol
msp 18/udp Message Send Protocol
# Rina Nethaniel <---none--->
chargen 19/tcp Character Generator
chargen 19/udp Character Generator
ftp-data 20/tcp File Transfer [Default Data]
ftp-data 20/udp File Transfer [Default Data]
ftp 21/tcp File Transfer [Control]
ftp 21/udp File Transfer [Control]
# Jon Postel <postel@isi.edu>
ssh 22/tcp SSH Remote Login Protocol
ssh 22/udp SSH Remote Login Protocol
# Tatu Ylonen <ylo@cs.hut.fi>
telnet 23/tcp Telnet
telnet 23/udp Telnet
# Jon Postel <postel@isi.edu>
24/tcp any private mail system
24/udp any private mail system
# Rick Adams <rick@UUNET.UU.NET>
smtp 25/tcp Simple Mail Transfer
smtp 25/udp Simple Mail Transfer
# Jon Postel <postel@isi.edu>
# 26/tcp Unassigned
# 26/udp Unassigned
nsw-fe 27/tcp NSW User System FE
nsw-fe 27/udp NSW User System FE
# Robert Thomas <BThomas@F.BBN.COM>
# 28/tcp Unassigned
# 28/udp Unassigned
msg-icp 29/tcp MSG ICP
msg-icp 29/udp MSG ICP
# Robert Thomas <BThomas@F.BBN.COM>
# 30/tcp Unassigned
# 30/udp Unassigned
msg-auth 31/tcp MSG Authentication
msg-auth 31/udp MSG Authentication
# Robert Thomas <BThomas@F.BBN.COM>
# 32/tcp Unassigned
# 32/udp Unassigned
dsp 33/tcp Display Support Protocol
dsp 33/udp Display Support Protocol
# Ed Cain <cain@edn-unix.dca.mil>
# 34/tcp Unassigned
# 34/udp Unassigned
35/tcp any private printer server
35/udp any private printer server
# Jon Postel <postel@isi.edu>
# 36/tcp Unassigned
# 36/udp Unassigned
time 37/tcp Time
time 37/udp Time
# Jon Postel <postel@isi.edu>
rap 38/tcp Route Access Protocol
rap 38/udp Route Access Protocol
# Robert Ullmann <ariel@world.std.com>
rlp 39/tcp Resource Location Protocol
rlp 39/udp Resource Location Protocol
# Mike Accetta <MIKE.ACCETTA@CMU-CS-A.EDU>
# 40/tcp Unassigned
# 40/udp Unassigned
graphics 41/tcp Graphics
graphics 41/udp Graphics
name 42/tcp Host Name Server
name 42/udp Host Name Server
nameserver 42/tcp Host Name Server
nameserver 42/udp Host Name Server
nicname 43/tcp Who Is
nicname 43/udp Who Is
mpm-flags 44/tcp MPM FLAGS Protocol
mpm-flags 44/udp MPM FLAGS Protocol
mpm 45/tcp Message Processing Module [recv]
mpm 45/udp Message Processing Module [recv]
mpm-snd 46/tcp MPM [default send]
mpm-snd 46/udp MPM [default send]
# Jon Postel <postel@isi.edu>
ni-ftp 47/tcp NI FTP
ni-ftp 47/udp NI FTP
# Steve Kille <S.Kille@isode.com>
auditd 48/tcp Digital Audit Daemon
auditd 48/udp Digital Audit Daemon
# Larry Scott <scott@zk3.dec.com>
tacacs 49/tcp Login Host Protocol (TACACS)

The point here: None of the standard Net services listed above are
services provided by the Duopoly to telephone customers or cable TV
customers. If you look at the whole list below, we believe you will
agree that these services are not offered by either the Telephone
Company nor by the Cable Company.

Example of a Net service: Consider port 17/tcp. The people who built,
and today, build and run the Net, have freely agreed, without
coercion, without payments, without contracts, to use port 17/tcp for
the Net application called qotd, which means "quote of the day". For
information about qotd see

http://en.wikipedia.org/wiki/QOTD

qotd is a very simple protocol/Net application. Here is an example of
its use. I issue the command

 telnet ota.iambic.com 17

and I get back

 Trying 64.124.71.12...
 Connected to ota.iambic.com.
 Escape character is '^]'.
 A good leader is a person who takes a little more than his share of
the blame
and a little less than his share of the credit | John C. Maxwell
 Connection closed by foreign host.

Again I issue the command:

 telnet ota.iambic.com 17

This time I get back:

 Trying 64.124.71.12...
 Connected to ota.iambic.com.
 Escape character is '^]'.
 If you have a procedure with 10 parameters, you probably missed some.
| Alan J.
Perlis
 Connection closed by foreign host.

So we see that, likely, on port 17/tcp of the machine with Internet
address 64.124.71.12, there is a qotd daemon running, which, in
accordance with protocol, when we ask it, hands us a random quote of
the day.

Now we adduce another document, the RFC for qotd. An Internet RFC, or
request for comment, is a document which describes a protocol (or
another useful standard thing) for use on the Net. The RFC for quote
of the day has number 865, and may be found at

http://tools.ietf.org/html/rfc865

RFC 865 is short, as RFCs go. Here is the whole document:

Network Working Group J. Postel
Request for Comments: 865 ISI
May 1983

Quote of the Day Protocol

This RFC specifies a standard for the ARPA Internet community. Hosts
on
the ARPA Internet that choose to implement a Quote of the Day Protocol
are expected to adopt and implement this standard.

A useful debugging and measurement tool is a quote of the day service.
A quote of the day service simply sends a short message without regard
to the input.

TCP Based Character Generator Service

   One quote of the day service is defined as a connection based
   application on TCP. A server listens for TCP connections on TCP
port
   17. Once a connection is established a short message is sent out
the
   connection (and any data received is thrown away). The service
   closes the connection after sending the quote.

UDP Based Character Generator Service

   Another quote of the day service is defined as a datagram based
   application on UDP. A server listens for UDP datagrams on UDP port
   17. When a datagram is received, an answering datagram is sent
   containing a quote (the data in the received datagram is ignored).

Quote Syntax

   There is no specific syntax for the quote. It is recommended that
it
   be limited to the ASCII printing characters, space, carriage
return,
   and line feed. The quote may be just one or up to several lines,
but
   it should be less than 512 characters.

Postel [Page 1]

The Internet Engineering Task Force, or, in this case, perhaps a
predecessor body, met and agreed that there was good reason to have
such a standard protocol, and so this RFC was adopted. The working
group that dealt with this RFC did not have to negotiate with the
Duopoly a place for this protocol. Nor did the Duopoly have to
consider pricing for delivery of qotd packet streams, nor whether, nor
how, to introduce this new service to its customers, nor what
regulatory bodies would have to approve the introduction of this new
service, nor how this protocol should be dealt with by the Duopoly's
hardware and software, etc.. None of these burdens attended the birth
of the quote of the day protocol. None of these burdens today weigh
down the deployment of the qotd service, none of these burdens weighed
me down when I used the service a few minutes ago, and none of these
burdens bore upon the owner of ota.iambic.com, when the owner started
his qotd daemon running.

We shall not discuss how RFCs are created. Except to remark the
central fact that the Duopoly has no direct business interest in the
writing, nor adoption of any RFC. But if the Main Error were not an
error, but a truth, then of course, the Duopoly would set its own
standards, and create its own services, in the interest of, at least
according to a now popular religious sect, stockholders in the
Duopoly. But, of course, that is not how the Net was built. Rather
the builders of the Net bought delivery of data, no better, signal, at
the best price they could get, and they built the Net on top of the
delivery of signal. There are over 5000 adopted RFCs, all hacked out
without oversight of the Duopoly and without oversight of the FTC, nor
of the FCC. We who think the Net we have is worth keeping, think that
the radical freedom of association, with near zero external imposed
frictions, is worth defending, because this is how we built the Net.

Again, we note at this point that the Duopoly never invented anything
like the Net. But, under the rules of common carriage, and under
contractual obligations to deliver signal, the Net was built, in
freedom, atop the signal carriers' faithful carriage of signal.

Those who are for Network Neutrality are not for regulation of the
Net. We are for freedom of the Net. Without freedom to design, and
freely use, new services and protocols and applications, there is no
Net. This same freedom makes possible the setting of standards, that
is, agreement on RFCs and adoption of RFCs.

We mention here a few of the applications/services/protocols which run
on the Net: email, the World Wide Web, various voips, various vpns,
ssh, usenet, rsync, cvs, apt-get, BitTorrent, ntp, ostiary, etc.. The
IANA list of ports shows just how many services have been invented
and, in measure, widely adopted. Of course, one also has services and
protocols which are unlikely ever to be widely adopted. For example,
Ed Felten and Alex Halderman's TinyP2P, which may be found at

http://www.freedom-to-tinker.com/tinyp2p.html

was written to demonstrate how easy it is to write a "P2P file
sharing" program. The program is less than one page of Python. This
program demonstrates something larger and more important: it shows us
the freedom and power of the Net. The program works, and perhaps some
folks are using it today. But clearly the Duopoly is not today
offering "Felten-Halderman TinyP2P" service. Nor does the Duopoly
today have the practical means, nor the legal right, to suppress

a. the writing of the program

b. distribution of the program

c. installation of the program

d. use of the program

Well, my claim as to lack of legal right, is unfortunately, not
entirely right today. If the Duopoly is providing signal transport at
high speed for delivery of Net packet streams, then indeed the Duopoly
might today have the legal power to suppress use of the program, due
to the FCC's denomination of certain higher speed signal transports as
"information services". Signal transport is not an "information
service".

Recommendation: Before considering any action on Network Neutrality
the FTC should hold another workshop to help the FTC grasp what the
Net is today. Necessarily this workshop will require some examination
of the history of the Net. The Internet Society should be invited to
partcipate at this workshop, and some designers of the Net we have
today should be invited to speak.