1. Unit 3 Transport layer Computer Networking
Departamento de Tecnología Electrónica
Computer Networking
Some of these slides are given as copyrighted material from:
Computer Networking: A Top Down Approach , 5th edition. Jim Kurose, Keith Ross Addison-Wesley, April 2009.
Unit 3 Transport layer

2. Unit 3: Transport Layer Our goals:
Understanding the principles behind transport layer services:
multiplexing & demultiplexing
reliable data transfer
flow control
learn about transport layer protocols in the Internet:
UDP: connectionless transport
TCP: connection-oriented transport
Transport Layer

3. Unit 3.Overview 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing
3.3 Connectionless transport: UDP
3.4 Principles of reliable data transfer
3.5 Connection-oriented transport: TCP
segment structure
reliable data transfer
flow control
connection management
Transport Layer

4. Transport services and protocols
application
transport
network
data link
physical
provide logical communication between app processes running on different hosts
transport protocols run in end systems
send side: breaks app messages into segments, passes to network layer
rcv side: reassembles segments into messages, passes to app layer
more than one transport protocol available to apps
Internet: TCP and UDP
logical end-end transport
application
transport
network
data link
physical
Transport Layer

5. Transport Layer Services
At the transmitter side (source), the transport layer accepts messages (A_PDU) from the network applications and forms with them segments (T_PDU) that then it sends by using network layer services.
At the receiver side (destination), the transport layer receives segments from network layer and passes the user data that contains (messages) to the application layer.
source
destination
Application protocol
application
transport
network
data link
physical
application
transport
network
data link
physical
Transport protocol
Network protocol
network data link
physical
Network protocol
L.P.
data link physical
data link physical
L.P.
L.P.
L.P.
P.P.
P.P.
P.P.
P.P.
switch
switch
router
L.P. = Data Link Protocol
P.P. = Physical Protocol
Transport Layer

6. Transport vs. network layer
network layer: provides a logical communication service between hosts
Similar to postal service that sends a letter to a postal address
transport layer: extends the network service to provide a logical communication service between application processes
It’s known as transport layer multiplexion and demultiplexion
It relies on, enhances, network layer services
Transport Layer

7. Transport vs. network layer
Household analogy:
Two houses with 10 kids in each one. They send letters among them every week.
processes = kids
app messages = letters in envelopes
hosts = houses
transport protocol = Ann (in one house) and Bill (in the other house) are responsible for picking up their brothers’ letters, sending them using the Postal Office, waiting for incoming letters and delivering them to their brothers
network-layer protocol = postal service
Transport Layer

8. Internet transport-layer protocols
TCP: reliable, in-order delivery
congestion control
flow control
connection setup
UDP: unreliable, unordered delivery
extension of “best-effort” IP
Not available services:
Guaranteed delay
Guaranteed bandwidth
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
logical end-end transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
Transport Layer

9. Unit 3. Overview. 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing
3.3 Connectionless transport: UDP
3.4 Principles of reliable data transfer
3.5 Connection-oriented transport: TCP
segment structure
reliable data transfer
flow control
connection management
Transport Layer

10. Multiplexing/demultiplexing
Multiplexing at send host:
= process
= socket
delivering received segments (T_PDU)
to correct socket, by using the header (T_PCI)
Demultiplexing at recv host:
gathering data from multiple
sockets, enveloping data (T_PDU) with header (T_PCI) (later used for
demultiplexing)
application
application
application P1 P4 P3 P1 P2
transport
transport
transport
network
network
network
link
link
link
physical
physical
physical
host 3
host 1
host 2
Transport Layer

11. How demultiplexing works
Network layer receives IP datagrams (N_PDU)
each N_PDU has source IP address, destination IP address in its header (N_PCI)
each N_PDU carries 1 transport-layer segment (T_PDU)
Transport layer receives segments (T_PDU)
each T_PDU carries in its T_PCI
a source port number and
a destination port number
each T_PDU carries application user data (T_UD)
32 bits
source port #
dest port #
other header fields T_PCI
T_UD: application
data
(message)
TCP/UDP segment (T_PDU) format
Destination host uses IP addresses & port numbers to direct the T_UD of the T_PDU to appropriate socket
Transport Layer

12. Connectionless demultiplexing (UDP)
when UDP protocol in destination host receives the segment (T_PDU):
checks destination port number in header segment (T_PCI)
directs user data (T_UD) of the T_PDU to UDP socket with that port number
Demux (UDP) doesn’t check source IP addresses and/or source port numbers
Create UDP sockets by using an specific host-local port number or using one unused:
DatagramSocket mySocket1 = new DatagramSocket(12534);
DatagramSocket mySocket2 = new DatagramSocket();
When source host creates the T_IDU to send into UDP socket, must specify (in T_ICI):
(dest IP address, dest port number)
Transport Layer

13. Connectionless demux (UDP) (cont)
Local port #. If it’s a server process is mandatory
DatagramSocket serverSocket = new DatagramSocket(6428);
Client
IP:B P2
client
IP: A P1 P3
server
IP: C
SP: 6428
DP: 9157
SP: 9157
DP: 6428
DP: 5775
SP: 5775
Source IP and source port allow P3 to identify the source process (P1 or P2) and return a message.
SP = Source port #
DP = Destination port #
Transport Layer

14. Connection-oriented demux (TCP)
TCP socket identified by 4-tuple:
source IP address
source port number
dest IP address
dest port number
recv host uses all four values (in N_PCI and T_PCI) to direct segment (T_PDU) to appropriate TCP socket
server host may support many simultaneous TCP sockets:
each socket identified by its own 4-tuple
web servers have different TCP sockets for each connecting client
non-persistent HTTP will have different socket for each request
Transport Layer

15. Connection-oriented demux (TCP)
… when the server receives a connection request from the client, server must accept connection. Connection is identified by the client socket (IP & port) and the server socket (IP & port)
Socket socketConnection = welcomeSocket.accept();
When destination host receives a T_PDU, it must check both source and destination ports in the Transport header (T_PCI). It also must check both source and destination IP addresses in the N_ICI. Then, it must send the user data (T_UD) to the correct application process.
When creating TCP socket…
… port number must be indicated at the server. Port must be “listening”
ServerSocket WelcomeSocket = new ServerSocket(6789);
… server socket (IP & port) must be provided as T_ICI. Connection with server’s socket is established.
Socket ClientSocket = new Socket(“ServerHostname", 6789);
Transport Layer
3-15

16. Connection-oriented demux (TCP) Web server with several process
client
IP: A P4 P5 P6 P2 P1 P3
SP: 5775
DP: 80
S-IP: B
D-IP:C
client
IP: B
SP: 9157
server
IP: C
SP: 9157
DP: 80
DP: 80
S-IP: A
S-IP: B
D-IP:C
D-IP:C
No problem if two clients process use the same source IP
No problem if two clients process use the same source port
SP = Source port #
DP = Destination port #
S-IP = Source IP address
D-IP = Destination IP address
Transport Layer

17. Connection-oriented demux (TCP): Threaded Web Server
client
IP: A P4 P2 P1
Instead of one server process per each socket, there is a “thread” per socket and only one process. P3
SP: 5775
DP: 80
S-IP: B
D-IP:C
SP: 9157
server
IP: C
client
IP: B
SP: 9157
DP: 80
DP: 80
S-IP: A
S-IP: B
D-IP:C
D-IP:C
SP = Source port #
DP = Destination port #
S-IP = Source IP address
D-IP = Destination IP address
Transport Layer

18. Unit 3. Overview 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing
3.3 Connectionless transport: UDP
3.4 Principles of reliable data transfer
3.5 Connection-oriented transport: TCP
segment structure
reliable data transfer
flow control
connection management
Transport Layer

19. UDP: User Datagram Protocol [RFC 768]
Very simple Internet transport protocol
“best effort” service, UDP segments (T_PDU) may be:
lost
delivered out of order to app
connectionless:
no handshaking between UDP sender and receiver
each UDP segment (T_PDU) handled independently of others
Why is there a UDP?
no connection establishment (which can add delay)
simple: no connection state at sender, receiver
small segment header (T_PCI)
Transport Layer

20. UDP segment format (T_PDU)
UDP: more…
32 bits
source port #
dest port #
T_PCI
length
checksum
often used for streaming multimedia apps
loss tolerant
rate sensitive
other UDP uses
DNS
SNMP
reliable transfer over UDP? It’s possible by adding reliability at application layer
application-specific error recovery!
T_UD
Application
data
(message)
UDP segment format (T_PDU)
The header (T_PCI) only has 4 fields.
Length, in bytes of the whole T_PDU, including header.
Transport Layer

21. UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted segment (T_PDU)
Sender (simplified):
treat T_PDU segment contents as sequence of 16-bit integers
checksum: addition of segment contents with carryout, then 1’s complement
sender puts checksum value into UDP checksum field (T_PCI)
Receiver:
compute checksum of received segment
check if computed checksum equals checksum field value:
NO - error detected
YES - no error detected. But maybe errors nonetheless? More later ….
Transport Layer

22. Internet Checksum Example
Note: when adding numbers, a carryout from the most significant bit needs to be added to the result at the right-most position.
Example: add two 16-bit integers 1
carryout
sum (with carryout)
checksum
Transport Layer

23. Unit 3. Overview 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing
3.3 Connectionless transport: UDP
3.4 Principles of reliable data transfer
3.5 Connection-oriented transport: TCP
segment structure
reliable data transfer
flow control
connection management
Transport Layer

24. Principles of Reliable data transfer
Important in application, transport and link layers
top-10 list of important networking topics!
Why is reliable transfer necessary?
wrong PDUs
Interferences in link transmission can change transmitted bits.
lost PDUs
When packet queue is full incoming packets are dropped.
duplicated PDUs
Communication failures make already received PDUs be retransmitted.
How are these problems detected?
wrong PDUs
Error checking mechanisms (included in PCI).
E.g. Checksum
Most complex and reliable algoritms are used in data link layer.
lost and duplicated PDUs
Adding “something” in the header (PCI) of each PDU to distinguish it from the rest of the sent PDUs.
How are these problems resolved?
Retransmission
Sender transmits again the PDU that had problems.
Transport Layer

25. Principles of Reliable data transfer
General case of communication between peers entities in a same layer:
To communicate to its peer entity, an entity sends the other a PDU makes up a header (PCI) and, in general, user data (UD).
Headers (PCI) contains protocol control information.
In general, both entities transmit and receive user data.
Bidirectional transfer of user data between peers entities.
Simplification of this general case:
Makes easier the explanation of the principles of reliable data transfer.
Suppose an unidirectional user data transfer.
One of these peer entities is a transmitter (Tx) and the other is the receiver (Rx).
Tx transmits PDUs with PCI and UD (UD comes from the above layer).
Rx receives PDUs with PCI and UD (UD goes to the above layer).
Rx transmits PDUs that only contents PCI (without UD, only control info.)
Bidirectional protocol control information transfer.
Transport Layer

26. Principles of Reliable data transfer
What types of PDU are used?
Data PDU
Sent by the Tx
Contents user data (UD)
Contents protocol control information (PCI)
Control PDU
Sent by the Rx
Does not carry user data (UD)
Contents only protocol control information (PCI)
Notice that
It’s wrong to think that Tx doesn’t send control information and sends only data PDUs.
Data PDUs also carry control information.
Transport Layer

27. Principles of Reliable data transfer
What does the header (PCI) content?
The PCI of a data PDU contents information that allows:
Rx detecting if the data PDU has errors.
Identifying the data PDU and distinguishing it from the others PDUs sent by Tx.
The PCI of a control PDU contents information that allows:
Tx detecting if the control PDU contents errors.
Rx identifying a particular data PDU, and reports that the data PDU:
has been received OK by the Rx:
ACK, acknowledgement, return receipt
Has not been received OK by the Rx:
NAK, NACK, Negative acknowledgement, negative return receipt
Note
Information in PCI that is for identifying a particular data PDU is called sequence number.
Transport Layer

28. Principles of Reliable data transfer
Tx basic operation:
The Tx entity in a particular layer forms a data PDU with UD and PCI and transmits it to the Rx.
Now, Tx waits for some time, known as time_out, until it receives a control PDU from the Rx. The control PDU indicates:
Data PDU received OK, with an ACK.
Tx doesn’t do anything else.
Data PDU received with errors, with a NACK.
Tx retransmits the PDU.
If time_out expires before control PDU from Rx arrives, then
Rx basic operation:
When receiving a data PDU, Rx entity in a layer:
If the data PDU arrives OK, it is mandatory that Rx sends Tx an ACK control PDU to notify it.
If the data PDU arrives with errors, it is optional that Rx sends Tx a NACK control PDU to notify it.
Q: How long should time_out be, as minimum?
Q: Does Rx pass always to the above layer the UD contained in a data PDU received OK?
Transport Layer

29. Principles of reliable data transfer
PDU X
ACK X
PCI
Example 1.
Tx sends only a PDU with UD and doesn’t send the next until the transmission is sucessful.
Rx only sends ACK control PDU.
dtransPDU
dtransack
PDU 1
PDU 1
Time_out
Lost PDU
ACK 1
PDU 1
PDU 2
Time
ACK 1
ACK 2
PDU 2
Time_out
PDU 3 X
PDU 2
ACK 3
wrong PDU
ACK 2 Tx Rx Tx
Transport Layer
With errors Rx
Without errors

30. Principles of reliable data transfer
Example 2.
Idem example 1.
Rx also sends NACK control PDU.
Without errors.
Same behaviour as previous e.g.
PDU 1 X
NACK 1
PDU 1
ACK 1
time
PDU 2
Time_out
PDU 2
ACK 2 Tx Rx
With errors
Transport Layer

31. Principles of reliable data transfer
The mechanism that guarantees a reliable data transfer is known as
a stop-and-wait protocol
It’s not much efficient
Tx must stop and wait for receiving the ACK before sending the next PDU.
Is it possible to measure transfer performance?
To simplify, let’s suppose that:
Tx always has a ready PDU to send,
There isn’t any error,
Each PDU has L bytes of UD and 0 bytes of PCI,
dtransack = 0.
Utilization of the Tx or channel (U tx) = fraction of time that Tx/channel is busy transmitting bits of the PDU.
Transport Layer

32. Stop-and-wait protocol performance
Remember
dtrans = L/R Rx Tx
First PDU bit sent, t = 0
Last PDU bit sent, t = L/R
First PDU bit received
RTT
Last PDU bit received, send ACK
ACK received, t = RTT+L/R
Send next PDU
Transport Layer

33. Stop-and-wait protocol performance
The protocol works but its performance is poor
Example: 1 Gbps link, RTT = 30 ms, PDU = 1KByte
1 PDU of 1KByte every 30,008 msec  33,3kByte/sec effective transfer rate in a 1 Gbps link
Protocol can limit the capabilities provided by the underlying network hardware!
Is it possible to improve it?
Transport Layer

34. Protocols with pipelining
Pipelining: Tx is allowed to send multiple PDUs (“in-flight”) without waiting for acknowledgements (ACK), improving performance by far.
Sequence numbers used in PCI must have enough range to distinguish all in-transit PDUs.
Buffers are needed in Tx and, sometimes, in Rx
PDU
PDU
ACK
Pipelining
Stop-and-wait
Note: We’ll study in depth this concept when studying TCP
Transport Layer

35. Pipelining: increased utilizationTx Rx
Send bit 1 of 1st PDU, t = 0
Send last bit of PDU, t = L / R
First bit of 1st PDU arrives
RTT
Last bit of 1st PDU arrives, send ACK
Last bit 2nd PDU arrives, send ACK
Last bit 3rd PDU arrives, send ACK
ACK received, send next PDU, the 4th, t = RTT + L / R
Increase utilization
by a factor of 3!
Transport Layer

36. Reliable data transfer service
How does transport layer provide a reliable data transfer service to the application layer?
Transport Layer

37. Reliable data transfer service
How does transport layer provide a reliable data transfer service to the application layer?
Transport layer is above network layer that provides an unreliable data transfer service.
Transport Layer

38. Reliable data transfer service
Transport layer must implement a reliable data transfer protocol (rdt).
Characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt). We’re going to experiment with different types of unreliable channels.
Transport Layer

39. Reliable data transfer: getting started
rdt_send(): called from above, (e.g., by app.). Passed data to
deliver to receiver upper layer
deliver_data(): called by rdt to deliver data to upper
sender
side (Tx)
receiver
side
(Rx)
udt_send(): called by rdt,
to transfer PDU over
unreliable channel to receiver
rdt_rcv(): called when PDU arrives on rcv-side of unreliable channel
udt = Unreliable Data Transfer
Transport Layer

40. Reliable data transfer: getting started
We will:
incrementally develop sender and receiver sides of reliable data transfer protocol (rdt)
consider only unidirectional data transfer (Tx  Rx)
but control info may flow in both directions!
use finite state machines (FSM) to specify sender, receiver
event causing state transition
actions taken on state transition
state 1
state: when in this “state” next state uniquely determined by next event
state 2
event
actions
Note
Rdt protocol actually can be applied in any layer that must provide reliability, not only in transport layer.
Transport Layer

41. rdt1.0: reliable transfer over a reliable channel
The most simple case. It’s not realistic.
underlying channel perfectly reliable
no bit errors
no loss of PDUs
separate FSMs for sender, receiver:
sender sends PDUs into underlying channel (to the below layer)
receiver read data from underlying channel (from the below layer)
Wait for call from above
rdt_send(data)
Wait for call from below
rdt_rcv(packet)
extract (packet,data)
deliver_data(data)
packet = make_pkt(data)
udt_send(packet)
sender (Tx)
receiver (Rx)
Note
In FSMs, PDUs are called packets.
Transport Layer

42. rdt2.0: channel with bit errors
underlying channel may change bits in packet
checksum to detect bit errors
the question: how to recover from errors.
acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK
negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors
sender retransmits pkt on receipt of NAK
new mechanisms in rdt2.0 (beyond rdt1.0):
error detection
receiver feedback: control PDUs (ACK,NAK) rcvrsender
Transport Layer

43. rdt2.0: FSM specification
rdt_send(data)
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
receiver (Rx)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for ACK or NAK
Wait for call from above
udt_send(NAK)
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(sndpkt)
Both, Tx & Rx, use udt_send() to send their PDUs through the unreliable channel implemented by the below layer.
rdt_rcv(rcvpkt) && isACK(rcvpkt)
Wait for call from below L
Both, Tx & Rx, wait for event rdt_rcv() that delivers a PDU from the below layer (unreliable).
sender (Tx)
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
Transport Layer

44. rdt2.0: operation with no errors
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for ACK or NAK
Wait for call from above
udt_send(NAK)
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
Wait for call from below L
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
Transport Layer

45. rdt2.0: error scenario rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for ACK or NAK
Wait for call from above
udt_send(NAK)
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
Wait for call from below L
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
Transport Layer

46. rdt2.0 serious fail
What happens if a control PDU (ACK or NAK) corrupted?
Tx doesn’t know if it has received an ACK or a NACK as the control PDU has errors!
Tx doesn’t know how data PDU arrived at Rx
can’t retransmit: possible duplicate
Handling duplicates:
Tx retransmits current PDU if control PDU (ACK/NAK) has errors
Tx adds sequence number in PCI to each PDU
Rx discards (doesn’t deliver up) duplicate PDUs
stop and wait
Tx sends one PDU, then waits for receiver response
Transport Layer

47. rdt2.1: sender, handles garbled ACK/NAKs
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
Wait for ACK or NAK 0
Wait for call 0 from above
udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt) L L
Wait for ACK or NAK 1
Wait for
call 1 from above
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
udt_send(sndpkt)
Transport Layer

48. rdt2.1: receiver, handles garbled ACK/NAKs
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt)
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt)
Wait for
0 from below
Wait for
1 from below
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) &&
has_seq1(rcvpkt)
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) &&
has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
Transport Layer

49. rdt2.1: discussion Sender: seq # added to PDUs
two seq. #’s (0,1) will suffice. Why?
must check if received control PDU (ACK/NAK) corrupted
twice as many states
state must “remember” whether “current” PDU has 0 or 1 seq. #
Receiver:
must check if received PDU is duplicate
state indicates whether 0 or 1 is expected PDU seq #
note: receiver can not know if its last ACK/NAK received OK at sender
Transport Layer

50. rdt2.2: a NAK-free protocol
same functionality as rdt2.1, using ACKs only
instead of NAK, Tx sends ACK for last PDU received OK
Rx must explicitly include seq # of data PDU being ACKed (in PCI of all control PDUs, ACK)
duplicate ACK at Tx results in same action as NAK: retransmit current PDU (not recognize yet)
Transport Layer

51. rdt2.2: sender, receiver fragments
Wait for call 0 from above
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_send(data)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
Wait for ACK
sender FSM
fragment
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt)
Wait for
0 from below
rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) ||
has_seq1(rcvpkt))
receiver FSM
fragment L
Transport Layer

52. rdt3.0: channels with errors and loss
New assumption: underlying channel can also lose PDUs (data or control -ACKs)
checksum, seq. #, ACKs, retransmissions will be of help, but not enough
New approach:
Tx waits “reasonable” amount of time for ACK (time_out)
Tx retransmits if no ACK received in this time
if data PDU (or control, ACK) just delayed (not lost):
retransmission will be duplicate, but use of seq. #’s already handles this
Rx must specify seq # of data PDU being ACKed (in PCI of ACK)
requires countdown timer to detect if time_out expires
Transport Layer

53. Design receiver FSM for the rdt3.0 protocol
rdt3.0 sender (Tx)
rdt_send(data)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt) L L
Wait for
call 0from above
Wait for ACK0
timeout
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,1)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
stop_timer
stop_timer
Wait for ACK1
Wait for
call 1 from above
timeout
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt) L
rdt_send(data)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,0) )
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
start_timer
Exercise
Design receiver FSM for the rdt3.0 protocol L
Transport Layer

54. rdt3.0 in action
Transport Layer

55. rdt3.0 in action
Transport Layer

56. Unit 3. Overview 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing
3.3 Connectionless transport: UDP
3.4 Principles of reliable data transfer
3.5 Connection-oriented transport: TCP
segment structure
reliable data transfer
flow control
connection management
Transport Layer

57. TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 point-to-point:
one sender, one receiver
reliable, in-order byte stream:
no “message boundaries” (A_PDUs)
pipelined:
TCP congestion and flow control set window size (maximum PDUs # in-flight)
send & receive buffers
full duplex data:
bi-directional data flow in same connection
MSS: maximum segment size (UDs)
connection-oriented:
handshaking (exchange of control msgs) inits sender, receiver state before data exchange
flow control:
sender will not overwhelm receiver
Transport Layer

58. TCP segment structure (T_PDU)
source port #
dest port #
32 bits
application
data
(variable length)
sequence number
acknowledgement number
Receive window
Urg data pnter
checksum F S R P A U
head
len
not
used
Options (variable length)
URG: urgent data
(generally not used)
counting
by bytes
of data
(not segments!)
ACK: ACK #
valid
T_PCI
PSH: push data now
(generally not used)
# bytes
rcvr willing
to accept
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
Internet
checksum
(as in UDP)
T_UD
Transport Layer

59. TCP seq. #’s and ACKs (I) Sequence number:
Assigned number for the first byte of a TCP segment that is sent to the other peer entity.
Initial value is set in a random way by each entity peer when connection is initiated.
Increased when segments containing PDUs are sent.
ACK number:
Points out the sequence number which is expected to be received by the other peer entity.
All the previous bytes are acknowledged (cumulative ACK ).
Q: How does the rcv manage disordered segments?
A: TCP specification leaves it to the implementer.
Transport Layer

60. TCP seq. #’s and ACKs (II)
simple “uppercase” scenario
Host A
Host B
User types
‘hello!’,
application
send it to the
remote host
Seq=42, ACK=79, data = ‘hello!’
host ACKs
receipt of
‘hello’ & sends
back a ‘HELLO!’
message
Seq=79, ACK=48, data = ‘HELLO!’
host ACKs
receipt
of ‘HELLO!’
Seq=48, ACK=85
The hosts have sent the ACK in their data PDU (“piggybacking”) in the two first segments.
Note
time
Transport Layer

61. TCP Round Trip Time and Timeout
Q: how to set up the TCP timeout value?
longer than RTT
but RTT varies
too short: premature timeout
unnecessary retransmissions
too long: slow reaction to segment loss
Q: how to estimate RTT?
SampleRTT: measured time from segment transmission until ACK
Retransmissions are ignored
SampleRTT may vary, so a more stable RTT value is desirable.
EstimatedRTT is calculated as the average of several recent measurements, not just current SampleRTT
Transport Layer

62. TCP Round Trip Time and Timeout
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
Exponential weighted moving average
influence of past sample decreases exponentially fast
typical value:  = 0.125
Transport Layer

63. Example RTT estimation:
Transport Layer

64. TCP Round Trip Time and Timeout
Setting the timeout
EstimatedRTT plus “safety margin”
large variation in EstimatedRTT -> larger safety margin
A first estimation of SampleRTT deviation from EstimatedRTT:
DevRTT = (1-)*DevRTT +
*|SampleRTT-EstimatedRTT|
(typically,  = 0.25)
Then set timeout interval:
TimeoutInterval = EstimatedRTT + 4*DevRTT
Transport Layer

65. Unit 3. Overview 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing
3.3 Connectionless transport: UDP
3.4 Principles of reliable data transfer
3.5 Connection-oriented transport: TCP
segment structure
reliable data transfer
flow control
connection management
Transport Layer

66. TCP reliable data transfer
TCP creates rdt service over IP’s unreliable service
pipelined segments, several segments “in-flight”
cumulative acks
TCP uses single retransmission timer
retransmissions are triggered by:
timeout events
duplicate acks
Initially, a simplified TCP sender is considered :
ignores duplicate acks
ignores flow control, congestion control
Transport Layer

67. TCP sender events: data rcvd 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:
retransmit segment that caused timeout
restart timer
Ack rcvd:
If acknowledges previously unacked segments
update what is known to be acked
start timer if there are outstanding segments
Transport Layer

68. TCP sender (simplified)
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum
while (true) {
switch(event)
event: data received from application above
create TCP segment with data and sequence number NextSeqNum
if (timer currently not running)
start timer
pass segment to IP /* Below layer, unreliable, sends segment to Rx */
NextSeqNum = NextSeqNum + length(data)
event: timer timeout
retransmit not-yet-acknowledged segment with smallest sequence number
event: ACK received, with ACK field value of y
if (y > SendBase) { /* If not-yet-adcknowledged data are being acknowleged */
SendBase = y /* Update indicator not-yet-acknowledged data*/
stop timer
if (NextSeqNum > SendBase) /* There are currently not-yet-acknowledged data */ }
} /* end of infinite loop */
Every data byte with seq# less than SendBase is acknowledged cumulatively. The ones that have greater or equal seq # are not yet acknowledged.
NextSeqNum points to “not sent” data.
Rx sends ack for all data with seq # less than y.
Transport Layer

69. TCP: retransmission scenarios (I)
Host A
Seq=92, 8 bytes data
ACK=100
loss
timeout
lost ACK scenario
Host B X
time
Host A
Host B
Seq=92 timeout
Seq=92, 8 bytes data
Seq=100, 20 bytes data
ACK=100
ACK=120
SendBase
= 100
Seq=92, 8 bytes data
SendBase
= 120
Seq=92 timeout
ACK=120
SendBase
= 100
SendBase
= 120
time
premature timeout scenario
Transport Layer

70. TCP retransmission scenarios (II)
Host A
Seq=92, 8 bytes data
ACK=100
loss
timeout
Cumulative ACK scenario
Host B X
Seq=100, 20 bytes data
ACK=120
time
Time_out Sec=92
Time_out Sec=92
SendBase = 120
Timer with the “recommended” timeout would have expired before ACK=120 arrived.
So, on a retransmission only, Tx will use a timeout that is longer that the recommended one (double for first retransmission, quadruple for second one, ….), which make it easy to produce cumulative ACKs.
Doesn’t expire
Transport Layer

71. TCP ACK generation [RFC 1122, RFC 2581]
Event at Receiver
Arrival of in-order segment with
expected seq #. All data up to
expected seq # already ACKed
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
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 ACK, that corresponds
to the arrived segment
Transport Layer

72. TCP: Fast Retransmission
time-out period is often quite 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.
if sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost:
fast retransmit: resend segment before timer expires
TCP doesn’t use NAKs, so Rx can not notify that a segment is missing.
Note
Transport Layer

73. TCP: Fast retransmission
Arriving these three segment out of order makes Rx send a duplicate ACK per one of them inmediately, acknowledging first segment data.
Host A
Host B
ACK
TX receives, three times, a duplicate ACK for first segment data. So it supposses that the second segment was missing and resend fastly it again, before timer expires.
Duplicate ACK
Time_out 2nd segment
Duplicate ACK
Duplicate ACK
Resend 2nd segment
time
Doesn’t expire
Transport Layer

74. TCP: Fast retransmit
This is the ACK reception event in the simplified TCP Tx.
event: ACK received, with ACK field value of y
if (y > SendBase) { /* If not-yet-adcknowledged data are being acknowleged */
SendBase = y /* Update indicator not-yet-acknowledged data*/
stop timer
if (NextSeqNum > SendBase) /*There are currently not-yet-acknowledged segments*/
start timer }
else { /*It’s a duplicated ACK for already acknowledged segment*/
increment count of dup ACKs received for y
if (count of dup ACKs received for y = 3) {
resend segment with sequence number y /*Fast retransmission*/
This part is for giving sender TCP more “intelligence” and knows to react if receives 3 duplicated ACKs, by doing fast retransmission for not-already acknowledged segment.
Transport Layer

75. Unit 3. Overview 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing
3.3 Connectionless transport: UDP
3.4 Principles of reliable data transfer
3.5 Connection-oriented transport: TCP
segment structure
reliable data transfer
flow control
connection management
Transport Layer

76. TCP Flow Control flow control
sender shall not overflow
receiver’s buffer by
transmitting too much,
too fast
flow control
receive side of TCP connection has a receive buffer:
RcvWindow
Variable size
Free space in TCP buffer
TCP data in buffer, waiting for being read by app
Data from IP
Application process
RcvBuffer
Fixed size
app process may be slow at reading from buffer
speed-matching service: matching the sender’s rate to the receiving app’s drain rate
Transport Layer

77. TCP Flow control: how it works
RcvWindow
Variable size
Free space in TCP buffer
TCP data in buffer, waiting for being reading by app
Data from IP
Application process
RcvBuffer
Fixed size
Suppose TCP receiver discards out-of-order segments, so they don’t take up the RcvBuffer.
Free space in buffer:
RcvWindow = RcvBuffer-[LastByteRcvd – LastByteRead]
This difference is the taken up space
Transport Layer

78. TCP Flow control: how it works
RcvWindow
Variable size
Free space in TCP buffer
TCP data in buffer, waiting for being reading by app
Data from IP
Application process
RcvBuffer
Fixed size
rcvr announces free space in buffer by including value of RcvWindow in header segments (T_PCI)
sender limits unACKed data to RcvWindow
Guarantees RcvBuffer is not overflown
Transport Layer

79. TCP Flow control: how it works
Source port #
Dest. Port #
Application data
(variable length)
Sequence #
ACK #
RcvWindow
Urg. Data Pointer
checksum F S R P A U
Head. length
not
used
Options (variable length)
T_PCI
T_UD
Segment format (T_PDU)
RcvWindow value of T_PCI is related with ACK# value of T_PCI.
When Tx receives a segment, ckecks the ACK# value and RcvWindow value to know the range of seq # matching to data that is autorized to have not-already-acked:
From ACK#
to (ACK# + RcvWindow – 1)
Transport Layer

80. Unit 3. Overview 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing
3.3 Connectionless transport: UDP
3.4 Principles of reliable data transfer
3.5 Connection-oriented transport: TCP
segment structure
reliable data transfer
flow control
connection management
Transport Layer

81. TCP Connection Management
Recall: TCP sender and receiver establish a “connection” before exchanging segments that carry user data.
During the connection phase, both of them have to initialize TCP variables:
seq. #s
Receiver and transmitter buffers (both in client and server)
Flow control info (e.g. RcvWindow)
client: connection initiator
Socket clientSocket = new Socket("hostname","port number");
server: listening and contacted by client
Socket connectionSocket = welcomeSocket.accept();
Transport Layer

82. TCP Connection Management
client
server
Three way handshake
SYN, SeqNum=client_isn(not carrying ACK neither DATA)
SYN, SeqNum=server_isn, ACK=client_isn+1 (not carrying DATA)
SeqNum=client_isn+1, ACK=server_isn+1 (not usually carryingDATA)
In TCP_PDUs flow, if a flag is active, it is indicated in the labels (except ACK, which is implicit).
Note
time
time
Transport Layer

83. TCP Connection Management: Establishment
Three-way handshake:
Step 1: Client sets up initial values for all TCP variables (buffers, initial sequence number, etc.)- Then, it sends a SYN segment to the server:
Doesn’t carry data.
Specifies the initial seq # (client_isn).
Carries SYN bit set to one. It is considered as the first byte of the data stream of the TCP connection.
Step 2: when receiving SYN segment, server initialize TCP buffers and variables and sends a (SYN-ACK segment) to the TCP client:
Has the same characteristics of client SYN segment but specifying the server initial seq # (server_isn).
Acknowledges the client’s SYN segment.
Step 3: Client receives the SYN-ACK segment from the server and responds sending an ACK segment:
acknowledges the server’s SYN-ACK segment.
May content user data, although it ‘s not usual.
Transporte

84. TCP Connection Management: Closing a connection
client
FIN
server
ACK
socketClient.close();
socketConnection.close();
Closed connection
timed wait
FIN segment has FIN bit set to 1. It is the last byte of the TCP connection data stream.
TCP entity that sends a FIN segment can not send data anymore but can receive.
Both client and server may start connection close.
Note
Transport Layer

85. TCP Connection Management: Closing a connection
Step 1: client app closes connection by socketClient.close();  sends a TCP FIN segment to server.
Step 2: server receives FIN, replies with ACK.
Step 3: server app closes connection by socketConnection.close(); sends FIN to client.
Step 4: client receives FIN, replies with ACK.
Enters “timed wait” - will respond with ACK to received FINs
When “timed wait” expires, TCP client considers the connection is closed (releasing buffers and others resources related to the connection).
Step 5: server receives ACK. Connection closed (releasing buffers…).
Transport Layer

86. TCP Connection Management: Closing a connection
Previous steps with some minor modifications are the same to close the connection if:
Server takes the lead to close the connection and run socketConexion.close();
Both client and server, decide, simultaneously, to close the connection and run at the same time socketCliente.close(); and socketConexion.close();
Connections have to be closed inmediately when a RST segment is received (RST bit set to 1). RESET segment is sent only in some special cases and it is not the usual way to close the connection.
Transport Layer

87. TCP Connection Management: Lifecycle
Life of a TCP connection: It is the sequence of TCP states of a TCP connection.
The next state machine shows 11 posible states and the diferent transitions among states.
CLOSING
LAST_ACK
CLOSE_WAIT
ESTABLISHED
LISTEN
FIN_WAIT_2
TIME_WAIT
FIN_WAIT_1
SYN_RCVD
SYN_SENT
CLOSED
Transport Layer

88. TCP Connection Management: Lifecycle
CLOSED is a fictitious state. It is the connection state before creating it, and after closing it completely. In this state, the connection doesn’t exist yet or has already stopped existing.
CLOSED is the initial and the final state of a connection
CLOSING
LAST_ACK
CLOSE_WAIT
ESTABLISHED
LISTEN
FIN_WAIT_2
TIME_WAIT
FIN_WAIT_1
SYN_RCVD
SYN_SENT
CLOSED
CLOSED
Transport Layer

89. TCP Connection Management: Lifecycle
When the connection is in ESTABLISHED state TCP entities can interchange segment containing data.
Thus, client and server’s goal is passing from CLOSED to ESTABLISHED, send and receive data and go back to CLOSED state again.
CLOSING
LAST_ACK
CLOSE_WAIT
ESTABLISHED
LISTEN
FIN_WAIT_2
TIME_WAIT
FIN_WAIT_1
SYN_RCVD
SYN_SENT
CLOSED
ESTABLISHED
Transport Layer

90. TCP Connection Management: Lifecycle
In green, the transitions of a typical client lifecycle.
In red, the transitions of a typical server lifecycle.
Black transitions are posible but not usual.
CLOSING
LAST_ACK
CLOSE_WAIT
ESTABLISHED
LISTEN
FIN_WAIT_2
TIME_WAIT
FIN_WAIT_1
SYN_RCVD
SYN_SENT
CLOSED
Transport Layer

91. TCP Connection Management: Lifecycle
The first transition in a typical client clifecycle goes from CLOSED state to SYN_SENT state.
It happens when a “Client app starts a connection”. Event is issued.
“Send SYN segment” action is associated to it.
ESTABLISHED
FIN_WAIT_2
TIME_WAIT
FIN_WAIT_1
SYN_SENT
CLOSED
Transport Layer

92. TCP Connection Management: Lifecycle
Possible combinations “event/action” of the transitions of a typical client lifecycle.
Client app initiates a connection
Pass twice MSL time
Send SYN segment
Send nothing
CLOSED
SYN_SENT
TIME_WAIT
SYN-ACK segment is received
FIN segment is received
Send ACK for SYN
Send ACK for FIN
ESTABLISHED
FIN_WAIT_2
App initiates close connection
ACK for FIN is received
FIN_WAIT_1
Send nothing
Send FIN segment
Transporte

93. TCP Connection Management: Lifecycle
The first transition for typical server lifecycle goes from CLOSED state to LISTEN state.
It happens when server app creates a welcome socket and remains waiting for connection from clients.
There aren’t any associated actions to the first transition.
LAST_ACK
CLOSE_WAIT
ESTABLISHED
LISTEN
SYN_RCVD
CLOSED
Transport Layer

94. TCP Connection Management: Lifecycle
Possible combinations “event/action” of the transitions of a typical server lifecycle.
Server app creates welcome socket
ACK for FIN is received
CLOSED
Send nothing
Send nothing
LISTEN
LAST_ACK
App initiates close connection
SYN segment is received
Send ACK-SYN segment
Send FIN segment
SYN_RCVD
CLOSE_WAIT
ACK for SYN is received
FIN segment is received
ESTABLISHED
Send nothing
Send ACK for FIN
Transport Layer

95. Unit 3: Summary principles behind transport layer services:
multiplexing, demultiplexing
reliable data transfer
flow control
instantiation and implementation in the Internet
UDP
TCP
Next:
leaving the network “edge” (application, transport layers)
into the network “core”
Transport Layer

96. PROBLEMs AND EXERCISES
Departamento de Tecnología Electrónica
Computer Networking – Unit 3: Transport layer
PROBLEMs AND EXERCISES
Transport Layer 96

97. Pr1: port numbers
Suppose that client A initiates a TCP connection to a Web server called S. Naerly simultaneously, client B also initiates a TCP connection to S.
Indicate possible source and destination port numbers for:
Segments sent from A to S
Segments sent from B to S
Segments sent from S to A
Segments sent from S to B
If A and B are in diferent hosts, could source port number from A to S be the same that from B to S?
What happens if client process A and B are in the same host?
Transport layer 2-97 97

98. Pr2: port numbers
Look at the connections that the clients have initiated with the Web server and answer the questions: P1 P4 P5 P6 P2 P1 P3
SP: 5775
DP: 80
S-IP: B
D-IP: C
SP: 9157
Web Server IP: C
SP: 9157
DP: 80
client
IP: B
Client IP: A
DP: 80
S-IP: A
S-IP: B
D-IP: C
D-IP: C
SP = Source port #
DP = Destination port #
S-IP = Source IP address D-IP = Destination IP address
Transport Layer 2-98 98

99. Pr2: port numbers (II)
What are the source and destination port number values in the segments flowing from the server to the clients’ processes?
What are the IP addresses (source and destination) of N_PDUs carrying these transport-layer segments?
Transport Layer

100. Pr3: checksum UDP and TCP use 1s complement for their checksums.
Suppose you have the following three 16-bit words:
What is the 1s complement of the sum of these 16-bit words?
Receiver adds the three words to the received checksum. If the result of the addition, in binary, contains some zero, the receiver realizes there is some error in some bit, is it right?
Is it possible that a 1-bit error will go undetected?
Propose a particular example for a non-detectable error.
Transport Layer

101. Pr4: Channel utilization
Pipeline protocols improve the performance of stop-and-wait protocols.
Suppose a Tx and a Rx with a 1Gbps link, 30ms RTT, 1500 bytes PDUs and header size equal to zero (negligible size in comparison to the data size).
How many data PDUs have to be “in-flight” for a channel utilization of 95%?
Transport Layer

102. Pr5: Control over T_PDU content
It was said that an application may choose UDP for a transport protocol as UDP offers finer application control (than TCP) of what data is sent in a segment, and when.
Why does an application have more control of what data is sent in a segment?
Why does an application have more control on when the segment is sent?
Transport Layer

103. Pr6
Suppose a client application protocol which is sending an only PDU of 1000 bytes, using transport reliable service. Server application replies with a 100 bytes PDU.
Make a diagram of TCP_PDU flow. Label active flags, point out seq numbers, ACK numbers, and the number of bytes of the TCP_DU. Also point out the size (bytes) of every TCP_PDU. Suppose there are no options for TCP, and initial sequence numbers (ISN) of 1000 for the client, and 3000 for the server.
Transport Layer

104. Pr7: MSS
Consider transferring an enormous file of L bytes from Host A to Host B. Assume a MSS of 536 bytes.
What is the maximum value of L, so that TCP sequence numbers are run out of? Recall that the TCP sequence number field has 4 bytes.
Note: MSS is the maximum size of user data carried by any segment in a TCP connection. In SYN segment, using TCP options header, each TCP entity informs the other about MSS. The smaller is used.
Transport Layer

105. Pr7: MSS (II)
For the value of L obtained in (a), how long does it takes to transmit the file?
Suppose that a total of 66 bytes of transport, network, and data-link header are added to each segment. The packet is sent out over a 155 Mbpslink. Ignore flow control and congestion control so A can pump out the segments back to back and continuously.
Transporte

106. Pr8.
Suppose that a client application protocol is sending an only PDU of 100 bytes using the reliable transport service on the internet. Server app replies with a 100-byte PDU.
Make a diagram of TCP_PDU flow. Label active flags, point out seq numbers, ACK numbers, and the number of bytes of the TCP_DU. Also point out the size (bytes) of every TCP_PDU. Suppose there are no options for TCP, and initial sequence numbers (ISN) are 0 at both client and server. MSS is 536.
Transporte

107. Pr9: seq # and ACK
Host A and B are using a TCP connection. Host B has already received from A bytes up to byte 126. Then, Host A sends two back-to-back segments to Host B. Both segments have 70 and 50 bytes of data, respectively. In the first segment, the sequence number is 127, the source port number is 302, and the destination port number is 80. Host B sends an acknowledgement whenever it receives a segment from Host A.
In the second segment sent from Host A to B, which are the sequence number, source port number, and destination port number?
Consider that the first segment arrives before the second segment. For the acknowledgement of the first arriving segment, which is the acknowledgment number, the source port number, and the destination port number?
Transport Layer

108. Pr9: seq # and ACK (II)
Now, consider that the first segment arrives before the second segment. For the acknowledgement of the first arriving segment, which is the acknowledgment number, the source port number, and the destination port number?
Suppose the two segments sent by A arrive in order at B. The first acknowledgement is lost and the second acknowledgement arrives after the first timeout interval. Draw a time diagram, showing all the segments and acknowledgements that were sent. (Assume there is no additional packet loss.) For each segment in your figure, provide the sequence number and the number of bytes of data; for each acknowledgement that you add, provide the acknowledgement number.
Transport Layer

109. Pr10: TCP flow control
Host A and B are directly connected with a 100 Mbps link.
There is a TCP connection between both hosts. Host A is sending an enormous file over this connection to Host B.
Host A can send its application data into its TCP socket at a rate as high as 120 Mbps
Host B can read out of its TCP receive buffer at a maximum rate of 60 Mbps.
Describe the effect of TCP flow control on host A’s application layer rate in sending data through its TCP socket.
Transport Layer

110. P11: estimated RTT
We discussed about TCP needs to estimate a value for RTT, in order to know how long it has to wait for an ACK.
To estimate the RTT, TCP uses SampleRTT values. SampleRTT is the time between a segment sending and the arrival of its ACK.
However, TCP does not use the SampleRTT associated to the retransmitted segments.
Why do you think TCP avoids measuring the SampleRTT for retransmitted segments?
Transport Layer

111. Pr12: variables in pipelining
What is the relationship between the variable SendBase of TCP transmitter and the variable LastByteRcvd of TCP receiver?
Transport Layer

112. Pr13: variables in pipelining
What is the relationship between the variable LastByteRcvd of TCP receiver and the variable y of TCP sender?
Transport Layer

113. Pr14: fast retransmission
TCP waits until it has received three duplicate ACKs before performing a fast retransmission.
When receiving three duplicate ACKs for a segment, TCP does a fast retransmission of the segment, as it is supposed lost. Retransmission does not waiting for timer expiring.
Why do you think the TCP designers chose not to perform a fast retransmission after the first duplicate ACK for a segment is received?
Transport Layer

114. Pr15: flow control
Host A is sending an huge file to Host B over a TCP connection.
Over this connection, no packet is loss and timers never expire.
Transmission rate of the link connecting Host A to the Internet is R bps.
Suppose that the process in Host A is capable of sending data into its TCP socket at a rate of S bps, where S = 10·R.
Furthermore, suppose that the TCP receiving buffer is large enough to hold the entire file. The sender’s buffer can hold only one percent of the file.
What would prevent the process in Host A from continuously passing data to its TCP socket at rate S bps? TCP flow control? TCP congestion control? Or anything else? Discuss it.
Transport Layer