[e2e] Is a non-TCP solution dead?

Tue Apr 1 09:14:18 PST 2003

I suggest people read:

S. Shenker, "Making Greed Work in Networks: A Game-Theoretic Analysis of
Switch Service Disciplines," in SIGCOMM Symposium on Communications
Architectures and Protocols, (London, UK), pp. 47-57, Sept. 1994.

> -----Original Message-----
> From: Cannara [mailto:cannara at attglobal.net]
> Sent: Tuesday, April 01, 2003 8:48 AM
> To: end2end-interest at postel.org
> 
> Hans, yes.  The only reason TCP was chosen to kludge in flow control
(that
> was
> not soley for ends) was the lacking of a true "network" concept in IP.
IP
> was
> designed without concern for link/path management.  It was designed to
run
> over some unknown substrate, which was, and is still, the synchronous,
> carefully managed telco system.  Everything underneath IP now, even
some
> wireless, provides flow management -- just check out the chips offered
by
> all
> the telco-system vendors (AMCC, Vitesse...).  You can buy a device
today
> to
> put on a board you're designing for a SONET application that will
manage
> >200,000 flows.  You can buy a chip + RAM to process millions of
pkts/sec
> in a huge number of prioritized, shaped flows.
> 
> The reason for bringing this up is to try to re-awaken us to the
archaic
> designs TCP/IP represent -- a heritage based in modem-to-host
character-
> mode
> communications.  IP has been inadequate for modern needs in several
> respects
> for many years.  TCP has as well, and was unfortunately used to kludge
in
> some
> IP-saving flow control.  We all understand the old saw about "what a
> tangled
> web we weave...".  Now it's harder, but no less necessary to do
something
> for
> the future.
> 
> Alex
> 
> Hans Kruse wrote:
> >
> > An interesting and quite central point -- not just to this debate.
You
> are
> > of course correct; if the network is designed to provide flow
control
> then
> > the transport should/need not do so.  I suppose a good example of
that
> > would be Frame Relay.
> >
> > However, IP by design does not provide these services.  Are you
saying
> we
> > should add them in the network layer for the Internet?
> >
> > --On Monday, March 31, 2003 18:49 -0800 Cannara
<cannara at attglobal.net>
> > wrote:
> >
> > > Hans,
> > >
> > > Your 2nd paragraph points up precisely a criticism of TCP -- it
has
> > > become a kludge ever since congestion management was added to
prevent
> > > flows that "...can damage the network as a whole, if these flows
> traverse
> > > the internet".  The purpose of a transport is end-to-end, not to
> manage
> > > flow control for the middle.
> > >
> > > Alex
> > >
> > > Hans Kruse wrote:
> > >>
> > >> Well, there are really two different possible implementations
here,
> and
> > >> it is not clear which one you are talking about.
> > >>
> > >> (1) If your mobile device is constrained to use "proxy" services
run
> by
> > >> the wireless provider to indirectly get information from the
> internet,
> > >> you have a lot of non-TCP choices for getting data from the proxy
to
> the
> > >> mobile, since that flow is internal to the providers network.
Some
> > >> folks will (probably correctly) claim that the mobile does not
> actually
> > >> have "internet access" in this case, since it does not directly
talk
> to
> > >> internet servers, but it is a valid design.
> > >>
> > >> (2) The minute the mobile sets up a clean end-to-end connection
> directly
> > >> to arbitrary internet servers, you have to be much more careful.
The
> > >> idea behind TCP is to prevent network overloads -- that is why
TCP
> > >> reacts with such caution; and on links prone to bit errors we
know
> that
> > >> to be a problem.  Bypassing TCP is not the answer, however;  by
> > >> definition you are trying to create a system that is more
aggressive
> > >> than TCP, which we know can damage the network as a whole, if
these
> > >> flows traverse the internet.
> > >>
> > >> --On Monday, March 31, 2003 10:05 -0800 Cannara
> <cannara at attglobal.net>
> > >> wrote:
> > >>
> > >> > Injong, excellent points.  There is no reason to continue to
> believe
> > >> > that TCP has any long-term purpose, especially in the
radio-link
> > >> > environment. Foot dragging in the IETF on ridding TCP of its
'80s
> > >> > myopic flow control has left us with a poor transport for
errored
> > >> > links.  It will be great if the control radio-link providers
have
> can
> > >> > generate a better thought-out transport, even if it simply
rides on
> IP
> > >> > or UDP.  We are in hope.
> > >> >
> > >> > Alex
> > >> >
> > >> > Injong Rhee wrote:
> > >> >>
> > >> >> Hi,
> > >> >>
> > >> >> I just came back from industry after working for a wireless
> multimedia
> > >> >> software company for about two years; this company makes media
> > >> >> servers, and clients that run on wireless handsets -- the
servers
> and
> > >> >> clients run at the end points. One thing I found in the field
is
> lack
> > >> >> of network transport. The only thing available was TCP and
UDP.
> But
> > >> >> its performance on CDMA 2.5G/3G (which is the network I have
been
> > >> >> working over) wasn't so great. It is because of well-known
> problems
> > >> >> with the losses not being indicative of congestion.
> > >> >>
> > >> >> So what we did was to develop our own flow control protocol
that
> can
> > >> >> run on top of UDP. Its performance was simply "better" than
TCP.
> We
> > >> >> could not find any alternative to this solution since all the
> > >> >> existing/proposed solutions (maybe I am not ignorant) require
some
> > >> >> changes in TCP and the
> > >> >> infrastructure -- I mean by "infrastructure" any changes that
the
> > >> >> wireless service providers have to do such as changes in
routers,
> > >> >> link-level mechanisms, base stations (BSC, BTS, PSDN), or any
> > >> >> components in their OSS networks. We couldn't ask our
customers
> > >> >> (wireless carriers) to do this nor you can change TCP (since
this
> > >> >> requires some deals with Qualcomm -- you know how that goes).
So
> we
> > >> >> changed our systems to support new protocols. Since we had
media
> > >> >> servers and clients, this wasn't difficult.
> > >> >>
> > >> >> Recently, I was talking to some folks here about the protocol.
The
> > >> >> first response I get is the following: "Since the protocol
> requires
> > >> >> change in the server and also client, this is the same as
changing
> > >> >> infrastructure; so our solution has deployment problems." Or
> "Since
> > >> >> all the applications use TCP, why not use TCP? Also if you
need
> any
> > >> >> change, all the changes must be at the TCP sender. Otherwise
you
> > >> >> can't deploy your solution." Or "There are a lot of work in
> modifying
> > >> >> TCP for better performance on wireless networks; why not use
> them?"
> > >> >>
> > >> >> This view is too simplistic and I disagree with this. First
all,
> the
> > >> >> wireless world is tightly controlled by wireless service
> providers.
> > >> >> They control applications that run on handsets, media servers,
and
> > >> >> even content providers. In addition, it is often the case that
> > >> >> software companies (typically small startups) have to develop
both
> > >> >> servers and clients -- look at mobile game companies. For
these
> > >> >> companies, modifying their servers and clients to provide
better
> > >> >> network performance is not that difficult to do -- in fact, as
> long
> > >> >> as this change brings in more revenue and edges over their
> > >> >> competitors, they are more than willing to do this. Also
deploying
> > >> >> new updates to customer handsets are easy now because of BREW
or
> J2ME
> > >> >> (FYI, we developed both solutions). For instance, in South
Korea,
> a
> > >> >> new release to client software can be deployed to the entire
> network
> > >> >> in the matter of days.
> > >> >>
> > >> >> The wireless revolution is a new phenomena happening in the
rest
> of
> > >> >> the world, but not in the US. The Far East (China, Japan,
South
> > >> >> Korea, Hong Kong, Singapore, etc) exhibits a completely
different
> > >> >> market trend/strategies from the US. I think it is incorrect
to
> > >> >> assume that every practice we have done in the wired IP world
> (esp.,
> > >> >> in the US market) is automatically applicable to the wireless
> world.
> > >> >> It is a different world out there.
> > >> >>
> > >> >> Any comments?
> > >> >>
> > >> >> Injong Rhee
> > >> >> rhee at csc.ncsu.edu
> > >> >> www.csc.ncsu.edu/faculty/rhee
> > >> >
> > >>
> > >> Hans Kruse, Associate Professor
> > >> J. Warren McClure School of Communication Systems Management
> > >> Adjunct Associate Professor of Electrical Engineering and
Computer
> > >> Science Ohio University, Athens, OH, 45701
> > >> 740-593-4891 voice, 740-593-4889 fax
> > >
> >
> > Hans Kruse, Associate Professor
> > J. Warren McClure School of Communication Systems Management
> > Adjunct Associate Professor of Electrical Engineering and Computer
> Science
> > Ohio University, Athens, OH, 45701
> > 740-593-4891 voice, 740-593-4889 fax
> 