Title: COMP361 Tutorial 6
1COMP361 Tutorial 6
2Chapter 3 Review
- Transport services
- rdt protocols
- GBN
- SR
3Transport Layer Services
- Provide logical communication between application
processes. - UDP vs. TCP
- UDP unreliable, unordered delivery
- Multiplexing/de-multiplexing function and light
error checking, nothing more to IP - multiplexing and demultiplexing is provided by
the 4-tuples, ltsource IP address, source port
number, destination IP address, destination port
numbergt. This uniquely identifies a communication
between a pair of processes on two end hosts. - TCP reliable, in-order delivery
- Flow control and congestion control
4More questions
- Problem Consider a TCP connection between host A
and host B. Suppose that the TCP segments
traveling from host A to host B have source port
number x and destination port number y. What are
the source and destination port number for
segment traveling from host B to host A? - Solution
- Source port number y and destination port number
x.
5More
- Problem Suppose Client A initiates a Telnet
session with server S. At about the same time,
client B also initiates a Telnet session with
server S. Provide possible source and destination
port numbers for - the segment sent from A to S.
- the segment sent from B to S.
- the segment sent from S to A.
- the segment sent from S to B.
- (Note that telnet uses port 23)
- If A and B are different hosts, is it possible
that the source port number in the segments from
A to S is the same as that from B to S? Yes - How about if they are the same host? No
6Example Checksum
- Problem UDP and TCP use 1's complement for their
checksums. suppose you have the following three
8-bit words 01010101, 01110000, 11001100. What
is the 1's complement of the sum of these words?
Show all work. Solution - One's complement 0 1 1 0 1 1 0 1.
7Example Checksum (Cond.)
- Problem With the 1's complement scheme, how does
the receiver detect errors? Is it possible that a
1-bit error will go undetected? How about a 2-bit
error? - Answer To detect errors, the receiver adds the
four words (the three original words and the
checksum). If the sum contains a zero, the
receiver knows there has been an error. All
one-bit errors will be detected, but two-bit
errors can be undetected (e.g., if the last digit
of the first word is converted to a 0 and the
last digit of the second word is converted to a
1).
8Summary of the protocols
- rdt1.0 all packets arrive correctly
- rdt2.0 all packets arrive, with possible errors
only in data packets, and introducing ACK and NAK
(no error) - rdt2.1 corrupted ACKS/NAKS
- rdt2.2 similar to rdt2.1 remove NAKs
- Rdt3.0 Allows packets to be lost and errors
9Rtd2.1 revised
SHOW that this receiver, when operating with the
sender shown in above figure, can lead the sender
and receiver to enter into a deadlock state,
where each is waiting for an event that will
never occur.
10rdt2.1 sender, handles garbled ACK/NAKs
rdt_send(data)
sndpkt make_pkt(0, data, checksum) udt_send(sndp
kt)
rdt_rcv(rcvpkt) ( corrupt(rcvpkt)
isNAK(rcvpkt) )
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
rdt_rcv(rcvpkt) ( corrupt(rcvpkt)
isNAK(rcvpkt) )
rdt_send(data)
sndpkt make_pkt(1, data, checksum) udt_send(sndp
kt)
udt_send(sndpkt)
11Rdt2.1 revised (Cond.)
- Answer
- Suppose the sender is in state "Wait for call 1
from above" and the receiver is in state "Wait
for 1 from below". The sender sends a packet with
sequence number 1, and transitions to "Wait for
ACK or NAK 1," waiting for an ACK or NAK. Suppose
now the receiver receives the packet with
sequence number 1 correctly, sends an ACK, and
transitions to state "Wait for 0 from below,"
waiting for a data packet with sequence number 0.
However, the ACK is corrupted. When the rdt2.1
sender gets the corrupted ACK, it resends the
packet with sequence number 1. However, the
receiver is waiting for a packet with sequence
number 0 and always sends a NAK when it doesn't
get a packet with sequence number 0. Hence the
sender will always be sending a packet with
sequence number 1, and the receiver will always
be NAKing that packet. Neither will progress
forward from that state.
12rdt2.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)
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)
13Rdt2.1 modification
- Consider a channel that can lose packets but has
a maximum delay that is known. Modify protocol
rdt2.1 to include sender timeout and retransmit.
Informally argue why your protocol can
communicate correctly over this channel. - Answer Here, we add a timer, whose value is
greater than the known round-trip propagation
delay. We add a timeout event to the "Wait for
ACK or NAK0" and "Wait for ACK or NAK1" states.
If the timeout event occurs, the most recently
transmitted packet is retransmitted. Let us see
why this protocol will still work with the rdt2.1
receiver. - Suppose the timeout is caused by a lost data
packet, i.e., a packet on the sender-to-receiver
channel. In this case, the receiver never
received the previous transmission and, from the
receiver's viewpoint, if the timeout
retransmission is received, it look exactly the
same as if the original transmission is being
received. - Suppose now that an ACK is lost. The receiver
will eventually retransmit the packet on a
timeout. But a retransmission is exactly the same
action that is take if an ACK is garbled. Thus
the sender's reaction is the same with a loss, as
with a garbled ACK. The rdt2.1 receiver can
already handle the case of a garbled ACK.
14rdt2.1 sender, handles garbled ACK/NAKs
rdt_send(data)
sndpkt make_pkt(0, data, checksum) udt_send(sndp
kt)
rdt_rcv(rcvpkt) ( corrupt(rcvpkt)
isNAK(rcvpkt) )
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
rdt_rcv(rcvpkt) ( corrupt(rcvpkt)
isNAK(rcvpkt) )
rdt_send(data)
sndpkt make_pkt(1, data, checksum) udt_send(sndp
kt)
udt_send(sndpkt)
15rdt3.0 sender
udt_send(sndpkt) start_timer
16Example rdt3.0
- Problem
- Draw a trace of the operation of protocol rdt3.0
when a data packet is garbled. - Draw a trace when an acknowledgement packet is
garbled.
17Pipelined protocols
- rdt3.0 stop-and-wait operation
- Low utilization fraction of time sender busy
sending - Two generic forms of pipelined protocols
go-Back-N, selective repeat
18Go-Back-N (GBN)
- Window size (N) is constant, which is the maximum
number of packets that a sender can send out
without receiving any acknowledgment. - This determines the link utilization
- Applet
19Receiver in GBN
- The receiver only delivers the packet that it is
expecting, i.e., the sequence number of the
packet is expectedseqnum - It will drop all out of order packets
- This is simple in that the receiver has no buffer
20Sender in GBN
- Sends packets with the sequence number in the
range of base, baseN, and the parameter
nextseqnum is updated - Keeps only one timer for all packets that has
been sent yet acknowledged - a timeout will trigger the sender to resend all
those packets - ACK(n) is received, which is cumulative
- i.e., indicating all packets up to n has been
received by the receiver. The parameter base is
updated, and a new timer is started if there are
still other packets transmitted but
unacknowledged.
21GBN in action
22Selective Repeat (SR)
- Individual packet acknowledgment as supposed to
the cumulative acknowledgement in GBN - Receiver buffers the out of order arrivals
23Receiver in SR
- Packet with the sequence number n in the range of
rcv_base, rcv_baseN-1 is correctly received,
send ACK(n), adjust parameter rcv_base and
deliver the packet to upper layer protocol if
necessary - Packet arrival with sequence number n rcv_base
N, rcv_base 1, ACK(n) - Otherwise, ignore
24Sender in SR
- Packet from upper layer with sequence number n
send_base, send_base N, send the packet and
start the timer for this packet - Timeout, resend the packet
- ACK received, mark the buffer as received and
update the parameter if necessary.
25SR in action