[e2e] Is a non-TCP solution dead?

[Cannara]

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