[e2e] Is a non-TCP solution dead?

[Hans Kruse]

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