[Mep-dev] TCP Performance Issues

[Timothy J. Salo]

I originally wrote:
>     Another approach is to use a performance-enhancing proxy
>     (PEP).  PEPs essentially break the end-to-end TCP connection
>     into several concatenated connections.

To which Phil Karn responded:
> Do ***NOT*** do this. I wish I had a nickle for every grad student 
> project I've seen that does this. It's a very bad idea. It breaks the 
> end-to-end nature of TCP, upsets how it does flow control, and violates 
> assumptions the application can ordinarily make about how TCP behaves.

Now that I think about it some more, this topic is relevant
to the MEP.  First, I will try to outline the broader
controversy and describe three contrasting views.  Then,
I will show one area where the MEP project will probably
need to, in some sense, pick sides.

The Middlebox Controversy
-------------------------

There are a variety of devices that tinker with the Internet
protocols in an effort to enhance performance or scaling.
Performance enhancing proxies (PEPs), mentioned in the original
e-mail exchange, are one.  Network Address Translators (NATs)
are another.  These types of devices, collectively called
"middleboxes" generate a range of opinions and even emotions.

One group, typified by the the Internet Engineering Task
Force (IETF), view midddleboxes as architecturally
abhorrent.  This group argues that middleboxes break the
Internet architecture.  As Phil notes, these devices can
subtly change the semantics of some fundamental Internet
protocols, they can make the deployment of new protocols
difficult, and they can make network administration more
difficult.  The IETF is pretty dogmatic about the evils
of these devices.  In fact, even as millions of NATs
were deployed, the IETF refused to do anything more than
proclaim that they were evil.  As a result, NATS generally
evolved without any guidance from the IETF.  After some
time, I finally concluded that the role of a standards
organization like the IETF is to be conservative.  A
standards organization must be very cautions making
any changes that adversely affect a large installed base,
such as the Internet.  In the case of the IETF, caution
became institutionalized as dogma.  Phil's e-mail is
consistent with this view of the world.

A second group, to which Phil refers, has a completely
different view about middleboxes.  Researchers (both
graduate students and graduated students), by their
very nature, question assumptions and try new ways of
doing things and understanding things.  Researchers have
proposed a wide variety of middleboxes to improve the
performance of the Internet protocols, particularly in
demanding environments such as wireless networks.  Some
of these approaches have serious limitations.  Some of
them subtly change the way the Internet protocols work,
as Phil pointed out.  And, some of them probably pass the
test of not changing the semantics of the Internet protocols.
I again suggest Hari's somewhat dated paper on enhancing
TCP performance in wireless environments.  Researchers, by
_their_ very nature, ought to be iconoclastic, but they don't
have to worry about adversely affecting the installed base
of the Internet.

The third group really doesn't care about all these debates,
they simply want things to work.  This group includes pretty
much everyone who administers or uses a network attached
to the Internet.  Almost every residential Internet
connection uses a NAT, IETF condemnations notwithstanding.
And, the Internet is arguably a much better place because of
it (unless you think that we should have all have been forced
to migrate to IPv6 by now).  Residential users use NATs
(almost universally) because they save money (IP addresses
generally cost money, usually beyond the first one) and they
make it easier to set up a home network.  Some large companies
use NATs because they can't easily get all the IP addresses
they need.  Few application developers understand, much less
rely upon, the subtle end-to-end semantics that some
some middleboxes break.  I understand that PEPs are used
to improve TCP performance over satellite links.  But, this
group is only concerned about making their own networks work.
Unlike the IETF, they don't have to worry about breaking someone
else's network or applications.

Middleboxes and the MEP
=======================

I start with the assumptions that the MEP ought to be a
fully functional IP network and that the MEP should be able
to connect to IP networks as well as directly to IP devices.
While I think these objectives are extremely important to
the success of the MEP and similar projects, they do cause
some complications.  Most networks to which the MEP will
connect are currently using private IP addresses.  (Most
residential networks are using private IP addresses,
typically addresses of the form 192.168.xx.yy.  The NAT
embedded in the DSL or cable "modem" or router translates
these private addresses to a single public IP address that
the Internet uses to route packets to the residence.)  The
widespread use of private IP addresses