A Technique to Enable the Corruption-aware Transport Protocols … · 2017-02-11 · transport...

I. INTRODUCTION

The traditional reliable transport protocols such as

transmission control protocol (TCP) [1] and Stream

Control Transmission Protocol (SCTP) [2] are originally

designed for the wired networks which regard any packet

losses as the indication of network congestion and halve

their congestion windows (cwnds) to alleviate the traffic

overload of network. Traditional transport protocols

perform well in wired networks since the packet losses are

mainly caused by network congestions rather than packet

corruptions.

In the wireless networks with high bit error rate

(BER), however, a high and variable packet corruption

rate (e.g., 10~50% erasure rate [3]) cannot be neglected

any more and those corrupted packets have to be

ultimately retransmitted in end-to-end manner [4]. This

will significantly degrade the end-to-end throughput of

traditional transport protocols due to incapability of

differentiating packet corruption from congestion losses.

In order to overcome the severe performance

degradation caused by corruption, some corruption-aware

transport protocols [5]~[8] have been presented among

which Datagram Congestion Control Protocol (DCCP) [7]

has been standardized as a congestion-controlled

unreliable transport protocol. The common ground of

corruption-aware transport protocols is that a sender can

avoid deflation of cwnd while only corrupted packets are

detected.

Unfortunately, the corruption-aware transport

protocols cannot work in realistic networks up to now

because the corrupted packets will be discarded by link

layer Cyclic Redundancy Check (CRC) checksum

mechanisms before they are delivered to transport layer.

To make the corruption-aware transport protocols

work in transport layer, there are two ways to be

129

The traditional reliable transport protocols are originally designed for the wired networks, which regard any packet

losses as the indication of network congestion and halve their congestion windows to alleviate the traffic overload of

network. However, unlike in wired networks, non-congestion losses will severely degrade the performance of

traditional transport protocols in wireless networks. Thus some corruption-aware transport protocols have been

proposed to overcome the performance degradation caused by corruption. Unfortunately, the corruption-aware transport

protocols cannot work in realistic networks up to now since the corrupted packets have been discarded by the link layer

checksum mechanisms before they are delivered to transport layer. This paper proposes a technique to overcome this

problem without disabling the link layer checksum mechanisms. Simulation results show that the performance of

corruption-aware transport protocols are still far better than that of traditional ones while the proposed scheme is

applied.

Keywords: TCP, SCTP, DCCP, Transport Protocol, FCS, checksum and Corruption

Lin Cui: Tianjin University of Technology and Education

Xin Cui: Shandong University

Seok J. Koh: Kyungpook National University

A Technique to Enable the Corruption-aware Transport

Protocols in Realistic Networks

Lin Cui ·Xin Cui ·Seok J. Koh

mentioned in previous studies. One is to disable the lower

layers' CRC checksums completely [5], the other is to set a

"skip flag" in every packet's header so that the lower

layer s CRC schemes can skip them [6]. Both suggestions

take the risks to overload the network traffic and/or to

deliver some garbage to upper layer. This is because some

packets with the corrupted MAC frame header may be

delivered to the wrong destinations or be acknowledged to

the wrong sources. More seriously, TCP may deliver some

garbage to application layer since both IP version 4 and

TCP itself employ the 16-bit 1's complement checksum

scheme which is relatively weaker than 32-bit CRC

checksum (IP version 6 has removed the checksum field in

order to reduce packet processing time in routers). On the

other hand, RFC 4340 [7] ignores the detailed suggestions

and only simply mentions that link layers may then reduce

their protection on unprotected parts of DCCP packets.

This paper introduces a detailed technique about how

to enable the corruption-aware transport protocols in

realistic networks without disabling the link layer

checksum mechanisms. The rest of this paper is organized

as follows. Section II introduces some related works.

Section III describes the proposed scheme in detail.

Section IV shows some simulation results and section V

concludes this paper.

II. RELATED WORKS

With exponential increment of mobile hosts during

recent two decades, wireless technologies have attracted

more and more attentions. So far a lot of related literatures

have been published and three kinds of approaches have

been mainly discussed in order to avoid the performance

degradation in wireless networks. They are split

connection schemes, link layer schemes and end-to-end

schemes.

Of the proposals, the most ones can be classified into

the end-to-end schemes. TCP Veno [8] estimates the

network congestion level by which the sender judges the

loss source between congestion and corruption.

Specifically 1) TCP Veno refines the multiplicative

decrease algorithm of TCP Reno [1], which is most widely

deployed in practice, by adjusting the slow-start threshold

according to the perceived network congestion level rather

than a fixed drop factor. 2) TCP Veno refines the linear

increase algorithm so that the connection can stay longer

in an operating region in order to fully utilize the network

bandwidth.

The explicit loss notification (ELN) scheme [13] uses

ELN signals to distinguish corruption from congestion. In

this scheme, a TCP-aware agent is requested to monitor

the passing packets at the base station. When the

corruption is detected over the wireless link, the agent sets

the ELN bit in the ACK s header to notify the sender not

to invoke the normal congestion control. In this way, this

scheme can avoid the degradation of TCP performance at

a certain extent.

TCP HACK [5] employs the two additional TCP

options for data segment at the sender side and for special

DUPACK at the receiver side. The former is the header

checksum option which covers the TCP header and the

pseudo IP header. The later is the ACK option which is

generated by the TCP receiver in response to a packet

corruption. In detail, on reception of a data segment, TCP

receiver firstly verifies the integrity of the whole segment

by checking the existing overall checksum. In case that the

segment is corrupted, the receiver then identifies the

integrity of the segment's header by verifying the

additional header checksum. Once corruption only occurs

in the portion of user data, the receiver can recover the

available sequence numbers from the integrated segment'sheader and timely report it to the sender. Therefore, in the

wireless environments with high BER, TCP HACK can be

used to improve the throughput performance of wireless

TCP by keeping it cwnd unchanged while only corruption

occurs.

TCP CAIAD [6] introduces a new error and

congestion control scheme using corruption-aware

adaptive increase and adaptive decrease algorithm. In [6],

the corrupted segments will be further processed by the

transport layer of the receiver, and a duplicate ACK is

generated to explicitly indicate both a real-time corruption

event and the congestion state of the link. Based on the

feedback information, the sender estimates the current

corruption strength and increases its cwnd by different

increments instead of entering fast recovery phase as long

as there is no concurrent loss. Meanwhile, the slow start

threshold will be estimated not only based on the received

integral packets but also based on the received corrupted

packets as per every round trip time and only updated

when the lost but not the corrupted segment is detected.

The authors argue that since the corrupted packets can still

arrive at the receiver side, they should reflect some

available bandwidth at a certain extent as well. Therefore,

TCP CAIAD [6] can estimate the network bandwidth

more precisely and can significantly improve TCP

performance over wireless networks.

The four schemes mentioned above focus on the

performance improvement by distinguishing random loss

130 Telecommunications Review·Vol. 19 No. 1·2009. 2

does not violate end-to-end semantics of TCP since the

packets cached in base station do not get through the base

station's transport layer.

As mentioned in introduction section, up to now there

are two approaches for the corruption-aware TCP to work

in transport layer. One is to disable the link layer CRC and

the other is to set a "skip flag" in every packet header for

the link layer CRC mechanism to skip the checking

procedure. The former may take the risk to deliver some

garbage to application layer and both schemes will

overload network traffic more or less since every

corrupted packet has to be delivered to a destination.

This paper introduces a new scheme that enables the

corruption-aware TCP variants to work in transport layer

properly and gets a tradeoff between performance

improvement and traffic overload, without the necessity of

disabling link layer CRC mechanism.

III. PROPOSED SCHEME

1. Technique to enable the corruption-aware protocols over CRC mechanism

We can recall the structures of IP header. IPv4 has a

''protocol'' field and IPv6 has a ''next header'' field. Both

fields indicate the type of transport layer protocol. Since

IPv4 is the de-facto IP standard currently, we present this

proposal in the environment of IPv4 (hereinafter, IP refers

to IPv4). The detailed base header structure of IPv4 is

shown in Figure 1.

To surely enable the corruption-aware transport

protocols to work in realistic networks, in this paper we

propose to assign a currently unused protocol type value to

the corruption-aware transport protocols. If so, when a

MAC frame is constructed at the source, the frame check

from congestion loss. On the other hand, Freeze TCP [14]

tries to boost the TCP performance in mobile scenarios. In

particular, with the indication of impending disconnection

from the network layer, the mobile host of Freeze TCP

[14] sends a zero window advertisement (ZWA) to the

fixed host so that the fixed host freezes all retransmission

timers and enters a persistent mode without transmission

as well as deflation of cwnd. In such a way, when the

mobile host uses triple DUPACKs to restart data transfer

after reconnection, the slow start phase can be avoided and

the sender can still transmit data at an unchanged sending

rate.

TCP Westwood [15] estimates the network bandwidth

based on the acked data amount by every ACK. In

addition, TCP Westwood [15] only revises the sender side

algorithms and does not need any feedback information

from the intermediated routers. Nevertheless, though TCP

Westwood [15] can better utilize the bandwidth of a single

wireless link, it tends to overestimate the available

bandwidth in the presence of ACK compression [16]. This

undesired feature may accelerate network collapse when

the network goes into incipient congestion. To avoid this

problem, TCP Westwood+ [16] estimates bandwidth per

RTT interval instead of every ACK. Therefore, TCP

Westwood+ can improve throughput performance even in

the presence of ACK compression.

The typical split connection scheme is I-TCP [11]

which splits a TCP connection between a fixed host and a

mobile host into the two separate connections. I-TCP

hides the TCP source from the wireless link by using a

protocol optimized for wireless link.

As for the link layer schemes, the Snoop TCP [12] is a

famous paradigm. Snoop installs a dedicated agent in the

base station and employs a local retransmission scheme

for wireless link errors so that only packet losses caused

by congestion can be detected by the source. Also, Snoop

A Technique to Enable the Corruption-aware Transport Protocols in Realistic Networks 131

32 BITS

Version

Flags

Protocol Header Checksum

Source Address

Destination Address

Figure 1. Structure of IP base header

Time to Live

Fragmented OffsetIdentifier

HeaderLength Type of Service Total Length

8 8 8 8

garbage to be delivered to application layer, TCP may

need an additional CRC checksum in its option field for

checking the checksum of entire segment. In contrary to

TCP, SCTP natively uses CRC scheme and DCCP also

has a CRC checksum option already. As a reference, the

detailed 802.11 MAC frame format is shown in Figure 2

[10].

Nevertheless, in whole travel of a MAC frame, not

only source and destination but also every intermediate

node has to correctly differentiate the partial FCS from the

normal FCS. For this purpose, either an additional type

value or a flag bit needs to be assigned in each frame

header. It is noted that different standards' MAC frames

may have different structures. Thus the sign of the partial

FCS can be expressed in different ways.

For instance, when a corruption-aware transport

protocol runs over a heterogeneous network which

consists of a WLAN and a wired network, the type

subfield of 802.11 MAC frame should be filled by ''10''and the subtype subfield should be filled by a currently

unused value. The former means this is a data frame and

the later means this frame has a partial FCS but not a

normal one. Notice that both type and subtype fields are

two subfields of 802.11 MAC frame's frame control field.

The detailed structure information is shown in Figure 2.

As for the Access Point, on reception of an 802.11

MAC frame, it needs to exchange the frame header

between 802.11 and 802.3 standards as shown in Figure 3.

At the same time, the protocol type field of 802.3

MAC frame should also be filled by a currently unused

value to inform the intermediate nodes that this frame will

be processed by a corruption-aware transport protocol

ultimately and a partial FCS is enclosed in the end of this

frame. The detailed 802.3 MAC frame format is shown in

Figure 4.

sequence (FCS) of this frame can be calculated based on

different checksum scopes, depending on the type value of

the protocol field contained in IP header.

In particular, once the protocol field indicates that a

corruption-aware transport protocol is employed in

transport layer, the FCS will be computed based on the

scope which covers the frame header (variable length for

different network standards), the possibly maximum

length of IP header (20-byte IP base header plus 40-byte

option field) and the maximum length among TCP base

header (20-byte), SCTP common header (12-byte) and

DCCP generic header (16-byte) (hereinafter, refers to

partial FCS). Otherwise, the FCS is calculated as normal

(hereinafter, refers to normal FCS).

The reason that we propose to calculate the partial

FCS based on above scope is that generally the

intermediate nodes have no the detailed knowledge of

every passing MAC frame and some IP headers may

contain option fields which extend their header scopes.

Thus, in order to ensure the integrity of transport

protocol's base header, the partial FCS has to be calculated

based on the possibly maximum header scope. However,

TCP option field can be omitted since the both useful

sequence number and checksum fields lie on TCP base

header.

For example, when a corruption-aware transport

protocol runs over a 802.11 wireless local area network

(WLAN), the FCS of a 802.11 MAC frame will be

calculated based on the first 110 bytes (the sum of 30

bytes' 802.11 MAC frame header, 60 bytes' possibly

maximum IP header and 20 bytes' maximum transport

segment s base header). The integrity of the rest part of

this frame can be responsible by the transport layer

checksum. Notice that internet checksum is relatively

weaker than CRC mechanism. In order to prevent some


Framecontrol

Protocolversion

Type SubtypeToDS

FromDS

Morefrag

Retry PwrmgtMoredata

WEP Rsvd

2

2

Figure 2. Structure of 802.11 MAC frame

2 4 1 1 1 1 1 1 1 1

2 6 6

MAC header(bytes)

6 2 6 0-2312 4

Duration/ID

Address1

Address2

Address3

Sequencecontrol

Addres4

Framebody

FCS

It is noted that the structure of 802.3 MAC frame is

different from that of 802.11 MAC frame, hence the

coverage scopes of their partial FCS fields are also

different. In detail, each intermediate node along the

wired path will check the FCS value based on the first 94

bytes (the sum of the length of 802.3 MAC frame header

which is 14-byte, the possibly maximum length of IP

header which is 60-byte and the maximum length of

transport segments' base headers which is 20-byte) in

order to identify whether the header scope is corrupted or

not.

In this way, only those MAC frames with the

corrupted header will be dropped in link layer, and the

frames with the valid header will successfully arrive at the


H1

AP

R1router

R1 MAC addr

AP MAC addr H1 MAC addr R1 MAC addr

dest.address

address 1

Figure 3. Exchange of frame headers

address 2 address 3

source address

802.3 fame

802.11 frame

AP MAC addr

Internet

MACHeader

OSI Layer 3 and higherMinimum: 46bytesMaximum: 1500bytes

7 bytesPreamble

10101011

10101010

DestinationMAC Address

Source MACAddress

Start Delimiter

Protocol type

data field

Pad Field=0~46bytes

Frame checksequence

Minimum: 64bytesMaximm: 1518bytes

1 byte

2 bytes

4 bytes

Figure 4. Structure of 802.3 MAC frame

6 bytes

6 bytes

receiver side without traffic overload as well as wrong

delivery. Therefore, the corruption-aware transport

receiver can process these corrupted segments and feed the

detailed corruption information back to the sender so as to

avoid deflation of cwnd.

2. Tradeoff between overload and throughput

Generally, while a packet travels a wireless channel

with a high BER, not only the part of user data but also the

packet header suffers bit errors with various probabilities.

In current networks, those corrupted MAC frames will be

discarded directly by the intermediate routers because of

failed FCS checksum. Thus normally the corrupted MAC

frames cannot arrive at receiver side unless corruption

occurs in the last hop of their traveling path.

The main side-effect resulted from applying the

corruption-aware transport protocol in transport layer is

that a certain amount of garbage (that is, corrupted

packets) will overload the network traffic. In particular, it

is not realistic to completely disable link layer CRC

checksum due to two reasons. First, some applications

still run over CRC mechanism (e.g., FEC scheme and

ARQ scheme). Second, too much garbage will be

delivered to the non-corruption-aware destinations. On the

other hand, although setting a ''skip flag'' in every packet

header can significantly reduce the garbage amount of

network traffic (since only particular flows skip CRC

checksum), the packet with the corrupted MAC addresses

may be delivered to the wrong destination or be

acknowledged to the wrong source. Unfortunately, the

''skip flag'' method is helpless for this kind of problem.

In the ''partial FCS'' approach, however, the wrong

delivery mistakes will be completely forbidden and only a

little overload will be introduced in network traffic

compared to other schemes.

Moreover, the authors assume in [5] that corruptions

only occur at the data payload. In [6], the packet dropped

rate caused by corruption is set in simulations by the

proportion of the header size over the packet size where

the header scope covers IP header and TCP header.

Without the particular instructions for performance

estimation, RFC 4340 [7] only refers that ''checksum

coverage may eventually impact congestion control

mechanisms as well''. We argue in this paper that when

partial FCS is applied, the packet dropped rate incurred by

corruption should be set in simulations by the proportion

between the possibly maximum header scope and the

whole size of the MAC frame over a lossy link. This is

because MAC frame is the service data unit (SDU) in


wireless channel. For example, if each IP packet has a

fixed size of 1040-byte and packet corruption rate is β, the

packet drop rate caused by corruption could be considered

as 110β/1074 (that is, 1074=30+1040+4) approximately in

802.11 WLAN.

Overhead is another drawback introduced by the

partial FCS scheme. It is noted that TCP employs internet

checksum in transport layer which is relatively weaker

than CRC mechanism. In order to prevent some garbage to

be delivered to application layer, TCP may need an

additional CRC checksum in its option field. This will

also result in some extra overhead. Nevertheless, the

overhead introduced by the partial FCS scheme could be

minor and can be ignored, compared to the improved

throughput.

IV. SIMULATION RESULTS

We use TCP CAIAD [6] as the corruption-aware

transport protocol in our experiments, and select TCP

Westwood+ [9] as the reference protocol from which TCP

CAIAD is evolved.

In the simulations, we only devote our mind to the

impacts of header corruption and neglect the checksum

procedure of partial FCS. For that, each IP packet uses a

fixed size of 1040-byte, and the packet drop rate incurred

by corruption is set to 110/1074 of packet corruption rate

for the proposed scheme. On the other hand, TCP

Westwood+ [9] regards packet corruption as packet loss.

Thus its packet drop rate is equal to the packet corruption

rate in simulations.

To minimize other impacts on performance

comparison, e.g., network layer's congestion, we use a

simple simulation topology as shown in Figure 5. In the

figure, the wired link has the link bandwidth of 10 Mbps

and the transmission delay of 35ms, whereas the wireless

link has the bandwidth of 2 Mbps and the transmission

delay of 1ms.

We compare the average end-to-end throughputs

during 100 seconds by performing the file transfer

application in ns2 simulator. In the comparison, each data

segment carries 1000 bytes' user data by TCP Westwood+,

whereas TCP CAIAD only sends 990 bytes' user data by

every data segment (we assume that each data segment

contains two additional checksums in option field. One is

CRC checksum option for entire segment and the other is

internet checksum option for header portion. Both options

need 10 bytes in all). Simulation results are shown through

Figure 6 to Figure 9.


A note on notation: in the Figures proposed scheme

refers to TCP CAIAD with partial FCS scheme, and TCP

CAIAD refers to TCP CAIAD with skip flag scheme.

From Figure 6, we can see that both the partial FCS

scheme and the skip flag scheme can provide the better

performances while the corruption rate is higher than

0.1%. Especially, when the wireless link experiences the

packet corruption rates ranged from 0.1% to 1%, it seems

that both corruption-aware schemes can almost fully

utilize the link bandwidth, while TCP Westwood+ [9]

already gets a drastic performance degradation then.

The figures from Figure 7 to Figure 9 show the

comparisons of bandwidth utilization, evolutions of

congestion window and slow start threshold with 10%

Various Packet Corruption Rate

Souce Basestation

SinkWired Link

Figure 5. Simulation topology

Wireless Link2M 1ms10M 35ms

2000

1800

1600

1400

1200

1000

800

600

400

200

0

Throughput (Kbps)

Figure 6. Throughput comparison

Figure 7. Bandwidth utilization comparison for 10% packet corruption rate

Proposed scheme

TCP CAIAD

TCP Westwood +

0 0.1% 0.5% 1% 5% 10%

Packet corruption rate


packet corruption rate, respectively. From the figures, we

can see that although all TCP variants get severe

performance degradation due to the heavy packet

corruption rate (e.g., 10%), the performance gains of the

corruption-aware schemes (including both the partial FCS

scheme and the skip flag scheme) are still prominent,

compared to that of TCP Westwood+ [9].

More seriously, once the initial control segments are

corrupted during connection establishment phase, the

traditional TCP will back-off the initial time exponentially

(See Figure 7). This will further degrade TCP

performance. On the contrary, both corruption-aware

schemes can retransmit the initial control segments

immediately so as to ensure the TCP connection to be

established in time (See Figure 7).

By comparisons, we can also see that partial FCS

scheme can still obviously improve the end-to-end

throughput compared to the traditional transport protocols,

though it cannot outperform TCP CAIAD. This is because

the proposed partial FCS scheme keeps the semantic of

differentiating packet corruption from packet loss. Hence

it inherits the native characteristics of TCP CAIAD. On

the other hand, although the TCP CAIAD with skip flag

scheme may lead to a higher throughput in simulation, the

reasons stated in introduction section make the proposed

partial FCS scheme more feasible for implementation in

realistic networks.

V. CONCLUSIONS

Although RFC 4340 points out that link layer should

reduce the protection on unprotected parts of DCCP

packets, it does not present any particular suggestion on

how to fulfill. In this paper, we present a detailed

technique to enable the corruption-aware transport

protocols to work in realistic networks without the

necessity to disable the link layer checksum mechanisms.

From simulation results, we can see that the proposed

scheme can still perform far better, compared to the

traditional transport protocols in wireless environment

with high BER.

On the other hand, even if disabling/skipping the link

layer CRC checksum can lead to the higher throughput in

Figure 8. Congestion window comparison for 10% packet corruption rate

Figure 9. Slow start threshold comparison for 10% packet corruption rate

simulations, the reasons mentioned before make the

proposed scheme more feasible to implement in realistic

networks.

AcknowledgementThis research was partially supported by the MKE

(Ministry of Knowledge Economy) of Korea, under the

ITRC support program supervised by the IITA (IITA-

2008-C1090-0804-0004).

[References][1] W. R. Stevens, ''TCP Slow Start, Congestion

Avoidance, Fast Retransmit, and Fast Recovery Algorithms,'' IETF, RFC 2001, Jan. 1997.

[2] R. Stewart et al., ''Stream control transmission protocol,'' IETF, RFC 2960, Oct. 2000.

[3] D. Aguayo, J. Bicket, S. Biswas, G. Judd and R. Morris, ''Link-level Measurements from an 802.11b Mesh Network,'' in Proceedings of the SIGCOMM 2004, Aug. 2004.

[4.] O. Tickoo, V. Subramanian, S. Kalyanaraman and K. K. Ramakrishnan, ''LT-TCP: End-to-End Framework to Improve TCP Performance over Networks with Lossy Channels,'' in Proceedings of the 13th IEEE International Workshop on Quality of service(IWQoS), Jun. 2005.

[5] R. K. Balan, B. P. Lee, K. R. Kumar, L. Jacob, et al, ''TCP HACK: TCP Header Checksum Option to Improve Performance over Lossy Links,'' in Proceedings of the IEEE INFOCOM 2001, Vol. 1, Apr. 2001, pp. 309?318.

[6] L. Cui, S. J. Koh, X. Cui, et al, ''Adaptive Increase and Adaptive Decrease Algorithm for Wireless TCP,'' in Proceedings of the ICNC2007, Vol. 2, Aug. 2007, pp. 392-398.

[7] E. Kohler, M. Handley and S. Floyd, ''Datagram Congestion Control Protocol,'' IETF, RFC 4340, Mar. 2006.

[8] C. P. Fu, S. C. Liew, ''TCP Veno: TCP Enhancement for Transmission Over Wireless Access Networks,'' IEEE Journal on Selected Areas in Communications, Vol. 21, No. 2, Feb. 2003, pp. 216-228.

[9] Westwood+ TCP - Modules for ns2 from http://193.204.59.68/mascolo/tcp%20westwood/modules.htm.

[10] A. Leon-Garcia and I. Widjaja, Communication Networks: Fundamental Concepts and Key Architectures, McGraw-Hill, 2000.

[11] Bakre and B. R. Badrinath ''I-TCP: Indirect TCP for Mobile Hosts,'' in Proceedings of the ICDCS, May 1995, pp. 136-143.

[12] E. Amir, H. Balakrishnan, S. Seshan, R. Katz. ''Efficient TCP over Networks with Wireless Links,'' in Proceedings of the 5th Workshop on Hot Topics in Operating Systems, May 1995, pp. 35-41.

[13] H. Balakrishnan, R. Katz, ''Explicit loss notification and wireless web performance,'' in Proceedings of the IEEE Globecom Internet Mini-Conference, Nov. 1998.

[14] T. Goff, J. Moronski, D. S. Phatak, V. Gupta, ''Freeze-TCP: A True End-to-end TCP Enhancement Mechanism for Mobile Environments,'' in Proceedings of the IEEE INFOCOM, Mar, 2000, pp. 1537-1545.

[15] S. Mascolo, C. Casetti, M. Gerla, M. Sanadidi, R. Wang, ''TCP Westwood: End-to-end bandwidth estimation for efficient transport over wired and wirelessnetworks,'' in Proceedings of the ACM Mobicom 2001, Jul. 2001, pp. 287-297.

[16] R. Ferorelli, L. A. Grieco, S. Mascolo, G. Piscitelli, P. Camarda, ''Live Internet Measure-ments Using Westwood+ TCP Congestion Control,'' in Proceedings of the IEEE GLOBECOM 2002. Vol. 3, Nov. 2002, pp. 2583-2587.



Lin Cui

Lin Cui received B.S. degree in Electronic Engineering

from Tianjin University, China, in 1989. He also received

M.S. degree in Computer Engineering from Kyunghee

University, Korea, in 2005 and Ph.D. degree in Computer

Science from Kyungpook National University, Korea, in

2009, respectively. He is now with Tianjin University of

Technology and Education, China. His current research

interests include Transport Layer Protocols, Wireless

Communication and Internet Mobility.

E-mail: [email protected]

Xin Cui

Xin Cui received B.S. degree in Materials Science and

Engineering from Northwestern Polytechnical University,

China, and M.S. degree in Interdisciplinary Program of

Electronic Commerce from Chonnam National University,

Korea, in 1986 and 2002, respectively. He has been an

instructor in Shandong University at Weihai, China, since

January 2003. His current research interests include

development and application of Electronic Commerce,

Networks Security, Wireless Networks and Transport

Control Protocol.


Seok Joo Koh

Seok Joo Koh received B.S. and M.S. degrees in

Management Science from KAIST in 1992 and 1994,

respectively. He also received Ph.D. degree in Industrial

Engineering from KAIST 1998. From August 1998 to

February 2004, he worked for Protocol Engineering

Center in ETRI. He is now an Associate Professor at

Electrical Engineering and Computer Science in the

Kyungpook National University since March 2004. His

current research interests include Mobility Management

for NGN, Internet Mobility and Transport Layer

Protocols. He has so far participated in the International

Standardization as an editor in ITU-T SG19, SG17, SG13,

ISO/IEC JTC1/SC6 and IETF.


A Technique to Enable the Corruption-aware Transport Protocols … · 2017-02-11 · transport...

Documents

Transcript of A Technique to Enable the Corruption-aware Transport Protocols … · 2017-02-11 · transport...