9/30/2003-10/2/2003 the transport layer september 30-october 2, 2003
Post on 22-Dec-2015
224 Views
Preview:
TRANSCRIPT
9/30/2003-10/2/2003
The Transport Layer
September 30-October 2, 2003
9/30/2003-10/2/2003
Assignments
• Homework 3– Chapter 3 review
• Finish 3.1-3.4
• Read 3.5-3.7 for next week
9/30/2003-10/2/2003
Transport Layer
• Goals– Understand transport layer services
• Multiplexing/demultiplexing• Reliable data transfer• Flow control• Congestion control
– Learn about Internet transport protocols• TCP – connection-oriented• UDP – connectionless
9/30/2003-10/2/2003
Transport Services
• 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
application
transportnetworkdata linkphysical
application
transportnetworkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysicalnetwork
data linkphysical
logical end-end transport
9/30/2003-10/2/2003
Transport Services
• Network layer– logical communication
between hosts
• Transport layer– logical communication
between processes – relies on, enhances,
network layer services
• No transport layer in the routers
application
transportnetworkdata linkphysical
application
transportnetworkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysicalnetwork
data linkphysical
logical end-end transport
9/30/2003-10/2/2003
Internet Transport Protocols
• TCP – reliable, in-order – congestion control – flow control– connection setup
• UDP – unreliable, unordered– error checking
• No delay or bw guarantees
application
transportnetworkdata linkphysical
application
transportnetworkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysicalnetwork
data linkphysical
logical end-end transport
9/30/2003-10/2/2003
Multiplexing/Demultiplexing
application
transport
network
link
physical
P1 application
transport
network
link
physical
application
transport
network
link
physical
P2P3 P4P1
host 1 host 2 host 3
= process= socket
delivering received segmentsto correct socket
Demultiplexing at rcv host:gathering data from multiplesockets, enveloping data with header (later used for demultiplexing)
Multiplexing at send host:
9/30/2003-10/2/2003
Multiplexing
• Transport layer takes the application message and creates a segment
• Why do I need both src and dest ports?
• What else might go in header?
source port # dest port #
32 bits
applicationdata
(message)
other header fields
TCP/UDP segment format
9/30/2003-10/2/2003
Demultiplexing
• Transport layer receives segment
• Uses port numbers (and sometimes IP addresses) to pass to appropriate socket
source port # dest port #
32 bits
applicationdata
(message)
other header fields
TCP/UDP segment format
9/30/2003-10/2/2003
Connectionless Demultiplexing
• Create sockets with port numbers
DatagramSocket mySocket1 = new DatagramSocket(99111);– This is port for client – how do I
choose the port number?
• UDP socket identified by two-tuple
(dest IP address, dest port number)
• When host receives UDP segment:– checks destination port
number in segment– directs UDP segment
to socket with that port number
• All datagrams with same dest IP and port are directed to same socket
9/30/2003-10/2/2003
Connectionless Demux
DatagramSocket serverSocket = new DatagramSocket(6428);
ClientIP:B
P3
client IP: A
P1P1P3
serverIP: C
SP: 6428
DP: 9157
SP: 9157
DP: 6428
SP: 6428
DP: 5775
SP: 5775
DP: 6428
SP provides “return address”
9/30/2003-10/2/2003
Connection-Oriented Demux
• TCP socket identified by 4-tuple: – source IP address– source port number– dest IP address– dest port number
• Recv host uses all four values to direct segment to appropriate socket
• Server host may support many simultaneous TCP sockets:– each socket identified
by its own 4-tuple
• Web servers have different sockets for each connecting client
9/30/2003-10/2/2003
Connection-Oriented Demux
ClientIP:B
P3
client IP: A
P1P1P3
serverIP: C
SP: 80
DP: 9157
SP: 9157
DP: 80
SP: 80
DP: 5775
SP: 5775
DP: 80
P4
9/30/2003-10/2/2003
UDP: User Datagram Protocol
• Mux/Demux• Light error checking
• DNS uses UDP – why?
• Characteristics of UDP applications?
Why is there a UDP?
9/30/2003-10/2/2003
UDP: User Datagram Protocol
• Mux/Demux• Light error checking
• DNS uses UDP – why?
• Characteristics of UDP applications?
• Why is there a UDP?– no connection
establishment (which can add delay)
– simple: no connection state at sender, receiver
– small segment header– no congestion control: UDP
can blast away as fast as desired
• Reliable UDP?
9/30/2003-10/2/2003
UDP Header
• Length – length of UDP segment
• Checksum – error detection – Send some extra
information – rcvr uses to determine whether a bit has been flipped
source port # dest port #
32 bits
Applicationdata
(message)
UDP segment format
length checksum
9/30/2003-10/2/2003
UDP Checksum
Sender• treat segment contents as
sequence of 16-bit integers
• checksum: addition (1’s complement sum) of segment contents
• sender puts checksum value into UDP checksum field
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?
9/30/2003-10/2/2003
Checksum Example
0110011001100110
0101010101010101
----------------------------
1011101110111011
0000111100001111
----------------------------
1100101011001010
0011010100110101 (Checksum)
0110011001100110
0101010101010101
----------------------------
1011101110111011
0000111100001111
----------------------------
1100101011001010
0011010100110101
----------------------------
1111111111111111
9/30/2003-10/2/2003
Reliable Data Transfer
• No bits Corrupted• No bits lost• Bits delivered in-order
9/30/2003-10/2/2003
Getting Started• Develop sender, receiver sides of reliable
data transfer protocol (rdt)• Consider only unidirectional data transfer
– but control info will flow on both directions!
• Use finite state machines (FSM) to specify sender, receiver
state1
state2
event causing state transitionactions taken on state transition
state: when in this “state” next state
uniquely determined by next event
eventactions
9/30/2003-10/2/2003
rdt1.0: Reliable Transfer over Reliable Channel
Wait for call from above packet = make_pkt(data)
udt_send(packet)
rdt_send(data)
extract (packet,data)deliver_data(data)
Wait for call from
below
rdt_rcv(packet)
sender receiver
9/30/2003-10/2/2003
rdt2.0: Channel with Bit Errors
• Underlying channel may flip bits in packet
• What does the protocol need to do?
9/30/2003-10/2/2003
rdt2.0: Channel with Bit Errors
• Underlying channel may flip bits in packet
• What does the protocol need to do?– Error detection– Receiver feedback– Retransmission
9/30/2003-10/2/2003
Techniques
• Error detection– Remember UDP
• Receiver feedback– ACK – “Yeah, that came through OK”– NAK – “Can you repeat that?”– ACK/NAK tradeoffs?
• Retransmission– ARQ – sender retransmits packet(s) in error
9/30/2003-10/2/2003
rdt2.0: FSM specification
Wait for call from above
snkpkt = make_pkt(data, checksum)udt_send(sndpkt)
extract(rcvpkt,data)deliver_data(data)udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Wait for ACK or
NAK
Wait for call from
belowsender
receiverrdt_send(data)
9/30/2003-10/2/2003
rdt2.0
• Stop-and-Wait– Sender sends one packet, then waits for
receiver response
• Flaw – what if ACK/NAK is corrupt?– ACK/NAK the ACK/NAK– Error correction– Resend data packet
9/30/2003-10/2/2003
Handling Duplicate Packets
• Sequence Number– Lets the receiver know if the packet is a
duplicate
9/30/2003-10/2/2003
rdt2.1: Sender Handles Garbled ACK/NAKs
Wait for call 0 from
above
sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)
rdt_send(data)
Wait for ACK or NAK 0 udt_send(sndpkt)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )
sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)
rdt_send(data)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)
Wait for call 1 from
above
Wait for ACK or NAK 1
9/30/2003-10/2/2003
rdt2.1: Receiver Handles Garbled ACK/NAKs
Wait for 0 from below
sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)
extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
Wait for 1 from below
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)
sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)
9/30/2003-10/2/2003
rdt2.1: Discussion
• Sender– seq # added to pkt– two seq. #’s (0,1) will
suffice. Why?– must check if received
ACK/NAK corrupted – twice as many states
• state must “remember” whether “current” pkt has 0 or 1 seq. #
• Receiver– must check if received
packet is duplicate• state indicates whether
0 or 1 is expected pkt seq #
– note: receiver can not know if its last ACK/NAK received OK at sender
9/30/2003-10/2/2003
rdt2.2: A NAK-free Protocol
• Why go NAK-free?• Instead of NAK, send ACK for last packet
received• When sender receives duplicate ACK –
retransmit
9/30/2003-10/2/2003
rdt2.2: Sender, Receiver Fragments
Wait for call 0 from
above
sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)
Wait for ACK
0
sender FSMfragment
Wait for 0 from below
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)
extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK1, chksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt))
udt_send(sndpkt)
receiver FSMfragment
9/30/2003-10/2/2003
rdt3.0: Channels with Errors and Loss
• Channel can lose packets• Approach: sender waits “reasonable” amount of
time for ACK – retransmits if no ACK received in this time
• If pkt (or ACK) just delayed (not lost)– retransmission will be duplicate, but use of seq. #’s
already handles this– receiver must specify seq # of pkt being ACKed
• Requires countdown timer
9/30/2003-10/2/2003
rdt3.0 in Action
9/30/2003-10/2/2003
rdt3.0 in Action
9/30/2003-10/2/2003
Performance of rdt3.0
• Alternating Bit Protocol
• Poor utilization
9/30/2003-10/2/2003
rdt3.0: stop-and-wait operation
first packet bit transmitted, t = 0
sender receiver
RTT
last packet bit transmitted, t = L / R
first packet bit arriveslast packet bit arrives, send ACK
ACK arrives, send next packet, t = RTT + L / R
U sender
= .008
30.008 = 0.00027
microseconds
L / R
RTT + L / R =
9/30/2003-10/2/2003
Pipelining• Pipelining – sender allows multiple, “in-
flight”, yet-to-be-acknowledged pkts– range of sequence numbers must be increased– buffering at sender and/or receiver
9/30/2003-10/2/2003
Increased Utilizationfirst packet bit transmitted, t = 0
sender receiver
RTT
last bit transmitted, t = L / R
first packet bit arriveslast packet bit arrives, send ACK
ACK arrives, send next packet, t = RTT + L / R
last bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK
U sender
= .024
30.008 = 0.0008
microseconds
3 * L / R
RTT + L / R =
Increase utilizationby a factor of 3!
9/30/2003-10/2/2003
Pipelined Protocols
• Go-Back-N– If timeout occurs, resend ALL outstanding
packets
• Selective Repeat– Retransmit only packets that were lost or
received in error
9/30/2003-10/2/2003
Go-Back-N
Sender• k-bit seq # in pkt header• “window” of up to N, consecutive unack’ed pkts allowed• ACK(n): ACKs all pkts up to, including seq # n – cumulative ACK
• timer for each in-flight pkt• timeout(n): retransmit pkt n and all higher seq # pkts in
window
9/30/2003-10/2/2003
GBN
Receiver
• Always send ACK for correctly-received pkt with highest in-order seq #– may generate duplicate ACKs– need only remember expectedseqnum
• Out-of-order pkt: – discard (don’t buffer) – isn’t this bad?– Re-ACK pkt with highest in-order seq #
9/30/2003-10/2/2003
GBN Example
9/30/2003-10/2/2003
Selective Repeat
• Receiver individually acknowledges all correctly received pkts– buffers pkts, as needed, for eventual in-order delivery
to upper layer
• Sender only resends pkts for which ACK not received– sender timer for each unACKed pkt
• Sender window– N consecutive seq #’s– again limits seq #s of sent, unACKed pkts
9/30/2003-10/2/2003
Selective repeat: sender, receiver windows
9/30/2003-10/2/2003
Selective Repeat
Sender• Receive data from app
– if next available seq # in window, send pkt
• timeout(n)– resend pkt n, restart timer
• ACK(n) in [sendbase,sendbase+N]:– mark pkt n as received– if n smallest unACKed pkt,
advance window base to next unACKed seq #
Receiver• Received pkt n in [rcvbase, rcvbase+N-1]
– send ACK(n)– out-of-order: buffer– in-order: deliver (also deliver
buffered, in-order pkts), advance window to next not-yet-received pkt
• Received pkt n in [rcvbase-N,rcvbase-1]
– ACK(n)– Why???
• Otherwise – ignore
9/30/2003-10/2/2003
Selective repeat in action
9/30/2003-10/2/2003
Window size vs Sequence Number Space
top related