[e2e] Is a non-TCP solution dead?

[Cannara]

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