[e2e] Is a non-TCP solution dead?

[Fu Cheng Peng, Franklin (Dr)]

Hi,


...... it seems TCP still has this problem in wireless environments
.......


Recently one SENDING-SIDE enhancement of Reno TCP, called Veno (this
name is from R eno and V egas), 
is proposed to attempt to overcome Reno's performance degradation in
wireless networks. 
The detailed algorihtm of Veno is just published in the last month on
IEEE JSAC (Feb, 2003), 
(Probably, it can be downloaded from
http://www.ntu.edu.sg/home/ascpfu/veno.pdf )
The title of paper is "TCP Veno: TCP Enhancement for Transmission over
Wireless Access Netwroks,"  

 

 

Here are just some Veno ideas and info for your quick references. 
I. Veno introductions 
II. Deployment issue

 


I. Veno introduction

A key ingredient of Veno is that it monitors the network congestion
level and uses that information 
to decide whether packet losses are likely to be due to congestion or
random bit errors. Specifically, 
1) it refines the multiplicative decrease algorithm of TCP Reno by
adjusting the slow-start threshold 
according to the perceived network congestion level rather than a fixed
drop factor; 
2) it refines the linear increase algorithm so that the network
bandwidth is fully utilized. 

Initial network testbed experiments and initial live Internet
measurements show that Veno can 
achieve significant throughput improvements without adversely affecting
other concurrent TCP connections, 
including other concurrent Reno connections. In typical wireless access
networks with 1% random packet loss rate,
throughput improvement of up to 80% can be demonstrated. A salient
feature of Veno is that 
it modifies only the sender-side protocol of Reno without changing the
receiver-side protocol stack. The all source  
codes of Veno (in NetBSD1.0, FreeBSD4.2 and Linux 2.4) are available
now. 

 


          II. Deployment

Veno can be deployed with merely upgrading of TCP stack at sever side,
for details, please download 
from http://www.ntu.edu.sg/home/ascpfu/veno2.pdf  The title of paper is
"TCP Veno Revisited"


It is known that the conventional network architecture in the current
Internet is as follows:

 

client 1        |---------|           
                |client 1 |  ******
                |---------|         *
                                    w *
client 2        |---------|           i  *
                |client 2 |  - -        r  *       |------------------|
                |---------|      -        e  *     |                  |
                                    -          *   |                  |
                              wireless -           |                  |
                   ....                 -          |      Proxy
|--------Internet
                   ....                   - - - -  |(NAT,Web,Firewall)| 
                   ....                            |                  |
                   ....                            |                  |
                   ....                 *********  |------------------|
                                       *
                                    *
client n        |---------|        *  Wire(ADSL)
                |client n |  *****
                |---------|

           ...... from  Intranet    .....................   to
....Internet.....

 

 

Fig.1. A common network topology showing the location of proxy between
clients (users) 
and servers with different access links

 

Proxies often operate in a split connection model where a user's node
desiring 
to communicate with an external server first makes a connection to the
proxy and tells it which server they want
 to communicate with. The proxy makes a second connection to the server.


TCP connections between the proxy and users 
usually traverse heterogeneous links. For example, as shown in Fig. 1,
some of them traverse wireline 
links (i.e., twist 5, ADSL), while others running over wireless links
(i.e., bluetooth, 802.11). 
TCP connections over these wireless or ADSL links are to suffer
performance degradations due to well-known problems. 


By upgrading legacy TCP stack of these proxies' OS (operation system) to
Veno-embedded stack, 
with reference to the Veno advantanges,  all TCP connections
over wireless, wired and ADSL for accessing outside servers would
co-exisit harmoniously and efficiently 
as if they were all running over wired lines.
 

Noted in this case, we needn't add extra nodes within intranet and thus
we avaoid unnecessary failure point,
what we do is to only upgrade the proxy TCP stack, all the network
architecture is kept without any changes.

 

 

 

 

Franklin FU

Asst Prof  School of Compuer Engineering

Nanyang Technological University, Singapore