Lecture 7

Outline
[Comer] - ch. 12 & 13 [Stevens] - ch. 11, 17, 18, 19, 20, 21, 22, 23, & 24
Introduction UDP Protocol Overview
Internetworking with TCP/IP (ETC003) Lecture 7: Transport Protocol
UDP Datagram Format UDP Ports UDP Datagram Size Limits UDP Datagram Truncation TCP Protocol Overview TCP Communication Model TCP Reliable Stream Delivery
Adrian Popescu, 2003, 2004
Dept of Telecommunications & Signal Processing

Internetworking with TCP/IP - ETC003 - Lecture 7
1/38

2/38
TCP Segment Format TCP Operation Connection Establishment & Termination Maximum Segment Size Data Transfer Implementation Options Flow Control Retransmission Timer Management Window Management Silly Window Syndrome New Developments
Internetworking with TCP/IP - ETC003 - Lecture 7 3/38
Introduction
Network Layer
NL protocols are fundamentally datagram-oriented and unreliable
Transport Layer & Session Layer

Main responsability: to enhance QoS to that requested by applications These protocols provide process-to-process communication Also called host-by-host protocols Another denition used: session management protocols

4/38
Introduction (cont.)
Major alternatives today for host-to-host protocols
User Datagram Protocol (UDP) Provides almost no functionality over IP Performs fast, unreliable datagram delivery Transmission Control Protocol (TCP) Provides reliable, stream-oriented delivery One of the most important protocols, but also one of the most complex Remote Procedure Call (RPC) Application transport protocol (client-server model) Designed for programs to make subrutine calls on other systems Request-reply protocol, mostly limited to LAN Uses UDP datagrams, adding own facilities for insuring data transfer Real-Time Transport Protocol (RTP) Used to transmit digitized audio or video signals over an IP internet Used together with RTP Control Protocol (RTCP) Does not provide timely delivery but mechanisms to control playback Uses UDP datagrams
UDP Protocol Overview

Main characteristics
Datagram-oriented protocol Provides unreliable, connectionless service Delivery not guaranteed, duplicate protection not guaranteed UDP datagrams can be lost, duplicated or arrive out-of-order, or delayed Checksum (optionally) guarantees integrity of data; it covers both header & data An UDP datagram is silently discarded if checksum errors; no error message generated UDP endpoints: ports A pair (IP address; UDP port) uniquely identies a delivery point (usually a single process on a specic machine) Main advantage: low overhead Adequate for many applications: DNS, NSF, SNMP, TFTP, DHCP, BOOTP, VoIP, MoIP, etc. UDP protocol is dened in RFC768

6/38
UDP Datagram Format

0 65.515 bytes (max) 8 bytes Source Port UDP Datagram Length 16 Destination Port UDP Checksum 31
UDP Ports
Port assignment
Communicating units must agree on a port number Server opens selected port and waits for incoming messages Client selects local port and sends message to selected port Obs: destination port and source port may be different Ways to assign ports Universal assignment (central authority) Port assignments specied by authority are called well-known port assignments Examples (/etc/services): echo (7/udp); time (37/udp); name (42/udp); domain (53/udp); tftp (69/udp); who (513/udp); etc. Dynamic binding Dynamically assigned port numbers
Data
Source Port (16 bits): optional; species the port address of the source; used to multiplex data from more processes onto the same UDP unit Destination Port (16 bits): species the port address of the destination; used to demultiplex datagrams among the processes waiting for them UDP Datagram Length (16 bits): information (in bytes) about the length of UDP datagram (header and data); minimum value is 8, i.e., header only UDP Checksum (16 bits): optional; covers more information than present in the UDP datagram alone, i.e., UDP Pseudo-Header (12 bytes) & UDP Header (8 bytes) & Data & Pad Byte; Obs: Pseudo-Header and Pad Byte are NOT transmitted with the UDP datagram, but used only for checksum computation (to check right destination, i.e., right port number at the right IP address)

8/38
UDP Datagram Size Limits

Theoretical limit
65.507 bytes (UDP data) + 8 bytes (UDP header) = 65.515 bytes (max) Obs: max size for IP datagram is 65.535 bytes, including the IP header (20 bytes)
UDP Datagram Truncation

Possible problem
The application is not prepared to read the datagram in the form presented (i.e., with the size sent)
Solution is implementation dependent Practical limits

Sockets API limits the size of send & receive buffer Usually the limit is 8 kbytes but this can be changed by a routine call TCP/IP implementation imposes diverse limits Traditional Berkeley: silently truncate 4.3BSD and Reno: notify the application about data truncation SVR4: excess data returned in subsequent reads & application is not informed
Another limit
Hosts are required to handle datagrams with a minimum of 576 bytes Consequence: many application protocols limit themselves to 512 bytes or less of data (e.g., DNS, TFTP, BOOTP, SNMP, etc.)

9/38

10/38
TCP Protocol Overview

Main characteristics
Provides reliable, stream-oriented service of type connection-oriented Compensates for loss, delay, duplication and other shortcomings in Internet, across a variety of reliable and unreliable networks TCP adds a great deal of functionality to the service offered by the IP it is layered over Streams: TCP data is organized as a stream of bytes & the datagram nature of the network is concealed Reliable delivery: sequence numbers are used to coordinate data transmitted & received; losses solved by retransmission Network adaptation: dynamical learning of the delay characteristics in network & adjustment of the protocol operation to maximize throughput without net overloading Flow control: trafc coordination such as data buffers are never overowed Applications using TCP: Telnet (23/tcp), FTP (21/tcp), HTTP (80/tcp), SMTP (25/tcp), login (513/tcp), etc. TCP protocol is dened in RFC793 and diverse, ulterior updates
TCP Protocol Overview (cont.)

Main features
Connection-oriented Connections between transmitters & receivers are setup to deliver data Stream interface Applications deliver data to TCP in the form of continuos streams, with no record boundaries Full duplex Simultaneous exchange of data (in both directions) over a TCP link Reliability (error control) Data delivery without loss, duplication or transmission errors Reliable connection setup Three-way handshake guarantees reliable & synchronized setup Graceful shutdown of the connection Delivery of all data is guaranteed even after shutdown by application Flow control Keeps sender from overrunning the receiver Congestion control Keeps sender from overrunning the network

11/38

12/38
TCP Communication Model
TCP Reliable Stream Delivery

Question
Application process
Application process
What does "Reliable Delivery" mean?
Answer
Write bytes Read bytes It depends!
Reliable Delivery minimally means

TCP Send buffer TCP Receive buffer No data values change (i.e., no data corruption) No data is missing No data is added or duplicated
Transmit TCP segments (TPDUs) Connection-Oriented Full duplex Byte-stream: sending process writes in some number of bytes into the TCP send buffer; TCP breaks into segments (TPDUs) & sends via IP; receiving process reads some number of bytes from the TCP receive buffer
TCP Protocol Specs RFC793

"The TCP must recover from data that is damaged, lost, delayed, duplicated, or delivered out of order by the internet communication system"

14/38
TCP Reliable Stream Delivery (cont.)

Minimal control mechanism required
Error control
TCP Segment Format

0 4 10 Source Port 16 24 Destination Port Sequence Number 20 bytes Acknowledgment Number HLen Reserved Code Bits Window Urgent Pointer Padding 31
Other (possible) mechanisms

Ordered delivery Flow control Congestion control
Checksum Options (if any)
TCP techniques used for the provision of reliability

Positive ACK with retransmission Flow control (credit-based) Retransmission timer management Congestion control (window management) Checksum on both header & data (mandatory) Data resequencing Discard of duplicate data Source Port (16 bits): source port number Destination Port (16 bits): destination port number Sequence Number SN (32 bits): identies the position in the senders byte stream of the data in the segment; refers to the stream owing in the same direction as the segment; SN is the rst data octet in the segment (except when SYN is present); if SYN is present, it is the Initial Sequence Number (ISN) and the rst data octet is (ISN + 1)
15/38
Data


16/38
TCP Segment Format (cont.) TCP Segment Format (cont.)

Acknowledgment Number (32 bits): a pyggybacked acknowledgment; identies the number of the octet that the source expects to receive next; refers to the stream owing in the opposite direction from the segment HLen (4 bits): contains an integer that species the length of the segment header measured in 32-bit multiples; this indicates where the Data begins; also called "Data Offset" Reserved (6 bits): reserved for future use; must be zero Code Bits (6 bits): also called "Control Bits"; TCP software uses thse bits to determine the purposes and contents of the segment; gives info about how to interpret other elds in the header according to: URG (Urgent Pointer eld signicant); ACK (Acknowledgment eld signicant); PSH (Push function); RST (Reset the connection); SYN (Synchronize sequence number); FIN (No more data from the sender) Window (16 bits): ow control credit allocation, in octets; TCP software advertises here how much data is willing/prepared to accept every time it sends a segment by speciyng its buffer size; it contains the number of data octets (to be accepted) beginning with the one indicated in the acknowledgment eld Checksum (16 bits): the (16 bit) ones complement of the ones complement sum of all 16 bit words in the TCP segment plus a (12 bytes) pseudoheader; the pseudo-header includes the following elds from the IP header: source IP address; destination IP address; Protocol; plus a segment length eld
Urgent Pointer (16 bits): this can only be interpreted in segments with the URG control bit set; it points to the sequence number of the octet following the urgent data; this allows the receiver to know how much urgent data are coming Options (variable): at present, only one option is practically dened, which species the maximum segment size (MSS) that will be accepted at the receive side; this is communicated to the TCP that sends the segment; if this option is not used, then any segment size is allowed Padding (variable): used to ensure that the header ends and the data begins on a 32 bit boundary; the padding is composed of zeros

18/38
TCP Operation
Purpose of TCP
To provide reliable, securable logical connection between pairs of processes on top of a less reliable internet communication system
TCP Operation (cont.)

Basic Data Transfer
TCP is able to transfer a continuous stream of octets in each direction by packaging some number of octets into segments Generally TCP decides when to block and forward data at their own convenience (creation of TCP segment) Push function: sometimes users need to be sure that all the data they have submitted to TCP has been transmitted; sending user indicates (by push) that the data submitted should be pushed through to the receiving user; a consequence is that the data is forced even if the buffer is not full
Facilities needed for operation (RFC793)

Basic Data Transfer Reliability Flow Control Multiplexing Connections Precedence & Security
Reliability
TCP must recover from data that is corrupted, lost, duplicated or delivered out of order This is done by assigning a sequence number to each octet transmitted, and requiring a positive ACK from the receiver If ACK is not received within a timeout interval, then data is retransmitted At the receiver, the sequence numbers are used to correctly order segments that may be received out of order and to eliminate duplicates Damage is handled by adding a checksum to each segment transmitted, checking it at the receiver, and discarding damaged segments

19/38

20/38

Flow Control
TCP provides a mean for the receiver to govern the amount of data sent by the sender Achieved by returning an "window" with information on ACK and Credit ACK species the sequence number of the next octet that the receiver expects to receive The "window" also indicates an allowed number of octets (Credit) that the sender may transmit before receiving further permission

Connections
Connection: combination of status info for each data stream, including sockets, sequence numbers, and window size Each connection is uniquely specied by a pair of sockets identifying its two sides When two processes want to communicate, their TCPs must rst establish a connection, i.e., initialize the status info on each side When the communication is complete, the connection is terminated to free resources for other users A handshake mechanism with clock-based sequence is used when initializing connections (to avoid erroneous initialization)
Multiplexing
Allows more processes on same host to use TCP facilities simultaneously Implemented by using ports Ports concatenated with the network & host addresses form together a socket; a pair of sockets uniquely identies each connection A socket may be simultaneously used in multiple connections The binding of ports to processes is handled independently by each host Frequently used processes can be attached to xed sockets that are publicly known Establishing & learning the port addresses may also involve dynamic mechanisms
Precedence and Security

Users of TCP may indicate the security and precedence of their communication Provision is made for default values when these features are not needed

22/38
Connection Establishment & Termination

TCP uses a three-way handshake for reliable establishment & termination of connections
The three-way handshake is both necessary & sufcient for correct synchronization between two ends of a TCP connection Procedure for connection establishment (always three-way handshake) Host_1 sends a segment with SYN bit set (Code Bits eld) and a (random) Initial Sequence Number (ISN) for communication Host_1 to Host_2 Host_2 sends a segment with SYN bit set, ACK to Host_1 (Code Bits eld) and a (random) ISN for communication Host_2 to Host_1, indicating so that it ACKs the rst SYN segment and is continuing the handshake Host_1 sends ACK, informing that a connection has been established Handshake works even in case of Simultaneous Open request Thus, a connection can be established or closed from either Host, or from both Hosts simultaneously Procedure for Half-Close (Host_1 to Host_2) Host_1 sends a FIN request (in Code Bits eld) Host_2 sends ACK of FIN, followed by some remaining Data (if any) Host_1 sends ACK of Data Host_2 sends FIN and, nally, Host_1 sends ACK of FIN
Maximum Segment Size

Maximum Segment Size (MSS)
MSS refers to the maximum amount of application-level Data in the TCP segment, and NOT to the maximum size of the TCP segment (including Header) RFC793 is not specic on MSS, and when TCP should actually send the buffered Data; RFC793 states only that "TCP should send Data in segments at its own convenience" Conclusion: MSS can be negotiable between the two end hosts (by using the Options eld) Practically: MSS depends on the TCP implementation, determined by the Operating System, and can often be congured Common values considered for MSS are 1500 bytes, 536 bytes & 512 bytes These MSSs are often chosen to avoid IP segmentation, i.e., the resulting IP datagrams match the network MTU (in the case both endpoints lie on the same physical network) or the minimum MTU along the path between endpoints (in the case the endpoints do not lie on the same physical network) For instance, 536 bytes corresponds to 576 bytes (the default size of an IP datagram) minus 2 20 bytes (standard sizes of IP & TCP headers)

24/38
Data Transfer
Main characteristics for TCP data transfer
Stream of octets Error control by Go-Back-N Flow control by credits Data buffered by the transport entity on both transmission & reception Choice for urgent transmission
Implementation Options
RFC793 provides a precise specication of TCP However, several aspects of the protocol admit different possible implementation options, with performance implications
Send policy (sender) Wait until full transmit buffer or not Depends on performance considerations Risk for silly window syndrome when frequent & small transmissions Deliver policy (receiver) Similarly, wait in receive buffer or not before delivering to application Data can be delivered as each in-order segment is received or data from more segments are delivered together (so, waiting in receive buffer for more segments before delivering) Accept policy (receiver) TCP has two choices for out of order segments In-order: accept only segments arriving in order & discard out of order segments In-window: accept all segments that are within the receive window
TCP has the choice of diverse implementation options, based on performance considerations

25/38

26/38
Implementation Options (cont.)

Retransmit policy (sender) TCP maintains a queue of segments that have been sent but not yet acknowledged In case of failure in receiving ACK within the specied time, TCP may use one of the following three retransmission strategies First-only: only one retransmission timer for the entire queue; if an ACK is received, remove the appropriate segment or segments from the queue & reset the timer; if the timer expires, retransmit only the segment at the front of queue & reset the timer Batch: maintain one retransmission timer for the entire queue; if an ACK is received, remove the appropriate segment or segments from the queue & reset the timer; if the timer expires, retransmit all the segments in the queue & reset the timer Individual: maintain one timer for each segment in the queue; if an ACK is received, remove the appropriate segment or segments from the queue & reset the corresponding timer or timers; if any timer expires, retransmit the corresponding segment individually & reset the timer
Implementation Options (cont.)

Acknowledge policy (receiver) There are two options regarding the timing of acknowledgment Immediate: when data is accepted, send immediately ACK Cumulative: when data are accepted, record the need for ACK, but wait for an outbound segment with data on which to piggyback ACK; also avoid long delays by setting a window timer & sending empty segments with appropriate ACK number

27/38

28/38
Flow Control
Flow control service & congestion control
TCP provides a ow control service to applications to eliminate the possibility of the sender overowing the receivers buffer Flow control is thus a speed matching machine: matching the rate at which the sender is sending to the rate at which the receiving application is reading BIG PROBLEM: TCP sender can also be throttled due to congestion within the IP network Consequence: congestion control (window management) to control the senders rate & keep it from overrunning the network
Flow Control (cont.)

Credit-Based Algorithm
Consider the following: MaxSendBuffer: sender buffer size MaxRcvBuffer: receiver buffer size LastByteWritten: number of the last byte in the data stream written from the application process into the transmit buffer LastByteRead: number of the last byte in the data stream read from the buffer by the application process at receiver LastByteRcvd: number of the last byte in the data stream that has arrived from the network and has been placed in the receive buffer LastByteSent: number of the last byte in the data stream that has been sent from the transmit buffer to network (not ACKed) LastByteAcked: number of the last byte transmitted and also ACKed Receive side must advertise the available space (i.e., the credit): AdvertisedWindow = MaxRcvBuffer - (LastByteRcvd - LastByteRead) Send side must adhere to advertised window size: EffectiveWindow = AdvertisedWindow - (LastByteSent - LastByteAcked) Block sender if (LastByteWritten - LastByteAcked) + (number bytes application process at sender wants to write) > MaxSendBuffer
29/38
Flow control mechanism

Very complex mechanism, involving interaction of transport users, transport entities & network TCP ow control is based on Sliding Windows Protocol (SWP) Some people call TCP ow control as Credit-Based Flow Control Some other people call it as SWP with an Advertised Window Size Important feature of Credit-Based algorithm: it decouples ACK from the ow control related information

30/38
Retransmission Timer Management

Several timers must be managed for every TCP connection
Retransmission timer: used to retransmit an UnACKed TCP segment Persistence timer: used to abort connection when no segments are ACKed Keepalive/Inactivity timer: used to abort connection when no segments are received Window timer: maximum time between ACK/CREDIT segments Quiet timer: to test for out-of-date TCP segments ......
Retransmission Timer Management (cont.)

Main procedure for determination of timeout
Virtually, all TCP implementations attempt to estimate the current RTT by observing the delay patterns for recent segments only, and set then the timer to a value (RTO) somewhat larger than the estimated RTT As the RTT changes, TCP should modify accordingly its timeouts
RTT estimates
There are different methods for RTT estimation, with different advantages & drawbacks: Simple average Exponential average RTT variance estimation (Jacobsons algorithm) Exponential RTO backoff (RTO: retransmission timeout time) Karns algorithm ....
Setting the Timeout for retransmission timer

Inappropriate timeout can cause poor performance Too long timeouts: sender waits longer than needed to retransmit Too short timeouts: sender may generate unnecessary trafc Timeout must be different for each TCP connection and set dynamically Delivery across Internet may change over time, and timeouts must accommodate changes TCP timeout & retransmission depends upon the measured Round-Trip Time (RTT)

32/38
Window Management
TCP congestion control
Problem: the size of TCP send window may have a critical effect on whether TCP can be used efciently without causing congestion TCP standard recommends two techniques to avoid congestion in the network, namely Slow Start (SS) Congestion Avoidance (CA) Obs: CA is also known as Dynamic Window Sizing on Congestion (DWSC) Because of using both SS & CA, TCP is referred to as an algorithm of type Additive-Increase, Multiplicative-Decrease (AIMD) Also known as Tahoe algorithm
Window Management (cont.)

Slow Start (SS)
Strategy recommended by Jacobson in 1988 SS works effectively to initialize a connection TCP uses a congestion window, measured in segments rather than octets At any time, TCP transmission is contrained by awnd = min[rcvwnd, cwnd] where awnd: allowed sender window, in segments; number of segments that TCP is currently allowed to send without receiving further ACKs rcvwnd: actual receiver window, i.e., the amount of data that the peer TCP entity is willing to accept; amount of unused credit granted in the most recent ACK (in segments); when an ACK is received, this value is calculated as window/segment_size, where window is a eld in the incoming TCP segment cwnd:congestionsenderwindow,insegments;windowusedbyTCPduring startup and also to reduce ow during periods of congestion When a new TCP connection is opened, the TCP entity initializes cwnd = 1 segment Each time an ACK is received, cwnd is increased by 1, up to a max value In reality, cwnd grows exponentially

33/38

34/38
Window Management (cont.)

Congestion Avoidance (CA)
SS continues until a segment gets lost (timeout), at a point either before or after cwnd reaches the size of rcvwnd; this is a signal that congestion started occuring, either in network or at destination When the timeout occurs, then SetaSS(SlowStart)thresholdequaltohalfofthecurrentcongestionwindow; that is, set ssthresh = max [2, min (cwnd/2, rcvwnd)] Set cwnd = 1 and perform SS until cwnd = ssthresh; in this phase, cwnd is increased by 1 for every ACK received For cwnd ssthresh, increase cwnd by one for each RTT Obs: ssthresh is initialized to 65535 bytes In summary: When the congestion window is below the threshold, the congestion window grows exponentially When the congestion window is above the threshold, the congestion window grows linearly Whenever there is a timeout, the threshold is set to one-half of the current congestion window and the congestion window is set to 1
Silly Window Syndrome

Silly Window Syndrome (SWS)
Under some circumstances, Sliding Window Protocol (SWP) may result in transmission of many small segments For instance, if the receiver window is full and the receiving application consumes a few data bytes, then the receiver will advertise small window; the sender will then immediately send small segment to ll window SWS is inefcient with regard to processing time & network bandwidth Solutions: Receiver delays advertising new window; also, avoids sending small increments in window advertisements that can trigger small data packets, or Sender delays sending data when window is small; also, avoids sending a small amount of data in each segment

35/38

36/38
New Developments
TCP problems with congestion control
Problems with Tahoe algorithm related to the need to wait long time periods for the timeout Other solution: Reno, which is implemented by most operating systems; Reno includes fast retransmission mechanism (retransmitting the missing segment before the segments timer expires), and also fast recovery mechanism (to cancel SS after a fast retransmission) Even better solution: Vegas, which attempts to avoid congestion while maintaing good throughput; basic idea is to detect congestion in routers before packets are lost
New Developments (cont.)

TCP problems for wireless networks
Main problem: bad quality channels, so timeout may be created by packet losses and not congestion Some solutions: Indirect TCP Snooping TCP
TCP problems of compatibility with different applications

The well-known "compatibility" problems between HTTP and TCP: Frequent round-trip delays due to connection establishment Performs SS in both directions for short duration connections Heavy latency penalties due to the mismatch of typical access proles Solutions: new developments, like Transaction TCP (TTCP)
TCP problems for high speed networks

The product bandwidth delay becomes huge, and exceeds the buffer size (so-called Long Fat Networks LFN - RFC1072) Consequence: some of the TCP parameters (e.g., window size, sequence numbers) have limitations problems, and the protocol itself becomes the bottleneck Another problem: extreme complexity of trafcal behavior (multi-fractal) Solutions: new protocols (research)

37/38

38/38

Lecture 7

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Lecture 7

Enviado por

Direitos autorais:

Formatos disponíveis

Outline

Introduction UDP Protocol Overview

Internetworking with TCP/IP (ETC003) Lecture 7: Transport Protocol

Dept of Telecommunications & Signal Processing

Dept of Telecommunications & Signal Processing

Transport Layer & Session Layer

Dept of Telecommunications & Signal Processing

UDP Protocol Overview

Dept of Telecommunications & Signal Processing

UDP Datagram Format

Dept of Telecommunications & Signal Processing

UDP Datagram Size Limits

UDP Datagram Truncation

Solution is implementation dependent Practical limits

Dept of Telecommunications & Signal Processing

Dept of Telecommunications & Signal Processing

TCP Protocol Overview

TCP Protocol Overview (cont.)

Dept of Telecommunications & Signal Processing

Dept of Telecommunications & Signal Processing

TCP Communication Model

TCP Reliable Stream Delivery

What does "Reliable Delivery" mean?

Reliable Delivery minimally means

TCP Protocol Specs RFC793

Dept of Telecommunications & Signal Processing

TCP Reliable Stream Delivery (cont.)

TCP Segment Format

Other (possible) mechanisms

Checksum Options (if any)

TCP techniques used for the provision of reliability

Dept of Telecommunications & Signal Processing

Dept of Telecommunications & Signal Processing

TCP Segment Format (cont.) TCP Segment Format (cont.)

Dept of Telecommunications & Signal Processing

TCP Operation (cont.)

Facilities needed for operation (RFC793)

Dept of Telecommunications & Signal Processing

Dept of Telecommunications & Signal Processing

TCP Operation (cont.)

TCP Operation (cont.)

Precedence and Security

Dept of Telecommunications & Signal Processing

Connection Establishment & Termination

Maximum Segment Size

Dept of Telecommunications & Signal Processing

Dept of Telecommunications & Signal Processing

Dept of Telecommunications & Signal Processing

Implementation Options (cont.)

Implementation Options (cont.)

Dept of Telecommunications & Signal Processing

Dept of Telecommunications & Signal Processing

Flow Control (cont.)

Flow control mechanism

Dept of Telecommunications & Signal Processing

Retransmission Timer Management

Retransmission Timer Management (cont.)

Setting the Timeout for retransmission timer

Dept of Telecommunications & Signal Processing

Window Management (cont.)

Dept of Telecommunications & Signal Processing

Dept of Telecommunications & Signal Processing

Window Management (cont.)

Silly Window Syndrome