Wireless Data Communication - Aalborg Universitetkom.aau.dk/~hps/WDC_Fall03/lecture4-TCP.pdf ·...

Tatiana K. MadsenHans Peter SchwefelWireless Data Communication: MM4, Wireless TCP, Fall03

Wireless Data Communication

www.kom.auc.dk/~tatiana/WDC

by Tatiana Madsen & Hans-Peter Schwefel

• Mm1 Short range Wireless Communication (TKM)

• Mm2 IP Mobility Support (HPS)

• Mm3 Ad hoc Networks (TKM)

• Mm4 Wireless TCP (HPS)

• Mm5 Wireless applications and cross-layer aspects (HPS/ TKM)

www.kom.auc.dk/~hps/teaching

Page 2 Tatiana K. MadsenHans Peter SchwefelWireless Data Communication: MM4, Wireless TCP, Fall03

Content1. Background

• IP, Transport Layer Protocols

2. TCP functionality• Connection set-up, flow/congestion

control3. TCP Performance Aspects

• Performance parameters, Performance Models

5. Wireless TCP• Problem statement, link

models, TCP Improvements

6. Use Case: TCP in GPRS• Architecture, Properties, TCP

Improvements

7. Summary/Conclusions

8. Outlook

+ Exercises

Goal: Make students familiar with • underlying problems• solution approaches • Overview on key technologiesWrt. Transport layer aspects in wireless IP-based networks


Background: IP Protocol StackNetwork Layer (Layer 3):• Internet Protocol (IPv4, IPv6)• Packet (IP datagram) transmission between end-systems [hosts] (packet size

up to 65535 bytes, often restricted by Layer 2 protocols)• Routing using 32 bit adresses (v4)• Unreliable, connectionless transmission: loss, duplication, reordering can

occurTransport Layer (Layer 4):• Most frequent transport protocols

Transmission Control Protocol TCPUser Datagram Protocol UDP

Application Layer/Services (Layer 5-7)• TCP based:

HTTP (HyperText Transfer Protocol),FTP (File Transmission Protocol),SMTP (Simple Mail Transfer Protocol), Telnet, ...

• UDP based:DNS (Domain Name Service), Streaming media, VoIP, ...

Application

TCP/UDP

IPLink-Layer

L5-7

L4

L3

L2


Transport Layer ProtocolsGoal: data transfer between application (processes) in end-systems

• support of multiplexing/de-multiplexing e.g. socket API

data stream/connection identified by:two IP addresses, protocol number, two port numbers


Overview: Transport Protocols• User Datagram Protocol UDP (RFC 768)

– Connectionless– Unreliable– No flow/congestion control

• Transmission Control Protocol TCP (RFC 793, 1122, 1323, 2018, 2581)– Connection-oriented (full duplex)– Reliable, in-order byte-stream delivery– Flow/congestion control

• Stream Control Transport Protocol SCTP– Connection oriented (full-duplex associations)– Reliable message delivery, support of multiple streams– Support of multi-homing, flow/congestion control

• Real-Time Transport Protocol RTP– Uses UDP– Provides: Time-stamps, sequence numbers– Supports: codecs, codec translation, mixing of multi-media streams


Content

1. Background • IP, Transport Layers UDP, TCP







Improvements


8. Outlook

Exercises


Transmission Control Protocol (TCP): Basics• Point-to-point, bi-directional connections (between end-systems)• Reliable, in-order transport of byte–stream using

– Sequence Numbers – Acknowlegements

• Flow/Congestion Control: Prevent flooding of– Receiver– Intermediate Systems

Important ‚new‘ Header Fields– Sequence number: number of first data byte transmitted in the segment– ACK number: number of next byte expected in the reverse data flow– Window size: number of bytes host is willing to accept in reverse data flow


Connection Establishment / Termination

Connection Establishment:• 3-way handshake (SYN, SYN-ACK,

ACK)• selection of initial sequence

numbers• agreement on maximum segment

size

Connection end:• Indicated by FIN flag• Signalled for both transmission

directions• ‚Alternative‘: RST flag


TCP Connection State Machine

TCB = TCP Control Block (5-tuple for conn. identification, Seq. nrs., timer values, etc.)Additional transitions: RST reception state ’CLOSED’


TCP Flow/Congestion Control: Purpose

• Flow Control:– Adapt sending rate to receiver speed– Prevent Buffer Overflow at receiverApproach: Receiver notifies sender about available buffer space

• Congestion Control– Avoid network overload– Prevent packet loss at buffers in intermediate systems (routers)– ‘fair’ sharing of rates between all TCP connections at bottleneck linksApproach: ‘Elastic traffic’ – sending rates adjust dynamically when

overload indicated


TCP Flow/Congestion Control

• Sliding Window: # packets sent and un-acknowledged limited by– receiver buffer (receiver advertised window)– congestion window (purpose: protect intermediate nodes)

• Congestion window dynamically adjusted (‚probing‘ for usable bandwidth): increase gradually until congestion indicated via– Timeouts– Duplicate Acknowledgements


Slow-start phase:• Initial congestion window set to size cwnd=one

segment

• Whenever ACK received: Increase cwnd by number of newly acknowledged bytes

• Slow-start phase ends

• When cwnd > ssthreshold Congestion Avoidance

• Packet loss detected (timeout, triple dup ACK)

TCP Congestion Control: Slow Start

Slow-start initiated after (depends on TCP version)

• connection start

• timeout detection

Example: Slow-Start(receiver using delayed Acks)

44

6

8

10


Slow-Start & Congestion Avoidance

Congestion detected:• timeout set ssthresh to

cwnd/2, perform slow-start• [three dup Acks half cwnd,

ssthresh=cwnd (Fast Retransmit/Recovery, see later)]

For High-Bandwith Links:• CWND doubles after each

round-trip time (RTT) in slow-start phase

• CWND increases by one segment size in each RTT during congestion avoidance phase

Throughput = CWND*MSS / RTT (for high-bandwidth links)


Impact of slow-start: Simulation Result

• Larger connection volume higher average throughput

• Upper Limit: Layer-2 throughput and MaximumWindowSize / RTT

Simulations of GPRS-like scenario without congestion (no losses/timeouts/dupACKs)

[Correction: y-axis in kbit/s]


Timeout intervals (RTO)• Based on measured Round-Trip-

Time (RTT):Timeout value RTO computed from moving average and variance estimate of samples of measured RTTs

• Retransmission ambiguous RTT sample: neglect these samples for RTO computation (Karn‘s algorithm)

• In case of retransmissions: increase timout value RTO geometrically for each repeated retransmission (up to some upper bound)


Fast Retransmit• Goal: Avoid long delays due to waiting for time-outs• Method: Use indication given by dupAcks, which may be generated due to

– packet loss, or– out-of-order packet delivery

• Fast Retransmit:– Upon receiption of three dupAcks consecutively, assume segment is

lost– Retransmit lost packet– Note: 3 dupAcks are also generated if a packet is delivered at least 3

places beyond its in-sequence location 7 9 1281110


Fast Recovery (TCP Reno)

• Keep up transmission rate after single lost packet (no slow-start, increase window upon dupAcks)• Avoid bursts of packets after ACK for retransmitted lost packet


Illustration of flow control mechanism


TCP flow/congestion controlAdditional Approaches (not discussed in detail here):• Zero Window Probing: prevent blocking after full receiver buffer• Silly Window Syndrome: prevent transmission of small fragments

– Delayed ACKs– Nagle’s Algorithm: buffer data until either MSS filled or ACK has arrived

• Delayed Window Update: avoid insignificant window updates

Different TCP versions (selection):• Tahoe: Slow-Start Congestion Avoidance, Fast Retransmit followed by Slow-Start• Reno: Tahoe + Fast Recovery (not followed by slow-start!)• New Reno: Reno + ‘partial ACK’ handling• SACK (selective Acknowledgements): only retransmit the lost segments• VEGAS: update cwnd based on measurements of delay variations


Content








Improvements


8. Outlook

Exercises


TCP Performance Parameters (Selection)• Packet based

– # of retransmissions, # of time-out events– Packet delay (max, min, average, distribution)

• Equals transmisison delay + queueing delay + retransmission time(if applicable)

• Connection based– Data (file) transfer time– Average Throughput/Goodput– Probability of successful transfer

• Fairness: – Bottleneck scenarios: if N TCP

sessions share same bottlenecklink, each should get 1/N of link capacity

– multi-hop scenarios, e.g. • Max-min fairness


Simulation Model: Congestion Scenario with Multiplexed ON/OFF Traffic

Scenario: N ON/OFF sources, queueing/loss only at bottleneck router

Here: Investigate average throughput per connection in TCP setting

connections


Correlation: Connection Size ↔ Throughput

• N=2 bursty TCP sources • N=30, N=90 TCP sources


Challenge: Traffic/Performance Models for TCP

End-to-End flow/congestion control Feedback: network behavior (congestion) ↔ ingress trafficNo separation traffic model/network model possibleNew traffic/performance models required

Approaches:1. Connection level models (e.g. [Heyman et al., Sigmetrics 97])

2. Sender/receiver behavior & fixpoint iteration3. Integrated models

Traffic Model

Network Model Performance

Values(Delay, Loss, etc.)

feedback


Connection Level model: e.g. [Heyman, Lakshman, Neidhardt]

• R0 = minimal Round-Trip Time

• B= Buffer Size at bottleneck

Modified Processor Sharing model (~M/M/1//N/PS) on connection level:

• N TCP sources share bottleneck node (service rate ν)

• Maximum Transmission Rate λp within each connection

• For j active connections, each obtains service at rateλp when jλp ≤ν

δν/j when jλp >ν

• with attenuation factor δ≤1 derived from TCP behavior

PS+

# of customers in queues corresponds to number of active connections


Fixpoint models

Network Model:• E.g. M/M/1/K model or bulk-arrival queue

TCP model, e.g. [Padhye et al., Sigcomm 98]

b: # packets acknowledged by ACK

RTT: Average Round-Trip-Time (including queuing delay)

Wmax: Maximum size of congestion window

T0: Average Time-Out interval

p: Fraction of retransmitted packets

TCPModel

Network Model

Initial loss rate p, delay d Average

packet rate

Update: loss rate p, delay d

When stable: result


Network model example: M/M/1/K queue• Poisson arrival of packets (first ’M’ Markovian) with rate λ

– ti : arrival time of packet i– Xi:=ti+1-ti : interarrival time– Poisson process of rate lambda:

• Xi independent and • Pr(Xi<x)=1 - exp(-λ x)

• Exponentially distributed service times of rate µ (second ’M’)

• Single Server (1)• Finite waiting room (buffer) for K packets• Often also specified: service discipline

– Default: First-In-First-Out– Others: Processor Sharing, Last-In-First-Out,

Earliest Deadline First,...

Finite buffer (size K)

µλ


M/M/1/K queue: Performance

• Finite Birth-Death Process (see e.g. [Cassandras & Lafortune]):– Probability of i packets in queue [using Chapman-Kolmogorov Equations]

pi := Pr(n=i) = (1-ρ)/(1- ρK+1) * ρi , where ρ= λ/ µ ≠1, i=0,…,K – Probability of packet loss:

p(loss) = pK = (1-ρ)/(1- ρK+1) * ρK

– Average Delay:

Ď = 1/[λ (1-pK)] * ρ/(1- ρK+1) * [(1- ρK)/ (1-ρ) – K ρK ]

λ λ λ λ

µµ µ µ

K


Integrated Models: exampleC

mp.

Pro

cess

or

shar

ing

Source 1

Source 2

Source 3 B

ν+

Bottleneck Router

[infinite queue]

Queueing Model with modified (queue-dependent) ON/OFF arrival process:

• ‚Sharing‘ of bandwidth: packet-rate λp at source reduced to δν/j for j active sources when jλp>ν

• conn. duration extended #packets in conn. unchanged

• Throttling only during congestion state when queue-length>=B

# active 1 2 3 2 1 0 1 ...


Comparison: Models & simulation results

... see [ITCOM01] for details & more results


Content








Improvements


8. Outlook

Exercises


Wireless (Infrastructure) Networks: Challenges• Wireless links tend to have the following properties:

– Large delays– Low throughput– Bit errors / packet losses due to poor channel conditions (noise, interference, fading)

• Impact of mobility– Delay/losses due to hand-over events

• Protocols in IP family not originally designed for such links– Increased volume due to headers– Deficiencies of TCP flow/congestion control– ... many more (e.g. applications HTTP WAP)

• Protocol Enhancements are being developed, e.g.– Robust Header Compression (RoHC) – Enhancements for Wireless TCP


TCP-mechanisms in wireless settings

• TCP assumes congestion if packets are dropped– possibly wrong in wireless networks, here we often have packet loss due to

transmission errors– furthermore, mobility itself can cause packet loss (handover losses)

or temporary connection disruptions (timeouts or even broken TCPconnections)

performance of an unchanged TCP degrades severely– however, TCP cannot be changed fundamentally due to the large base of

installation in the fixed network, TCP for mobility has to remain compatible– the basic TCP mechanisms are needed to for congestion control in the wired

network parts


TCP Performance Degradation

At right end of graph: About 30% packets lost due to wireless link but approx. 95% TCP throughput reduction!!

Example using Bursty Loss Model:• While current state i: packets

corrupted with probability εi

• After each packet: state transition with probability pik

Average Packet Loss Probability:


Wireless TCP: Common Approaches for Enhancement

• Link-Layer Approach– Local Retransmission of lost packets– Hide losses from sender

• Explicit Notification Approach– Explicitly notify TCP sender of the condition of the network / type

of the loss• End to End Approach

– Enhance TCP Protocol stack at sender and receiver to achieve better throughput (e.g. TCP SACK)

• Split-Connection Approach– End-to-End flow control terminated before wireless link


Wired network

Fixed host (FH)

Wire Network Interface

IP

TCP

ServerApplications

TCP connection

Wire Network Interface

IP

TCP

Wireless Network I/F

IP

TCP/Enhancedprotocol

Split-TCP Demon

Wireless Network

Enhancing Proxy (PEP)

connection

Mobile host (MH)

Wireless Network I/F

IP

TCP/Enhanced protocol

Applications

Wireless TCP: Split Connection

• Proxy is located between the 2 end-hosts to split the TCP connection into 2 parts• Different implementations: Indirect TCP (state-full), Mobile TCP (stateless, send

recv=0 when disconnection detected)


Wirless TCP: Split Connection (cont`d)• Advantages

– No Changes in wired network and correspondent host necessary– Shields the end-host in the wired network from the wireless network

characteristic: Wireless Local Recovery by Proxy– Possibly reduced header size for optimized transport protocol over wireless

link– Allows for ‘Smaller’ and simpler wireless protocol between MH and Proxy

• Disadvantages– Loss of end-to-end TCP semantics– Not usable with end-2-end encryption (e.g. IPsec), since access to the TCP

header neededFor ‘state-full’ versions:– Requires buffer management at Proxy– Requires state transfer when hand-over to different proxy occurs– Hard state: Failures of proxy can result in loss of data


Wireless TCP: Link-Layer Approach

• Proxy detects losses over the wireless link• Proxy does local retransmission before the sender timeouts. Hides the

wireless losses from the Sender• TCP-unaware approaches: FEC, local retransmission• TCP-aware approaches: e.g. SNOOP (but: filtering of dup Acks!)

TCP

IP

Layer 2

Layer 1IP

Network

IP

Layer 2

Layer 1

Sender Proxy

TCP

IP

Layer 2

Layer 1

MH

[Source: G. Reuss]


Wirless TCP: Link-Layer Approach• TCP-aware approach: SNOOP

– Buffering of down-stream packets in mobile host (until receipt of Ack)– Local retransmission of lost-packets– Filtering of up-stream dup-Acks– Soft-state at Base-station (loss of state affects performance but not correctness)

Discussion: Link-Layer Approaches• Advantages

– No modification to TCP layer in end hosts– Prevent propagation of losses/errors to TCP source

• Disadvantages– TCP-aware link layer solutions cannot be used with IPSec– Link-layer retransmission cause RTT variations (and thus possibly TCP time-

outs)– Not usable if data and Ack traverse different paths)


Wirless TCP: End-to-end approach• TCP Protocol Stack at Sender and Receiver enhanced

e.g. SACK, FACK, D-SACK, Eifel• Possible enhancements

– Differentiate Lossese.g. no slow-start for wireless losses

– Efficient Utilisation of Bandwidthe.g. no initial slow-start

– Detection of Multiple Losses• Advantages

– End-to-End semantics and layered architecture of network protocols are preserved

– IP packet encryption can be used• Disadvantage

– Modification at end host[Source: G. Reuss]


End-2-End Enhancements: SACK

TCP Reno inefficient for multiple packet losses within congestion windowExtension: Selective Acknowledgement (SACK)

SACK principles:• Several (3) SACK blocks mark successfully received sets of data (in TCP

Option header extension)• Sender maintains scoreboard of successfully transmitted packets• Special treatments of partial Acks during Fast Recovery

Allows retransmission of more than one segment per RTT


Wireless TCP: Performance Comparison (ns simulation)

Single source scenario with burst errors on wireless link (ε1=1 ≅ ca 28% packet loss)Snoop (Split-TCP) together with SACK provides best goodput

Source: Master Thesis, D. Höllisch

Congestion scenario (20 ON/OFF TCP sources) with same wirless link model:

Combination SACK with Snoop shows much lower goodput than Snoop by itself


Other Improvements

• Shortened Connection set-up– Transaction oriented TCP (RFC 1644)

• Large Initial Windows• Hand-over Improvements

– Send (forced) dup-Acks after hand-over• TCP improvements in ad-hoc (wireless multi-hop) scenarios


Content








Improvements


8. Outlook

Exercises


Motivation: Performance measurements in GPRS networks

GPRSBackbone

SGSN GGSNBSC

HTTP Server

RADIUS

DHCPRadius/DHCP

Client

Core Network InternetRAN

HTTP

TCP

IPLink-Layer

L5-7

L4

L3

L2

• GPRS system (3 time-slots, coding scheme 2): 40.2 kb/s ‚raw‘ throughput

• Substracting overhead L1-L4 headers: 33kb/s• BUT in performance measurements using HTTP: 10-20kb/s

Performance predictions need to consider all protocols, in particular Transmission Control Protocol (TCP)


GPRS: General Packet Radio Service

• Packet Switched Extension of GSM• 1996: new standard developed by ETSI• Components integrated in GSM architecture• Improvements:

– Packet-switched transmission– Higher transmission rates on radio link (multiple

time-slots)– Volume based charging ‚Always ON‘ mode

possible• Operation started in 2001 (Germany)


GPRS - Architecture

PDN

Other

PLMN

GSM GPRS

BTS

CCU

MSC

BSC

PCU

HLR GR

GGSN

Components

A Abis Gb Gp

Gs

Gn

G Gr

Gi

UmBSS

SGSN

MS

Components:• CCU: Channel Coding Unit• PCU: Packet Control Unit• SGSN: Serving GPRS Support Node • GGSN: Gateway GPRS Support Node• GR: GPRS Register

Transmission: • Packet Based Transmission• Radio link:

– Radio transmission identical to GSM– Different coding schemes (CS1-4)– Use of Multiple Time Slots

• Volume Based Charging


TCP/IP in GPRS

• No end-2-end IP Routing in GPRS network• Fragmentation in LLC frames & RLC blocks• Potential bottleneck: air-interface (≈10-50kbit/s)


GPRS Boundary conditions & Simulation Parameters

GPRS Boundary conditions• RTT between 700ms and 1sec (for 40 Byte packet with no queueing delay)• Possible modes: RLC Ack/unAck mode, LLC Ack/unAck mode• Coding Scheme 2 raw 13.4 kb/s per Time-Slot)• Possible use of 1-4 downlink time-slots supported in practice (here: 3 time-slots)• Cell Reselection: between 5-40 seconds disruption of data connection

Simplified Simulation Model(TCP Reno, fixed packet size, constant transmission delays, no delayed Acks)

Two Scenarios:• Packetsize 1460 Bytes: Max Throughput (L4) 33kbit/sec• PacketSize 536 Bytes: Max Throughput (L4) 31.5kbit/sec


TCP Throughput in simplified GPRS Setting

RecWin limits throughput for large connectionsThroughput in short connections reduced due to slow-startScenario without congestion (single TCP connection)

[Correction: y-axis in kbit/s]


Other issues: Choice of Maximum Segment Size

Parameters:Coding Scheme 2 Downlink: 4 time-slotsUplink: 1 time-slotMax. Window Size 8100BNo Impact of Slow-StartNo losses/congestion

Larger MSS reduces overheadBut increases RTT


Solution in Practice: Proxies (Split-TCP)

E.g. ‚Mobile Smart Proxy‘ (MSP):• TCP Optimizations (Larger initial window, etc.)• Content caching and compression (http)• User authentication (Radius) and access control• Content aware billing

GPRSBackbone

SGSN GGSNBSC

HTTP Server

RADIUS

DHCP

Core Network InternetRAN

MSP


Content

1. Background • IP, Transport Layer Protocols (UDP,

TCP, SCTP, RTP)

2. TCP functionality• Connection

establishment/termination• flow/congestion control (slow-start,

congestion avoidance, fast retransmit, fast recovery)

3. TCP Performance Aspects• Performance parameters• Simulation Results• Performance Models, in particular

fix-point models (using M/M/1/K queue)

5. Wireless TCP• Problem statement

• Performance degradation

• TCP Improvements: split-TCP, link-layer approaches (SNOOP), end-2-end approaches (SACK)


Improvements


8. Outlook

Exercises


Outlook: research topics, Wireless TCP

• TCP optmizations– Cross-layer– Trade-off congestion behavior & wireless link performance

enhancement • (Wireless) TCP modeling• TCP in ad-hoc networks

Other interesting topics (not touched in this lecture):• Scheduling for TCP traffic (e.g. Random Early Dropping RED)• TCP and QoS architectures/mechanisms (e.g. starvation)• TCP over satellite links


References• IETF (www.ietf.org)

– RFCs: UDP (768), TCP (793,1122, 1072, 1106, 1110, 2018, 2414, 2582), SCTP (2719, 2960), RTP (1889)

– WGs: PILC,TCPSAT• W. Stevens: TCP/IP illustrated, Vol.1. Addison-Wesley 1994.• TCP modeling

– Padhye, Firoiu, Towsley, Kurose: Modeling TCP throughput: A simple model and its empirical validation. ACM SIGCOMM, 1998.

– Heyma, Lakshman, Neidhardt: A new method for analysing feedback-based protocols with applications to engineering web traffic over the Internet. ACM Sigmetrics, 1997.

– Schwefel: Behavior of TCP-like elastic traffic at a buffered bottleneck router. Infocom 2001.• TCP Improvements:

– Fall, Floyd: Simulation-based comparison of tahoe, reno, and tcp sack. Computer Communication Review, 1996.

• J. Schiller: ’Mobile Communications’. Addison-Wesley, 2000.• Tutorials, see next slide


Acknowledgements• Student work (all TU Munich)

– Raimund Brandt (Seminar), Helmut Obermeier (Msc Thesis), Daniel Höllisch (Msc Thesis)

• InfotechLecture notes: IP Based Networks and Applications, Chapter 3 (J. Charzinski), www.jcho.de/jc/IPNA

• Tutorial: IP Technology in 3rd Generation mobile networks, Siemens AG (J. Kross, L. Smith, H. Schwefel)

• Lecture Notes: Networking Introduction (J. Kurose, K. Ross)• Lecture notes: Mobile Communciations, Jochen Schiller, www.jochenschiller.de• Tutorial: TCP for Wireless and Mobile Hosts (N. Vaidya),

www.cs.tamu.edu/faculty/vaidya• Siemens AG: D. Weber, S. Rugel, G. Reuss


BACKUP


GSM: Global System for Mobile Communication

• 2nd Generation of Mobile Telephony Networks• 1982: Groupe Spèciale Mobile (GSM) founded• 1987: First Standards defined• 1991: Global System for Mobile

Communication, Standardisation by ETSI (European

Telecommunications Standardisation Institute) - First European Standard

• 1995: Fully in Operation

History:


GSM – Architecture

Components:• BTS: Base Transceiver Station• BSC: Base Station Controller• MSC: Mobile Switching Center• HLR/VLR: Home/Visitor Location

Register• AuC: Authentication Center• EIR: Equipment Identity Register• OMC: Operation and

Maintenance Center

Transmission: • Circuit switched transfer• Radio link capacity: 9.6 kb/s

(FDMA/TDMA)• Duration based charging

BSC

BSC

MS

BTS

BTS

BTS

MS

MS

MSC

HLR

VLR

OMC

EIR

AuC

O

Abis AUm

Radio Link

Base StationSubsystem

Network andSwitchung Subsystem

OperationSubsystem

Connection toISDN, PDNPSTN

Radio Subsystem (RSS)

Wireless Data Communication - Aalborg Universitetkom.aau.dk/~hps/WDC_Fall03/lecture4-TCP.pdf ·...

Documents

Transcript of Wireless Data Communication - Aalborg Universitetkom.aau.dk/~hps/WDC_Fall03/lecture4-TCP.pdf ·...