1 cmpe 252a: computer networks set 13: end-to-end transmission control (tcp and udp)
TRANSCRIPT
1
CMPE 252A: Computer Networks
Set 13: End-to-End Transmission Control (TCP and UDP)
2
Transport Protocols
Services: Addressing of processes Reliable or unreliable transport from
source process to end process(es) Multiplexing and demultiplexing Flow control
Avoid overflowing receiver’s buffer Congestion control
Avoid overflowing the network bottleneck Examples: UDP and TCP
3
Why Multiplexing
IP delivers packets from source host to destination host.
However, multiple processes run in the hosts! Applications require communication among
processes, not just host computers. Example: Multiple telnet sessions, email, ftp
sessions, and www can all be running concurrently in the same host.
Ports are defined as the addresses of processes inside a host.
How do we identify processes uniquely and efficiently?
4
Well-Known Applications Well-known ports under 1024, such as
FTP - port # 21 Telnet - port # 23 HTTP - port # 80
Host A Host BClient Server
Source port = x Source port = 23
Dst. port = 23 Dst. port = x
Segment
5
Transport Protocols
Transport protocols used today are point to point UDP used for:
Remote file server (NFS), name translation (DNS), intra-domain routing (RIP), network management (SNMP), multimedia applications.
TCP used for: Electronic mail (SMTP), file transfer (FTP),
remote login (Telnet), web (HTTP)
No standard multipoint e-t-e protocol yet!
6
UDP: User Datagram Protocol [RFC 768]
“No frills,” “bare bones” Internet transport protocol
“Best effort” service, UDP segments may be:
Lost Delivered out of order to
app Connectionless:
No handshaking between UDP sender, receiver
Each UDP segment handled independently of others
Why is there a UDP?• No connection establishment
(which can add delay)• Simple: no connection state
at sender, receiver• Small header• No congestion control: UDP
can blast away as fast as desired
7
UDP Header specifies the minimum
needed for multiplexing and framing.
Source and destination ports: identify the end points.
Often used for streaming multimedia apps Loss tolerant Rate sensitive
Other UDP uses: DNS
Reliable transfer over UDP Must be at application layer Application-specific error
recovery
Source port # Dest port #
32 bits
Applicationdata
(message)
UDP segment format
Length Checksum
Length, inbytes of
UDPsegment,includingheader
Checksum: optional; if not used, set to zero.
8
UDP Checksum
Computed over a pseudo-header + UDP header+data+padding (to even number of bytes if needed).
Pseudo-header:0 31
Source IP address
Destination IP address
00000000 Protocol Segment length
9
High-Level TCP Characteristics Protocol implemented entirely at the ends
Fate sharing (on IP) Protocol has evolved over time and will
continue to do so Nearly impossible to change the header Use options to add information to the header Change processing at endpoints Backward compatibility is what makes it TCP
10
Differences From Link Layer Logical link vs. physical link
Must establish connection Variable RTT
May vary within a connection Reordering
How long can packets live implies max segment lifetime
Endpoints need not match link Buffer space availability
Transmission rate Must be found
11
TCP in a Nutshell
Abstraction: Reliable. Ordered. Point-to-point. Byte-stream.
Mechanisms: Window-based flow
control. Sequence
numbers/ordering, 3-way handshake.
Reliability (ACK, retransmission policies).
Congestion control. RTT estimation.
12
TCP Header
Source port Destination port
Sequence number
Acknowledgement
Advertised windowHdrLen Flags0
Checksum Urgent pointer
Options (variable)
Data
Flags: SYNFINRESETPUSHURGACK
13
History of TCP “The” Internet protocol for reliable end-to-end
communication First key paper:
V. Cerf and R. Kahn, “A Protocol for Packet Network Interconnection,” IEEE Trans. Commun., 1974, pp. 627-641.
Designed per se in the early ‘80s J. Postel, RFC 793 (also IP and UDP) Network assumptions:
reliable links losses due to congestion only! symmetric network connections Implicit in order delivery of packets (more than IP can promise!)
14
Evolution of TCP
1975 1980 1985 1990
1982TCP & IP
RFC 793 & 791
1974TCP described by
Vint Cerf and Bob KahnIn IEEE Trans Comm
1983BSD Unix 4.2
supports TCP/IP
1984Nagel’s algorithmto reduce overhead
of small packets;predicts congestion
collapse
1987Karn’s algorithmto better estimate
round-trip time
1986Congestion
collapseobserved
1988Van Jacobson’s
algorithmscongestion avoidance and congestion control(most implemented in
4.3BSD Tahoe)
19904.3BSD Renofast retransmitdelayed ACK’s
1975Three-way handshake
Raymond TomlinsonIn SIGCOMM 75
15
TCP Through the 1990s
1993 1994 1996
1994ECN
(Floyd)Explicit
CongestionNotification
1993TCP Vegas
(Brakmo et al)delay-based
congestion avoidance
1994T/TCP
(Braden)Transaction
TCP
1996SACK TCP(Floyd et al)
Selective Acknowledgement
1996Hoe
NewReno startup and loss recovery
1996FACK TCP
(Mathis et al)extension to SACK
16
Services Provided
End-to-end flow control Reliable byte stream In-order packet delivery (buffering) Connection-oriented
Socket <host address, port> uniquely identify connection
17
TCP Service Model
TCP connections are full-duplex and point-to-point.
Byte stream (not message stream). Message boundaries are not preserved
e2e. A B C D
Four 512-byte segments sent asseparate IP datagrams
A B C D
2048 bytes of data deliveredto application in single READ
18
TCP Byte Stream When application passes data to TCP,
it may send it immediately or buffer it.
Sometimes application wants to send data immediately. Example: interactive applications. Use PUSH flag to force transmission.
URGENT flag. Also forces TCP to transmit at once.
19
TCP Header Important fields:
source port and destination port: identify connection end points
32 bit SN: identifies byte in segment 32 bit ACK: identifies next byte expected 4 bit header length: how many 32-bit words in header 16-bit window size (max. 64KB) advertised by the receiver
(RAW) checksum: checks header, data and pseudo-header Flags: SYN, FIN, ACK, URG, PUSH Options: Way to add more information.
Important: Only one sequence number! Identifies the segment, but does not identify
which retransmission of the segment is being sent!
20
TCP Header Flags
Six TCP flags: URG: indicates urgent data present; urgent pointer
gives byte offset from current sequence number where urgent data are. Generally not used.
ACK: indicates whether segment contains acknowledgment; if 0, acknowledgement number field ignored.
PUSH: indicates PUSHed data so receiver delivers it to application immediately. Generally not used.
RST: used to reset connection, reject invalid segment, or refuse to open connection.
SYN: used to establish connection; connection request, SYN=1, ACK=0.
FIN: used to release connection.
21
TCP Connection Management
TCP ClientLifecycle
TCP ServerLifecycle
22
TCP Transmission
Sender process initiates connection. Once connection established, TCP
can start sending data. Sender writes bytes to TCP stream. TCP sender breaks byte stream into
segments. Each byte assigned sequence number. Segment sent and timer started.
23
TCP Transmission
If timer expires, retransmit segment. After retransmitting segment for maximum
number of times, assumes connection is dead and closes it.
If user aborts connection, sending TCP flushes its buffers and sends RESET segment.
Receiving TCP decides when to pass received data to upper layer.
24
Timeout-Based Recovery
Wait at least one RTT before retransmitting Importance of accurate RTT estimators:
Low RTT unneeded retransmissions High RTT poor throughput
RTT estimator must adapt to change in RTT But not too fast, or too slow!
Spurious timeouts “Conservation of packets” principle – more than
a window worth of packets in flight
3-25
TCP Sender Events:Data received from
app: Create segment with
seq # Seq # is byte-stream
number of first data byte in segment
start timer if not already running (think of timer as for oldest unacked segment)
expiration interval: TimeOutInterval
Timeout expires: Retransmit segment
that caused timeout Restart timer
Acknowledgments: If acknowledges
previously unacked segments
update what is known to be acked
start timer if there are outstanding segments
3-26
TCP ACK Generation [RFC 1122, RFC 2581]
Event at Receiver
Arrival of in-order segment withexpected seq #. All data up toexpected seq # already ACKed
Arrival of in-order segment withexpected seq #. One other segment has ACK pending
Arrival of out-of-order segmenthigher-than-expect seq. # .Gap detected
Arrival of segment that partially or completely fills gap
TCP Receiver action
Delayed ACK. Wait up to 500msfor next segment. If no next segment,send ACK
Immediately send single cumulative ACK, ACKing both in-order segments
Immediately send duplicate ACK, indicating seq. # of next expected byte
Immediate send ACK, provided thatsegment starts at lower end of gap
3-27
TCP Seq. #’s and ACKsSeq. #’s:
byte stream “number” of first byte in segment’s data
ACKs: seq # of next byte
expected from other side
cumulative ACK Piggybacking
NOTE: TCP spec does not dictate how receiver handles out-of-order segments
(store them with modern hardware)
Host A Host B
Seq=42, ACK=79, data = ‘U’
Seq=79, ACK=43, data = ‘U’
Seq=43, ACK=80
Usertypes‘U’
host ACKsreceipt of echoed‘U’
host ACKsreceipt of‘U’, echoesback ‘U’
timesimple telnet scenario
28
Flow Control vs. Congestion Control
Congestion control Global issue: concerns all routers and
hosts on path from Source to Destination make sure every subnet can handle the
traffic
Router
Senders
Receiver
Router
1Mbps 1Mbps1Mbps
29
Flow Control vs. Congestion Control
Flow Control Involves two endpoints Make sure sender doesn’t transmit
faster than receiver can absorb packets
Server1Gbps
PC1Mbps
File transfer
30
End-to-End Congestion Control
Why do it at the transport layer? Real fix to congestion is to slow down
sender. Use law of “conservation of packets”.
Keep number of packets in the network constant, just below maximum that bottleneck can take
Don’t inject new packet until old one leaves.
Congestion indicator: packet loss.
31
TCP Flow Control TCP is a sliding window protocol
For window size n, can send up to n bytes without receiving an acknowledgement
When the data is acknowledged then the window slides forward
Each packet advertises a window size Indicates number of bytes the receiver has
space for Original TCP always sent entire window
Congestion control now limits this
32
Self-Clocking
If we have large actual window, should we send data in one shot? No, use ACKs to clock sending new data.
PrPb
Ar
Ab
receiversender
As
33
TCP Congestion Control Mechanisms
Collection of interrelated mechanisms: Slow start. Congestion avoidance. Accurate retransmission timeout
estimation. Fast retransmit. Fast recovery.
34
TCP Flow Control Transmission Window, a.k.a. congestion window ( cwnd )
Sliding window maintained by sender conservation of packets
Receiver’s window set through socket API controlled by the receiver advertised to the sender in field of TCP header ( RAW )
cwnd
1 2 3 4 5 6 7 8 9 10 11 12 ...Sent and ACKed
Sent, not ACKed
Send ASAP
Can’t send
35
ReceiverReceiverSenderSender
Sender/Receiver Statew/o Buffering at Receiver
… …
Sent & Acked Sent Not Acked
OK to Send Not Usable
… …
Max acceptable
Receiver window
Max ACK received Next seqnum
Received & Acked Acceptable Packet
Not Usable
Sender window
Next expected
36
acknowledged sent to be sent outside window
Source PortSource Port Dest. PortDest. Port
Sequence NumberSequence Number
AcknowledgmentAcknowledgment
HL/FlagsHL/Flags WindowWindow
D. ChecksumD. Checksum Urgent PointerUrgent Pointer
Options…Options…
Source PortSource Port Dest. PortDest. Port
Sequence NumberSequence Number
AcknowledgmentAcknowledgment
HL/FlagsHL/Flags WindowWindow
D. ChecksumD. Checksum Urgent PointerUrgent Pointer
Options...Options...
Packet Sent Packet Received
App write
Window Flow Control: Send Side
37
TCP Flow Control: Observations
TCP sender not required to transmit data as soon as it comes in form application. Example: when first 2KB of data come in,
sender could wait for more data since window is 4KB.
Receiver not required to send ACKs as soon as possible. Example: Wait for data so ACK is
piggybacked.
38
Data Flow Conservation of packets
Inject new packets at the rate ACKs are returned by receiver
New window: cwnd initially cwnd = 1 segment
Sender’s window = min(cwnd, RAW)
39
TCP Congestion Control Slow Start
Due to Van Jacobson (SIGCOMM 88) Algorithm:
Initialize cwnd = 1 MSS. If an ACK is received before timeout: cwnd = cwnd + 1 MSS for each acknowledged
segment
Algorithm used at the beginning of a connection and after a timeout
Leads to exponential growth in the amount of outstanding data in network
cwnd doubles every RTT epoch (i.e., once last segment in current window is acknowledged)
How do we avoid congesting the network?
40
Slow Start Example
1
one RTT
one pkt time
0R
21R
3
42R
567
83R
91011
1213
1415
1
2 3
4 5 6 7
41
When Should Slow-Start End?Congestion Avoidance
Want to end slow start when the pipe is full! When cwnd > ssthresh. Start with large ssthresh, but then refine it.
Slow start continues until BWDP is exceeded, then: Routers drop packets -- losses occur Need to stop exponential increase!
Use congestion avoidance to deal with lost packets! Slow down the transmission rate Provide for linear increase of the transmission
window Congestion avoidance implemented together with slow
start
42
Congestion Avoidance Introduce a new variable, ssthresh
Initialized to 65,535 (max. window) On packet loss (timeout):
Set ssthresh = cwnd/2 and cwnd = 1 Re-enter slow start, until cwnd = ssthresh
When cwnd = ssthresh, then Grow cwnd linearly until it reaches RAW When ACK is received before timeout then set cwnd = cwnd + 1/cwnd Hence, cwnd increases by 1 segment every RTT
43
Putting it together: Slow start and congestion avoidance
The algorithm: If cwnd < ssthresh
do slow start Else if cwnd > ssthresh
do congestion avoidance
44
Problems with CA and SS Slow start is an attempt to discover the
network bandwidth (quickly) Discovery proceeds by filling network
queues in intermediate routers. Once queues are full, routers drop packets. Once loss is discovered, it’s too late! TCP sender reduces window when loss is
discovered Queue level oscillates between full and
cwnd/2 What sort of problems does this introduce?
45
Tahoe TCP Congestion Control: Under-damped Feedback
System!cwnd
rt times
ssthresh
ssthresh/2
1 MSS
Very drastic a reaction to congestion!
Slow start
Congestion
avoidance
Waiting
timeout
Slow start
Congestion
avoidance
46
Tuning TCP Tahoe’s Congestion Control
Coarse timeouts remained a problem, and Fast retransmit was added with TCP Tahoe.
Timeouts can cause connections to be idle for a long time waiting for timer to expire.
Fast retransmit: may trigger retransmission of dropped packet sooner. Complements regular timeouts.
47
Fast Retransmit When can duplicate ACKs occur?
Loss, packet re-ordering, or sender waits for some number of duplicate ACKs before retransmitting.
Assume packet re-ordering is infrequent. Use receipt of 3 or more duplicate ACKs as
loss indicator Retransmit that segment before timeout.
Generally, fast retransmit eliminates about half the coarse-grain timeouts.
Conventional wisdom is that this yields roughly a 20% improvement in throughput.
Note – fast retransmit does not eliminate all the timeouts due to small window sizes at the source.
48
Reno: Fast Recovery Goal:
Reduce the number of times connection is slow-started.
Use ACKs in the pipe for self-clocking. In congestion avoidance mode,
after fast retransmit, reduce cwnd to half (rather than dropping it to 1).
Reno vs Tahoe: Slow start only used in the beginning of connection or when timeout occurs.
49
Reno: Tahoe with Fast Retransmit and Recovery
If 3 duplicate ACKs for segment N received: Retransmit segment N. Set ssthresh = 0.5*cwnd. Set cwnd = ssthresh + 3*MSS. [account for 3 duplicate ACKs]
For every subsequent duplicate ACK: Increase cwnd by 1 segment.
When “new” ACK received to retransmitted packet: Reset cwnd = ssthresh Resume congestion avoidance.
Result: cwnd is reset to half of the old cwnd after fast recovery
50
Delayed ACKs Tries to optimize ACK transmission. Delay ACKs (500msec) hoping to
piggyback on data segment. Example: telnet to interactive editor:
Send 1 character at a time: 20-byte TCP header+ 1-byte data+20-byte IP header.
Receiver ACKs immediately: 40-byte ACK. When editor reads character, window
update: 40-byte datagram. Then echoes character back: 41-byte
datagram.
51
Example Simple Bottleneck
Packet size = 1Kbyte Initial ssthresh = 32 packets BWDP (capacity of network) = 16.3 Kbyte Queue capacity = 17 packets
52
Reno: Congestion Window and Queue Growth
53
Reno: Congestion Window and Queue Growth
Queues fill once window grows larger than 17 packets After packet loss, Reno cuts window and starts again See-saw oscillations in window and queue length
increases end-to-end delays bad for real-time and interactive applications
54
So far…
Have way to fill pipe (slow start). Have way to run at equilibrium
(congestion avoidance). But tough transition.
No good initial ssthresh. Large ssthresh causes packet loss. Need approaches to quickly recover from
packet loss.
55
How Do Losses Occur? Bit errors detected by CRC Wireless links: common place Congestion in network - packets
dropped by routers competing data flows window exceeds bandwidth delay
product (BWDP) Note that BWDP is a function of
length (prop delay) of link and bandwidth
56
Error Recovery After Timeouts and duplicate ACKs. Sender retransmits segment after a
Timeout Sender must estimate connection RTT
times one packet per windowperforms smooth average over time
• rtt = β*old_rtt + (1-β) * rtt_sample (e.g., β = 0.875)•RTO = rtt + 4 * dev• Difference = rtt_sample – rtt_estimated• rtt_estimated = rtt_estimated + (δ x
Difference)• dev = δ (|Difference| - Deviation) and0 < δ < 1
57
Error Recovery (Conc.)
Sender also retransmits segment after 3 duplicate ACKs Receiver sends cumulative ACK stating the
next in-order packet expected Missing packet causes generation of
duplicates No theoretical reason for 3
58
Estimating RTT
Karn, P. and Partridge, C. 1987, “Improving Round-Trip Time Estimates in Reliable Transport Protocols”
Reno performs one RTT estimate per window of data What do we do when there is a timeout and
retransmission? When ACK arrives, does it refer to 1st or 2nd transmission?
Karn and Partridge’s solution: Don’t update RTT on any segments that have been
retransmitted Instead, double timeout on each failure, until successful Goal: Induce exponential backoff!
This is a direct result of using a single sequence number over a non-FIFO link!
TCP option can be used with time stamps!
59
Example RTT Estimation:RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
100
150
200
250
300
350
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
RTT (milliseconds)
SampleRTT Estimated RTT
TCP New RenoTCP New Reno Two problem scenarios with TCP Reno
bursty losses, Reno cannot recover from bursts of 3+ losses
Packets arriving out-of-order can yield duplicate acks when in fact there is no loss.
New Reno solution – try to determine the end of a burst loss.
60
TCP New RenoTCP New Reno When duplicate ACKs trigger a retransmission for a
lost packet, remember the highest packet sent from window in recover.
Upon receiving an ACK, if ACK < recover => partial ACK If ACK ≥ recover => new ACK
Partial ACK implies another lost packet: Retransmit next packet, inflate window and stay in fast
recovery. New ACK implies fast recovery is over:
Starting from 0.5 x cwnd proceed with congestion avoidance (linear increase).
Positive result: New Reno recovers from n losses in n round trips.
Many servers support New Reno 61
62
Evaluation of TCP Reno Good:
Tries to adapt to network conditions, uses the Internet transparently.
Undesirable: Error recovery:
RTT measurements and assumptions of link reliability. Sequence numbering evolved from ARQ schemes that assume in-order
delivery of packets. Caveat: wireless networks and mobility
Congests to discover bandwidth available in the connection: Creates congestion and fills network queues until a loss occurs.
Poor performance over asymmetric networks RTT is used, rather than forward delay! Internet is asymmetric
Out-of-order packet delivery happens When is a packet really lost? No packet self clocking!
Could be improved: Every object is not just a byte stream with the same service needs!
63
Improvements to TCP
CUBIC: meant for high-speed networks. Meant to improve TCP friendliness and RTT fairness. Throughput is defined by packet loss rate only and not RTT.
SACK: include information in the ACK which indicates missing packets in the window
Vegas: use rate control instead of arrival of ACKs to pace data into network
Santa Cruz: use relative delay over forward path to anticipate queue buildup
64
Extras…
65
Goals for “TCP Santa Cruz”1. Improve detection of congestion
Decouple error control from congestion control Don’t rely on packet loss Identify direction of congestion
2. Improve congestion control Don’t fill network queues Robust to congestion on reverse path and to
ACK loss Isolate forward throughput from events in
reverse path
3. Provide high throughput, low delay and delay variation
66
Error Recovery
1. Improve RTT estimate by timing each packet, including retransmissions
identify by SN and copy numbereliminate Karn’s algorithmtime packets when needed most during
congestion2. Retransmit after 1st duplicate ACK if
necessary (Vegas does this for original transmissions)
3. Receiver transmits an ACK window to indicate holes in the transmission stream
67
ACK Window Provides status of every packet within send
window Each bit represents a specified number of
bytes received Granularity of bit determined by the receiver
68
Congestion Control
Detect changes in queue length at the bottleneck link
Monitor the relative delay over the link: Delay that one packet experiences with
respect to another Limit number of packets in bottleneck queue Calculated by sender from a timestamp
returned by the Receiver
69
Relative Delay Calculation Dj,i = 0 no additional
queuing
Dj,i > 0 increased queuing on forward path
Dj,i < 0 decreased queuing on forward path
Dj,i = Rj,i - Sj,i
70
Congestion Control Algorithm
1. Let Nop be the desired number of packets, per session, queued at
the bottleneck2. For each pair of ACKs received,
Sender computes:Relative Delay: D = R - SCurrent packet service time at receiver:
•pktS = R / # pkts received
71
Congestion Control Algorithm (cont.)
3. Translate the relative delay into packets:
(a) Queuing over window interval: • sum delay measurements for all packet pairs and divide by
average packet service time
(b) Total queuing:
72
Congestion Control Algorithm (cont.)
4. Window adjustment policy:• controls amount of outstanding data in
network• Goal is to maximize throughput and minimize
delay
if ni == Nop maintain current window size if ni < Nop increase by one segment if ni > Nop decrease by one segment
73
Simulations ns-2 Network Simulator Derived protocol from existing TCP
implementation Compare TCP-Santa Cruz to Reno and
Vegas 3 configurations:
Simple bottleneck Traffic on reverse path Asymmetric configuration
74
Experiment #1 simple bottleneck
Packet size = 1Kbyte BWDP (capacity of network) = 16.3 Kbyte Queue capacity = 17 packets
75
Reno: Congestion Window and Queue Growth
Queues fill once window grows larger than 17 packets After packet loss, Reno cuts window and starts again See-saw oscillations in window and queue length
increases end-to-end delays bad for real-time and interactive applications
76
TCP-Santa Cruz: Congestion Window and Queue Growth
Nop = 1 (minimal queuing to reduce delays)
Window at desired operating point: 17 + 1 = 18 No see-saw oscillations in window and queue length !! Transmits at available bandwidth without introducing
congestion No overflow of network queues
77
Simple Bottleneck - summary
TCP Santa Cruz provides: Slightly improved throughput (not much room for
improvement) Lower delay (20 - 45% )improvement over Reno Reduced delay variance over Reno and Vegas
78
Experiment #2 - Reverse Traffic
Question: Is throughput affected by reverse path traffic?
Goal: Isolate forward throughput from reverse path events ! can’t be done with RTT measurements!
No reason to slow forward path transmission rate
79
Reverse Traffic: Window Growth
Reno Window growth slowed because of lost and
delayed ACK packets Loss detection is also delayed
Santa Cruz Nop = 5 Achieves optimal window size: 17 + 5 = 22
80
Reverse Traffic - Summary
Throughput: Santa Cruz achieves 47 - 67% improvement Delay: Santa Cruz achieves 45 - 59% improvement Delay variance: 3 orders of magnitude improvement
81
Experiment #3 Network Asymmetry
ADSL, HFC, Combination Networks: e.g., telephone upstream, cable downstream
Forward path: 24Mbps 3000 pkts/sec Reverse path: 320kbps 1000 pkts/sec Asymmetry factor: k = 3 commonplace
82
Reverse Traffic - Summary
Throughput: Santa Cruz achieves 99% improvement
Delay: Santa Cruz achieves 42 - 58% improvement over Reno
83
Conclusion High throughput Low end-to-end delay and delay variation Isolate forward throughput from events on
reverse path ACK loss, congestion on reverse path,
asymmetric links Problems:
Modify AID (additive increase and decrease) to ensure fairness under multiple sources!
Problems with different bottlenecks? Wireless
84
TCP-SACK Goal: Improve TCP error recovery mechanism Selectively acknowledge lost data within the transmission
window Uses sequence number ranges
example: ACK = 1000, SACK = 1040:1080 Limited by max. size of TCP header to 3 distinct ranges Important when there are multiple losses per window
multiple losses often results in a timeout Significance performance improvements in wired networks
85
MSS (Maximum Segment Size)
Largest “chunk” of application-level data can be specified in SYN segment, else
default Typical values are 1500, 536 and 512 bytes
“non-local address” - default 536 bytes
Ex: In practice MSS is limited by MTU of LAN… limited by outgoing interface’s MTU of 1500 bytes