Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture...
-
date post
22-Dec-2015 -
Category
Documents
-
view
217 -
download
1
Transcript of Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture...
![Page 1: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/1.jpg)
Announcement
• Homework 1 due last night, how is that ?– Will discuss some problems in the lecture
next week
• Should have completed at least part II of project 1
• Homework 2 will be out next week
![Page 2: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/2.jpg)
Some slides are in courtesy of J. Kurose and K. Ross
Review of Previous Lecture
• Socket programming with TCP
• Socket programming with UDP
• I/O multiplexing
• Web caching
![Page 3: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/3.jpg)
Chapter 3: Transport LayerOur goals:
• understand principles behind transport layer services:– multiplexing/
demultiplexing– reliable data transfer– flow control– congestion control
• learn about transport layer protocols in the Internet:– UDP: connectionless
transport– TCP: connection-
oriented transport– TCP congestion control
![Page 4: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/4.jpg)
Outline
• Transport-layer services
• Multiplexing and demultiplexing
• Connectionless transport: UDP
• Principles of reliable data transfer
![Page 5: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/5.jpg)
Transport services and protocols
• 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
application
transportnetworkdata linkphysical
application
transportnetworkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysicalnetwork
data linkphysical
logical end-end transport
![Page 6: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/6.jpg)
Transport vs. network layer
• network layer: logical communication between hosts
• transport layer: logical communication between processes – relies on, enhances, network layer services
• On one host, there may be several processes communicating with processes on several other hosts, with different protocols
![Page 7: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/7.jpg)
Internet transport-layer protocols
• reliable, in-order delivery (TCP)– congestion control – flow control– connection setup
• unreliable, unordered delivery: UDP– no-frills extension of
“best-effort” IP
• services not available: – delay guarantees– bandwidth guarantees
application
transportnetworkdata linkphysical
application
transportnetworkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysicalnetwork
data linkphysical
logical end-end transport
![Page 8: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/8.jpg)
Outline
• Transport-layer services
• Multiplexing and demultiplexing
• Connectionless transport: UDP
• Principles of reliable data transfer
![Page 9: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/9.jpg)
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:
![Page 10: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/10.jpg)
How demultiplexing works
• Host receives IP datagrams– each datagram has source IP
address, destination IP address
– each datagram carries 1 transport-layer segment
– each segment has source, destination port number (recall: well-known port numbers for specific applications)
• Host uses IP addresses & port numbers to direct segment to appropriate socket
source port # dest port #
32 bits
applicationdata
(message)
other header fields
TCP/UDP segment format
![Page 11: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/11.jpg)
IP datagram format
ver length
32 bits
data (variable length,typically a TCP
or UDP segment)
16-bit identifier
Internet checksum
time tolive
32 bit source IP address
IP protocol versionnumber
header length (bytes)
max numberremaining hops
(decremented at each router)
forfragmentation/reassembly
total datagramlength (bytes)
upper layer protocolto deliver payload to
head.len
type ofservice
“type” of data flgsfragment
offsetupper layer
32 bit destination IP address
Options (if any) E.g. timestamp,record routetaken, specifylist of routers to visit.
how much overhead with TCP?
• 20 bytes of TCP
• 20 bytes of IP
• = 40 bytes + app layer overhead
![Page 12: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/12.jpg)
Connectionless demultiplexing
• 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
• IP datagrams with different source IP addresses and/or source port numbers directed to same socket
![Page 13: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/13.jpg)
Connectionless demux (cont)
ClientIP:B
P2
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”
![Page 14: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/14.jpg)
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– non-persistent HTTP will
have different socket for each request
![Page 15: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/15.jpg)
Connection-oriented demux (cont)
ClientIP:B
P2
client IP: A
P1P1P3
serverIP: C
SP: 80
DP: 9157
SP: 9157
DP: 80
SP: 80
DP: 5775
SP: 5775
DP: 80
P4
![Page 16: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/16.jpg)
Outline
• Transport-layer services
• Multiplexing and demultiplexing
• Connectionless transport: UDP
• Principles of reliable data transfer
![Page 17: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/17.jpg)
UDP: User Datagram Protocol [RFC 768]
• “no frills,” “bare bones” Internet transport protocol
• “best effort” service, UDP segments may be:– lost– delivered out of order to
app
• connectionless:– no handshaking
between UDP sender, receiver
– each UDP segment 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
• no congestion control: UDP can blast away as fast as desired
![Page 18: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/18.jpg)
UDP: more
• often used for streaming multimedia apps– loss tolerant– rate sensitive
• reliable transfer over UDP: add reliability at application layer– application-
specific error recovery!
source port # dest port #
32 bits
Applicationdata
(message)
UDP segment format
length checksumLength, in
bytes of UDPsegment,including
header
![Page 19: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/19.jpg)
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:
• addition of all segment contents + checksum
• check if all bits are 1:– NO - error detected– YES - no error detected.
But maybe errors nonetheless? More later ….
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
0110010110110100
Addition:1’s complement sum:
0110010101001111
1’s complement sum:Addition:
![Page 20: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/20.jpg)
Outline
• Transport-layer services
• Multiplexing and demultiplexing
• Connectionless transport: UDP
• Principles of reliable data transfer
![Page 21: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/21.jpg)
Principles of Reliable data transfer• Top-10 list of important networking topics!
• Characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)
![Page 22: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/22.jpg)
Reliable data transfer: getting started
sendside
receiveside
rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer
udt_send(): called by rdt,to transfer packet over unreliable channel to
receiver
rdt_rcv(): called when packet arrives on rcv-side of channel
deliver_data(): called by rdt to deliver data to
upper
![Page 23: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/23.jpg)
Reliable data transfer: getting started
We’ll:
• incrementally 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
![Page 24: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/24.jpg)
Rdt1.0: reliable transfer over a reliable channel
• underlying channel perfectly reliable– no bit errors– no loss of packets
• separate FSMs for sender, receiver:– sender sends data into underlying channel– receiver read data from underlying 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
![Page 25: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/25.jpg)
Rdt2.0: channel with bit errors• underlying channel may flip bits in packet
– recall: UDP 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 msgs (ACK,NAK) rcvr->sender
![Page 26: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/26.jpg)
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)
![Page 27: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/27.jpg)
rdt2.0: operation with no errors
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
below
rdt_send(data)
![Page 28: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/28.jpg)
rdt2.0: error scenario
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
below
rdt_send(data)
![Page 29: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/29.jpg)
rdt2.0 has a fatal flaw!
What happens if ACK/NAK corrupted?
• sender doesn’t know what happened at receiver!
• can’t just retransmit: possible duplicate
What to do?
• sender ACKs/NAKs receiver’s ACK/NAK? What if sender ACK/NAK lost?
• retransmit, but this might cause retransmission of correctly received pkt!
Handling duplicates:
• sender adds sequence number to each pkt
• sender retransmits current pkt if ACK/NAK garbled
• receiver discards (doesn’t deliver up) duplicate pkt
Sender sends one packet, then waits for receiver response
stop and wait
![Page 30: Announcement Homework 1 due last night, how is that ? –Will discuss some problems in the lecture next week Should have completed at least part II of project.](https://reader035.fdocuments.us/reader035/viewer/2022062516/56649d795503460f94a5cc9a/html5/thumbnails/30.jpg)
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