Tcp tutorial part i
This presentation is the property of its rightful owner.
Sponsored Links
1 / 94

TCP Tutorial - Part I - PowerPoint PPT Presentation


  • 50 Views
  • Uploaded on
  • Presentation posted in: General

TCP Tutorial - Part I -. Laboratory of Intelligent Network @ KUT ( http://link.kut.ac.kr ) Youn-Hee Han. It is licensed under a Creative Commons Attribution 2.5 License. TCP Introduction. TCP Features. (Virtual) Connection-oriented Service with Reliability

Download Presentation

TCP Tutorial - Part I -

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Tcp tutorial part i

TCP Tutorial- Part I -

Laboratory of Intelligent Network @ KUT

(http://link.kut.ac.kr)

Youn-Hee Han

It is licensed under a Creative Commons Attribution 2.5 License


Tcp tutorial part i

TCP Introduction

KUT


Tcp tutorial part i

TCP Features

  • (Virtual) Connection-oriented Service with Reliability

  • Information unit is a “segment”

    • TCP itself divides the application date into “segment”

    • Note: Programmer him/herself creates properly-sized UDP datagrams

  • Byte stream service

    • Two applications exchange 8-bit (byte)stream data

    • TCPdoes not interpreter the bytes’contents

    • No application-specific message boundary

Five Segments

KUT


Tcp tutorial part i

TCP Features

  • Sender TCP sets a timer whenever sending a segment

    • Sender waits an ACK (Acknowledgment) message after sending a segment

    • Receiver TCP should send an ACK message to the sender

    • Sender re-sends the segment if it does not receive an ACK message before the timer expires

KUT


Tcp tutorial part i

TCP Features

  • TCPsegment is delivered as IP datagram

    • IP datagrammay be out of order  TCP segmentmay be out of order

    • Receiver TCP re-organizes the segments according to the correct sequence

  • Receiver TCP eliminates the duplicated segment

KUT


Tcp tutorial part i

TCP Features

  • TCP provides flow control

    • TCP sender has the “SEND BUFFER”

    • TCP receiver has the “RECEIVE BUFFER”

    • e.g., if a PC sends data to a hand-held PDA that has a small “RECEIVE BUFFER” and is slowly processing received data, the PDA must regulate data flow so as to not be overwhelmed

    • TCP uses a sliding window flow control protocol

  • TCPprovides congestion control

    • TCP uses a number of mechanisms to avoid ‘network congestion collapse'.

    • TCP controls the rate of data entering the network, keeping the data flow below a rate that would trigger network congestion collapse

    • ACKs for data sent, or lack of ACKs, are used by senders to infer network conditions between the TCP sender and receiver.

KUT


Tcp tutorial part i

TCP Features

  • TCP utilizes the checksum to detect an error

    • To assure correctness of TCP header and data, a checksum field is included in the TCP header

    • If the checksum is incorrect, the TCP receiver ignores the TCP segment.

      • TCP sender’s timer is expired

      • TCP sender re-transmits the same TCP segment

    • TCP provides 32 bit checksum within TCP header and data.

    • IPv4 provides 16 bit checksum within the IPv4 header.

    • IPv6 does provides the checksum filed within the IPv6 header. Why?

KUT


Tcp tutorial part i

TCP Features

  • Full-duplex communication

    • Bi-directional data flow

    • Data can be transmitted while receiving

    • Use of "Piggyback"

      • Data packets can convey feedback information in the opposite direction

(ACK)

KUT


Tcp tutorial part i

TCP Features

  • TCP may delay data transfer.

    • If TCP has not received enough data from the application, TCP tries to aggregate data as much as possible

    • The aggregated data size is “MSS(Maximum Segment Size)”

    • When constructing a segment, TCP starts a TIMER and sends a segment of which size is “not” MSS if there is no futher application data and the TIMER is expired.

      • Telnet

      • HTTP Request

(segment)

KUT


Tcp ports connections and endpoints

TCP Ports, Connections, and Endpoints

  • Endpoint of communication is application program

    • TCP uses protocol port number to identify application

    • TCP defines an “endpoint” to be a pair of two following integers:

  • TCP connection between two endpoints identified by four items

    • Sender’s IP address

    • Sender’s protocol port number

    • Receiver’s IP address

    • Receiver’s protocol port number

  • (host IP, port)

KUT


Socket

process

process

TCP with

buffers,

variables

TCP with

buffers,

variables

socket

socket

Socket

Socket: a door between application process and transport protocol (UCP or TCP)

controlled by

application

developer

controlled by

application

developer

controlled by

operating

system

controlled by

operating

system

internet

host or

server

host or

server

KUT


Ipv4 header

IPv4 Header

20 Octets + options : 13 fields, including 3 flag bits

0 bits

4

8

16

24

31

Ver

IHL

Type of Service

Total Length

Identifier

Flags

Fragment Offset

Time to Live

Protocol

Header Checksum

32 bit Source Address

32 bit Destination Address

Options and Padding

KUT


Ipv4 header notes

IPv4 Header - notes

  • Internet Header Length (IHL)

    • Unit: 4 bytes, Min: 5 (54=20 bytes), Max: 15 (154=60 bytes)

  • Type of Service (ToS)

    • RFC 2474 provides a definition of this field in terms of DS (Different Service)

  • Total Length

    • Unit: 1 bytes, Min: 20 bytes, Max: 65,535(=2^16) bytes

  • Identifier

    • If an IPv4 packet is fragmented, all of the fragments retain the same Identification values, so the destination can group them for reassembly

  • Flags

    • 0, 3: Reserved

    • 1: Don’t fragment

    • 2: More fragment

  • Time to Live (TTL)

    • When TTL becomes 0, ICMPv4 Error message is sent to the source

KUT


Tcp segment header

TCP Segment Header

  • 20 bytes + options

0

15

16

31

16-bit source port number

16-bit destination port number

32-bit sequence number

Counting by bytes

of data (not segments!)

32-bit acknowledgment number

4-bit header

length

reserved

(6bits)

U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

16-bit window sizes

16-bit TCP checksum

16-bit urgent pointer

options (if any)

  •  Maximum Segment Size (MSS)

data (if any)

KUT


Tcp segment header1

TCP Segment Header

  • Acknowledgment Num, Sequence Num, Window Size

    • Congestion Control + Flow Control

  • Flags

    • SYN, FIN, RESET, PUSH, URG, ACK

  • Checksum

    • pseudo header + TCP header + data

KUT


Six flags and option

Six flags and Option

  • Six flag bits

    • URG - The urgent pointer is valid. (generally not used)

    • ACK - The acknowledgment number is valid

    • PSH - The receiver pass this data to the application as soon as possible. (generally not used)

    • RST - Reset the connection.

    • SYN - Synchronize sequence numbers to initiate a connection.

    • FIN - The sender is finished sending data.

  • Urgent pointer

    • Effective only if URG flag is set

    • Way to send an urgent out-of-band data

  • Option field

    • maximum segment size (MSS) option

    • MSS option is inserted when the connection is established (SYN is set)

KUT


Tcp connection establishment

TCP connection establishment

  • 3 way handshake (Conceptual Description)

Client: “I want to talk, and I’m starting with byte number X ”.

Server: “OK, I’m here and I’ll talk. My first byte will be called number Y, and I know your first byte will be number X+1”.

Client: “Got it - you start at byte number Y+1”.

1

Server

Client

SYN

ISN=X

1

2

time

SYN

ISN=Y, ACKN=X+1

2

3

ACKN=Y+1

3

ISN: Initial Sequence Number

KUT


Tcp connection establishment1

TCP connection establishment

  • 3 way handshake

  • Initial sequence numbers, x & y, are chosen randomly

  • Guarantees both sides ready & know it, and sets initial sequence numbers, also sets window & mss

  • Once connection established, data can flow in both directions, equally well, there is no master or slave

Site 2

Site 1

Send SYN seq. #=x

Active

win 4096, mss 1460

Rcv SYN segment

Send SYN seq.#=y,

ACK #=x+1

Passive

win 4096, mss 1024

Rcv SYN + ACK segt

Send ACK seq.#=y+1

Rcv ACK segment

KUT


Tcp connection establishment2

TCP connection establishment

  • Active & Passive Opens

    • Two sides of a connection

      • Client

      • Server

  • One side initiates contact

    • A client program (Site 1)

    • Uses TCP’s active open

  • One side waits for contact

    • A server program (Site 2)

    • Uses TCP’s passive open

KUT


Tcp close connection

TCP close connection

  • Usually the application tells TCP to terminate the connection politely with a FIN segment.

  • TCP layer can send a RST segment that terminates a connection if something is wrong.

  • FIN segment

    • Either end of the connection can initiate termination.

    • Application 1 call “close()” function

    • A FIN is sent, which means the application is done sending data.

    • The FIN is ACKed by Application 2

    • Application 2 call “close()” function

    • A FIN is also sent.

    • That FIN must be ACKed Application 1

KUT


Tcp close connection1

App2

App1

FIN

SN=X

1

ACK=X+1

2

...

FIN

SN=Y

3

ACK=Y+1

4

TCP close connection

  • Modified 3 way handshake (or 4 way termination)

App1: “I have no more data for you”.

App2: “OK, I understand you are done sending.”

……. pause…

App2: “OK - Now I’m also done sending data”.

App1: “I understand , Goodbye”

1

2

3

4

KUT


Tcp close connection2

TCP close connection

  • Modified 3 way handshake (or 4 way termination)

  • In Site 1, App tells TCP to close, TCP sends remaining data & waits for ACK

  • Receiving the ACK, then sends FIN & EOF (End of Data)

  • In Site 2, TCP ACKs FIN, tells its application “EOF”

  • In Site 2, sends FIN when its app closes connection (maybe after a long delay)

    • exit(0)automatically calls close()

(App closes)

Send FIN seq=s

FIN (EOF)

Rcv FIN segment

Site 2

Site 1

Send ACK s+1 (inform app)

Rcv ACK segment

(app closes connection)

Send FIN seq=t, ACK s+1

FIN (EOF)

Rcv FIN + ACK seg

Send ACK t+1

Receive ACK segment

TIME_WAIT

KUT


Tcp close connection3

TCP close connection

  • Both sides close at the same time – Case 1

(App closes)

Send FIN seq=s

FIN (EOF)

Rcv FIN segment

Site 2

Site 1

(app closes connection)

Send ACK s+1 & FIN seq=t

ACK + FIN (EOF)

Rcv ACK+FIN segment

Send ACK t+1

TIME_WAIT

Receive ACK segment

KUT


Tcp close connection4

TCP close connection

  • Both sides close at the same time – Case 2

(App closes)

Send FIN seq=s

(app closes connection)

Send FIN seq=t

FIN (EOF)

Site 2

Site 1

FIN (EOF)

Rcv FIN segment

Rcv FIN seg

Send ACK t+1

Send ACK s+1 (inform app)

Receive ACK segment

Rcv ACK segment

TIME_WAIT

TIME_WAIT

KUT


Tcp close connection5

TCP close connection

  • Why TIME_WAIT?

    • This gives enough time to Client TCP so as to ensure the ACK it sent to the server was correctly received.

    • If the ACK the client sent is lost, the server will re-transmit FIN.

      • The FIN should be received by Client

    • TIME_WAIT = 2 * maximum segment life (MSL)

Start TIME_WAIT

Re-Start TIME_WAIT

KUT


State transition diagram

State Transition Diagram

  • It shows only the states involved in opening a connection (everything above ESTABLISHED) and in closing a connection (everything below ESTABLISHED)

  • Everything while a connection is open—e.g., congestion control—is hidden in the ESTABLISHED state.

  • Each side starts in the CLOSED state

  • State transition according to the arcs of which is labeled with a tag of “event/action”

  • e.g., a server is in LISTEN and a SYN segment arrives. At this event, LISTEN is transited to SYN_RCVD and reply with an SYN+ ACK segment

KUT


State transition diagram1

State Transition Diagram

  • Two kinds of events trigger a state transition

  • (1) a segment arrives from peer

  • (2) local application process invokes an operation on TCP (e.g., active open event on arc from CLOSED to SYN_SENT)

  • Most of the states that involve sending a segment to the other side also schedule a timeout that eventually causes the segment to be resent if the expected response does not happen.

  • These retransmissions are not depicted in the state transition diagram.

  • If after several tries the expected response does not arrive, TCP gives up and returns to the CLOSED state.

KUT


State transition diagram2

State Transition Diagram

  • [Connection Establishment]

1. server invokes a passive open operation

: CLOSED  LISTEN

2. client invokes an active open operation

: client sends a SYN to server

: CLOSED  SYN_SENT

3. SYN arrives at server

: LISTEN  SYN_RCVD

: responds with a SYN+ACK

4. SYN+ACK arrives at client

: SYN_SENT  ESTABLISHED

: sends ACK

5. ACK arrives at server

: SYN_RCVD  ESTABLISHED

KUT


State transition diagram3

State Transition Diagram

[NOTE about connection establishment]

1. if client’s ACK to server is lost, the connection still functions correctly

- client side is already in ESTABLISHED

- local process starts sending data

- Each data segments will have ACK which has the correct value

- server moves to ESTABLISHED when the first data segment arrives

2. there is a transition out of the LISTEN state whenever local process invokes a send operation on TCP

- passive participant identifies both ends of connection (i.e., itself and remote participant are willing to have connect to it)

- then changes its mind and instead actively establish connection

KUT


State transition diagram4

State Transition Diagram

[terminating a connection]

- application process on both sides of the connection must independently close its half of the connection

- possibility that the two sides invoke the close operation at the same time

- as well as the possibility that first one side invokes close and then, at some later time, the other side invokes close

KUT


State transition diagram5

State Transition Diagram

  • [Three Cases of “ESTABLISHED state to the CLOSED” ]

  • This side closes first: ESTABLISHED >> FIN_WAIT_1 >> FIN_WAIT_2 >> TIMEWAIT >> CLOSED

  • The other side closes first: ESTABLISHED >> CLOSE_WAIT >> LAST_ACK >> CLOSED

  • Both sides close at the same time:

  • ESTABLISHED >> FIN_WAIT_1 (>> CLOSING) >> TIME_WAIT >> CLOSED

KUT


Tcp tutorial part i

MSS (Maximum Segment Size)

KUT


Mss maximum segment size

MSS (Maximum Segment Size)

  • Overview

    • Maximum Transmission Unit (MTU) is defined by the maximum payload size of the Layer 2 frame.

    • MTU determines the maximum size of a Layer 3 packet/fragment.

    • Layer 3 payload determines Layer 4 Maximum Segment Size(MSS)

KUT


Mss maximum segment size1

MSS (Maximum Segment Size)

  • Overview

    • MSS: Maximum Segment Size

      • Largest payload size that TCP can send for this connection.

      • Usually, MSS is calculated by “Maximum Transmission Unit (MTU) - 40 bytes.”

MAC Header

(Path MTU)

KUT


Mss maximum segment size2

MSS (Maximum Segment Size)

  • Overview

    • An example of MSS negotiation

      • In this example, both sides use 960 bytes as MSS.

KUT


Link mtu

Link MTU

  • Link MTU

    • The max packet size that can be transmitted over a link

    • If a router receives a packet whose size is bigger than its outbound Link MUT, it must fragment the packet.

    • Most modern router and link implementations now support MTUs of 1500

KUT


Path mtu

Path MTU

  • Path MTU

    • The minimum link MTU of all links in a path between a source and a destination

    • Source host’s IP can fragment payloads of upper-layer protocols of which packet size is larger than the Path MTU

    • all IP hosts (and routers) are required to accept or reassemble fragments of which size is 576 octets  Default (and Safe) value of Path MTU is 576!

  • Path MTU Discovery

    • Used to send packets bigger than 576 bytes

    • Increase Path MTP

      • To detect increases in a path’s PMTU, a node periodically increases it.

      • Increasing Path MTU must not be done less than 5 minutes after ICMP has been received (Recommend : 10 minutes)

    • Minimal implementation can omit Path MTU Discovery as long as all packets kept  576 bytes

KUT


Path mtu1

2. ICMP Packet Too Big message (MTU =1400)(Note : Packet Discard)

1400

1500

1600

1. Source Node initially assume that…PMTU = MTU of first hop=1500

4. ICMP Packet Too Big message (MTU=576)(Note : Packet Discard)

576

1400

576

1400

1500

1500

1600

3. Source Node assume that…PMTU = MTU notified by ICMP=1400

1600

5. Source Node assume that…PMTU = MTU notified by ICMP=576

Path MTU

  • Path MTU Discovery

576

KUT


Path mtu2

Path MTU

  • How to get Path MTU by yourself?

    • PING <IP-Address/Domain Name> -f -l <estimated MTU - 28>

      • 28 represents IP Header (20 Bytes) and an ICMP-Header (8 Bytes)

      • -f: Don’t Fragment

      • -l: ICMP’s Payload Size

      • Ex] ping -f -l 1472 www.yahoo.com

        Reply from 209.131.36.158: bytes=1472 time=141ms TTL=50

        ping -f -l 1473 www.yahoo.com

        Packet needs to be fragmented but DF set

KUT


Path mtu mss

Path MTU & MSS

  • How to determine TCP MSS

    • SndMSS = MIN(Path MTU - sizeof(TCPHDR) - sizeof(IPHDR),Advertised MSS)

  • Case I: both the IP header and the TCP header are minimum size, that is, 20 octets

    • SndMSS = MIN((576 - 20 - 20, Advertised MSS) = MIN(536, Advertised MSS)

  • Case II: if the IP Security option (11 octets) were in use

    • SndMSS = MIN((576 - 20 - 20 - 11, Advertised MSS) = MIN(525, Advertised MSS)

  • In Modern Internet, path MTU is usually 1500 and MSS can be 1460

    • Self-check: http://www.speedguide.net:8080

KUT


Tcp tutorial part i

Sliding Window

KUT


Tcp window

TCP Window

  • TCP Window

    • the amount of data a TCP sender can send on a connection before it gets an ACK back from the receiver

    • Measured in bytes

    • If TCP sender’ window size is 64 KB (kilobytes), the sender can only send 64 KB of data and then it must stop and wait for an acknowledgment from the receiver

/* An example of client code that sets the TCP window size */

int window_size = 128 * 1024; /* 128 kilobytes */

sock = socket(AF_INET, SOCK_STREAM, 0);

/* These setsockopt()s must happen before the connect() */

setsockopt(sock, SOL_SOCKET, SO_SNDBUF, (char *) &window_size, sizeof(window_size));

setsockopt(sock, SOL_SOCKET, SO_RCVBUF, (char *) &window_size, sizeof(window_size));

connect(sock, (struct sockaddr *) &address, sizeof(address));

KUT


Sliding window

Sliding Window

  • Sliding Window Used By TCP

    • Illustration in SEND_BUFFER

    • 1st and 2nd bytes are acknowledged

    • Bytes 3 through 6 not yet acknowledged

    • Bytes 7 though 9 waiting to be sent

    • Bytes above 9 and lie outside the window cannot be sent

  • TCP sliding window mechanism operates at the octet (byte) level

  • TCP allows the window size to vary over time

    • Variable size window means thatTCP provides “flow control”

    • Window size is related to bandwidth & RTT

KUT


Four sources of packet delay

Four sources of packet delay

  • Processing Delay (=Dproc )

    • Time to examine the packet’s header and determine where to direct the packet

  • Queuing Delay (= Dqueue)

    • Time to exist in queue

    • In Input queue, it depends on the number of earlier-arriving packets that are queued

    • In Output queue, it depends on the number of waiting for transmission across the link

  • Transmission Delay (= Dtrans )

    • Time to push all of the packet’s bits into the link (= Packet Length / Transmission Rate)

    • E.g., Packet Length: 1,500 Bits, Transmission Rate : 100 Mbps, Transmission Delay = ?

  • Propagation Delay (=Dprop)

    • Time to propagate from the beginning of the link to the end of the link (= Distance / Propagation Speed)

    • E.g., Distance: 1Km, Propagation Speed: 3*10^8 m/sec, Propagation Delay = ?

Transmission

Propagation

Queuing (Input queue)

Queuing (Output queue)

Processing

Bandwidth

KUT


Transmission rate bandwidth

Transmission Rate & Bandwidth

  • Bandwidth

    • typically means physical layer “net transmission bit rate”

  • The channel capacity

    • a theoretical upper bound for the maximum net bit rate

Channel capacity ≥ Net bit rate (Bandwidth)

KUT


Propagation speed

Propagation Speed

  • It is well known that…

    • Copper: 2.3 x 108 m/s

    • Fiber: 2.0 x 108 m/s

    • Radio: 3.0 x 108 m/s

  • “Speed” of the Internet is…

    • between 2.0 x 108 and 3.0 x 108 m/s

  • Let’s assume Internet propagation speed S…

    • S = 2.0 x 108 m/s

KUT


How long will it take to download

How Long Will It Take To Download?

  • Let’s download the following image file from a location

  • Assume the distance D is 5288 km

  • If it were just one bit!

    • D / S = 5288 * 1000 / 2.0 x 108 = 26.4 x 10-3 sec

  • Size: 62,728 bytes

    • D / S = 62,728 x 8 x 26.4 x 10-3 = 13,248 s = 3.7 hours!

  • Is this correct?

62,728 bytes

KUT


Tcp window size issue

TCP Window Size Issue

One bit at a time!  Very Poor Throughput

KUT


Tcp window size issue1

TCP Window Size Issue

  • Keeping the pipe full!

    • Maximize the throughput

KUT


Tcp window size issue2

TCP Window Size Issue

Keeping the pipe full when using TCP Window

ACK

ACK

ACK

ACK

ACK

Window Size = 5 segments

A B C D E F G H I J K L M N O

Is it Correct Behavior to keep the pipe full?

A B C D E F G H I J K L M N O

When Sliding?

KUT


Tcp window size issue3

TCP Window Size Issue

Keeping the pipe full when using TCP Window

ACK

ACK

ACK

ACK

ACK

Window Size = 10 segments

A B C D E F G H I J K L M N O

That’s right!

The pipe can be used fully!

A B C D E F G H I J K L M N O

When Sliding?

KUT


Window size issue

Window Size Issue

  • Default (Maximum) Window Size

    • Can we re-scale the (Maximum) Window Size?

      • YES!

      • Now, we try to get “the Achievable throughput” using TCP can get close to 100% of bandwidth

Windows XP, SP3: 65535 Bytes ≈ 64KB

KUT


Window size bandwidth delay rtt

Window Size & Bandwidth * Delay (RTT)

  • RTT (Round-trip Time)

    • The time received an ACK minus the time a data was sent

KUT


Window size bandwidth delay rtt1

Window Size & Bandwidth * Delay (RTT)

  • Bandwidth * Delay (Round Trip Time)

    • the amount of data that can be in transit in the network

    • It is a very important concept in a TCP Window Size

    • If the TCP sender’s window size is lower than “Bandwidth * Delay”, we can't fill the pipe since the TCP receiver can't send acknowledgements back fast enough.

    • The TCP Window needs to be large enough to fit the “Bandwidth * Delay”.

total_available_bandwidth (bits/sec) x round_trip_time (sec)

KUT


Window size bandwidth delay rtt2

Window Size & Bandwidth * Delay (RTT)

  • How to determine the exact optimal TCP Window

    • 1) Determine MSS, maximum anticipated latency and advertised maximum bandwidth.

      • E.g., 1460 MSS, 300ms max latency, 6Mbit/s max bandwidth

    • 2) Find the default window size

      • E.g., 65535 bytes (in Windows XP, SP3)

    • 3) Find the largest even multiple of MSS less than 65535 (Why?)

      • 65535 / 1460 (MSS) = 44.9  round down to even number = 44  44 x 1460 = 64240

    • 4) Multiply the value by 2 until it is larger than “Bandwidth * Delay”

      • 6Mbits/s = 6 * 1024 * 1024 bps = 6291456 bps

         6291456 bps / 8 = 786432 bytes/s

      • “Bandwidth * Delay” = 786432 bytes/s * 0.3 s = 235929.6 bytes

      • 64240 x 2 x 2 ... = 256960 bytes

KUT


What is optimal window size

What is “optimal” Window Size?

  • So, Is “256960 bytes” really the optimal window Size?

    • Absolutely No!

  • Actually. “Window Size” should be designed while keep in mind the followings

    • Potentially different RTT

      • need adaptive timeout mechanism

    • Potentially different capacity at receiver

      • need to accommodate different node capacity (flow-control)

    • Potentially different network capacity

      • need to be prepared for network congestion

    • Potentially “unexpected” long delay in network

      • need to be prepared for arrival of very old segments

KUT


Flow control tcp window

Flow Control & TCP Window

  • Receiver controls flow by telling sender the size of currently “Available RECEIVE_BUFFER” measured in bytes

  • Each acknowledgement contains a window size that specifies how many additional bytes of data the receiver is prepared to accept.

    • Sender never sends more than the advertised window size

    • Receiver buffer will never overflow

KUT


Flow control tcp window1

Flow Control & TCP Window

Sender = client

Receiver = server

0

Ack : 1001 , win : 4000

Empty buffer

seq : 1001 , 4000 bytes

4000

Ack : 5001 , win : 0

2000

Ack : 5001 , win : 2000

seq : 5001 , 1000 bytes

3000

KUT


Tcp tutorial part i

TCP in Action

KUT


Reliability in tcp

Reliability in TCP

  • Checksum used to detect bit level errors

  • Sequence numbers used to detect sequencing errors

    • Duplicates are ignored

    • Out of order packets are reordered (or dropped)

    • Lost packets are retransmitted

  • Timeouts used to detect lost packets

    • Requires RTT calculation

    • Requires sender to maintain data until it is ACKed

KUT


Tcp in action

TCP in Action

  • The sending node will:

    • split the data sequence into packets (segments)

    • for each packet, give:

      • destination address (for routers)

      • source address (for replies)

      • sequence number (for reconstruction)

      • sum check (for error detection)

    • send the packets

  • The receiving node will:

    • discard any corrupted packets (for which the sum check doesn't agree)

    • request retransmission of any missing packets

    • restore packets to original order

    • reconstruct the original byte stream

KUT


Tcp data exchange

Site 2

Site 1

User

types

‘C’

Seq=42, data = ‘C’

host ACKs

receipt of

‘C’, echoes

back ‘C’

Seq=79, ACK=43, data = ‘C’

host ACKs

receipt

of echoed

‘C’

Seq=43, ACK=80

time

simple TELNET scenario

TCP data exchange

Seq. # is:

- byte stream

“number” of first

byte in segment’s

data

Ack. # is:

- seq # of next byte

expected from

other side

- Cumulative ACK

KUT


Sequence number

Sequence Number

  • Indicates the position of the data in the packets

    • Every byte is sequenced

    • Used for re-ordering packets and finding lost packets

    • Initial Sequence Number (ISN) is randomly assigned for every TCP connection

      • For security reasons, ISN should not be easy to be guessed

    • [Note]

      • SYN and FIN packets also consume 1 sequence number, although they do not include any data.

      • ACK packets without payload also consume 1 sequence number

KUT


Tcp tutorial part i

Cumulative Acknowledgement

  • TCP Ack specifies the sequence number of the next octet that the receiver expects to receive

    • An acknowledgment of sequence number X indicates that all bytes up to but not including X have been received.

    • TCP Ack is called cumulative because it reports how much of the stream has accumulated

  • Pros.

    • Ack is easy to generate unambiguously

  • Cons.

    • The sender does not receive information about all successful transmission

KUT


Tcp tutorial part i

Cumulative Acknowledgement

  • Let’s think the following scenario (1/3)

sender

receiver

Seq. #=101, 100 bytes data

Seq. #=201, 100 bytes data

Seq. #=301, 100 bytes data

Seq. #=401, 100 bytes data

Seq. #=501, 100 bytes data

Timeout

Seq. #=601, 100 bytes data

Acq. #=201

101

Acq. #=401

201

Acq. #=501

301

Acq. #=601

401

Acq. #=701

501

601

KUT


Tcp tutorial part i

Cumulative Acknowledgement

  • Let’s think the following scenario (2/3)

sender

receiver

Seq. #=101, 100 bytes data

Seq. #=201, 100 bytes data

Seq. #=301, 100 bytes data

Seq. #=401, 100 bytes data

Seq. #=501, 100 bytes data

Timeout

Seq. #=601, 100 bytes data

Acq. #=201

101

Acq. #=201

201

Seq. #=201, 100 bytes data

Acq. #=201

301

Seq. #=301, 100 bytes data

Acq. #=201

401

Seq. #=401, 100 bytes data

Acq. #=201

501

Seq. #=501, 100 bytes data

601

Seq. #=601, 100 bytes data

KUT


Tcp tutorial part i

Cumulative Acknowledgement

  • Let’s think the following scenario (3/3)

sender

receiver

Seq. #=101, 100 bytes data

Seq. #=201, 100 bytes data

Seq. #=301, 100 bytes data

Seq. #=401, 100 bytes data

Seq. #=501, 100 bytes data

Timeout

Seq. #=601, 100 bytes data

Acq. #=201

Acq. #=201

Acq. #=201

Seq. #=201, 100 bytes data

101

Acq. #=201

201

Acq. #=201

301

Seq. #=301, 100 bytes data

Acq. #=701

401

Duplicate ACKs

& Fast Retransmit

501

KUT

601


Tcp tutorial part i

Duplicate ACK and Fast Retransmit

  • How the TCP sender know the Segment loss

    • 1) Timeout !

    • 2) Receives duplicate Ack. From the receiver

  • Duplicate Ack

    • The sender sends a sequence of segments to the receiver

    • The receiver fails to receive the expected segments

    • The receiver sends “duplicate ACKs”

    • Ex.]

      • Sender sends #1~#8segments to the receiver

      • The receiver does not receive #5 segment, but receives #6 segment

      • As the correspondence of #6 segment, the receiver still sends an Ack for the #5 segment

      • Although the receiver receives #7 and #8segments continuously, it still sends Acks for the #5 segment

KUT


Tcp tutorial part i

Duplicate ACK and Fast Retransmit

  • The cases of sending “Duplicate Ack”

    • RULES] The sender immediately sends “Duplicate ACK” when receiving an out of order segment.

      • CASE I – The segments are simply out of order

        • It is likely that just oneor two duplicate ACKs may be received by sender

      • CASE II – Segment is really lost

        • It is likely that three or more duplicate ACKs may be received by sender

  • “Three” Duplicate Ack and Fast Retransmit

    • Only one or two “Duplicate Ack” does not distinguish CASE I from CASE II.

    • It is highly possible that the segment was lost if the sender receive three duplicate acknowledge (the duplicate ack. threshold =3)

    • That is, if the sender receives three duplicate Ack., it should send the corresponding segment instantly without waiting to retransmission timer expiration.

KUT


Tcp tutorial part i

Time-out period often relatively long:

long delay before resending lost packet

Detect lost segments via “duplicate ACKs”.

Sender often sends many segments back-to-back

If segment is lost, there will likely be many duplicate ACKs.

Duplicate ACK and Fast Retransmit

  • If sender receives 3 ACKs for the same data, it supposes that segment was lost:

    • fast retransmit:resend segment before timer expires

KUT


Tcp tutorial part i

Delayed Ack

  • TCP has a rule like the following:

    • If you send me two packets, I will send you one acknowledgement (ACK).

    • If you send me one packet, I will wait 200 ms but not more than 200 ms before I respond with an ACK. (IETF RFC recommends 500ms)

  • Delayed ACK (Optional, But Recommended)

    • Every two receipts of segment, the receiver sends ACK.

    • At least within 500ms, the receiver sends ACK.

      • If it happens that the receiver has a data destined for the sender within 500ms, the receiver sends the data and the delayed ACK without further waits

    • This rule reduces the number of unnecessary ACKs.

KUT


Segment corruption

TCP Scenario (1/5)

Segment Corruption

Receiver

sender

Seq : 1001, 200bytes

Seq : 1201, 200bytes

Seq : 1401, 200bytes

Segment 3 - corrupted

ACK : 1401

OK

OK

Seq : 1401, 200bytes

Timeout

ACK : 1601

OK

(Everything is ok.)

KUT


Lost segment

TCP Scenario (2/5)

Lost segment

Receiver

sender

Seq : 1001, 200bytes

Seq : 1201, 200bytes

Seq : 1401, 200bytes

Segment 3 - lost

ACK : 1401

OK

OK

Seq : 1401, 200bytes

Timeout

ACK : 1601

OK

(Everything is ok.)

KUT


Tcp tutorial part i

TCP Scenario (3/5)

KUT


Tcp tutorial part i

TCP Scenario (4/5)

KUT


Cumulative ack scenario ii

TCP Scenario (5/5)

Cumulative Ack Scenario II

Receiver

sender

Seq : 1001, 200bytes

Seq : 1201, 200bytes

Seq : 1401, 200bytes

Acknowledgement Lost

ACK : 1401

ACK : 1601

OK

OK

OK

KUT


Tcp ack generation rfc 1122 rfc 2581

TCP ACK generation[RFC 1122, RFC 2581]

TCP Receiver action

Delayed ACK. Wait up to 500ms

for 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 single cumulative ACK

Event at Receiver

Arrival of in-order segment with

expected seq #. All data up to

expected seq # already ACKed

Arrival of in-order segment with

expected seq #. One other

segment has ACK pending

Arrival of out-of-order segment

higher-than-expect seq. # .

Gap detected

Arrival of segment that

partially or completely fills gap

KUT


Tcp tutorial part i

TCP Timeout and Retransmission

KUT


Internet environment

Internet Environment

  • Designed for Internet environment

    • Delays on one connection vary over time

    • Delays vary widely between connections

real-time plotting of measured round trip time (RTT) delay from lancelet.caida.org (in Ann Arbor, MI) to www.ucsd.edu (in San Diego, CA)

KUT


Timeout and retransmission

Timeout and Retransmission

  • Fixed value for timeout will fail

    • Waiting too long introduces unnecessary delay

    • Not waiting long enough (early timeout) wastes network bandwidth with unnecessary retransmission

  • Retransmission strategy must be adaptive

KUT


Rtt round trip time

RTT (Round-trip Time)

  • TCP keeps estimate of round-trip time (RTT)

    • RTT:

      • The time received an ACK minus the time a data was sent

  • “Timeout Interval” is calculated from RTT

    • It is derived from observed RTT

    • Appropriate time for retransmission is very different from each communication path.

KUT


Adaptive retrasmission

Adaptive Retrasmission

  • Difficulties with adaptive retransmission

    • Segments or ACKs can be lost or delayed, making roundtrip estimation difficult or inaccurate

    • Round-trip times vary over several orders of magnitude between different connections

    • Traffic is bursty, so round-trip times fluctuate wildly on a single connection

    • Retransmission can cause congestion on routers or hosts

KUT


Rtt smoothing

RTT Smoothing

  • Solution: Smoothing

    • Adaptive retransmission schemes keep a statistically smoothed round-trip estimate

    • Smoothing keeps running average from fluctuating wildly, and keeps TCP from overreacting to change

    • Difficulty: choice of smoothing scheme

KUT


Rtt smoothing1

RTT Smoothing

  • Smoothing Scheme

    • Let “EstimatedRTT” be current (old) average round-trip time

    • Let “NewRTT” be a new sample

    • Compute

      • EstimatedRTT = a * EstimatedRTT + b * NewRTT

      • where a + b = 1

      • Recommended values [RFC2988]: a = 0.875, b = 0.125 (=1/8)

    • Large a makes estimate less susceptible to a single long delay (more stable)

    • Large b makes estimate track changes in round-trip time quickly

KUT


Tcp timeout and retransmission

TCP Timeout and Retransmission

KUT

Smoothed RTT


A measured snr values 1 2

A Measured SNR Values #1-2

Smoothing Effect

dB

  • EstimatedRTT = a * EstimatedRTT + b * NewRTT

Use Moving Average!

ms

b=0.6

b=0.9

b=0.1

b=0.3

KUT


Original algorithm

Original Algorithm

  • Adaptive Retransmission

    • Compute

      • EstimatedRTT = a * EstimatedRTT + b * NewRTT

      • where a + b = 1

      • Recommended values [RFC2988]

        • : a = 0.875, b = 0.125 (=1/8)

    • Set timeout based on EstimatedRTT

      • TimeOut Interval = 2 * EstimatedRTT

KUT


Jacobson karels algorithm

Jacobson/Karels Algorithm

  • Jacobson/Karels Algorithm

    • More Finer Determination of Timeout Interval

    • EstimtedRTT plus “safety margin”

    • large variation in EstimatedRTT  larger safety margin

    • Then set the improved timeout interval:

      • DevRTT is a good approximation of the Standard Deviation

      • By using DevRTT, we can avoid computing square root.

DevRTT = (1-)* DevRTT + *|NewRTT-EstimatedRTT|

(typically,  = 0.25)

Timeout Interval = EstimatedRTT + 4*DevRTT

KUT


Tcp timeout intervel based on jacobson karels algorithm

TCP Timeout Intervel based on Jacobson/Karels Algorithm

  • Measurement Of Internet Delays For 100 Successive Packets At 1 Second Intervals

TCP Round-Trip Estimation For Sampled Internet Delays

KUT


Retransmission ambiguity

Retransmission Ambiguity

A

B

A

B

Original transmission

Original transmission

RTO

RTO

ACK

Sample

RTT

Sample

RTT

retransmission

retransmission

ACK

Which one is correct?So, what should we do?

KUT


Karn s algorithm

Karn’s Algorithm

  • Karn’s Algorithm

    • Improve accuracy of the RTT measurement.

    • RTT measurement with packet loss

      • Duration A: use the most recent retransmission for RTT measurement.

      • Duration B: use the original transmission for RTT measurement.

    • Which duration is suitable for RTT measurement?

    • example 1:

      • We should use "duration A" as RTT in this case.

      • But, this assumption is not always correct.

Data

Retransmission

B

Retransmission

A

Ack

KUT


Karn s algorithm1

Karn’s Algorithm

  • Karn’s Algorithm

    • example 2:

      • We cannot use "duration A" as RTT in this case!

      • So, what should we do?

Data

Retransmission

B

Retransmission

A

Ack

KUT


Karn s algorithm2

Karn’s Algorithm

  • Karn's algorithm

    • Rule 1: Ignore measured RTT for retransmitted packets.

      • When retransmissions occur, the RTT estimate is not updated

      • Reuse RTT estimate only after one successful transmission

      • Remove ambiguity from RTT measurements.

    • Rule 2: “Timeout Interval” should be doubled after retransmission.

      • This is called "Exponential Back-off"

KUT


Karn s algorithm3

Karn’s Algorithm

  • Why is Rule 2 necessary?

    • When “Timeout Interval” is smaller than Real RTT..

      • If only Rule 1 is applied, TCP will use S as RTO for a long time (or forever).

      • Many packets will be retransmitted.

      • More severe congestion occurs

Data 1

S

Real RTT

Retransmission

Ack

Data 2

S

Real RTT

Retransmission

Ack

KUT


  • Login