[e2e] Is a non-TCP solution dead?

[Cannara]

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